So, if you saw lots of adverts and crap like that over the last few days, that’s why.

Also, apologies to the guy (Neill, I think?) who commented on one of my posts, mentioning the adverts. I thought it was spam, so I deleted it. Sorry!

Help Jane buy a bakery.

When I created the original design, I was just getting stared with WordPress, so didn’t fully understand the theme development process. I’ve certainly learnt a lot more in the last couple of years.

So, here’s the new design!

I’m more of a coder than a designer, so I decided to keep things simple and clean, with plenty of whitespace (or greyspace?). You might even call it “minimal”, possibly?

It should be pretty speedy, too. I’ve kept HTTP requests to a minimum, making use of as much CSS3 snazziness as possible.

Try it on your iPad / phone, it’s responsive too!

Anyhoo, I’m quite pleased with it, I think. It turned out to be one of those projects where you’ve been working on it for so long that you can no longer decide whether it’s brilliant, awful or somewhere in between.

A couple of months back, I did begin a major rewrite of the plugin, with all sorts of snazzy improvements, but it’s a long way off release worthy, or even beta worthy, at present. I’ll continue to work on it when I can, but I thought I’d better fix a couple of minor (yet annoying) bugs in the current version for the time being.

The fixes in 0.7.2 are as follows:

• There was an issue with the “More details” Google Calendar page link. The URL wasn’t constructed correctly, which resulted in the event details defaulting to the UTC timezone. This only affected the simple display options (not the event display builder), but is fixed now.
• Previously, setting the cache duration to 0 would be ignored, causing caching to still occur. Setting this to 0 should now work correctly.
• With FORCE_SSL_ADMIN enabled, the plugin’s Ajax requests would fail in most cases, preventing month navigation. This shouldn’t be the case any longer.

Also, an issue brought up in the WordPress core Trac recently made me realise I’d been using the wrong method (an incorrect hook) for enqueuing the plugin CSS and JavaScript, which could potentially cause an issue with the newly released 3.3 version of WordPress. I don’t think the issue would have affected Google Calendar Events, as I had is_admin() checks in place, but better to be safe (and correct) than sorry!

Before updating, remember that if you’ve made any changes to the main plugin stylesheet (google-calendar-events/css/gce-style.css), you should take a backup first, as changes will be overwritten during the update. If you’ve used the “Custom stylsheet URL” method instead, you shouldn’t need to worry about this!

You can download the update from the plugin directory, or simply update from your WordPress admin.

Feedback, bug reports and feature requests are always welcome. You can add a comment below (or on the plugin homepage), or send me an email.

Thanks!

Weird AJAX Bug

An odd bug was causing AJAX enabled calendar grids to disappear, or just get stuck loading, when navigating between months. It took me quite a while to replicate it, which was very frustrating, as several people had reported the same issue but I had no idea what was going on!

Anyway, I finally tracked down the problem. It was due to me being an idiot and not really understanding how preg_replace_callback works.

Stupid Timezones

Timezones are confusing. If I ever make another plugin, please remind me to make sure it has nothing to do with dates and times.

Hopefully, this release should fix an issue causing all-day events to continue to be displayed even after they have ended.

Tooltip Date Title Bug

In some cases, the title settings for AJAX grids were being ignored during AJAX requests. This release should fix that too. Many thanks to S. Wyatt Young for bringing my attention to this problem.

Output Sanitisation

Output sanitisation was a bit lacking in some places, but should be much improved now.

Caching Empty Feeds

Previously, the plugin did not cache feeds that returned no events. This meant that if you were displaying a list or grid of events from several feeds, one or more of which were empty, HTTP requests would be made for the empty feeds on every page load, which is slow.

Many thanks to everyone who reported the above issues, and helped with testing the fixes. It is very much appreciated!

As always, bug reports, feature requests and any other feedback can be left in the comments on the plugin homepage, or on this post.

Bugs

• Timezone issues: dates and times should now display in the correct timezone, regardless of the WordPress timezone setting. The plugin “Timezone adjustment” option should now work correctly
• [link-path] shortcode: this Event Display Builder shortcode has been changed to [url] to address an issue preventing it from working correctly
• Hidden page lists in Opera: page lists should now display correctly in Opera

Features / Enhancements

Descending order

Lists can now be displayed in descending order. This can be useful if you’re showing a list of past events. There’s a new drop-down box in the widget settings where you can choose the order. If you’re using the shortcode, there’s a new order parameter that can be set to asc or desc.

New Event Display Builder shortcodes

