WordPress, the publishing engine that powers this site, has today seen the release of of an update to version 2.04. It can be warmly welcomed as it not only fixes more old bugs but corrects the mistakes that were left loose in 2.03 and secures some further vulnerabilities that have come to light. I for one, am quite happy with the progress of WordPress. Since I first started to learn my way round it just prior to the release of 1.5, it has become more rugged and, I believe, faster and more responsive.

Also in the works is the next future major release – 2.1 – which I have been playing with for the last few days, the second alpha being available for anyone who wants to see what is coming along soon. As anyone would expect, there are things I like and things I don’t which was also the case with 2.0 and most probably applies to most users. Surely everyone has a ‘feature’ they desperately want to see included just as there are new things implemented that make you scratch your head and wonder who on earth thought it would be a good idea.

What I don’t see and what is very much needed, is a re-visit to some of the older code to bring about some consistency of approach and to clean up some glaring disparities. I for one, and I suspect I am not alone, would prefer to see some effort going in to improving what is already there and making it more usable and consistent than simply adding new features for the sake of it – especially when they are of questionable importance and even more so when they have a negative effect on currently developed themes and plugins.

For example, and this is only a single example – 2.1 will see the demise of specific Link Categories in favour of a global pool of categories to be shared between links and posts. I can see some reasoning behind this decision and I can also see that it will upset a lot of people who define their categories with care and structure. It will be fine if I am given new template tags so that my link specific categories do not show up in my post categories list and visa versa but even that will be a burden for all those users who are uncomfortable editing their templates and code – which is probably the majority. What looks to be a fairly small change can quickly get out of hand and have users throwing up their hands in horror and hitting the support forum. This is even more likely when you take into account that in the past, documentation regarding features in an update has been virtually non-existent.

So – is this a feature of ‘questionable importance’? Well that depends what hat I am wearing when I answer the question. As a user of WordPress facing altering my templates and possibly re-structing my categories then yes – it is absolutely unwanted. As a software designer, having looked at the disparate database structure and the code behind it then I would want to clean it up once and for all.

Which leads to my next problem. Disparity of design and implementation. WordPress, as we all know, is open source software – coded, tested and documented largely by volunteers without financial reward. And it often shows that a team of developers are at work with only a very brief design framework to work within. Take a trip through the various administration panels that are home to all users of the software. There is a tremendous lack of consistency in the way they function, in the naming of buttons and controls, in the sizes of fonts and layouts. In itself, as long as it all works, this is not that important – although it would be good to see the Shuttle designs implemented to address this. The real problem is that these disparate implementations run deeper than the visual interface.

Take, for instance, template tags. Without doubt, template tags are wonderful. They are part of the backbone of what makes the design of WordPress powered sites and the ability to produce site specific code simplicity itself. But there is a terrible lack of consistency within the tag library that is long past due for an overhaul.

As a first example, there is one tag that will allow me to display an unordered list of my links sorted into their categories. This tag is get_links_list(). But if I want to use this, it also embeds h2 tags around the category name. I am not given the choice to select my own HTML heading tag and within my site design, h2 isn’t the one I need. This is the only tag that I am aware of – although there may be others I haven’t used – that forces a heading tag into the output. What’s more, this tag does not, I believe, enclose the list with the ul tag.

The tag list_cats() on the other hand, allows me to pass an argument on whether I want this as a list and if so includes the ul tags as well as allowing me to set a large number of other options in the process. But wp_list_pages() does not return the ul tag although it does allow me to set which h tag I want to use for the optional heading.

A second example of tag inconsistency can be seen with the comment_link() tag. This tag generously allows me to have it return the value only so that I can pick it up in code without displaying it and therefore format the result as I wish. But where this would be really useful, in the previous_post() and next_post() tags, it is not catered for meaning that if you want to display your post links in any special way, you need to go through coding hoops to achieve it.

These are just a few random examples of where it looks obvious that different people, with different ideas, developed parts of the core without a set of pre-determined guidelines. There are others. Just about all software is guilty of this to some degree or another. I know from my own experience in the industry that going back to clean up these inconsistencies is always put on the back burner in favour of new bells and whistles. But I also believe that it is a mistake. Even when there are many thousands of apparently satisfied customers.

A little over a year ago, when this site was quite new, I wrote an item entitled Problems in the WordPress Camp which followed a couple of hastily released security updates that left many users floundering and confused. I raised a small handful of criticisms in that item and it is sad to see that they still hold true a year later. I am speaking specifically here about the relationship between the core development team and people like me – users who construct a few simple plugins and then wait for the next release preparing for them to break.

There has been an interesting discussion this past week on one of the WP mailing lists concerning a potential security vulnerability that many plugins may not be avoiding. Those in the know stated that authors needed to do this and that to ensure their users were ’safe’. I, along with a couple of others, asked a very simple question – where are the instructions? If we are meant to adhere to a set of rules in our code – where are those rules to be found? Not an unreasonable question. We were not there at the birth of WordPress – we did not help design the plugin and the security infrastructure. The important point however, is that we received no reply. In other words, it isn’t written down anywhere. There are no guidelines, no set of rules, no do’s and don’ts except for a few pointers in the codex, none of which I have found deal with the security issues. But even more importantly, having identified the problem, the core team are still unwilling to answer the question.

I have learnt a lot about the plugin architecture by dissecting other peoples code but I have no way of knowing if the code I have been learning from follows the mythical rules! I sincerely hope it does though.

I have said enough. Here is a short list of the things I would personally like to see the WordPress core team deliver before worrying about new features. They are in no particular order and I feel sure a lot of people would disagree with many or even all of the items but for me they would be big ticket improvements.

• Bring consistency to all template tags allowing users to specify all formatting and whether to ‘echo’ to the screen.
• Publish well in advance all future changes that effect structure, database tables, data and operation – preferably in plain language as well as technical.
• Publish the definitive rule set to plugin authorship.
• Build a central repository for plugin details and a mechanism for users to find out that there are updates out there.
• When a WordPress update is published (as opposed to a major release) it is never necessary to replace everything. Let us know at the time exactly which files need to be replaced.
• Tell us what has changed in an update. It doesn’t have to be a secret.
• Make the ‘Write Post’ admin screen consistent by allowing us to close the image upload area or – preferably – get rid of it altogether without resorting to editing core code.

That would be great for starters. Other than that – keep up the good work. WordPress is still special and I thoroughly applaud it.