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.

0.5 contains a couple of new features, which between them encompass a large proportion of the feature requests I have received over the last few months. Here’s a brief overview of the new stuff:

Event Display Builder

The old display options were pretty inflexible, and made things like showing the start and end time on the same line impossible, without hacking about with the code. The event display builder makes things such as this much easier.

I won’t go into too much depth here, as I’ve written an extensive guide, with examples, on how to use the feature. Some of the things that are now possible, that were previously difficult / impossible, are listed below:

• Handling of all-day events – Previously, you couldn’t differentiate between all-day and normal events, so start and end times for all-day events would be displayed as ’12:00 am’, which could be confusing. Now, using the [if-all-day] and [if-not-all-day] shortcodes in the event display builder, you could display something like ‘All day’ rather than the start / end times for all-day events, whilst still showing the start / end times for ‘normal’ events.
• HTML and Markdown parsing – If you enter HTML into any of the Google Calendar fields (title, location, description) it is sent as plain text in the feed data. Now, using the html attribute, the plugin can convert the plain text back to HTML and display it as such. Markdown can also be parsed (if you have PHP Markdown installed), using the markdown attribute. Thanks go to James Hicks for the Markdown stuff.
• Greater control over the markup – You can now use whatever markup you like to structure the event information. This also allows you to change the ordering of the event information, or display several things on the same line, or make the event title into a link, or anything you like! You can also generate feed-specific CSS classes using the [feed-id] shortcode.

If you have ideas for any other useful shortcodes for the event display builder, or have noticed any bugs, please let me know in the comments below, or here.

Flexible Event Retrieval Date Range

Previously, the date ranges you could specify for retrieval of events from a feed were very limiting. You could retrieve from 00:00 ‘today’, or from the beginning of the month, but that’s it. With the new ‘Retrieve events from’ and ‘Retrieve events until’ settings you have much greater control over the date range.

The options you can choose from are as follows:

• Now
• 00:00 today
• Start of current week
• Start of current month
• End of current month
• The beginning of time (Retrieve from only)
• The end of time (Retrieve until only)
• Specific date / time

However, you can also specify an offset, in seconds, to the above options (except for the last three), allowing a lot of flexibility. Here’s a few examples:

• Date range required:All of time!
  • Retrieve events from: The beginning of time
  • Retrieve events until: The end of time
• Date range required:The past
  • Retrieve events from: The beginning of time
  • Retrieve events until: Now
• Date range required:The future
  • Retrieve events from: Now
  • Retrieve events until: The end of time
• Date range required:Today
  • Retrieve events from: 00:00 today
  • Retrieve events until: 00:00 today, with an offset of 86400
• Date range required:This week
  • Retrieve events from: Start of current week
  • Retrieve events until: Start of current week, with an offset of 604800
• Date range required:Last week
  • Retrieve events from: Start of current week, with an offset of -604800
  • Retrieve events until: Start of current week
• Date range required:The past 12 hours and the next 12 hours
  • Retrieve events from: Now, with an offset of -43200
  • Retrieve events until: Now, with an offset of 43200
• Date range required:April 2011
  • Retrieve events from: Specific date / time (1301616000)
  • Retrieve events until: Specific date / time (1304208000)

These are just a few ideas, there’s lots of other possibilities too.

Custom Error Message

These are the two main error messages that the plugin displays if something has gone wrong:

The following feeds were not parsed successfully: 1. Please check that the feed URLs are correct and that the feeds have public sharing enabled.

No valid Feed IDs have been entered for this widget. Please check that you have entered the IDs correctly and that the Feeds have not been deleted.

You probably don’t want your site visitors to see these messages, so you can now specify a custom error message to display to non-admin users. As a logged-in admin user, you will still see the above messages.

You can upgrade to this version of the plugin through your WordPress admin, or by downloading from the WordPress plugin directory.

Many thanks to those that downloaded and tested the beta of version 0.5!

As always, any feedback is greatly appreciated. Add a comment below, or on the plugin homepage, or send me an email via the contact form.