[cal-id] and [event-id] shortcodes have been added. These output unique identifiers assigned by Google for the calendar (feed) or event. These are most useful for constructing links to the XML or ical feeds for a single event.
For example, to construct the link to the .ics feed for a single event, you can enter the following into the Event Display Builder:

<a href="http://www.google.com/calendar/ical/[cal-id]/public/full/[event-id]">ics feed</a>

New Event Display Builder parameters

Two new parameters have been added. The first is offset. This can be applied to the date / time based shortcodes, and essentially adds an offset (in seconds, can be negative) to dates / times before they are formatted and displayed.
The second is autolink. This parameter can be applied to the description shortcode, and controls whether or not URLs entered in the description field in Google Calendar will be automatically made into “clickable” links.

CSS Classes

The plugin now adds classes to calendar grid cells to indicate whether the day that the cell represents is in the past or the future. Past days get a gce-day-past class and future days get gce-day-future.

Tidier CSS

The CSS stylesheet that the plugin provides had a few !important declarations in it, which made overriding certain styles difficult. These have been removed. Other minor tweaks have been made too.
I’ve added a new general option that, when enabled, adds another stylesheet that contains much of the old CSS. This is to prevent layouts of sites using 0.6 and below from going wonky straight away. It would be a good idea to adjust your CSS so that you don’t need this enabled. It will be removed at some point.

All Feeds

Previously, if you didn’t enter a feed ID into the widget settings, an error message would be displayed. The shortcode would display only feed 1 if the id parameter was omitted. Now, the plugin will display all feeds in these cases. This is more consistent, useful and intuitive. You can still specify comma-separated lists of feeds IDs as before too.

Many thanks to those who downloaded, tested and provided feedback on the beta of 0.7. It is very much appreciated!

Any feedback on the new version is also welcomed. Please leave a comment below, or on the main plugin homepage, or send me an email.

You can download 0.7 from the plugin directory.

Bugs

Here’s a list of the bugs that 0.7 will (hopefully!) address:

• Timezone issues: The last release introduced a bug that causes times / dates to be displayed in UTC, regardless of the ‘Timezone adjustment’ setting. This can be worked around by ensuring that the WordPress timezone (Settings > General) is set to a city and not a UTC+/- offset, but that’s hardly an ideal solution. This also affects the [if-now], [if-started] and similar event display builder shortcodes. Some general faffing with date functions should have fixed this
• [link-path] shortcode: This shortcode isn’t behaving correctly. It has been changed to [url] to fix this
• Opera CSS issue: There is a stray content:none is the CSS. I can’t remember why it’s there, but it certainly shouldn’t be! It causes an odd bug in Opera, preventing page lists from appearing. I’ve removed it

Enhancements

The enhancements 0.7 will incorporate:

• Descending order: The order of events in lists can be changed from ascending to descending, which is useful for lists of past events
• [event-id] and [cal-id] shortcodes: These allow you to output the unique IDs that Google assigns to events and calendars. They’re useful for constructing links to iCal feeds, for the whole calendar or just individual events
• CSS classes: The plugin will now add gce-day-past and gce-day-future classes to calendar grid cells, so you can style them differently. Also, depending on whether ‘today’ has some events, either gce-today-has-events or gce-today-no-events will be added (in addition to gce-today)
• offset parameter: There’s a new offset parameter for the date / time event display builder shortcodes. This allows you to adjust the date / time (by a number of seconds) before it is displayed. This is most useful currently for changing the end date of all day events, so that they appear to end on the ‘correct’ day. It’s used like this: [end-date offset="-1"]
• autolink parameter: URLs in the description field are currently automatically made into links. This is still the case by default, but can now be disabled with: [description autolink="false"]
• Tidier CSS: There are a few !important declarations in the CSS, which makes overriding certain things difficult and is pretty bad practice. These have been removed. There’s a new general option that allows you to continue to include the ‘old’ CSS stuff, so that existing layouts don’t go wonky

I think that’s it. I might add a couple of other bits and bobs before release if I get chance. I’ll properly document all this stuff when 0.7 is released.

Also, I’m gradually going through the code and ensuring it conforms to the WordPress coding standards, so there may be a little inconsistency in coding style in various places at the moment. Sorry about that if you’re reading the source!

I’d really appreciate some feedback on any of the various bug fixes and enhancements. Testing the timezone stuff would be especially helpful. If anyone could test and give feedback on the following, that would be great:

