News is surfacing all over the WordPress community and beyond of a fledgling, open-source based weblog/CMS project named Habari. Seemingly started by a small group well-known within the WordPress community it aims to be in direct competition and has been started out of certain frustrations with its elder and dominantly established platform.

I can both understand and sympathise with those frustrations. WordPress is a great piece of software and will be very hard to knock from its perch but it is going through the stage that all innovative software and indeed small companies go through that experience huge and unplanned for growth with the addition, as I have discussed before, of a certain arrogance at parent company Automattic. Avoiding the pitfalls that WordPress is experiencing is no easy task and decisions made by the Habari team now will inevitably come back to haunt them in the future.

Having myself been involved with both start-up companies and a clean slate within which to engineer new software applications, I know that those first few weeks and months are an exciting time, the ideas and the adrenaline flowing, exhausted fingers rattling the keyboard full of desire to get it all coded before the dream starts to evaporate. It is the most productive time in any software project but it is also the most dangerous.

The key to it of course is planning, which also, in my experience, tends to be the part that programmers in particular tend to disdain as it immediately starts to shackle their imagination. But if a project like Habari is to achieve success and, more importantly, sustained success, time spent at the beginning planning for the future is an imperative – before the project has actual users to worry about and before the project moves from the bedrooms and studies of two or three key people into the public domain and the inevitable conference and board room.

A week or so spent watching the WordPress support forum and subscribing to the various mailing lists is almost a lesson in futility. The same questions get repeated over and over again on the forums and the same suggestions get raised over and over again on the mailing lists. Leaving aside the sometimes arrogant dismissal of outsiders by the Automattic team, much of the problem with WordPress is the very fact that it is a juggernaut. Even a small change request that might be seen as a great benefit to the many is hard to accommodate because of the havoc it can wreak on the user-base. But often you can’t help thinking that many of those same requests actually make so much sense they should have been in the core product since the beginning.

The suspicion, of course, is that WordPress was started in the same way that so many projects are, by a couple of people with a vision and an itch to get it coded, never expecting that it would be the huge success that it has become. And seriously never realising the pressures that thousands of users can bring to bare when something goes wrong or when necessary changes can’t be made because of initial design limitations. In short, there was no plan for success.

I both applaud and welcome the Habari project. I will be one of the first to download an early cut when it becomes available and I look forward to watching it’s progress over the coming months. I suspect that it will be a bigger undertaking than anyone on the team yet anticipates but I wish them every success. The goals they have set themselves are admirable and I hope they achieve them. And while I understand that it’s both hard and a nuisance at this stage of the game, I implore the team to think long and hard about the future. A short-cut or compromise taken at the beginning for expediency more often than not turns into the nightmare that cannot be undone two years down the road.

For what it’s worth, here are a few of my main gripes with the WordPress world, leaving aside any actual software and usability issues. It is my contention that these points also need to be taken on board by any competitor:

