With over 50K packages in the WordPress.org plugin repository – all open source – the code within these plugins is all over the place. Getting a plugin hosted with WordPress just isn’t that difficult, and everyone from well-meaning amateurs to professional software development companies are represented. Each have their own coding styles and development standards (or lack thereof) and there are brilliant examples of stellar code and, well, examples of what not to do.
Into this picture enter the WordPress Plugin Boilerplate. In their own words, the Boilerplate is “a standardized, organized, object-oriented foundation for building high-quality WordPress Plugins.” According to the maintainers, it “follows both the coding standards and the documentation standards” set forth by WordPress for plugin development. This should make the developer’s job much easier, and the more it gets used, the better able we’ll all be to follow one another’s code.
Not only can you access the Boilerplate’s code on Github, you can also use the generator to create a zip file of the Boilerplate with your plugin’s name and basic info already inserted. So all you have to do is download it and get started.
But… how do you use this darn thing?! There doesn’t appear to be a lot of “getting started” documentation, at least not that we were able to find when we started playing around with it. So we thought we’d try and help out with that.
Basic Concepts
The Boilerplate code is 100% object-oriented; everything is handled with classes. As with any WordPress plugin, there is a file in the root folder with the same slug-name as your plugin, and it contains the comment section required by WordPress (plugin name, version, author, description, etc.) It has a function for plugin activation and deactivation, and ends by instantiating the main class and running itself:
function run_myplugin() {
$plugin = new MyPlugin();
$plugin->run();
}
run_myplugin();
If you’re familiar with WordPress plugin development, you know that everything happens via hooks and filters. Accommodating this, the real “running” of your plugin happens in a different spot. (More on that later.)
Boilerplate Structure
With WordPress plugins, you have two main sections to think about: what your plugin does on the front-end (i.e. things that get displayed to site visitors) and the options and settings available to logged in users via the WordPress dashboard.
Within the root folder of a Boilerplate plugin, there are three subfolders: includes, admin, and public. As you may have already guessed, “admin” is the section for things that live in the dashboard, and “public” is where all the front-end stuff lives.
The “includes” section is sort of the linchpin; it binds it all together. It starts with “class-myplugin.php,” which, among other things, brings in the other default “includes” files:
- class-myplugin-activator.php
- class-myplugin-deactivator.php
- class-myplugin-i18n.php
- class-myplugin-loader.php
Not surprisingly, the *activator.php and *deactivator.php files will contain your plugin’s on-activation and -deactivation code. The *i18n.php file is for internationalization.
The *loader.php file – a file you’ll probably not need to edit – gets called from the main file (“class-myplugin.php”) when you’re registering the aforementioned hooks. These calls look a bit like this:
/**
* Register all of the hooks related to the admin area functionality
* of the plugin.
*
* @since 1.0.0
* @access private
*/
private function define_admin_hooks() {
$plugin_admin = new MyPlugin_Admin( $this->get_plugin_name(), $this->get_version() );
$this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_styles' );
$this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_scripts' );
}
/**
* Register all of the hooks related to the public-facing functionality
* of the plugin.
*
* @since 1.0.0
* @access private
*/
private function define_public_hooks() {
$plugin_public = new MyPlugin_Public( $this->get_plugin_name(), $this->get_version() );
$this->loader->add_action( 'wp_enqueue_scripts', $plugin_public, 'enqueue_styles' );
$this->loader->add_action( 'wp_enqueue_scripts', $plugin_public, 'enqueue_scripts' );
}
Remember, everything that happens in a WordPress plugin starts via action hooks and filters; with the Boilerplate, all of those hooks and filters get registered here. Thus, at a glance, someone reading the code for the first time can see those important points at which your plugin engages its own actions.
In the next couple of posts in this series, we’ll go deeper into how we can use the WordPress Plugin Boilerplate to make our development lives cleaner, more consistent, and – of course – easier.