• The WordPress timezone should no longer have any effect on the display of dates / times
• The WordPress timezone should have an effect on stuff that requires the current time as a reference, such as some event display builder shortcodes (below), but it should no longer matter whether it is set to a city or a UTC+/- offset
• The ‘Timezone adjustment’ option in the feed settings should work correctly
• The following event display builder shortcodes should work properly and be accurate:
  • [if-now]
  • [if-not-now]
  • [if-started]
  • [if-not-started]
  • [if-ended]
  • [if-not-ended]
  • [start-human]
  • [end-human]

To test the beta, please download the development version of the plugin. Leave comments below, or on the plugin homepage. You can send me an email too, if you like. Thanks!

I’ve had some spare time over the last week (yay for Easter!), so I decided to really get to grips with these issues, and hopefully eradicate them.

I didn’t ‘officially’ announce a beta this time around, as I had some brilliant assistance from Derek and Tom, who tested several iterations of the in-development code and helped to iron out many issues and bugs along the way. Many thanks again to them!

Here’s a run-down of the changes:

Memory

The plugin has always had issues with memory, especially with large numbers of events and feeds. The changes in 0.5, that allowed you to specify a much greater date retrieval range and therefore potentially retrieve many more events, really pushed things too far and have caused many people’s sites to run into their (perfectly reasonable) PHP memory limits.

Unfortunately, the major cause of the memory issues was the SimplePie feed parser on which the plugin relied to do much of the hard work. SimplePie (with some help from WordPress’ class-feed.php) took care of feed retrieval, feed parsing and caching, meaning the plugin didn’t have to be bothered about any of this. However, the memory problems were too great to ignore any longer; SimplePie had to go!

Don’t get me wrong, SimplePie is great, it made things really simple (hence the name, I guess), but I just don’t think it’s quite the right solution for the plugin any longer.

So, the plugin now takes care of retrieval, parsing and caching itself. The result is a massive reduction in memory usage.

Don’t hold me to any figures, but I’ve done quite a bit of unscientific testing, and the reduction is roughly between 75-90%.

Caching

As I mentioned above, caching wasn’t directly controlled by the plugin in 0.5 and below. While this made things simple from a coding point of view, it wasn’t ideal. I won’t go into the details, as it’s complicated (and boring) but essentially the plugin created far too many caches of feed data, and never really cleaned up expired caches. Also, the feed data was cached in a completely raw state, meaning it was enormous and had to be processed from scratch each time. On top of that, the plugin couldn’t really keep track of what cached data existed, so it couldn’t be cleared on demand.

All of the problems above are addressed in 0.6:

• One feed, one cache – Now, there is one cache of feed data per feed. That’s it. You don’t need to worry about your database filling up with useless cached data, as the same cache will always be overwritten for each feed.
• Much less is cached – Now, the plugin caches processed data rather than the raw feed. This means that only useful information is stored. All the extra stuff sent along with the feed that the plugin doesn’t need is discarded, so there’s much less to keep in the database.
• Only processed once – As I said, the plugin processes the feed before caching it. Therefore some of the work only needs to be done once per cache, rather than every time a grid or list is requested.
• Refresh on demand – There’s a new ‘Refresh’ option for each feed you have added. This will clear the cache of the feed, forcing it to be recreated next time a grid or list is requested. This means it is no longer necessary to faff about changing the cache duration option to 0 in order to retrieve the most up-to-date data.

Of course, none of this solves the problem of existing, useless feed data that has been created by previous versions of the plugin. To address this, I have built in some functionality that detects whether you’re upgrading from 0.5 or below, and asks you whether or not you’d like to empty your database of expired cached data. This appears the first time you visit the plugin options screen after upgrading.

I would definitely recommend that you do clear the useless cached data, but you can choose to ignore it.

General Performance

I’ve done a bit of a ‘performance overhaul’ of the plugin. I fired up XDebug and WinCacheGrind and looked for bottlenecks. I’m sure that there’s more optimisation that could be done, but now the plugin should:

• Load faster – You may not notice it, but page load times should be faster due to generally more efficient code.
• Make fewer database queries – Maybe only a couple fewer here and there, but the less database hits, the better.
• Be quicker on AJAX requests – The plugin checks more carefully to ensure that only necessary stuff is done on AJAX requests. This should make month navigation in AJAX grids a little faster.

These bits and bobs may not sound much, but every little helps, especially on high traffic sites. Coupled with the major memory usage and caching improvements, the plugin is a much more efficient piece of software than it used to be.

Error Handling

Another handy side effect of the changes is that I was able to put together an improved error handling system.

