No.
Debugged it and for me it was the “Object Cache” not the minify.
If the Object Cache is off, i think it’s o.k. for now.
I’m having the same issue with W3TC.
Works fine but as soon as you enable Object Cache get server error 500.
My testing so far has narrowed it download to something that changed between 1.3.4 and 1.3.5
OK, it’s down to the PHP DateTimeZone object I think.
By default in PHP 5.3+ you have to activate this configure this in PHP ini I think…
http://www.silverstripe.org/installing-silverstripe/show/15398
The bit that is failing is when Event Organiser caches a version of the DateTimeZone object. If I comment sort that it continues to work fine.
I added in a check that only saves the cache if it returns a valid offset:
https://github.com/stephenh1988/Event-Organiser/pull/1
This is just a quick fix I think and it might slow things down as that object is not cached and is used frequently in the plugin.
Is it worth looking at moving away from DateTimeZone if it is going to be an issue in PHP 5.3+ or at least finding if there is a way around it?
Great work, thanks Ben! In the next update I shall save the timezone with a string identifier instead. Feel free to try this to see if it works:
$timezone = new DateTimeZone($tzstring);
wp_cache_set( 'eventorganiser_timezone', $tzstring);
and
$tzstring = wp_cache_get( 'eventorganiser_timezone' );
if ( false === $tzstring ) {
//Find timezone
Then obviously $timezone = new DateTimeZone($tzstring);
just before retuning…
So this object cache issue was related to the timezone issue or not?
From what I can tell, it is an error caching a DateTimeZone() object.
$timezone = new DateTimeZone($tzstring);
wp_cache_set( ‘eventorganiser_timezone’, $timezone);
Caching just the string works OK I think:
$timezone = new DateTimeZone($tzstring);
wp_cache_set( ‘eventorganiser_timezone’, $tzstring);
Since 1.5 the string identifier for the timezone, rather than the timezone object is stored. This should fix this bug.
Thanks Ben for resolving this one :).