I originally authored this post on WP Realm, but I moved it back here after that website folded.

Over the past year I have changed from approaching plugin development with the intention of pleasing as many users as possible, to attempting to solve single problems as flawlessly as possible.This has made the plugins I release of significantly better quality, although it has resulted in less popular plugins. Unfortunately it seems that plugin users are most happy when they can install a plugin which lets them do everything under the sun to modify their site to the nth degree.

My own screwups

When I began developing WordPress plugins around 2008, I started with an extremely simple plugin for adding a drop down menu; it did one thing and it did it well. Over time I added more and more features and eventually spun it off into another more feature-rich multi-level navigation plugin and later into the even more feature rich PixoPoint Menu plugin. This seemed sensible to me at the time as I knew how to add the new features users were asking for and those users appreciated it.

Fast-forward four years and I landed myself in a real mess. I had created a monstrous plugin, riddled with poor code and bugs I did not have the motivation or time to fix. My critical failure was that I failed to realise that I was attempting to satisfy everyone rather than creating the optimal plugin for a specific task. Had I concentrated on creating a plugin which achieved its primary goal with a minimum of settings I would have had a much smaller code base and much less code to maintain and optimise.

I ended up having to retire the PixoPoint Menu plugin recently when I received a very serious security report on it. I fixed the security flaws reported, plus a few more which I discovered during my own audit, but decided that the poor little plugin needed to killed off as, although I poured a huge amount of effort into it during its hey day, I knew I had no motivation to fix some serious problems inherent in it.

One of the PixoPoint Menu plugin administration pages. An excellent example of how not to build a plugin.

One of the PixoPoint Menu plugin administration pages. An excellent example of how not to build a plugin.

History repeats

Unfortunately, I can see the sames mistakes I made back then apparent in many of the plugins released by new developers today. It is hard to know where you are going wrong until you are too far down the wrong track. It is easy to look back in retrospect and see where you went wrong, but when your head is buried in code and you have lots of happy plugin users it can be very hard to pull yourself back and take a broader view of things. The primary lesson I learned was not to dump excessive amounts of code into a plugin simply to add minor features that someone, somewhere may use. Catering for everyone is not possible and attempting to do so will simply result in an unmanageable amount of code and an excessive number of bugs.

Decisions, not options – WordPress.org

Examples of well implemented plugins

There are no perfect plugins, but there are some which come closer than others. Extremely elegant examples of simple plugins with minimal code are the caching plugins Batcache and APC. Unlike most other caching plugins for WordPress, these two plugins feature no options whatsoever, yet are considered by many WordPress experts to be two of the best solutions available for handling caching in WordPress. Other caching plugins for WordPress feature huge options pages allowing the configuration of every possible option under the sun. Personally, I prefer to simply install a plugin and have it achieve it’s goal with no messing around. Neither the Batcache or APC plugins will work on shared hosting, but by not bothering to support crappy webhosts they are able to provide a far superior quality product to those who have access to more advanced server configurations.

An example of one my own attempts to implement plugins with this sort of mindset is the Spam Destroyer plugin which I developed as a “set it and forget it” plugin to obliterate spam from your site. Many similar plugins require configuration to ensure that they work correctly. I found configuring settings page infuriating when all I was attempting to do was to remove spam, so I created the Spam Destroyer to ensure that I could remove spam with minimal effort.

But I really badly need options!

Sometimes you do need to provide options with a plugin. I’m not entirely sure what the optimal solution to this is, but if you provide appropriate hooks and filters in the plugin, it should be possible for people to modify features via their theme or from a secondary plugin.

I’ve recently begun implementing options in plugins by instructing users to modify their wp-config.php file. I wouldn’t do this for situations in which most users will need to edit the settings, but it can be useful to provide a simple solution for people to change settings in the rare instance that they may need to. If the constants aren’t set in the wp-config.php file, then the plugin sets some defaults automatically. This requires significantly less plugin code than building an entire administration page and avoids adding an extra layer of complexity in the admin panel. An example of this can be seen in my Simple Colorbox plugin, which provides the ability to change Colorbox designs and sizes by simply adding some constants to the wp-config.php file.

Here is an example of the settings that can be applied to the Simple Colorbox plugin via wp-config.php. The intention is for the end-user to never need to change these, but they’re there if they need to.
https://gist.github.com/3692314

Take home for developers and end-users

Simple problems are best solved with simple solutions. Just say no to options!