There is a well known software design paradigm that is called “Convention over configuration“. At its core, it aims to make software development easier by reducing the amount of decisions that a developer has to make when writing software.

It accomplishes this by providing the developer with a set of rules or conventions to follow. That in turn reduces the amount of configuration and scaffolding needed to get to the software built.

The most common example that gets thrown around is that of a class to database relation. If your class is called “Posts” your database table name would be called “posts” too. No mappings or configuration required.

By following defined rules and conventions, developers can almost always build their software in a standardised way. That means writing less code and focusing on what they’re really good at, solving complex problems.

Some of the biggest and best software frameworks and libraries are built upon this design paradigm, and for good reason.

What if however, we approached the paradigm from a different angle. What if we applied it to how we design our WordPress plugins from a users perspective rather than software design perspective?

Creating simpler, better and LESS WordPress plugins

What does this mean and how do we achieve that? Simply put it means designing your WordPress plugins using an acronym I’ve come up with called LESS. LESS is a recursive mnemonic acronym (something similar to KSES in the WordPress wp_kses function) and it stands for…

  • LESS – Apply the principles of LESS
  • Eliminate – By eliminating, we aim to get rid of any configuration, functionality or features that are not absolutely essential to the function of the plugin. It means giving the user only one way to do something. It means creating plugins that do less but offer more.
  • Standardise – To standardise means to do the same thing, in the same way, over and over again. A good example would be having multiple different plugins which are written and behave in the same way. Same naming conventions (preferably inline with WordPress standards), same type casing, same UI (see next point), same same same.
  • Seamless – Lastly your plugins should seamlessly integrate with WordPress. Your plugins should feel as if they’re a Core feature. Only by a user deactivating the plugin should they realise that it is not core functionality. Not only that, they should implement filters and actions religiously.

The benefits of writing LESS WordPress plugins

Applying the LESS principles to your plugins is definitely not always easy. It takes discipline and a real understanding of what your WordPress plugin is and what it is not.

It means turning down feature requests (and even pull requests for open source plugins) because they don’t always fit with the vision for what your plugin is.

However, by applying that discipline and knowing your plugin or plugins deeply, there are multiple different wins that you will notice…

  • Much easier and reduced support load. As long as you make sure your documentation and FAQ is as good as your software (an important topic for another day), you will receive far fewer support queries. Why? Well because there is simply just one way to do something.
  • Your plugins are more extensible. In fact extensibility is a feature and if someone want’s to go beyond what you provide with your plugin, they’re easily able to do that. It’s a selling point.
  • LESS is more. By simplifying and almost dictating how a problem is solved through your plugin, you are helping people by reducing the amount of decisions they have to make. That’s hugely beneficial and frees up their time to focus on what is more important to them.

Applying the LESS principles to my own WordPress plugins

I’ll admit, I haven’t always applied the principles to the many plugins that I’ve written. That’s mostly because from my part, coming up with the LESS principles took a lot of experimentation, creating and learning the hard lessons of NOT following the principles.

Right now, my next step is to completely rewrite WP Most Popular and apply the principles to that plugin. Even though it’s well on it’s way to becoming a LESS WordPress plugin there is still more work to do on my part.

How can you apply these principles to your own plugins? I would love to hear your thoughts.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.