There appears to be some disquiet in the WordPress community following the latest security update, the fourth in just a few short weeks. As a newcomer to WordPress of just a couple of months, I am saddened to see harsh criticism coming from unexpected quarters. Both MacManX and Angsuman – two regular support hero’s – being openly critical of the platform and the updates. And, as happened with previous patches, a lot of the userbase having problems with the upgrade.

WordPress is a great piece of software. I personally chose it because I wanted the twin challenges of finally learning CSS and starting to master PHP. Therefore my requirements were technical and the weblog itself almost a by-product. I don’t go out of my way to encourage visitors – although they are nice to have.

But most users are not like me and that is where the problems start. So I woke this morning deciding to put up my two cents worth of what I hope is constructive criticism of the platform.

The catch 22 of Open Source software

Because Open Source software is essentially free to the user, there is a tendency for people to feel that being critical is somehow ‘unfair’ to the development team behind it. They toil away at all hours, often out of love for the project and so to be critical of their efforts is somehow thought to be almost like a personal attack. But this is an irrational viewpoint. Anyone starting and controlling an open source project needs to have an army of users. Without users of the software there is little point in doing it. And once you have made that commitment to produce the software you also have to accept the responsibility that goes with it. That not only includes ensuring the software is secure and performs as advertised, but, more importantly, also means ensuring that the software actually works. As an ex-programmer, the mantra has always been the same: test, test and test again. Then give it to someone else to test as programmers make awful testers of their own code.

The Update Style

The WordPress team make it hard on themselves – and more importantly on the support forum volunteers – by the very way they announce and distribute updates. !.5.1.3 is a good example. The instructions are to remove basically everything and replace it with new files. It is left to support volunteers and ordinary users to point out that only five files actually need replacing. So the people who removed all the files in a folder, which included third party plugin files, could have been saved a lot of heartache if only decent update instructions accompanied the software. There have been no such instructions on the four updates I have undertaken – but I am a savvy user. Most are not so they do as they are told. Delete the lot and replace. Out go plugin files and even the config file is at risk with such orders. But even non-savvy users can follow simply written instructions if they are clear and precise.

The 5 Minute Install Myth

Well, it took me less than 5 minutes to install WordPress on my host. But that was because I already knew what MySQL and PHP were and already checked all was available and turned on. Mention ‘Apache’ to me and I know what you are talking about. But the vast majority of weblog users probably don’t have a clue. So they inevitably get in a mess and then appear on the support forums asking the same questions over and over again.

The Codex is admirable and has undergone a vast improvement in recent weeks thanks to major efforts by a team of volunteers. But a new user does not expect to have to resort to an online repository just to install the software. They rightfully expect a decent set of instructions to come with the program. It might have changed but the instructions I received with the software made no mention of looking in the Codex for answers to common problems. So you hit support.

It is a common failing with open source software projects, and the reasons are obvious, that documentation and instructions are often scant and often couched towards the technically able. Commercial software houses employ people to write user documentation that is geared towards the non-technical. Open source teams have yet to learn the distinction. Until they start to do this, they will alienate a lot of their potential users. And in the case of WordPress, those users will go off and start blogging somewhere else and tell everyone how awful WP is. Which is a shame and unnecessary because it is fundamentally a great piece of software.

Kubrick is a Big Mistake

While I am rattling the sabre I’ll say a few words about the default theme, Kubrick. It is actually a very good theme. Clean, simple and enjoyable to use. But it is, in my opinion, a great mistake to make it the default theme for new, inexperienced users.

And the reasons I say this is because it uses background images (the faux-column CSS technique) and some convoluted CSS. Out of the ‘box, when I signed on, Kubrick didn’t even pass CSS validation. The vast majority of support forum posts to do with themes is down to a complete lack of knowledge of CSS by the average user, and giving them Kubrick as a base to work with is totally confusing to most.

If the WP team keep with Kubrick as the default then explanatory notes of how the CSS in constructed is a must. As a savvy user inexperienced in CSS it took me a couple of weeks to work out what was what. And the worse bit of all? Some of the CSS is in the header.php file!

Kubrick needs documentation. WP should also try and provide a default theme that does not rely on images and scattered CSS. Not perhaps the ancient ‘Classic’, but one of the many themes that the strong userbase are starting to engineer. Simpler CSS for the unknowledgable to learn from.

The Responsibility that goes with Plugins

And finally! The plugin architecture of WordPress is wonderful. But it is also a major problem. When you design your software to be extensible and open the door wide to third party coders to add value to your product, you take on a responsibility to preserve their efforts. I use an Apple Mac. When Apple decide on changes to the core of OSX, they have a developer program that informs the third party coders of changes they may have to make to their applications – prior to the new release. So, the team at WordPress should be working with the plugin authors with advanced information on how to make changes so that their work will continue to function with every update.

I have just completed my first plugin but I am wondering about the wisdom of offering it to others because I have seen so many fail (through the support forum again) after an update has been applied. And the standard response is – go yell at the plugin developer. Sorry? Did the plugin developer KNOW that his code was suddenly going to be redundant?

The Bottom Line

I guess the bottom line is that WordPress could very well be in danger because of it’s own success. The more users it attracts the larger the proportion of people who are going to get the install wrong or mess up a plugin installation and cause themselves, and support, endless problems. And when they go looking elsewhere, they are going to take that bad news with them.

All I am suggesting is that the WordPress team take a long look at their userbase, acknowledge that the vast majority are just ordinary users who don’t know their FTP from their TCP and slow down a bit. When you issue the next important update, send it out with simple instructions so that people can upgrade without it blowing up in their faces.

People who know exactly what they are doing don’t mind the instructions being written for the non-tecnical. People who don’t have a clue what they are doing – need some basic hand holding. And then they will remain happy users.