The WordPress Plugin Boilerplate has been a bit of a pet project of mine a little over the past two years.

In that time, it’s grown from something that I was using to jumpstart my own plugin development efforts into a more mature boilerplate that provides a significant number of features specifically to help developers get started with best practices in developing WordPress plugins.

However, that maturity has happened not because I’m the one who has been constantly contributing to the project, but because it has received so many awesome pull requests and discussions from others.

And with my getting ready to release `2.6.0` of the Boilerplate, I’m looking for one final push!

What’s Coming in the WordPress Plugin Boilerplate 2.6.0?

The next version of the WordPress Plugin Boilerplate has the largest `ChangeLog` of any update to this point. This is due largely in part to the number of contributions to other people.

For example, here’s some of what you can expect:

  • Added an admin class
  • Defining a section to provide links for recommended tools
  • Adding a ‘GitHub Plugin URI’ to the wordpress-plugin header
  • Fix loading textdomain when the plugin is symlinked
  • Added multisite activation/deactivation functionality.
  • Added empty array for dependency to fix version number.
  • Removing a lot of whitespace, updating function comments, and comment blocks within a function, and making sure no comments exceed 80 characters
  • Adding a ‘TODO’ so users can more easily find where all they need to supply the name of their plugin
  • …and much more.

But here’s the thing: There are still a few outstanding issues and discussions.

The WordPress Plugin 2.8.0 Issues and Discussions

The WordPress Plugin 2.8.0 Issues and Discussions

As you can see from the screenshot above, over the course of the Boilerplate’s lifetime, we have closed 96 issues, and we’re down to four a couple of which are either slated for `3.0.0`, or a still up for discussion in terms of how we’re going to organize the code.

This is where you can help!

If you take a look at the outstanding issues, you’ll see that we’re discussing:

  • Should we move the class files to their own subdirectory?
  • Fix activation/deactivation/uninstall functionality
  • Improve support for GitHub Updater
  • Should we move the `assets` directory?

So if you’re up for it, hop into any of the issues, issue a pull request, or simply chime in with your thoughts given any one of the above.

This will help contribute to one of the upcoming versions (if not the upcoming version), and will continue to help make this Boilerplate not only a community-driven effort, but one that aims to help other developers build plugins using WordPress best practices.