Software, Development, and WordPress

WordPress Widget Boilerplate: Aiming For 1.0

WordPress Widget Boilerplate

In the same way that I’ve been working on the WordPress Plugin Boilerplate, I’ve never really done a good job of handling versioning. I’ve simply closed tickets as they’ve been opened and I’ve resolved issues as I – or others – have encountered them.

Next month, I’m hoping to officially tag it and the WordPress Plugin Boilerplate as version 1.0, but I’m hoping to get a few more eyes on the code prior to doing so.

This weekend, I spent some time closing tickets, refactoring some code, and improving a few aspects of both of the boilerplates to improve its overall standard.

Here’s a run down of everything that’s been updated since the I initially launched the WordPress Widget Boilerplate:

Updates To The WordPress Widget Boilerplate

  • Completed localization
  • Added a .gitignore file
  • Updated JavaScript to conform to JSLint standards
  • Stopped using WP_PLUGIN_URL as it was breaking secure sites
  • Changed from plugins_dir_path to plugin_dir_path
  • Cleaned up the code to comply with the WordPress Coding Standard
  • Simplified and correctly enqueued JavaScript and stylesheets
  • Added a sample field to show how to use the boilerplate
  • Resolved a minor typo in a code comment
  • Resolved typos in plugin-specific JavaScript and stylesheet issues
  • Removed the closing PHP tag
  • Removed ampersands on $this for changes in pass-by-reference changes in PHP 5.4.4

Of course, many of these couldn’t have been done without pull requests and contributions for others on GitHub. I’m certainly not taking credit for all of the work that’s been done!

What’s Needed For 1.0?

Generally speaking, I think that the WordPress Widget Boilerplate (and the Plugin Boilerplate) are almost ready for 1.0, but I’d like to have as many of you code review it as possible.

Ultimately, I’d love to have this become the de-facto boilerplate for creating WordPress widgets so if you have five minutes and feel like opening a ticket, contributing a pull request, contributing some other change (even if it’s a feature request), please do.


  1. Eric Dye (@DYECASTING)

    You’re getting a lot of link love on this, and for good reason!

    Hawt stuff.

  2. Norcross

    Do you have some sort of ‘pending’ or ‘to-do’ list on this? I would love to help.

    • Tom McFarlin

      Nope – this has been purely a minor ongoing project of mine. Mainly, it’s a matter of taking what’s considered to be the absolute foundation required for writing plugins or widgets and capturing them in this boilerplate.

      If you see something missing (or something that’s overkill!), or room for improvement be it in comments, code, convention, styles, etc., submit a pull request for it.

  3. Pippin Williamson

    Just submitted my contribution :)

  4. Daniel

    Hi Tom,

    Good project. It’s helping me to get into OOP. However, I have a question. How can I use $control_ops? I don’t have idea where to put them. I tried something like:

    __( 'Tabber', 'tabber-locale' ),
    'classname' => 'my-tabber',
    'description' => __( 'Display widget in tab format.', 'my-tabber-locale' )
    'width' => 230,
    'height' => 350,

    But of course… it didn’t work.


    • Tom McFarlin

      If I correctly understand what you’re asking, the $control_ops would probably work better as an attribute on the class.

      So something like this:

      class Foo {

      private $control_ops;

      public function __construct() {
      $this->control_ops = array( 'width' => 230, 'height' => 350 );
      } // end constructor

      } // end class

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