So, before I get to the actual release link, some house rules. There will be no support for this release. If you choose to use it live, that is your shout, but if you break something or someone hacks you, its your fault and you will have to deal with it. What I am after here is bug reports and comprehensive testing. Comments about how well the tests are going, problems, bugs, security flaws are welcome. Such comments should be made in the comments field of this post only, nowhere else. I’m not taking comments and questions by e-mail because there will most likely be too many. Thanks for understanding!

Ok, so the Calendar 1.2 Beta 1 release is here. Instructions are in the readme.txt file, please read this first, especially if you are upgrading. If you are upgrading you should ensure you backup your blog and your current install of Calendar, including the database. You may very well need this if there are unforeseeable problems, or if there is an issue with the beta such that the upgrade feature fails and causes problems. Again, you test this at your own risk and while I can’t see any problems with it at my end, that doesn’t mean you won’t. If you find a problem, report it, I’ll fix it.

A final note is that those of you with keen eyes will note the Event Categories feature is missing. I don’t have much spare time as you all know so I’ve decided to leave this out of the beta because I don’t want to release something which I know to have issues due to the lack of time spent on it. During the beta phase I will work on this feature and it will make it into the final release. If testing is required of this added functionality then a beta 2 will be released instead of the final version in two weeks meaning the absolute final release will be 4 weeks from now. I hope however that because the categories feature will use much of what is being tested in the beta already, an additional beta will not be necessary.

Some keen eyed viewers will no doubt notice from what is visible that only one feature, “Event Categories”, as mentioned in one of my previous posts, remains to be implemented. Its close folks

In the light of seeing the plugin about to hit 10,000 downloads I’ve decided that the beta of the new version will be released when the 10,000 figure is hit. Comments will be invited from users on the blog post announcing the beta and any bugs reported will be fixed. When two weeks of beta testing have elapsed, the new version will go live

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.

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

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.