I’ve made a useless WordPress plugin…

…which you might find useful if you develop plugins with system requirements, like a particular version of PHP. This plugin is a simple proof of concept for a method of messaging the user when they activate a plugin.

This evening, I downloaded a new WordPress security plugin on the recommendation of Gareth Heyes on the GeekUp list. I read through the description, skimmed the code to see what it was hooking into and roughly what it was doing, and then uploaded it to my site… and of course it didn’t work. (Not the fault of the plugin authors, as you will see.) I immediately thought, like the good and helpful chap I am, that I’d submit a bug report. “Plugin won’t install, fatal error as follows, blah blah blah”… but then I remembered, the description stated a requirement for PHP5 and my personal website is running on PHP4. Time to upgrade obviously.

All this got me thinking: how many bug reports and complaints are the writers of this security plugin going to get, given that I’m betting I’m not that different to most people in my careless disregard for noting system requirements? Surely there must be a way of producing a clear message explaining why the plugin hasn’t activated?

When you activate a plugin, WordPress creates a little sandbox and runs the plugin in it to check that nothing breaks immediately; if something does break, the error message is printed at the top of the plugin management page. I present my useless plugin, which will fail to activate with a meaningful message if your PHP version is less than 7.1.0. With this technique, next time I write a plugin that depends on a particular version of PHP, or WordPress, or another plugin, I can check my requirements and then communicate any problems to the user, rather than have the whole thing fall over in a heap of PHP code errors. A much nicer user experience.

Download: WordPress plugin: fail (proof of concept)

Update: I woke up this morning and realised my previous code example wasn’t clear enough, so I’ve enhanced it. The basic concept still stands: you determine dependencies at the top of the script, and use die() to pass a message to the blog owner. The problem was that if the “broken” code (either PHP5 specific syntax, or calls to non-existent functions, or use of non-existent variables, etc) is in the same file as the checks, then those errors will still cause problems. I’ve got around this by doing my checks in the main plugin file and then, when I’m sure dependencies are met, using require() to pull in the rest of the plugin code.

Let me know any other problems you find with the idea.