Homeland Security Advisory SystemWordPress developer Dougal Campbell recently wrote an article warning us to “upgrade or be hacked”, and then went on to say that if our plugins or other additions to WordPress no longer functioned we should “get over it” because security is more important than functionality. To really rub salt in the wound, Mr. Campbell informs us that every release of the popular open-source blogging platform is essentially a heaping pile of crap code strung together by incompetent oafs who couldn’t program their way out of a wet paper bag if it had a hole in both ends.

Way to instill confidence in your product, Dougal. Maybe instead of putting down the previous versions of your team’s software, you can make better use of your time and write a proper security update for the 2.0.x, 2.1.x, 2.2.x and 2.3.x releases.

Fact of the matter is that many people prefer the previous versions of WordPress, and I am one of them.

WordPress 2.5 Is Not Ready For Adoption

The most current release of the WordPress family is 2.5, which was made available less than two weeks ago. I’ve had the opportunity to test this most current release since it was in the Release Candidate stage and, while it does have a few nice additions to the administration screens, there are many areas that require a bit of polishing before it can be considered ready for the masses.

Browser compatibility is still a huge problem with the Admin screens, as I can’t write a proper page or post with Opera. Because of this, I’m forced to use Firefox or a 3rd-party application like Windows Live Writer, BlogJet or Elicit whenever publishing content on any of my sites.

From what I’ve read and experienced first hand, users of Opera, Konqueror and SeaMonkey cannot write posts in the visual editor without receiving some form of text wrapping error by the second or third paragraph. Unfortunately, this wrapping problem is not limited to the visual editor, and any published articles with this formatting issue have the very same fault on the front page, regardless of the templates and formatting options we have in place. This means that bloggers are forced to use Firefox, Internet Explorer or Mac’s Safari (there have been some issues with the Windows version reported) to publish content through WordPress.

If this isn’t bad enough, the new method of uploading and embedding images into our posts has become far more complicated and troublesome than it’s worth. In the three days since installing WordPress 2.5 on some secondary and development sites, I’ve had countless headaches with the image uploading and formatting functions built into this newest of versions.

With previous installations of the blogging software, image handling was often straightforward. Select an image from our computer to upload, give it some title and description, then send it to the visual editor where we could then position, resize and format the media. There were certainly some issues with image searching, but it wasn’t something that couldn’t be managed with a little help from Google. Not only does this make it more difficult to work with images, but it’s now much less friendly for long-time WordPress users.

Plugin Compatibility Issues

Dougal’s inflammatory statement underlines a major problem within the WordPress development cycle; compatibility is secondary to new functionality. There is only one major software vendor that has this very same problem, and it’s Microsoft with their endless array of over-powered software packages.

How many of us remember the transition from Windows 3.1 to Windows 95? How about Windows 98 to Windows2000 or WindowsXP? Remember how the scanner wouldn’t work? Remember how you had to buy a new printer because the drivers were unsigned and you couldn’t override Windows’ initial protection system? Remember how your old software wouldn’t run and would give you “Cannot Run on WindowsNT-based systems” error? How did we get around these problems?

A simple right-click to Properties, and set the compatibility mode to Windows 98. Voila! Problem (mostly) solved!

Why can’t we do something similar to this in WordPress? Why must plugin developers constantly be held accountable for keeping up to date with the seemingly whimsical API and database changes of the WordPress team? How many plugin authors have written some superior code that gives us the exact functionality that we need for our site, but it’s the only piece of code they’ve ever put out and have explicitly stated that they will not be making updates because they’re tired of the predictable cycle? I can count seven authors that have done this, and that’s without firing up a quick Google search.

Perhaps it’s time WordPress fans started pushing for some better thought-out backwards compatibility handling. It’s nothing new to most developers and, if it is, then it’ll be great practice for anyone looking to transfer their skills from an open-source project to one that might offer a steady paycheck.

Incomplete Security Models

Most WordPress installations use a MySQL database and, because of this, can be made quite secure. Like most database engines, implementation of user-level permissions are not only possible, but highly recommended for most applications. How many visitors to our blogs actually need to have administrator access to the database? Something tells me that number is between zero and none. So why is there only one shared login used by everyone from the administrator, to authors, to subscribers, to occasional visitors? Security should never be handled by anything other than the database itself. Why over-complicate things?

If I had written my database applications so haphazardly back in Canada, I would have been fired for incompetence. Most of the WordPress developers I’ve had the opportunity to chat with have seemed quite intelligent and would have a good understanding of security methods. Because of this, I’m forced to wonder if someone is holding back this tried and true method of securing a database from unwanted insert, update, delete and drop functions.

WordPress should have a requirement of at least two database logins. One for the administrator, which can only be used from within the administration panel. And one with read-only access (a.k.a. select) to the primary WordPress data tables, which would be used by everyone (including the administrator and content creators) when viewing the site itself.

The advantage of having the world-facing code limited to read-only access for all viewers is to prevent malicious theme-writers from gaining access to our most important database records. Of course, there would still be the potential for exploits through other plugins, but by nipping the one area in the bud, the chances of hacking will be reduced. There are far more themes downloaded from less-than-trustworthy sites than plugins. Naturally, there would be some tables that would need to have both read and write permissions, but these would be few and far between. Stats packages, the comments table, various superfluous plugins what collect polls and other data from users. The list can go on forever, but the need for unrestricted database access should not.

Naturally, there are some disadvantages to a design like this. Commentors would no longer have the option to edit their comments (since that would be considered an update command, and those would need to be restricted to administrators and content creators only to prevent malicious code from modifying our existing posts and comments), and there could be some issues with other functions that require permissions of select, insert, update and delete, but these would be few and far between.

If You Really Want Us To Upgrade, Hire A Professional Promotions Officer

Many long-time WordPress bloggers have become tired of the same old pattern. Every few months there’s a “major” release of the blogging platform made available and, without fail, every few months there’s a senior developer saying that everything prior to the most current version is crap and we should all upgrade to prevent whatever serious security flaws were discovered since the last. The amount of energy and effort that these programmers and designers put into the WordPress platform is often inspiring and a testament to the power of the web.

Nothing can be 100% secure all the time and, considering how most of us have used Microsoft products for several years, we’ve come to expect the occasional hiccup or flaw in code. At the end of the day, humans are writing the software, and we all know that nobody is perfect. So why do we have to hear the same “OH SH**! YOU’RE SITE IS SO EXPOSED!” tripe with every release? Why are we told that plugin developers are responsible for keeping up with the changes in the WordPress core when the key architects of these changes are not effectively communicating with some of the internet’s best plugin authors, thus alienating them from the process?

Despite the various complaints I’ve made over the years about the software, WordPress is still one of the best blogging platforms available on the web. I can say this because I’ve tested and supported almost every major web platform that’s been released in the last two years, both paid and open-source. However, if people are forever hearing the same fear-mongering chants every few months from the very people that write and support the code, then long-time bloggers will eventually start porting over to other platforms where the advertising department knows how to properly sell the advantages of an upgrade.

The people that really need to “get over it” and make the big changes aren’t the bloggers that use the software.