WordPress Plugin Boilerplate, Part One

Share on facebook
Facebook
Share on twitter
Twitter
Share on reddit
Reddit
Share on linkedin
LinkedIn

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.

More to explore

Photo by Artem Sapegin on Unsplash

2 Must-Have Tools for WordPress Development

There are some exceptional tools that can be used for WordPress development that make the process way easier than it would be otherwise. I didn’t know about some of these early on in my WordPress development days, so for those of you who might not be familiar with them, I’d like to share.

Photo by Caspar Camille Rubin on Unsplash

Getting WP Post and Postmeta in Single Rows

WordPress uses wp_posts to store post, page, and Custom Post Type (CPT) data the wp_postmeta table for Custom Metabox data. To retrieve this data you have to read for the post plus multiple linked postmeta rows. In this post, we conquer postmeta with subqueries.

Using Redis with WordPress on Ubuntu

Redis is “an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams.” Translation? It makes websites run faster.

Leave a Comment

Your email address will not be published. Required fields are marked *