So, here it is, Calendar 1.2 Beta 1 finally seeing the light of day! I’d like to thank everyone for their patience in waiting for this, I hope after giving it a try you will feel the wait has been worthwhile. The final release will come two weeks from today, after people have had a chance to test the software and report bugs in the comments field of this post.

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.

I’m now running the development version of Calendar 1.2 on my publicly visible development server. You can see it running on Lara here. Comments are of course welcome, those who suggested features will no doubt spot some of them in action. Two screenshots are shown below to give you an overview of the new admin panel which you are not able to see on the development site.

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

So it looks like my Calendar plugin is in the top 100 list of WordPress plugins. This is a pleasant surprise and makes me wonder how much higher up the list the plugin might go when the new features go live. Thanks to all who use my plugin and have offered suggestions for its future development - its success is down to you.

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

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.

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.

It has come to my attention that a number of people have been posting comments on blog articles of mine asking for support for calendar when the subject of the post wasn’t even anything technical. Please don’t do this, it clutters things up for readers and confuses search engines. I have a contact page with an e-mail address which you can use to ask me for support. Please help me to keep things nice and ordered on the blog.

For those who frequent RouterTech it can’t have escaped your attention that we have recently released our v2.5 firmware. This was an important release for many reasons and marks an impressive milestone as we approach our 2 year birthday.

We now have over 4,000 community members, have had nearly 10,000 downloads of our firmware and have recently welcomed a new member to the RouterTech team. My impending graduation will give me a lot more time to work on the website and other aspects of the group so I hope things will get that little bit better in a few months time, if that is possible!

I had a quick hack around today with Calendar for WordPress and I have fixed some of the long standing bugs that while weren’t serious, were causing some people issues. I’ve also tightened up some of areas I considered sightly weaker than they should be on the security front and also introduced a few new features.

One of the most notable changes is in the way the links work on the new version. Personally I much prefer the clean URL structure that currently ships with Calendar, however this requires a modification to the .htaccess file which many users were having issues with. This was due to the vastly differing ways in which people had chosen to setup their blogs and permalink structures already chosen.

The new version will provide standard arguments-in-a-url style operation and nothing else. It will install and work on any blog configuration out of the box (even MU as I’ve had requests for it to work on that too) and without edits to the .htaccess file. Clean URLs however will only be possible with a code edit to the plugin file and the addition of lines in the .htaccess file. Because of the support time that .htaccess issues have consumed in the past, users making such changes on their own will have to choose to do so unsupported.

Below I have listed all the modifications made so far, but this is not an exhaustive list of everything that will make it into the next release.

• Security audit resulting in increased code injection protection of argument strings
• Removed the need to edit the .htaccess file
• Removed clean URLs by default as these were causing issues for novices
• Placed the whole plugin into one file; install is now just a case of dropping this file into your plugins directory and activating it
• Enabled compatibility with WordPress MU
• Fixed the bug in the admin screen that would cause IE users to not see the dates, times etc. in add/edit event the form.
• Allowed the week to start on a Sunday. Users who have their WordPress options set to Sunday as the starting day of the week will see the calendar obeying the setting.

A release will be made in the next few days both here and on the WordPress plugins repository. If anyone has anything in particular they would like to see in the next version then shout in comments.

Recently an upgrade on my hosting server has been conducted, making a change from predominantly PHP4 (PHP5 available but not widely used) to predominantly PHP5 (PHP4 available but infrequently used). This has been prompted by the announcement by PHP developers that support for PHP4 will be discontinued at the end of the year.

I didn’t think there would be any issues with the migration as I have long been coding in a PHP5 compatible way, however after the move Halifax Online suffered a few issues. After much investigation I discovered that this was due to some deprecated code use within some functions in a party application which had been added to the site. This was easily fixed, but the issue its self is rather interesting.

It is common practice to store ephemeral data in loops and pass this data along to other loops or functions. While the actual variable name doesn’t matter so long as it is consistent, it makes sense to name it something which indicates that the data is for use only in situ and is ephemeral. The developer of the problematic application had used a variable named $this to perform this action.

Name wise this makes a lot of sense because it indicates quite clearly that the content of the variable is ephemeral and for use only in situ, especially with respect to functions. The problem is that $this is somewhat reserved under PHP5 and so while can be read from under ordinary circumstances, cannot be written to. This is because in an object orientated environment it is used to represent the current object in which a piece of code resides, and so changing it within this context has no meaning; changing attributes of it makes sense, but changing the whole thing (as the code was effectively doing by assigning it a value) is impossible. Can I demolish and rebuild my house while still inside it?

I just thought I’d share this little gem with folk who are trying to make their applications PHP5 compatible before the end of the year. It took me quite a while to find because I was looking primarily for deprecated function use, not variable use.

I’ve had many people contact me since I launched my Calendar plugin to wordpress.org asking if it is possible to change the day the week starts on from Monday to Sunday. Now obviously I’m aware that some people do start the week on Sunday, but I had never realised quite how many people this was until the use of my plugin became widespread and I must say I’m still really perplexed as to why.

The working week the whole world over is Monday through Friday, with Saturday and Sunday being affectionately known as the “week end”. This being the case, how can Sunday be the start of the week on a calendar when it is one of the days that constitutes the week end? Surely it is a contradiction in terms? Visibly this would make the week end split up at opposite sides of the calendar.

Due to demand I will be allowing users of the next version of my Calendar to change the day the week starts on but in the mean time I’d very much like comments on why some might start the week on a Sunday. Any financial, economic, religious etc. reasons with online references to further explanations would particularly helpful.