Over the last couple of weeks, I managed to find a little time to spend developing my WordPress plugin, Google Calendar Events. I’ve implemented a couple of features / enhancements that I’m quite excited about, as I think they really add a lot of flexibility.

These features also encompass a large proportion of the requests I have had over the last few months, and should prevent a lot of the inelegant hacks that have been required to do various things in the past.

I have had to make some fairly significant changes to the code in order to implement the features, so I don’t want to release 0.5 straight away, just in case I’ve introduced (or re-introduced) any bugs. Any feedback on this beta ‘release’ would be greatly appreciated!

You can download the beta from the plugin directory (choose the ‘Development Version’). The beta version will still say it is 0.4.1 in the WordPress plugin admin, as I haven’t changed the readme file yet.

Here’s a quick explanation of the new stuff / changes:

Event Display Builder

I’m quite pleased with this feature, it’s pretty snazzy! I can’t really take much credit for it though, much of the concept and code behind it is ‘borrowed’ from the WordPress shortcode API.

The event display builder allows you customise the information that is displayed for each event in the grid tooltips or list. This is done by specifying a HTML structure containing shortcodes that will be replaced by the relevant event information when the grid or list is generated.

A brief explanation of the available shortcodes is below. I’ll write a more in-depth guide to these before release.

In addition to the above shortcodes, there are also logical / conditional shortcodes. Anything you enter between the opening and closing tags of the following shortcodes (including any further shortcodes!) will only be displayed if its conditions are met:

The possible attributes mentioned in the above tables are explained here:

Here’s an example of the sort of thing you could enter in the event display builder field:

<div class="gce-tooltip-event">[event-title] ([feed-title])</div>
[if-not-all-day]<div><strong>Time:</strong> From [start-time] until [end-time]</div>[/if-not-all-day]
[if-all-day]<div><strong>Time:</strong> All day</div>[/if-all-day]
[if-location]<div><strong>At: </strong> [maps-link newwindow="true"][location][/maps-link]</div>[/if-location]
[if-description]<div><strong>Description:</strong> [description html="true"]</div>[/if-description]

This would result in a tooltip something like the following:

Notice that the event display builder has allowed the following things, that were previously difficult / impossible:

• Differentiation between all-day and ‘normal’ events
• Display of feed titles
• Parsing of HTML entered in Google Calendar fields
• Linking to Google Maps
• Customisation of where information is displayed (start and end time on same line, for example)
• Ability to specify your own HTML and CSS classes, allowing for more styling possibilities

Obviously, this is a little more complex than the ‘old’ display options from current versions of the plugin and may take a little getting used to, especially for those without any knowledge of HTML. For this reason (and for backwards compatibility) the plugin still has the old display options available.

Flexible Retrieval Date / Time Range

In previous versions of the plugin, there wasn’t much flexibility in the date / time range of when events would be retrieved from the Google Calendar feed. The new options offer much more control, making the following ranges simple to set up:

• This month
  • Retrieve events from: Start of this month
  • Retrieve events until: End of this month
• The past
  • Retrieve events from: The beginning of time
  • Retrieve events until: Now
• The future
  • Retrieve events from: Now
  • Retrieve events until: The end of time
• The next 7 days (including today)
  • Retrieve events from: 00:00 today
  • Retrieve events until: Number of days (7)
• 1 hour ago until 1 hour from now
  • Retrieve events from: Number of seconds (-3600)
  • Retrieve events until: Number of seconds (3600)
• Events currently occuring
  • Retrieve events from: Now
  • Retrieve events until: Now
• Today until Christmas Day 2021
  • Retrieve events from: 00:00 today
  • Retrieve events until: Specific date (1640390400)

These are just a few examples, of course there are lots of other possibilities. Note that it may be necessary to reduce the cache duration when using smaller time ranges, to ensure that the plugin remains ‘up-to-date’.

Error Message

The error messages that the plugin outputs when something has gone wrong aren’t particularly friendly, and it’s unlikely that you’ll want your regular site visitors to see them. So, in the General Options for the plugin, you can now specify an error message that regular users will see if any error occurs that prevents the grid list from being displayed. Logged-in admin users will still see the old error messages, that give more information on the problem.

