Months ago, I announced that there was going to be a major update to the WordPress Plugin Boilerplate.

Because of its nature in being a hobby project, because this project is something that’s being worked on by a number of contributors, and because the next iteration is going to be a major rewrite of what we have so far, it’s taking a while to begin pushing code for the new Boilerplate.

But there are a lot of neat things coming, and I think that even if it’s taking us a while to get something on GitHub, it’s worth providing updates as to where we currently stand with the project.

Planning the WordPress Plugin Boilerplate

When I first started working on the WordPress Plugin Boilerplate, I did so as a way for me to provide a consistent foundation off of which to build plugins (many of which I was doing on a contract basis).

So I extracted most of the common code that I was using, threw it up on GitHub, and thanks to the many gracious people in the open source community, it grew into something much neater than I ever expected.

It continues to do so, and I couldn’t be more excited.

That said, I’ve also shared that the next iteration is going to be a major overhaul of the plugin as it stands today, so I thought I’d provide some insight as to how it’s being planned, what’s in the pipeline, and what to expect as we begin pushing code.

Who Is This “We” You’re Talking About?

Some time ago, I put out a call for those who were interested in participating in some backchannel discussion with me about working on the plugin.

I received some feedback, so I’ve got a really small team that’s chatting through some of the initial points of the rewrite of the Boilerplate with me.

WordPress Plugin Boilerplate Backchannel

Using Houston as our backchannel theme.

To be clear, I could not be happier with the people with which I’m working. Specifically, I’m working with:

  • Ulrich Pogson
  • Josh Eaton
  • Brad Vincent

“But This Is Open Source!”

I’ve heard a very little amount of push back about the idea of talking with others about rewriting the plugin, and talking about it in a backchannel.

I know, I know. It’s all about the open source, and the backchannel is closed, and all that fun stuff.

The source code is open and will continue to be, and I’ve put out an invitation some time ago for others to join us in the pre-planning stages.

Conversation isn’t covered by the GPL – just the source code :). Plus, once the initial planning is done, I imagine that all of the discussion and commenting will resume in the form of code comments, pull requests, and so on.

What on the Roadmap?

As of right now, here’s a super high-level view of what we’re looking at doing for the Boilerplate in order to prepare it for the next release:

  • A complete rewrite from the ground up
  • Merging the widget boilerplate into the plugin Boilerplate
  • A dedicated web site for the project
  • Documentation, FAQs, and HOWTOs for the Boilerplate
  • Optional, advanced features that will be included (or how to include them) with the base level of the Boilerplate
  • Improved examples of using the Boilerplate
  • How features such as custom post types, taxonomies, widgets, and so on work within the context of the Boilerplate
  • A standardized directory structure that’s flexible enough for the simplest plugins to the more complex plugins.
  • …and more.

We’ve done a lot of conversing, debating, and planning for this initial structure of the Boilerplate.

We’ve looked at ways other plugins organize their code, we’ve looked at how larger WordPress-based projects organize their code, we’ve looked at how other projects are documented, and so on, and we’re trying hard to not only borrow from the best, but also to standardize things as much as possible so that we have some type of convention by which plugins can be developed, and I couldn’t be more excited.

Though we’ve not yet had the initial code push, we’re very close. As soon as the initial directory structure is locked down, the team is going to begin pushing code and we’re each going to have our own set of responsibilities as it relates to peer reviewing what’s going on in the Boilerplate.

Furthermore, this part of the process will also be open source so that it’s not only us, but it’s the entire community who watches and/or uses the Boilerplate offering up their input.

So there’s some exciting stuff that’s finally coming down the pipeline, and I can’t wait to get all hands involved. For now, though, that’s the status of the WordPress Plugin Boilerplate.

Expect code pushes to start very soon (and, naturally, a blog post to go along with it).


Join the conversation! 17 Comments

  1. Fantastic to hear, Tom! I’ve been a fan of the boilerplate since you first threw it up on GitHub, and am very excited to see what the next version comes out like.

  2. Nice to read that! But, Tom, can you answer a question? Are you going to include a form, so that we can type our plugin’s name and other stuff, to automatically include it on the code, thus reducing the “to do” list?

    It would be a good feature.

    Anyway, thanks for this.

    • Are you going to include a form, so that we can type our plugin’s name and other stuff, to automatically include it on the code, thus reducing the “to do” list?

      The short answer is yes. We’ve got a domain, a roadmap, and a plan for different builds.

      The longer answer is that it will come a little bit after we get the core code in place and then begin building up the site, documentation, FAQs, etc., around the project.

  3. This all sounds great to me! Looking forward to it already.
    Mauro’s idea sounds great, hope that gets a chance.

  4. I’ve been working with version 2.6.1, which has been really helpful. There’s one technique that I’m wary of, however, and I’d like to know if it will change in the new version. The i18n functions are of the form __( ‘Some literal’, $this->plugin_slug ), where the context is stored in a variable. This conflicts with the advice in:
    Translating WordPress Plugins and Themes: Don’t Get Clever
    Internationalization: You’re probably doing it wrong

    Should I be replacing “$this->plugin_slug” with a literal?

    Thanks for a great project and any wisdom you can share.

    • There are a number of articles about i18n and whether or not to use a string literal or a variable and they all offer compelling reasons for both.

      We’re working to make this much easier in the next version, and we’ll make sure that we’re extremely clear on the reasons that we’ve selected.

      Oh! And to clarify: You can use a string literal or a variable, really – it depends on the tools that you’re going to use to translate the plugin. If you feel more comfortable using a string literal, then go for it! :)

  5. This all sounds awesome enough that I’d hold off on some plugin ideas for a new version to get my cruddy code in line with standards.

  6. “The source code is and will continue to be ,” I think something’s missing from there (maybe open?), it seems important :)
    Thanks for the boilerplate, I’ve used it for our Infinite Slider release, and it was a great help!

  7. Tom, very excited! When can we expect to see the new boilerplate?

    • Thanks Marnus!

      Unfortunately, since it’s a hobby project, I don’t have a set date on when the next version will be released.

      The team and I are working when we can, but it’s taking a bit of time since it’s a completely rewrite and there are other responsibilities, as well :).

  8. Very exciting… Are there any old tutorials or videos about the current version of boilerplate around that you recommend, so as to prepare?

    • Unfortunately, no — all of the existing tutorials, comments, and discussions are on GitHub; however, we are looking into having extensive documentation on how to use it as well as use certain new features, as well.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.