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?
Big fan of Tom’s Boilerplate.
I’d like it to be more transportable though.
That is, when there is an update, I’d like to be able to easily update my existing plugins to it. Seems, each time I make a plugin, it is with a different version of the boilerplate.
It is probably a bit of an idealistic and unreal hope though.