Memory

Previously, the plugin was loading SimplePie all the time, even when not needed. I think this may have been the cause of the memory limit issues that several people experienced. Now the plugin should only load SimplePie when it actually needs it!

Any feedback (good or bad!) on any of the new stuff would be very much appreciated. Obviously, this is just a ‘beta’ at the moment, so there may be some horrible bug lurking! I wouldn’t recommend that you use this on a live site, yet!
Specifically, feedback on the following would be great:

• Event display builder – any shortcode combinations that don’t work / produce unexpected results? Any ideas for more shortcodes?
• Date / time range options – are they accurate, especially in timezones other than UTC? Ideas for more options?
• Memory – if you were previously experiencing memory limit issues, are they resolved / better / worse now?
• Updating from previous versions – are your settings carried across properly?
• Usability – are the new options easy to understand? Are more instructions required?

Please use the comments below, or contact me directly.

Just in case you missed the link at the top, the beta can be downloaded here (choose the ‘Development Version’). The beta version will still say it is 0.4.1 in the WordPress plugin admin, as I haven’t changed the readme file yet.

Thanks!

I’m afraid it isn’t particularly exciting, as it is really only a bug fix release (albeit one that fixes a rather annoying and long-running bug). There are a few things to explain though:

Timezone Bug Fix

The bug caused the plugin to retrieve and display events from the previous day, even if the ‘Show past events…’ setting was disabled. This meant that, for many people who used the plugin to display a list of upcoming events, some of the events shown ended the previous day (confusing and rubbish).

The reason this occurred is due to the way Google Calendar handles date parameters that are sent to it, meaning that in some timezones (well, any really, except UTC), events outside of the required date range were retrieved.

To get around this, I have implemented a further check that ensures that events that have ended before the required start time (usually 00:00 ‘today’) are not displayed even if they have been retrieved.

The knock-on effect of this has is that the ‘Maximum number of events to retrieve’ setting can no longer be relied upon for the purposes of displaying an exact number of events. Therefore I have added a further option to the widget settings / shortcode parameters, explained below:

(Many thanks to David and Jamie for their assistance with identifying / fixing the bug)

Maximum Number of Events to Display Option

Previously, if you wanted to display events from the same feed in both a grid and list, but wanted to show a different number of events in each, you had to add two seperate feeds in the plugin with different values for the ‘Maximum number of events to retrieve’ option. With this new option, you can add one feed (setting the number of events to retrieve to the higher value) and use it for both the grid and list, specifying the number of events to display in the widget / shortcode settings.

The widget option is fairly self explanatory; there is simply a new textbox into which you enter the required number of events to display.

For the shortcode, a new parameter has been added (max), which you use something like this:

[google-calendar-events id="1" type="list-grouped" title="Events on" max="5"]

If you want to display all the events that have been retrieved, set this to 0.

Note: As mentioned earlier, the ‘Maximum number of events to retrieve’ setting can’t be relied upon for displaying an exact number of events (whereas this new option can), so it should be set to retrieve a few more events that you actually require, to allow for the timezone issue (and also caching). Don’t set it to retrieve hundreds of events if you only want it to display 3 though! 5-10 more than required should be plenty for most cases.

Extra Bits and Bobs

I took the opportunity to also add / fix a few extra things that I have been meaning to do:

• i18n fix: There was a slight error with the language files path, which has now been corrected
• widget_title filter support: Props to James!
• Hungarian translation: Many thanks to Takács Dániel for this (apologies for the delay)!
• Minification of qTip plugin: Minification reduces its size by more than half. I’ve no idea why I didn’t do this from the beginning

Now that the timezone bug has been eradicated (fingers crossed!), I can concentrate on adding snazzy features. I can’t promise anything, as I’m quite busy with other things at the moment, but I’ll try to ensure gaps between releases are not quite as large as between 0.4 and 0.4.1!

Download the new version from the WordPress plugin directory, or update automatically from within your WordPress admin.

As usual, all feedback is appreciated. Add comments here, or on the main plugin page. Thanks!