Practical WordPress Development

The WordPress Plugin Boilerplate 2.6.0 is Now Available

For those who are interested in following future development, sign up for the mailing list!

Today, I am absolutely stoked to announce the next major release of the WordPress Plugin Boilerplate.

I discussed some of the things I’ve learned – and some of the changes that have been implemented in a recent post – but I couldn’t be happier with this release.

Some quick statistics:

  • The last official release was on May 17, 2013. We had one minor release in July that I opted to fold into this release and officially tag as `2.6.0`.
  • We’re now working to implement semantic versioning into the Boilerplate.
  • The milestone for `2.7.0` is already being planned.
  • The project now includes 241 commits and 10 contributors

This is by far the largest commit and set of changes that have gone into the Boilerplate since it has been released. You can grab it here, but read on for more details!

The WordPress Plugin Boilerplate 2.6.0

The WordPress Plugin Boilerplate 2.6.0

The WordPress Plugin Boilerplate 2.6.0

You can read the `ChangeLog` in its entirety; however, there are a number of notable changes that have come with this particular version of the Boilerplate that are both exciting and important to share, especially for those of you who have been working with the project for the past couple of years.

1. Separate Directories

We’re not at a place where we can use namespaces within the context of our plugins; however, we’ve restructured the plugin so that it should be easier to get up and running not only with WordPress’ plugin subversion repository, but also as it relates to organizing your code:

  • There is now an `admin` directory for dashboard-specific functionality
  • There is now a `public` directory for pubic-facing functionality
  • There is a top-level `includes` directory where shared classes and libraries may reside

All files that reside in the top-level `assets` directory belong the Subversion repository’s `assets` directory (all of which is covered in the `README`).

2. Recommendation Localization Tools

One of the challenges of working with internationalizing your plugins is knowing how best to structure the base localization file for other tools, and for your plugin itself.

To that end, the contributors have come together to provide a set of recommended tools all of which will play nicely with WordPress, the Boilerplate, and now your plugin.

Again, you can find this information in the `README`.

3. Support For The GitHub Updater

As GitHub continues to gain popularity among developers – WordPress included – we’ve introduced support for the GitHub Updater plugin so that you can easily hook up your plugin to its GitHub repository so users will be notified when there’s an update when you push to its respective GitHub repository.

4. And Much More

This isn’t all – there is a lot to checkout between the `ChangeLog`, the restructuring of the plugin, and the documentation that is provided throughout each attribute, function, and class in the Boilerplate.

Thanks To All!

This version would not have been possible were it not for the generosity of people who offered their time and talents on hopping in on discussions, offering pull requests, and debating some of the best ways to handle situations for those who are using this as a starting point for their plugin development efforts.

In no way can I take credit full for this project as we’ve got quite a handful of awesome people now working on it. If you’re interested, feel free to jump in and start working with us.

Now, on to `2.7.0`.


  1. syed Aly

    Tom this is great article on boierplate. was searching on this, i heard from my friend and was researching on it . I’m glad to found on your blog.

  2. Chris Howard

    Tom, no direct link to the GitHub? Just to Readme and Changelog. Was that deliberate?

    Really looking forward to this.

  3. ale

    Hi Tom!
    Thank you for this fantastic tool!
    I try to build a simple plugin that add some html code into footer (front-end). According to you, what is the best way to do it? I can simply add an action to my public/class-plugin-name.php but I want to use also public/views/public.php.


    • Tom McFarlin

      Assuming you’re referring to wp_footer, then you’d add an action to wp_footer, then in the hook, include a function that renders the public/views/public.php.

      • ale

        Thank you Tom!
        Another simple question? Where and How can I put constants and global variables for all plugin files(both admin and public)?

        • Tom McFarlin

          Right now, the best place to put them would probably be in the `plugin-name.php` file – that is, define them in the file prior to instantiating the plugin.

  4. Martin

    Hi Tom, thank you for your great work!

    I have a question and a recommodation:

    Where is the best place to store images used by the plugin?

    And: I would define a function which checks the requirements to run and use the plugin.
    The classical check is on plugin activation: compare the current WP version with the required minimum version number.

    • Tom McFarlin

      Right now, the best place to store images for the plugin is in the `assets` directory, preferably under an `images` directory. This is something that we’ll eventually tighten up in future releases.

      Also, thanks for the note about a define function – good idea!

  5. Dasha

    Hey Tom,

    Thank you for all your hard work preparing the boiler plate. I’m planning to start using it for my first ever plugin – very exciting!

    The link at the top of the post to signup for the mailing list doesn’t work – it just reloads the current post.

    Best wishes,

  6. Dasha

    Hi Tom,

    Another question: where would I put widget code if I’d like to have one with my plugin?

    Many thanks,

  7. Jacob Harasimo

    Hey, great work on this.

    I’m newer to wordpress/php as I have generally developed in .net languages. But there is value in learning so I decided to start here. I have a question about the admin/public part. I got the admin stuff down i think (it controls the administration function of the plugin like a settings page) but the public has me baffeled.

    I get that public/views/public.php is where the code goes but how do I display the plugin on the front end? Is it setup to use a shortcode in a post to display the public facing end? Do i need to construct a widget to display it? Or do i need a custom post-type so i can use custom html to output this?

    • Tom

      Hey Jacob – welcome to WordPress :).

      Regarding the admin, you’re exactly right. As far as the `public` is concerned, that’s for rendering information on the front end of the blog like a widget or like displaying content on the front end of a post or a page (it really depends on your implementation).

      To see how I use it in a simple plugin, check out the source code here in the widget function.

  8. Tom

    Glad to see this has a folder to store all the pubic facing functionality

    • Tom

      Yep – and we’re going to make sure that continues on even in the next version of the Boilerplate, too :).

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