I’m not usually a massive fan of South Park but I have to say this episode about there being no more internet tickled me somewhat. The hilarity of the concept was one thing, but the sheer dependency on the service shown by the characters added a whole new level of amusement as of course did the concept that the internet can just shut down universally and only originates from one location. RouterTech fans will note that “The Internet” appears to be a large Linksys wireless router with the tell-tale flashing ADSL light that frequently occurs when ADSL sync cannot be acheived. As the saying always goes “Have you tried turning it off and on again?”

Looks like I’m not suitable for a career in IT because I can’t read paragraphs in 2 seconds flat and answer questions on them in an online test. But oh yeah, thats right, you need to be able to do that when you’re working with low level programming and mathematics don’t you. Sure, I can read. Sure, I can assimilate information. Can I do it before you can finish saying “Jack Robinson”? No. What do you think I’ve spent my last 5 years doing? Reading Shakespeare? For fucks sake.

I run the legacy 2.0.x branch of WordPress. I’m often asked why I don’t upgrade and I’ve decided to voice my reasons here and talk about using legacy software in general.

My reasons for not upgrading are simple. I don’t want to have to update regularly, simple as. I’m very busy and I run a lot of blogs. Upgrading all of them takes time, time that I don’t have. The legacy branch is supported and secure. It is only updated for security reasons and because its had a few updates in the past, new issues hardly ever arise - indeed I haven’t needed to update in months. Sure I don’t get the shiny new features, but these are not numerous and I don’t need them to maintain good websites. By spending less time upgrading I spend more time writing and more time developing software.

I am continually surprised by the attitude of plugin developers concerning people running the legacy branch. Many will release a security update for their plugin and at the same time introduce new features which require the latest WordPress version thereby preventing legacy users fixing their security holes. This is annoying because I am faced with a choice; keep the insecure version, stop using the plugin or back port the fix. Clearly I’m not going to use an insecure version and removing the plugin would reduce my sites functionality, so I end up having to take the time to back port the fixes.

In my eyes plugin authors should do one of two things; only use features that are available in the legacy branch thus keeping their updates accessible to all or maintain two branches themselves. Leaving users high and dry without security fixes is just not acceptable. I run a legacy version to save time. Many newbies however run the legacy version because they find upgrading daunting and they don’t want the hassle. This is particularly note-worthy as it is the newbies who cannot back port fixes and they WILL end up running insecure versions.

When developing Calendar I take the time to ensure that legacy users can run the plugin. I even pay careful attention to the server requirements of the legacy version of WordPress so that users staying on the legacy version for this reason can still use the plugin (see my update to support certain versions of MySQL). This doesn’t take much effort. Why can’t everyone do this?

Forgive me for ranting but this is a very important issue. Running a hosting company as I do I’m continually concerned by the scripts users are running, particularly those with security holes. A lot of my time is spent helping users upgrade and advising them on the best course of action concerning loss of functionality after an upgrade. Dougal Campbel notes that upgrading is important, even at the expense of functionality. I believe we should be able to have both. Some comment authors on Dougal’s article seem to agree with me. Upgrades to WordPress shouldn’t break plugins (but they do), neither should plugin updates remove support for the legacy branch (but they do). To users it is WordPress *and* the plugins that make their site, not one or the other. Developers clearly don’t agree with the users.

Come on people, get it together, it doesn’t have to be this way.

So I’ve been bought golf lessons for 4 people at a charity auction and I need to find 3 other people from in and around Leeds to join me in taking them. It will just be one lesson, on some weekend in the not too distant future although obviously a date wouldn’t be set without either having the right number of people or ensuring that all of said people could make it.

Back in St. Albans there are a number of people who I would have asked directly, but here in Leeds things are a little different and I’m not so aware of the golfing landscape amongst friends so I figured posting here was easiest.

Essentially all that is required is an interest. Having played before would help significantly, but you certainly don’t have to be any good. Nor do you need your own clubs although you would be welcome to use them. If you know me (no random blog readers please) and are interested then please get in touch. If you need a clincher, remember, its FREE

Its about time I offered my users an update given its a while since I last discussed the plugin.

I have been very busy on other things recently which means progress has been rather slow and bitty. That being said most of the requested and accepted features from my last consultation have now been implemented and have been seen to work on my development machine.

The following features have been added since there was last an update

• Changeable styles. Inline styles are no more and there is now a dedicated area on the new Calendar options page to edit the stylesheet directly.
• Users other than Administrator can edit events if the Administrator changes a setting on the Calendar options page.
• There is now an option to show the event author on the pop up for each event. This is set on the Calendar options page. This also means that for budding developers there is now a user ID by each event in the database allowing interesting things to be done with the plugin data.
• There is a set of drop down boxes to jump straight to a given year and month. This can be shown or hidden based on a setting on the Calendar options page.
• The description can now be any length. There is a text box to show this fact on the manage events screen instead of the small box that was there before.
• The dates can be selected from pop up mini-calendars meaning you don’t have to check somewhere else if you are choosing the right date. This system also prevents you from selecting a finishing date which is before the starting one which caused some problems when done accidentally in the past.
• The 30 character limit for the event title is now visibly enforced so that users are not surprised by their title appearing truncated.
• HTML errors have been fixed by ensuring that all styling is placed in the header of the page and not in the body.
• Seeing as WordPress 2.5 has recently been released, compatibility with this was coded in. This brings the range of WordPress branches the plugin is compatble with to 5; 2.0, 2.1, 2.2, 2.3, 2.5. It is of course worth noting that the only versions you should be running are the 2.0 legacy branch and the latest 2.5 branch.

Two main features do remain to be implemented. These are

• Event Categories
• Upcoming Events

All this means that a release does draw ever closer. I have been spurred on in particular by the release of 2.5 as I note that the current Calendar version doesn’t support 2.5. I have also been getting increasing support requests concerning things that don’t work on Calendar 1.1. I ask that you all hold off on these requests; you can be sure your issue will be fixed in Calendar 1.2.

Most importantly thanks for your patience and for deciding to use my plugin.