• Installation: WordPress boasts a simple and quick install and, if you know what you are doing, it is. The reality is that most people don’t know what they are doing and a large number of them screw it up and then clutter the support forum. A proper, simple and guided installation process is a must.
• Upgrades: Again the WordPress method of upgrading is as bizarre as the lack of cohesive instructions on how to do it. With every release or even small update the recommended approach is to wipe out all files and upload a completely new set. This worries a lot of users and many, once again, get it wrong or worse, ignore security fixes and don’t upgrade at all. The lack of hand-holding through this difficult process – for most users – is a severe lack of sensitivity to the fact that the vast majority of users don’t even know what ftp is. Automatic or semi-automatic upgrades must be a goal from the early stages.
• Upgrade Details: This is a big and contentious issue. Trying to find out exactly what has been changed with any update, even big major releases, is like trying to pry information out of government agencies. Ask, and they shout ‘look at Trac’ which to the vast majority of users is, of course, gobbledygook! Transparency and information is a must to foster a good development community – plus it removes the unwanted surprises from users.
• Documentation: The WordPress Codex is large and expanding all the time and I applaud the efforts of those who contribute to it. The problem is that it’s an unqualified mess. It sprawls uncontrolled with no sense of structure or cohesion and the search facility is pretty worthless. The codex should be the first stop for problem solving but I suspect many people look, don’t find it easily and give up or go to the forum – usually to ask the same questions that come up daily! Easy to navigate, simply written but extensive documentation is an absolute must. Good documentation will keep the users questions at bay. And decent and comprehensive development documentation will go a long way to making a fledgling system a success.
• Support Forum: The WordPress forum does it’s job but because of the insistence on using lightweight sister product bbPress it leaves a lot to be desired – mainly in the search arena. Trying to find previous answers is a depressing ordeal yet the first thing the forum volunteers yell is ’search, search, search’. We would if it worked. So the tip here is use decent software that is up to the job.
• Themes and Plugins: Of course being able to build third party themes and to extend the base system through plugins are major strengths and I doubt any competitor would get out of the starting gate without offering this level of functionality. The problem is that WordPress takes no responsibility for the safety, quality and reliability of either. Whilst I understand that would be an awesome task to undertake, they do appear to endorse certain plugins by allowing them to be listed on the Codex. But anyone can add a plugin to the Codex – even a harmful, rogue one. I have always believed that WordPress should ‘own’ the central repository of plugins and themes and allow the user-base to endorse them.

Of course, to suggest that the Habari team have all these things in place from day one is a pipe dream. But I do implore the team to careful consideration early on and plan for the infrastructure they will need down the road because playing catch-up later rarely seems to work.

And then, of course, there is the raising of the cash to pay for it all…

For more information relating to this news you can visit key team members: Chris J.Davis, Khaled Abou Alfa, and Michael Heilemann at their respective homes.

Please Note:

My WordPress plugins have a new home.
If you would like to take a look at my plugins that are currently available please visit my plugin site and follow your nose – Stuff at Yellow Swordfish.

I have had something of another coding frenzy over the last four weeks which partly explains the lack of posts. Three and a half WP plugins although, of course, I have only published the three so far.

Interestingly two of them came about because I wanted specific plugins, of which there are a variety out there, but was unable to find ones that both worked and apparently still supported.

First up was an integrated forum sub-system. I do believe it is my responsibility to support my plugins but was finding it harder and harder to track issues, problems and suggestions through the comments system. A simple forum was the answer and I looked at various packages but really wanted something integrated in look and feel. There are a couple of good plugins available but one I just couldn’t get to work and the other appeared to be unsupported and abandoned.

So I created Simple Forum to do the job and am rather happy with it so far. The main problem is convincing people not to use the comments! But it is starting to get used as intended.

My next task was to sort out the download counter. It’s nice to see how many people download the plugins even knowing that a download does not equate necessarily to a user. The plugin I had been using had always given me trouble and I often found I had to go and edit the database table manually to correct data. So I hunted around for another one and again, there a few available. The only one I found that worked did much more than I needed so Download Counter was born. That’s all it does – track downloads. Simply and efficiently and – so far – correctly!

([Update 7th Jan 2007] After several months of the 2.1 alpha showing this behaviour and now, after the first official beta release, the dev team have suddenly decided that the category listing problem (described below) is a bug and are going to change it so I have withdrawn the following plugin.)
My final offering in this batch stems from a bit of a personal gripe. Soon to be released will be WordPress version 2.1 and, as I have discussed before on this site, Post Categories and Link Categories – up until now held as two separate entities – will be merged. I can see that this is a benefit to many – maybe even to most – but I like to keep my post and link categories separate.

The new implementation still allows me to do that but the annoyance – to me – is the fact that the category listing on the ‘Write Post’ page now lists ALL categories which firstly makes the list longer than need be and secondly makes it very easy to tick the wrong box! Hence, my third plugin called, rather clumsily, Post Category List Filter removes any categories that have ONLY ever been used for links. In other words, the list becomes filtered to the same list that WP 2.0 produces but includes any defined categories that have not yet been used for anything. Which makes me happy!

Like most people with one of these web loggy things, it’s nice to see statistics. You know the sort of thing: how many visits you’re getting; which items are getting repeat viewings and are more popular. That sort of thing. Sure, my host offers me a couple of options but they tend to be transitory and over-complicated.

