When Tom McFarlin released his WordPress Plugin Boilerplate on github last November, he has no idea how many developers would jump on board to contribute to this open source learning resource. The plugin has received a ton of support from the community, including commits from more than 26 contributors. McFarlin will soon be putting out a major release that will make the boilerplate better than ever.

An Introduction to the WordPress Plugin Boilerplate

The plugin boilerplate provides the foundation for building a WordPress plugin. Based on the WordPress Plugin API, it provides example values for a basic plugin, so you can learn how to structure your own. All the basics are nicely documented within the plugin using PHPDoc conventions.

File organization matters.

Sometimes you find WordPress plugins with files scattered all over throughout random directories with no rhyme or reason. The WordPress Plugin Boilerplate provides a standardized directory structure for maintaining your plugin’s assets.

Here’s just a quick sampling of what you can learn from starting with the boilerplate:

Register and enqueue public-facing JavaScript files

Create a .pot as a starting translation file

Make your plugin network-aware and compatible with WordPress multisite

Register and enqueue admin-specific JavaScript and stylesheets

Provide updates to your WordPress plugin from GitHub

All of the above and so much more is documented inside the plugin boilerplate with links to where you can find more information. This is a very valuable resource for anyone who wants to get started with best practices in developing WordPress plugins.

WordPress Plugin Boilerplate 2.8.0 Will Be a Major Update

Many developers have been eager to contribute to the project and McFarlin announced that a major release of the accumulated community efforts is coming soon. Highlighted additions to this release include:

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…

How Developers Can Help

McFarlin has a number of outstanding issues and discussions that he’d like to address before pushing out the next release. These include questions such as whether or not to move class files to their own subdirectory, the possibility of moving the assets directory, and more. If you can lend any wisdom on these issues, you’re invited to comment on McFarlin’s post, issue a pull request or get in touch with him on Twitter. This is a community effort that can only help to raise the standards for WordPress plugin development.

Have any of you used this boilerplate to get started building plugins? Is there anything you would change about how it is structured?