Beginner of WordPress Plugin Development: Using WordPress Plugin Boiler

WordPress plug-in development has a low learning curve and there is no only way to build plug-ins. Plugins can be as simple as Hello Dolly, just a single file; they can also be built in a very complex way based on various needs and functions. The WordPress plugin boilerplate is designed to provide a standardized, high-quality foundation that helps you build your next great plugin. In the first part of this series, we will explore the boilerplate in depth, including the structure of files and folders, as well as the code organization of the boilerplate.

Key Points

• WordPress plugin boilerplate provides a standardized, high-quality foundation for building WordPress plugins, with a low learning curve, and can be flexibly used for simple or complex plugin structures.
• The 3.0.0 version of the boilerplate has brought significant improvements in the separation of code organization and internal concerns between plug-ins and can be easily obtained by cloning the git repository or downloading zip files from the GitHub repository.
• The boilerplate follows recommended WordPress coding and documentation standards, provides useful starter guides and tool recommendations, and includes five default classes for a variety of features, making it an excellent starting point for plugin developers.

Background

The WordPress plugin boilerplate was originally initiated by Tom McFarlin to provide a standardized object-oriented approach to building WordPress plugins. Because boilerplate is built on top of the plug-in API and follows the coding and documentation standards recommended by WordPress, you can be sure that you are in a safe and reliable environment. The boilerplate has recently been updated to version 3.0.0, bringing significant improvements in code organization and further separation of internal focus of plugins. If you are already familiar with developing plugins with legacy boilerplate (v2.6.2), it may take some time to relearn what’s new in the latest version, including the new folder structure. This boilerplate is no longer maintained by Tom McFarlin himself (at the time of writing), and he has passed the baton to Devin Vinson. Development is still continuing as planned, so feel free to report it in your GitHub repository if you have any questions. We also welcome your contribution.

Get a template copy

The easiest way to get a boilerplate copy of the WordPress plugin is to clone the git repository itself.

<code>git clone https://github.com/DevinVinson/WordPress-Plugin-Boilerplate.git</code>

Or you can always download zip files from your GitHub repository. Since version 3.0.0 is released, you cannot simply copy the plugin directly into your wp-content/plugins directory. This is because the actual source code of the plugin is not included in the root directory, but is actually in a subdirectory called trunk. Don't worry about this now, we'll discuss the new folder structure later in this article. The README.md file details a complete description of how to properly install the boilerplate. In short, you can:

• Copy the trunk directory to the wp-content/plugins folder
• Copy the entire boilerplate directory and create a symbolic link to wp-content/plugins// for the trunk subdirectory. Creating a symbolic link will depend on the operating system you are using.

After you have done this, you should now find a plugin called WordPress Plugin Boilerplate in the list of plugins in the admin panel, assuming you have not made any modifications to the boilerplate itself. Just activate the plugin and get started!

Customize plug-in with online generator

When activated, you will have a "normal" plugin that basically does nothing -- at least for now. You also need to run search and replace operations on the entire boilerplate code base, which can be very tedious and time-consuming. Fortunately, Enrique Chavez created an unofficial generator that automates the process. Simply visit http://www.miracleart.cn/link/6340831392e9cd8af9598274f4b3c5c0 and fill in the form at the bottom of the page to generate a personalized copy of the WordPress plugin template.

Folder structure

Let's take a closer look at how WordPress plugin boilerplate 3.0.0 is organized compared to older versions. As mentioned earlier, the actual plugin code is contained in a subdirectory called trunk, not in the root directory. This is to follow the standards used in the official WordPress plugin repository, which contains three main directories: assets, branches, and trunk. The boilerplate already provides two of them: assets and trunk. Here are the complete directories and files included in the boilerplate (at the time of writing):

<code>git clone https://github.com/DevinVinson/WordPress-Plugin-Boilerplate.git</code>

The following is a brief description of the functions of each file and folder:

• .gitignore: Provides a reasonable default .gitignore for most content that should not exist in the git repository.
• CHANGELOG.md: Standard change log for boilerplate changes, including the change date.
• README.md: A useful starter with the installation instructions listed, along with some other parts such as tool recommendations and acknowledgments.
• assets: This directory contains recommended resources you need to provide when you decide to publish the plugin to the WordPress plugin repository. All images contained in this directory are of the recommended resolution for publication.
• trunk: This is the actual plugin you are going to develop. There are some folders that divide the code base into administrative and public-facing features. We will explain in detail what each subdirectory means.
  • admin: The directory contains three directories, namely admin, css and js. As the name implies, all management-oriented features should be placed here. By default, partials and plugin-name-admin.js are added to your wp-admin. plugin-name-admin.css will provide common features where you can define management-specific hooks. class-plugin-name-admin.php
  • : This directory is very similar to the functionality provided by the public directory, the only difference is that the admin directory is used to store all public-facing functional code bases. public
  • : A starting languages file where you can provide translation functionality for plugins. .pot
  • : This is probably where almost everything magic happens. By default, there are five starting classes, which we will discuss in the next section. includes
  • : Contains a copy of the GPL v2 license by default. LICENSE.txt
  • : The starting point of the plug-in README file. This file covers all sections that you can further fill in to provide a good plugin page in the WordPress plugin repository. README.txt
  • : The entry point of the plug-in. Here, a common plugin file header is included that you can modify according to your preferences. If you need to include a feature when the plugin is activated and/or deactivated, plugin-name.php and register_activation_hook will also be registered in this file. register_deactivation_hook

Included classes

directory. Let's see what each class does: trunk/includes

• class-plugin-name-activator.php: This class is instantiated during plug-in activation. It has only one static method activate(), which is registered to register_activation_hook. Use this class whenever you need to perform certain actions when the plugin is activated, such as creating a custom table or saving default options.
• class-plugin-name-deactivator.php: The corresponding category of class-plugin-name-deactivator.php. It also has only one static method deactivate() that can be used to run any feature during plugin deactivation.
• class-plugin-name-i18n.php: The starting point of the plug-in i18n function. It has a property $domain that stores plugin text fields. This property can be set using the public method set_domain(). Finally, whenever the plugin is loaded, the load_plugin_textdomain() method in this class is called.
• class-plugin-name-loader.php: The most important class in the template. It contains two properties $actions and $filters, where all hooks registered in the plugin will be stored. It provides two simple wrapper functions add_action() and add_filter() for adding an action or filter to the $actions and $filters properties. This is not to be confused with WordPress's default add_action() and add_filter() functions, because such classes do not actually register them directly. All hooks will only be registered during another method called run().
• class-plugin-name.php: A class that glues all parts together. It contains important information about the plugin, such as the plugin name and version. Additionally, it will load the dependencies using the load_dependencies() method, which will contain the above four classes, and the plugin text field will be set using the set_locale() method. All administrative and public hooks registered previously can also be defined here. This class also provides simple get methods such as get_plugin_name() to return the plugin name, get_version() to return the current plugin version, and get_loader() to preserve the instance of class-plugin-name-loader.php.

Conclusion

In short, WordPress plugin boilerplate provides a great starting point for plugin developers. It follows the recommended WordPress coding standards as well as WordPress documentation standards, so you know you're on the right path from the start. Additionally, publishing to a WordPress plugin repository becomes easier because boilerplate already provides most of what you need. Once we are familiar with the code organization and folder structure, we will explore how to develop actual plugins using WordPress plugin boilerplate in the second part of this series.

The above is the detailed content of Speed up Development Using the WordPress Plugin Boilerplate. For more information, please follow other related articles on the PHP Chinese website!