Posts Tagged ‘WordPress’

Posted on November 5, 2007 in WordPress by Andy @ Yellow Swordfish3 Comments »

If you use WordPress to run a website and you allow people to leave comments then you will know what a pain in the arse comment spam is. Waking up in the morning to two or three hundred unwanted messages is enough to almost turn you to drink especially when spam comment after spam comment is full of a couple of hundred links to videos and pictures of people purporting to put just about any object you can imagine into every human orifice you know about – and sometimes ones you don’t. And the problem, of course, is that hidden in that morass of spam ads for penis enhancers and nipple polishers are a few that are genuine and that you want to publish and respond to.

Which is why, some time ago now, the Automattic team, the same people who develop WordPress, launched Akismet, a service – free to non-commercial users – and a WordPress plugin that does a pretty good job at identifying spam and helping you remove it. Note the distinction there; not get rid of it but help you remove it. The back-end service, to which each comment is presented to receive judgement and sentencing, is pretty good at learning what is and is not spam and marking your inbound comments accordingly. The plugin at the front-end, however, is pretty damn useless. I note, though, that this may be a minority view as most users seem to give it nothing but praise.

The problem, of course, is that the back-end is not perfect and false positives do occur. I get them regularly so I still end up ploughing my way through hundreds of junk comments every week to isolate the gold nuggets from the silt. Which is exactly what I would be doing if I did not have Akismet installed. So the question becomes – what benefit is there in using the Akismet plugin? And my answer to that is, well, none really. But it would take very little to make me change my mind. All it needs are a few simple options.

The vast majority of comment spam that I receive these days consists of endless lists and links, often a hundred or more. An option that says simply, “if the comment includes X number of external links then by all means check it out but please don’t bother showing it to me – just get rid of the bloody thing” would probably remove a good 75% right there. Maybe even more. An option that says “if you find any of these words in the comment text then blow it away” could account for a few more. All I am talking about here is pruning down the daily bombardment to a smaller, more manageable amount so that I can trawl a smaller list looking for the odd one that was misdiagnosed.

It’s the same model as I, and I suspect most people, use to deal with junk mail through the post. The morning mail arrives on the doormat. You scan it all and it generally falls into three categories. The genuine mail, the stuff that looks like junk but might not be and the pure junk. And surely nobody spends time with the pure junk. Mine goes straight into the recycling bin unopened.

It would be nice if Akismet could do the same for my daily dose of unwanted comments.

Posted on July 28, 2007 in The Web by Andy @ Yellow Swordfish4 Comments »

OK – I have trimmed out all of the fat and gone back to blue. As well as resurrected an old colophon from the past.
One other thing I have done is to remove all of my own WordPress plugins and my Support Forum and moved them to a sub-domain Stuff at Yellow Swordfish, stuff being, I recall my oldest son once telling me, a ‘technical term’.

I’ve removed all of the AJAX stuff and fancy bits and gone right back to basics. And hopefully it will be a little quicker and responsive now as well.

Posted on April 12, 2007 in The Web by Andy @ Yellow Swordfish2 Comments »

I have been absent from these pages for over a week now. This is largely because I have been completing the latest version of my forum plugin. It’s not the problems, little bugs and support that ends up taking the most time; it’s actually all the good ideas that people keep coming up with, so many of which I can’t resist. But at the same time I have been tiring of the ‘blue’ look to the site and felt it needed a refresh. Which also tied in nicely with one of the reasons I started this site in the first place.

Originally I just used it as a learning device. I was new to php, css, xhtml, rss and lots of other acronyms and wanted to learn. I wont say I have conquered them but at least I now know what they all mean and how they all work. So the next challenge I wanted to have a go at was scalability and to swap from blue to red.

It’s not perfect and there is still some CSS to tweak and little things to alter but the goal was to create a theme that still worked when a user hits the control + (or, for us Mac users, the Apple +). So wherever possible, although not complete yet, I have eradicated fixed pixel widths in favour of ‘ems’, fixed font sizes in favour of percentages and on the whole it is hanging together as planned. Even, I believe, in Internet Explorer 6. Well, almost.

Posted on January 8, 2007 in Habari by Andy @ Yellow Swordfish15 Comments »

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.

Posted on January 5, 2007 in WordPress by Andy @ Yellow Swordfish6 Comments »

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!