I’ve been very busy lately, which is why it has been some time since I’ve last posted anything. One area of my job that sucks a lot of time is maintaining onMason, the WordPress-based platform on which this blog runs.
onMason recently celebrated it’s tenth anniversary, which means onMason is very, very old in tech years.
One of the things I’ve been trying to do is update the PHP, the programming language WordPress is written in, to version 7.3. WordPress itself is ready for this upgrade. In fact, they display a very misleading “PHP Update is Required” warning in the Dashboard if you are running anything but PHP 7.3.
However, many of the plugins (and themes) we use on the site will not run or run poorly with PHP 7.3. For example, the report generated by the PHP Compatibility Checker plugin is an imposing 161 pages long.
So why is upgrading such an ordeal? It’s because of a mistake we made when we created onMason back in 2009 – we decided that we would basically install any plugins (or themes) our users asked for. Over the next ten years, we installed no less than 160 plugins. We were even less selective with themes, with nearly 200 installed over the same period. So what’s the problem with that? After all, plugins (and themes) add functionality not included with WordPress and who doesn’t want more features?
The problem is that plugins are not maintained as well as the WordPress core, typically only for a few years. Sometimes the author loses interest in the plugin, or sometimes they tragically pass away. Unfortunately, it just isn’t in the WordPress community’s DNA to adopt an abandoned plugin, no matter how popular it once was. It is also rare that a plugin will import another plugin’s data and settings. Occasionally, a plugin won’t even import data and settings from an older version of itself.
Over the years, I’ve managed to slim down the number of the number of plugins and themes to around 80 and 130 respectively. If I’m lucky, the plugin functionality gets integrated into the WordPress core and I no longer need the plugin. Sometimes the plugin relied on a web service that shut down (e.g., del.icio.us). But most of the time, I effectively become the maintainer for dozens of abandoned plugins and themes.
Is it worth it to maintain a plugin for one or two users? Is it worth it to have plugins to support features that have fallen out of favor (like tag clouds)? Is it worth it to support advanced features (like podcasts) when many users may want to use it, but probably never will?
For years, I’ve known how many sites use each plugin. However, what I didn’t know was how many people actually used the plugin. It was shocking to learn that around 70-80% of people who activate a plugin, never actually use it. I can tell since many plugins require users to configure something – completing a wizard, entering an API key, etc. If these steps were never completed, the plugin was obviously never used. In one example (Smart YouTube Pro), a plugin was active on 30 sites, but not a single user actually used it.
Due to health reasons, I no longer have the time to maintain all these abandoned plugins and themes. I’ve come to the bitter conclusion that it’s best to run as close to a stock WordPress instance as possible. It’s the only way we can maintain a secure and high performing service with the resources we currently have. So, in the future, you’ll see a lot less options for additional plugins and themes – and that is a good thing.