WordPress Plugin Boilerplate 3.0 Released with New Community Website

wppb

Version 3.0 of the WordPress Plugin Boilerplate was released today. The open source project was started in 2011 by Tom McFarlin as a GitHub repository for storing code while he learned plugin development. Over the past three years, the boilerplate has matured beyond his expectations with the help of 39 contributors. It now has more than 1800 stars on GitHub and a brand new logo and website.

What’s New in 3.0?

The 3.0 release constitutes a major rewrite of the boilerplate. The primary objective of the project is to provide a standardized, object-oriented starting place for building high quality plugins.

“In the new version, we’ve broken things down into a very, very specific organizational structure,” McFarlin explained. “It’s much more object-oriented than it’s predecessor, the code doesn’t include a lot of TODO’s. Instead, the comments give developers guidance as to what a variable or a function should be doing when using the Boilerplate.”

As developers implement their own work using the boilerplate, they are encouraged to overwrite the comments that are included as a guide.

McFarlin and contributors made every effort to ensure that the code in version 3.0 conforms to WordPress’ coding standards and its inline documentation standards.

The plugin boilerplate now includes classes that are responsible for everything. There are classes for:

  • Plugin activation
  • Plugin deactivation
  • Plugin Internationalization
  • A class that’s used to register all hooks with WordPress
  • A core plugin class
  • Some use of common object-oriented design paradigms
  • A specific location for dashboard-related functionality, styles, and scripts
  • A location for public-facing styles, and scripts
  • A location for shared code (be it libraries or not)
  • A template for a plugin readme
  • A directory structure that mimics the WordPress Plugin Repository’s Subversion directory
  • Places for screenshots, banner images, and even the custom icons that were just announced for WordPress 4.0

The new directory structure is now broken down into assets and trunk directories:

wppb-directory-structure

One of the most exciting updates to 3.0 is that this version of the boilerplate can be installed and activated like a regular plugin, making it easier for new plugin developers to get started. “It doesn’t introduce any functionality into WordPress,” McFarlin explained. “But there are two sample JavaScript files that show how to use the core Boilerplate code to get started.”

The Future of the WordPress Plugin Boilerplate: Expanded Documentation and Community

Version 3.0 omits the Github Updater, which was part of previous versions. The reason behind this change is that McFarlin wanted to scale back the boilerplate’s contents in order to offer only the bare essentials to get started.

“I want to start up Editions (or basically forks) of the Boilerplate that are tailored to those who like to use Grunt or Composer or those who want to include the GitHub updater in the plugin,” he said. “Personally, I’m a big fan of it and I use it in a number of my plugins, but I didn’t want to build it into this version when it can just as easily be added by someone else’s fork.”

With the new website and branding in place, McFarlin hopes to develop the community behind the project. “Hopefully, having a face to relate to the Boilerplate will help elevate it beyond just a miscellaneous GitHub repository,” he said. “A domain, a logo, branding, and all of that stuff can go a long way in helping others to associate a project with an idea and a group of people more than an open source repository and a README could ever do.”

McFarlin plans to expand the boilerplate’s documentation on the website and grow a community where developers can share ideas and forks that they’ve created for specific use cases, such as WordPress multisite.

Appealing to new developers is also part of the goal for the new website. “I want to make the Boilerplate more accessible – GitHub is great, but it’s great if you’re a programmer,” McFarlin said. “If not, it’s really intimidating and people have no idea how to get started with contributing to a project.”

The boilerplate website will serve to provide documentation, example code, and an explanation of how people can get involved contributing to the project. McFarlin is even considering adding courses, editions, and a forum. “To be honest, I’ve even considered holding online events where people can pay to learn how to use the Boilerplate for certain things, though this and all of the other things are so far on the backburner that it’s hard to envision how it’s going to play out right now,” he said.

Over the years, the community surrounding the boilerplate has helped to shape its future and McFarlin is committed to move the project in a direction that continues to serve WordPress plugin developers.

“I think the one thing that I never expect to hear, yet never get tired of hearing, is: ‘I didn’t know how to write a plugin or where to start until I found the Boilerplate,’” he said. “That’s a really great feeling.”

7 Comments


  1. Awesome job Tom! Again you never cease to amaze me and teach me something new. When you told me you were planning a massive rewrite I didn’t think it was going to be like this. Even better than before amigo

    Report


  2. Hi Tom – thanks for the leg up! We are trying to improve the way we implement plugins and this is a great learning resource.

    One question – what is the most appropriate way to implement template tags (methods called in the theme)?

    Currently we have a template-tags.php which we include in the load_dependencies method in the main plugin file. We were unsure whether the intent of Boilerplate was to have all these methods in the plugin_public.php. I note that Custom Field Suite uses a public method to return a singleton instance to the controller so you can call CFS()->method_name()

    What’s considered best practice here?

    Report

Comments are closed.