Yesterday an ICS Calendar user started a new topic on the WordPress Support Forums, around strange timezone behavior they were observing on their website.
I set up a test scenario using one of my own calendars, and I verified that, yes indeed, if the site had both ICS Calendar and another calendar plugin — Modern Events Calendar Lite (which serves a different set of needs) — installed, there was very strange behavior.
The best I could guess was that it seemed to be causing a double calculation of timezone offsets from UTC. If the shortcode included tz="America/New_York", events that were supposed to occur at 5 PM were showing up at 1 PM. And if you switched to tz="America/Chicago", those events were now at 11 AM, not noon as one would expect from a shift between adjacent timezones. Likewise, setting tz="Europe/London", which should currently shift events ahead of UTC by one hour (due to Britain’s observation of Daylight Saving Time), would show the event as being at 11 PM, not 10 PM, as it should be if the UTC time of the event is 9 PM. But setting tz="UTC" did put the event at the correct UTC time of 9 PM.
It was only in hindsight that this pattern became obvious. In the moment, it just all seemed “weird” because I was more immediately distracted by the fact that, with WP_DEBUG enabled, my page was full of error messages… specifically, error messages concerning the improper use of a particular function from the ics-parser library, which ICS Calendar relies on for the initial parsing of iCalendar data into a PHP array. But in this case, the stack trace pointed to a copy of that library inside the Modern Events Calendar Lite plugin, which shouldn’t even be coming into play on a page that is only displaying a calendar generated by ICS Calendar!
That was when I realized, both plugins include ics-parser, and I had specifically coded ICS Calendar to check if the library was already loaded, before it tries to load it, in order to prevent a PHP fatal error that occurs when you try to define a class that already exists.
In theory, any copy of the library should be as good as any other. Except, Modern Events Calendar Lite includes an older version (2.1.4) than the one that is included with ICS Calendar (currently 2.2.2). Uh oh.
ICS Calendar needs the current version of the library, and the fact that it was dealing with the older version from Modern Events Calendar Lite was the reason for both the miscalculated times and the PHP error messages. But ICS Calendar also needs to “play nice” with other active plugins that may be loading different versions of the library for their own purposes. What to do?
This is where namespaces come in.
Fortunately, the ics-parser library uses namespaces. Specifically, it uses the ICal namespace. So all I needed to do was change a few lines of code in three different files: in two files within my embedded copy of ics-parser, I needed to change its defined namespace to something unique, so I went with:
namespace R34ICS_ICal;Then in the main class-r34ics.php file, I needed to change three references to the ICal namespace so they used R34ICS_ICal instead.
Since the loading and initialization of the library are fairly well abstracted in ICS Calendar, that was all I needed to do to ensure that ICS Calendar will load its own, correct version of ics-parser, and that it will avoid doing anything that might conflict with other plugins that also include their own versions of the same library.
Of course in an ideal situation the application would not be loading two separate versions of the same library, with the additional performance overhead associated with that, but fortunately the overhead is extremely small, and this is just an unavoidable tradeoff of the plugin-focused architecture of WordPress.
But thank goodness for namespaces! This was a problem I was able to fix in a matter of minutes once I had identified the issue, and it was an extremely clean and simple fix. Without namespaces, it could have been a lot more work, and much more likely to break something else along the way!
—Scott