As Yellow Swordfish is built on WordPress there are also a number of respectable plugins that will also do the job – usually from within the admin pages themselves. And I have tried several.

The first I tried was StatTraq which is very comprehensive and well presented but appeared to falter after one of the WP updates and then started to fail. Next I gave BAStats a try. This was my favourite actually but has never appeared to move out of beta and is, to be frank, somewhat buggy and is now, I fear, basically unsupported. And this I dumped after I started to see some very spurious data creeping in with no help in sight to get it sorted. The next to come under trial was WP-ShortStat which again is extremely well presented except that I disliked it! As simple as that! I particularly didn’t like the baggage of all the extra CSS that was getting loaded throughout my admin pages and before long I cast it aside and basically gave up on the whole idea.

But then along came a relative newcomer to the scene – FireStats – written by Omry Yadin. Omry has done a great job and FireStats delivers what you want efficiently and quickly. It fits well into the WP admin interface and he has made great use of AJAX routines to ensure that updates and changes are quick and smooth. But what I particularly like about FireStats is that Omry is very quick to respond to queries and to offer advice and take on board suggestions. And that is something many plugin authors don’t seem to want to do.

FireStats is still, at the time of writing, in beta. Yes there are one or two small bugs and anomalies but unlike some of the above, I have confidence that they will be sorted. And it seems Omry has some great plans to extend his software further. The one negative I have applies to all the statistics plugins I have tried and seen and that’s the lack of a way to stop the stored data tables becoming too huge to cope with. The more successful your site and the more visitors you have then the bigger this data storage will be and all packages need a way of periodically archiving data into ‘totals’ to keep the tables slimmer and more manageable. Omry assures me that this is on the ‘to do’ list for the near future.

I am using it now and am more than happy to wait for better things to come along as FireStats gets developed. And it has been something of a pleasure to be actually able to discuss the plugin with the author who has shown great patience helping me track down the odd problem or two. I wish Omry and FireStats the best of luck and look forward to future revisions. Maybe this time I have found one I can stick with.

Earlier this year during May, I wrote up a surprise email I had received from Chris Wilson, Group Program Manager for Internet Explorer at Microsoft. He was asking me why I had stated in an even earlier piece, that Yellow Swordfish looked pretty lousy in IE6 and had gone so far as putting a message over on the left (for IE6 users) stating that view.

He was, understandably, of the opinion that it looked and worked just fine in IE. We shot one or two friendly emails back and forth and he even helped out with a small HTML error I had coded in and, at the end of the day, left me with the distinct impression that the particular rendering issues and CSS non-compliance issues I raised would be fixed up in IE7.

And now IE7 is past it’s beta and is released and I have today taken a long hard look at the official version.

Sorry Chris. Nearly there. But I have taken the notice down so it’s going in the right direction.

The website of Sam Devol – Running With Scissors – is fast becoming a great repository of information for newcomers to WordPress with an abundance of step by step advice, troubleshooting tips and links to other sites that deal with specific issues. Sam is a regular on the WP support forum and has helped me out a few times in the past, including one or two fixes for some sloppy code, and he knows his stuff. It’s just a shame that so much of this useful material has to be hunted down outside of the official WordPress Codex.

Anyway, I have Sam to thank for another discovery. FireBug from Joe Hewitt. Yes I’m sure everyone knows about FireBug except me but I am bad at browsing so much of this stuff just passes me by. FireFox is not my browser of choice. But it is the browser I use just about all of the time. And that is largely because of the wonderful extensions that are available. As far as help with web development is concerned, I figured that the absolutely indispensable Web Developer Extension from Chris Pederick was the extension king. FireBug builds on that with even more fantastic help. As the author says: “FireBug lets you explore the far corners of the DOM by keyboard or mouse. All of the tools you need to poke, prod, and monitor your JavaScript, CSS, HTML and Ajax are brought together into one seamless experience, including a debugger, error console, command line, and a variety of fun inspectors.”

FireFox is not my browser of choice but it is more and more becoming the only browser possible for me to use.