Professional WordPress Plugin Development. Brad Williams
Чтение книги онлайн.

Читать онлайн книгу Professional WordPress Plugin Development - Brad Williams страница 15

Название: Professional WordPress Plugin Development

Автор: Brad Williams

Издательство: John Wiley & Sons Limited

Жанр: Программы

Серия:

isbn: 9781119666936

isbn:

СКАЧАТЬ following is an example of how a plugin folder structure may be organized. Some of the files in this list are covered later in this chapter.

       plugin.php: Primary plugin file

       uninstall.php: Uninstall file

       /src: PHP source codeActivator.php: Activation classDeactivator.php: Deactivation classPlugin.php: Primary plugin class

       /resources: Development asset files

       /css: Development CSS/js: Development JavaScript

       /public: Production asset files/css: Production CSS/js: Production JavaScript

      This is a clean structure that will help you maintain your plugin code over time. You may choose a different structure for your own projects.

      NOTE The most important thing is consistency. In a professional environment, more than one developer will often be working on code, so it's important that your team understands where to find and edit code.

      When using namespaces as described in the “Namespace Everything” section of this chapter, it is standard practice to have a folder structure that matches how your namespaces and subnamespaces are set up so that it is easy to autoload the files using a system that follows the PHP‐FIG autoloading standard (https://www.php-fig.org/psr/psr-4).

      With a fully qualified class name of PDEV\Post\Edit, you'd have the following structure within your /src folder:

       /Post: SubnamespaceEdit.php: Class file

      Following this structure will tie your code and namespace structure directly to your folder structure. It makes it simple for you and other developers to navigate your project's files and folders by just looking at the namespace and class name.

      This is the standard used by the larger PHP community and has been for many years. Much of the WordPress community is still light‐years behind in following this standard, but it is beginning to catch on with more and more plugin developers.

      For WordPress to recognize a plugin, the plugin's primary PHP file must have what's called a plugin header at the top of the file. This tells WordPress that this particular file is the file that it must load to your plugin. WordPress plugins can be and do anything, but this is the only hard requirement for a plugin to function.

      Creating the Header

      The plugin header is nothing more than a normal PHP inline code comment with some special formatting that WordPress can recognize. The following is an example of a plugin header:

      Each line is called a header file and provides some info to WordPress about your plugin. The only required field for the plugin to work is the Plugin Name field. Each field should be straightforward to understand. The following is a brief description of what each field sets:

       Plugin Name: The name for your plugin

       Plugin URI: A URI with more information about your plugin

       Description: A brief summary that describes what your plugin does

       Version: The current version of your plugin, which should be incremented with each update

       Requires at least: The minimum version of WordPress required for your plugin to work

       Requires PHP: The minimum version of PHP required for your plugin to work

       Author: Your or your team/business name

       Author URI: The link to your website

       License: The license that the plugin is distributed under

       License URI: A link to the full text of the license

       Text Domain: The text domain used for internationalizing your plugin (see Chapter 11 for more information)

       Domain Path: The relative path to where translation files are located in your plugin

       Network: An optional field that can be set to true for plugins that can only be activated across the entire network on a multisite installation

      Plugin License

      When distributing your plugin to others, it's important to have a clear license so that you both protect your own copyright and make sure anyone who receives your plugin has a clear understanding of what their rights are. WordPress is licensed under the GNU General Public License (GPL), version 2 or later. Any plugins distributed should use a license that is compatible with the GPL.

      The GPL recommends placing the following copyright notice in every source file for your plugin. However, most plugins only place this after the plugin header in the primary plugin file.

      You need to replace the <year> and <name of author> snippets in that notice with the year the code was created and your name. Once you add the notification to your plugin file(s), it will then be licensed under the GPL.

      If working with a client or employer and not distributing the plugin to the public in any way, your plugin may not need a license. Copyright and/or license should be determined by your contract and what you and your client/employer agree to.

      Perhaps one of the toughest hurdles to jump when building WordPress plugins is simply figuring out the appropriate path when loading or referencing a file. Because you as a plugin developer do not control how the user chooses to set up their WordPress installation, you cannot rely on a specific pattern.

      Plugin Paths

      There are two types of paths that you might be concerned with when building СКАЧАТЬ