In 2011, I released the first version of the WordPress Plugin Boilerplate and have been maintaining it (along with contributions from other programmers) ever since.

Over the last couple of years, the Boilerplate became quite active – as far as very small projects are concerned – with issues, pull requests, and so on. It’s been a lot of fun to maintain, and it’s been really neat to receive so much feedback from other developers in terms of making the Boilerplate more resilient and from those who were just getting started with plugin development.

Earlier this year, I shared that I – along with a small group of other people – began working on the next iteration of the WordPress Plugin Boilerplate. That is, we were initiating a complete rewrite of the project.

As of today, I’m officially launching a beta of sorts of 3.0.0 of the Boilerplate. This is a major rewrite and refactoring of the Boilerplate in the state that its had for the past few years, and there’s a lot of change coming not only to the Boilerplate itself, but to new site, documentation, forks, and so on.

On Deck For The WordPress Plugin Boilerplate

Before going into the details about how the beta is going to be treated, I want to share a few things that are planned for the final release of this version of the plugin.

An Official Logo

Earlier this year, I shared that the project didn’t really have a brand and that was something I was looking to change with this release.

An early sketch of the Boilerplate's logo.

An early sketch of the Boilerplate’s logo.

I received some really great feedback from a lot of people and ultimately have Kevin Grennan at Bunga Web to thank for the logo. I am excited to show off the official logo when the Boilerplate is officially launched early next month.

A Website

Another addition to the Boilerplate is the introduction of an official website. Right now, the current project has nothing but a GitHub repository with a relatively extensive README file and various code comments to help guide users, but there’s not really any official documentation.

A working copy of the WordPress Plugin Boilerplate landing page.

A working copy of the WordPress Plugin Boilerplate landing page.

With this release, that’s going to change. Aside from having the core project its be simplified, the website is going to serve not only as landing page for the project, but will also include documentation, frequently asked questions, “how to” articles (along with gists gists), and so on.

Ultimately, the goal is to set up the site such that some of the more advanced functionality that or some of the code that’s not really relevant to starting off a plugin is still contained in documentation that can be easily added the existing foundation of the Boilerplate.

A Change in Focus

As previously mentioned, one of the biggest changes that’s coming to the Boilerplate is the simplification and removal of a lot of the code.

The goal isn’t to completely get rid of some of the functionality – such as the Multisite-specific code – that existed in the Boilerplate, but to make it available via other avenues on the website.

Ultimately, I’d like the Boilerplate to be a skeleton off of which anyone and everyone who writes a plugin and needs a starting point can use it as a point of reference. Not everyone uses a Multisite installation, so that’s why code such as that is being moved elsewhere.

Additionally, the plugin has been restructured in an attempt to improve the cohesion of each aspect of the plugin. It now has dedicated areas for the dashboard, shared code, and for public-facing functionality. On top of that, there are also some new classes (like the activator classes and the loader) that help to de-couple code and make sure that each class is focused on performing a single job.

The Forks

One of the challenges of the current version of the Boilerplate is making sure that it has all of the necessary functionality and flexibility for any type of plugin, but also has various options for those who use tools use as Composer or Grunt.

As the project moves forward, I’m looking for others to create several official forks (or “Editions” for those who are less familiar with open source terminology) of the project each of which has a specific focus. That is, there may be an edition for Multisite projects, an edition for those who use Composer, an edition fork for those who want to use newer PHP features (that aren’t supported in older versions of PHP), and so on.

Improved Examples

Another one of the challenges that comes with maintaining the Boilerplate is that people have been curious for how to use the Boilerplate to create, say, custom fields, custom post types, meta boxes, and so on.

Though this will not be a part of the core project, I’m looking to have examples for how to do things like this. These will likely be maintained as gists or forks and will be covered on the website as it’s built out with content.

But I Need Help!

The Boilerplate is moving into a more opinionated direction and has a specific vision to make it more easier to maintain moving forward, so I certain pull requests may not be merged, may be moved to documentation, or may not be included at all. This is all in order to keep the Boilerplate as focused and as flexible as possible.

Remember: if the Boilerplate does something you dislike or doesn’t do something that you want it to do, then feel free to fork it and let me know about it. I’m happy to maintain a list of all of the variations that come out of this.

Over the last few months, I’ve had the pleasure of working with Ulrich Pogson, Brad Vincent, and Josh Eaton‘ on the plugin. It wouldn’t be where it is in this current version were it not for their contributions and their input for which I greatly appreciate.

In order to launch the next iteration of the plugin, I’d like to have help testing and reviewing the code in the Boilerplate as it stands today.

To that end, we need help testing and reviewing the current version of the plugin. So if you’re a WordPress plugin developer who is familiar with the WordPress Coding Standards, the Documentation Standards, and who prefers an object-oriented approach to plugin development, then please check out the develop branch on GitHub.

I’m looking to launch the official version and the website in the first week of September. Until then, it’s all heads down on the Boilerplate, its site, and so on.