This is the second post in the Thinking Holistically About WordPress Plugins as Products series.

In this series of posts, I’m sharing my thoughts on what it means to think holistically about WordPress plugins as products rather than simple extensions for WordPress.

In the first post in the series, I defined this by saying:

Thinking holistically about WordPress Plugins is about the top-to-bottom, end-to-end experience that goes into building and that will go into using the product.

I generally consider the top-to-bottom aspect of plugins as the developer’s experience and the end-to-end aspect of plugins as the user’s experience.

So while sharing specific tips for developing WordPress plugins, I’ll be looking at the developer’s experience – or the top-to-bottom approach – thinking holistically about WordPress plugins.

Top-To-Bottom (or The Developer’s Experience)

WordPress Plugins as Products

Code Quality

When building a WordPress plugin, I don’t believe that it’s enough to simply “make it work.” There needs to be a clear, thoughtful design behind the plugin’s architecture.

This isn’t limited to the source file either:

  • There should be a clear strategy behind the plugin’s file organization. It’s not enough to drop everything into a single file. Overtime, this becomes a maintenance nightmare, and if you open your plugin to development from others then it’s more difficult for them to follow.
  • Some developers will claim that their code should be its own documentation, but I disagree: if code was always easy to follow, then it wouldn’t be called code. As such, comment and comment a lot – comment specific lines, blocks, and functions. In fact, I believe that developers should do as far as commenting using PHPDoc tags.
  • And the usual: Follow the Coding Standards, use proper Actions and Filters, and follow the Plugin Guidelines.

This isn’t limited to new projects, either. Existing plugins and projects can always be improved and refactored to have a higher grade of quality.


Though some developers will say that your plugin should be compatible with as many versions of WordPress as possible, I disagree.

It’s okay to be opinionated – if you want your plugin to be compatible with three, two, or even a single version of WordPress, that’s fine. But be clear about it – you have to set the expectation for your users in the documentation and associated collateral (landing pages, blog posts, etc.) so that they know what they’re getting when they download your product.

From there, test thoroughly. Use the Developer Plugin to make sure you’re using the most up-to-date API calls, that you’re following all of the proper coding conventions, and that you’re queries are performing as expected.


The Plugin Guidelines require that plugin’s ship with a README file, but I believe this to be the bare minimum. Though this may suffice for a free plugin, I don’t think that it’s unreasonable to expect plugins to have a bit more than a single README file.

Instead, a plugin should have an associated website or blog that users can visit to stay up-to-date with what’s going on with development, questions, bugs, issues, and releases.

On top of that, if you’re writing a premium-level plugin that’s a bit more complex, having full user manual for how to use the product (complete with screen shots) can go along way to guiding the user through using your work.

The Short of It

The Developer's Experience

The main point of all of this? The top-to-bottom experience of building a WordPress plugin does not stop at writing code. In fact, I argue that that’s just the beginning.

Instead, I see the top-to-bottom of development as starting with writing code (and simultaneously documenting the code with comments) with documentation being written after the initial completion of the project and a final round of testing occurring at the end.

This isn’t to say that testing shouldn’t occur while certain features are being written – of course not – but I’m referring to black box testing being conducted at the end. Finally, this is subject to change – as issues arise, features are added or removed, the product changes and the associated collateral will have to be updated.

In the last post in the series, I’ll discuss the end-to-end aspects of WordPress Plugins as Products – that is, the User’s Experience.