In previous versions of the plugin, using multiple feeds in one grid / list, if any of the feeds were not parsed successfully, no events would be displayed, even if the remaining feeds were fine. Now, the plugin will ignore ‘broken’ feeds and continue to display events from any working feeds.

As a logged-in admin user, you will see error messages explaining the problems that are preventing each feed from being displayed. These messages are much more specific to the problem than the generic message displayed in previous versions of the plugin.

Other Changes / Additions

I’ve also implemented a few other miscellaneous things:

• Optimise event retrieval – There’s a new option in the general plugin settings. When enabled, the plugin will use experimental parameter of the Google Data Protocol, called fields. This parameter allows the plugin to specify exactly what data it needs, so that Google doesn’t send back any extra information that isn’t useful. This makes the feed data much smaller, meaning it takes less time to transfer, less time to process and uses less memory, resulting in a significant performance improvement. However, this is an experimental feature, so Google could potentially remove or change it an any time, possibly causing the plugin to break. Even though this is unlikely, I’ve made it an option rather than hard-code it into the plugin, just in case. Hopefully, Google will make this a ‘proper’ feature eventually… it’s awesome!
• Custom stylesheet – If you specify a custom stylesheet, it will be included as well as the default stylesheet, rather than instead of. This is so that if the custom stylesheet gets deleted or overwritten (for example, during plugin updates, as quite a few people have experienced!), the default one will still be there to ensure that the basic CSS rules required to prevent things going wonky are in place. This also means you don’t need to make a copy of the default stylesheet, you add only the CSS you want to change / override.
• Uninstall – If you delete the plugin via the WordPress plugin admin screen, it will ‘uninstall’ itself. This means it will remove all trace of itself from your database, including saved feeds and cached data.
• Now doesn’t mean now – In version 0.5, if you used the ‘Now’ option of either of the ‘Retrieve events from’ or ‘Retrieve events until’ settings, the plugin interpreted this as literally now, to the second. This had the effect of reducing the cache duration to 1 second, regardless of the cache duration option. In this version, the plugin rounds now to the previous minute, so that the minimum cache duration is also 1 minute when using the ‘Now’ options (unless you set the cache duration lower, but… don’t!). Events in Google Calendar are only precise to minutes anyway.
• Check for PHP 5.2 – The plugin requires PHP 5.2, as it now makes use of json_decode. The plugin has required PHP 5 for a long time, so this shouldn’t affect many, if any, existing users. There’s now a check to ensure that PHP 5.2+ is installed, if not, the plugin won’t activate and will display a message explaining why not. WordPress itself will also require PHP 5.2 (5.2.4 to be exact) as of version 3.2. I got the idea and implementation for this from Yoast.
• Improved multi-day event handling – Multi-day events are now handled correctly. They used to display outside of the specified date retrieval range, they don’t any more (Thanks Chris!).
• More event display builder shortcodes – I’ve added 3 new shortcodes: [if-multi-day], [if-single-day] and [length]. Take a look at the event display builder guide for explanations of these.
• Improved ‘human’ time differences – For the [start-human] and [end-human] event display builder shortcodes, the plugin was using the WordPress human_time_diff function. It works well, but is limited to minutes, hours and days. So, the plugin now uses an improved version of this function, as suggested in a WordPress trac ticket by Viper007Bond, which displays weeks, months and years too.

Bug fixes

I’ve fixed a couple of bugs too:

• Missing ctz parameter – Links created in the event display builder (with [link] or [link-path]) were missing the current timezone (ctz) parameter. This meant that anyone not currently logged into a Google account who clicked on one of these links would see event times in UTC time, rather than the correct timezone (Thanks to Jodi for spotting and reporting this).
• Clickable URLs – When using the simple display options, URLs in the description of an event would be automatically made into a ‘proper’ link. This should have occurred in the event display builder too, but didn’t. It does now (Thanks to Jim for pointing this out).
• HTTPS URLs – At some point, Google seems to have changed the default protocol for calendar feed URLs to https. On some server configurations, these https URLs failed to work (although simply changing https to http fixed the problem). Another side effect of the changes in this release is that this problem can be avoided, so both protocols should work just fine.

I think that’s about it. I’m hoping this release will be well received, as although it doesn’t add any terribly exciting features, it does solve some long running problems, which will allow the features added in 0.5 to really be used to their full potential.

You can update the plugin automatically from within your WordPress admin, or download it from the plugin directory.

Bug reports, feature requests, questions and any other feedback is always welcome. You can leave a comment below or on the plugin homepage, or send me an email.