Over here in John Andrews Land we fight the status quo. WordPress is great, and the plug-in architecture is great, but we don’t build businesses on free, open source code unless we trust it. And we don’t trust free, open source code unless we have checked it. And we don’t rely upon free, open source WordPress plugins unless we know we have taken appropriate risk-management steps, addressing what we consider to be typical concerns when dealing with software, but which the modern world seems to think are optional:
- does the code conform to programming best practices? At least a little?
- does the code include obvious or less-than-obvious security flaws?
- does the plugin abide by the rules to help support the idea of upgrade? Will WordPress break when next upgraded?
- does the plug in warrant a plug-in? Maybe it doesn’t do enough to be worth the risk?
- is the WordPress plugin “phoning home”, sending business intelligence to the plugin owner, or otherwise exposing us to unexpected consequences of use, such as hidden links or cloaking?
It sure costs more to do things right, but it sure costs a lot to fix problems in real time, too. Which is your preference?
We can’t check all of WordPress. We rely on that large community of eyeballs looking at it for months prior to release, and the even larger community of eyeballs looking at it during the months after release, to help make sure it is worthy. That’s how Open Source works. But that is NOT the case for plugins. A plugin author may never share his code until publication time. Many plug-ins see very few installs compared to large open source projects. Even 1,000 users will not lead to good code if that is 1,000 non-programmer users (common with WordPress plugins). We look at plugin code very carefully.
This morning I reviewed another plugin from a well-respected SEO plugin author, and there in the code are all sorts of “potential problems“. All around the web you read “you should have this plugin for SEO” and yet, a quick review by my far-less-than-professional PHP coding eyes shows divide by zero gotchas, opportunity for injections by hackers, and risky reliance on system variables that are not as genuine as the PHP manual might suggest. This isn’t rocket science, but it is web programming, and we’re talking about the basics of web application programming in PHP here. i don’t need to send this one to a php security expert. I know it’s dead just by looking at the code myself.
What is the cost of a bad plugin? Well, you may not care if one day your visitors see a PHP error on the screen. You may even have error reporting turned off completely. You can get problems fixed in a day or so anyway, so no harm done, eh? Well, when was the last time you looked at what is in your WordPress database? I mean looked at the content in the database… using some database tool. Time and again I find volumes of bad data filling WordPress databases, which are hidden from the blogger because WordPress is smart enough to skip over them at display time. But they are still there… and with every upgrade, they carry forward. And one day the database tables break. Or some injected code gets run. What. A. Mess. Or WAM v2.0
A good SEO consultant charges in excess of $200 per hour for routine technical work, as does a good PHP security consultant. That reflects the cost of maintaining the ability to perform as a knowledgable consultant. It takes time to audit code, but not a lot of time, especially when compared to what it takes to rebuild a database that has been corrupted with invalid characters or mussed-up attempted code injections. Unless your risk management plan includes “just start over”, it seems wise to spend a little money and get your site checked out before there are problems.
Not every “SEO plug in for WordPress” is a must-have, and some are not even worthy of the time it takes to download them. How do you know?