How We’re Planning The Next Iteration of the WordPress Plugin Boilerplate

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).

17 Replies to “How We’re Planning The Next Iteration of the WordPress Plugin Boilerplate”

  1. 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.

    1. 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.

  2. 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.

    1. 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! :)

  3. “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!

    1. 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 :).

    1. 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.