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.
PLUGIN HEADER
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:
<?php /** * Plugin Name: My Plugin * Plugin URI: https://example.com/plugins/pdev * Description: A short description of the plugin. * Version: 1.0.0 * Requires at least: 5.3 * Requires PHP: 5.6 * Author: John Doe * Author URI: https://example.com * License: GPL v2 or later * License URI: https://www.gnu.org/licenses/gpl-2.0.html * Text Domain: pdev * Domain Path: /public/lang */
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.
<?php /* Copyright (C) <year> <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */
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.
DETERMINING PATHS
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
