Software, Development, and WordPress

Decisions on Documentation for the WordPress Plugin Boilerplate

When I first launched the landing page for the WordPress Plugin Boilerplate last year, the main idea was to grow a site around the single landing page that offered code examples, how to’s, and other forms of documentation.

The WordPress Plugin Boilerplate Homepage

The WordPress Plugin Boilerplate Homepage

But I’ve spent the last month working on some special material for the Boilerplate (that I’ll talk about in an upcoming post) which got me thinking more about what I wanted to offer in terms of documentation for the project.

And I’ve changed my mind.

When I first started out, the WordPress Plugin Boilerplate was supposed to be something that served two purposes:

  1. Provided a foundation for writing well-organized WordPress Plugins
  2. Be easily understood and accessible to as wide an audience as possible

I still want both of those things to happen, of course, but I think that in trying to setup a new site in order to make the Boilerplate as widely available as possible was a bit misguided. Simply put, the Boilerplate is for developers.

It doesn’t matter if you’re a beginner, it doesn’t matter if you’re intermediate, and it doesn’t matter if you’ve been writing plugins for years. In fact, odds are, if you’ve been doing this for years, you probably have strategies (some of which are probably better!) than what I have in place (and pull requests are always welcome :).

Regardless, the target audience is developers and since the code resides on GitHub, I think it only makes sense to keep all of the documentation, examples, and so on actually on GitHub. It’s where developers are going, it’s where developers will be.

To that end, rather than opening up documentation up on yet-another-site, I’m going to be using GitHub as the place to begin writing, collecting, and sharing the documentation.

And now that I’ve finished with the first pass (again, which I’ll share later), I can get into sharing more details about that in the future.

In the meantime, look for the documentation to begin taking shape on GitHub very soon.


  1. Steven Slack

    I second that plan! GitHub is where we all end up to grab the plugin, look at the code and eventually read the docs.

  2. Alexandre Plennevaux

    I second that! github has all that you – and us – need: bug reporting, forking and the Wiki for the documentation, often under used!

    thanks Tom!


  3. DeBAAT

    Would second any form of documentation.

    Now I’m working on a new plugin using this as a starting point.

    And at the moment, I’m missing the code to determine when to activate the Admin and when the Public part of the plugin.

    Can you provide an example on how to do this?

    I recon particularly the definition of a shortcode would be something purely Public.

  4. Saumya

    Hey man great post. I have one question to ask, may be an off topic one. How do you put that shadow behind your images you put on your article? Do you use photoshop? How do you do it?

    • Tom

      That’s built into OS X – when you take the a screenshot of an application’s window, it automatically adds :).

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