A few years ago, I started the WordPress Plugin Boilerplate project as nothing more than a GitHub repository used to store code that I found myself frequently using in both personal and client projects.
As I became more involved with WordPress, as I began to build more plugins for fun and profit, and as I began updating the repository, it grew into something a little more than I had expected.
Over time, people began to open issues, offer pull requests, perform code reviews, and create their own forks of the project. I learned a lot over the next few years, and I honestly couldn’t be more excited to see such a little project become, you know, such a slightly less little project.
Months ago, I mentioned that work on the next iteration of the WordPress Plugin Boilerplate was started and I’m excited to announce that, as of today, the WordPress Plugin Boilerplate 3.0.0 is officially ready for use.
And it comes with a lot of new and neat things to boot.
An All New WordPress Plugin Boilerplate
As of this version, there are a number of new things and major changes all of which I’m excited to share (though I know we’ve all got limited time to so I’m going to keep this as brief as possible).
First, the project now has an official homepage. This is the first step to making the project more accessible to those who are just jumping into the foray of writing WordPress plugins.
There are more plans for the site: I’d love to create an area for documentation, frequently asked questions, perhaps a community forum, and more. I certainly don’t plan on leaving it as a single page for long – but this is the first step.
A Total Rewrite
As mentioned throughout several previous blog posts, the Boilerplate underwent a complete rewrite. This means the project started at ground zero and was built upwards from there.
So what does this look like?
As you can see, the project itself includes its own
ChangeLog and then the rest of the project is broken down into two directories:
For anyone who as submitted a plugin to the WordPress plugin repository, then you’re familiar with the standard Subversion directory structure. The Boilerplate now mimics that.
assets directory contains placeholders for plugin headers, plugin icons (which are a new addition coming in WordPress 4.0), and a screenshot that corresponds to the contents of the plugin’s
trunk contains the actual Boilerplate source code. This is a functioning plugin that can be installed and run within WordPress all of which I talk more about momentarily.
The directory structure of
trunk has changed a bit since this previous version of the Boilerplate. Ultimately, the goal was to create better file organization, a better class architecture, and generally a more organized approach to working with plugins.
- `admin` is used for all dashboard-specific functionality
- `includes` is used for all shared functionality either as part of the core of the plugin or for a third-party library
- `languages` are where the i18n files are kept
- `public` is where all public-facing functionality is kept
Naturally, there are subdirectories to each of these directories, as well; however, rather than spend time going through each and every file, you can read the comments contained in each one to get an idea as to how they all work together.
This means that the Boilerplate no longer uses the
TODO placeholders. Instead, the comment blocks explain exactly what’s going on and are left for you to change the content during implementation of your work.
There are a number of classes that are located in the
includes directory such as the activator, deactivator, and more. But the newest addition to the project is The Loader (in context of the Boilerplate, this class is called
The goal of this file is to encapsulate the registration of hooks and then execute both actions and filters at the appropriate time when the plugin is loaded.
Based on the feedback I’ve gotten, this particular class is the one thing that’s resulted in people asking the most questions, sharing that they aren’t sure how they feel about, sharing that they dislike it, and sharing that they love it.
Such is the nature of programming.
Regardless, this helps to easily manage hooks throughout the plugin as you’re working on your code, and you can trust that everything will be registered with WordPress just as you would expect.
Up To Standards
One of the things that I think we should all be doing is adhering to the WordPress Coding Standards and the Inline Documentation Standards. To that end, the Boilerplate has come done the best possible job at attempting to adhere to both of those.
If you find something that needs changing or think something needs to be removed, issue a pull requests, I’ll review, and I’ll be happy to merge.
Ultimately, the point is to get more people using the standards as defined in the Codex to write more WordPress-specific and maintainable code.
Projects like this are rarely done alone and this is no exception.
Their opinions, contributions, and overall backing in this project helped drive it to the point that it is today.
Notice also that the project has its own branding including colors and a logo. I have Rob McCaskill of BungaWeb to thank for lending his talents on creating the Boilerplate. I basically said that I was interested in something that was steampunk, vintage Americana, and a bit more modern and he delivered.
Mickey Kay is also responsible for creating a small set of icons one of which is used as the plugin’s favicon.
And, naturally, I thank everyone who has opened issues, contributed pull requests, and helped out in whatever capacity.
Yes, there’s still a lot that I want to do around this project, but I’m really excited to start fresh, to see where this goes, and to continue building out the Boilerplate in order to make it the best place to start building plugins for those who are just getting into object-oriented WordPress plugin development.