MODX » Revolution

I can confirm this to be an issue in the mentioned version of MODx Revo using Safari 5.1.2 on Mac OSX Lion with the following server info:

PHP: 5.2.17
MySQL: 5.0.92

QuickUpdate successfully changes the template, but the page simply refreshes when using the standard document editor.

I first encountered this with an installation of articles and reported it weeks ago. For many of us this is extremely painful. Using database queries to change the template is a bit of a pain.
A hit an miss temporary solution was placed there: http://tracker.modx.com/issues/6827

I can confirm this bug as well. Here are my server specs:
PHP: 5.2.17
MySQL: 5.0.92
Modx: MODX Revolution 2.2.0-pl2 (traditional)

• Articles is not installed
• Almost certain that issues #6827 and #6771 are related to this one
• Using Quick Create or the workaround described by W ShawnWilkerson on issue #6827 seem to work

Shaun,

Would you like login information on my server to see the problem in action and help troubleshoot?

Updated "date_timezone" from empty to America/Edmonton and retried changing the template without success.

same here

Jeff and Miguel...
I have had this problem several times. I install a phpinfo(); file in root level of server...search (with Firefox it's ctrl +F) for dateTimezone, copy value paste it into date Timezone System setting inside manager, clear cache and you should be good to go. It was a quick easy fix..(once I knew what to do) :)

-Noah

I have this problem in both localhost and production despite changing the server timezone within MODx to America\New_York and server offset to +1.

Noah Learner wrote:

Jeff and Miguel... I have had this problem several times. I install a phpinfo(); file in root level of server...search (with Firefox it's ctrl +F) for dateTimezone, copy value paste it into date Timezone System setting inside manager, clear cache and you should be good to go. It was a quick easy fix..(once I knew what to do) :)

-Noah

Noah (& Shaun)! Thank you! The above worked beautifully. I set my MODx date_timezone setting to the same timezone as my server as indicated by phpinfo(), namely "America/Los_Angeles". Even though I'm not in LA this will do just fine :)

Miguel & Tom, hope this works for you.

-J

I have not tested it, but... isn't it a bug? Why we have to make this fix to get template change working? And what if we need to set other timezone or the set timezone is wrong as Tom said?

Shaun,
But what if we need to set a different timezone than the system default? For example, we have servers in Dallas but want to set timezone to Atlantic/Canary. Will MODX fail?

I think that Evo allowed the Date/Time setting to override the server date time to present the dates per Miguel's inquiry. I think that it makes sense to handle it that way.

Any idea when this issue will be solved, without having to resort to changing timezone values? Solutons above don't work for me and losing FC-profiles whenever a template is changed, is a pretty big bug in my opinion.

There may be a fix which basically lowers the bar of having a server properly configured. As I can't reproduce this on any of my servers either I'm looking for people that are having issues changing their templates to manually apply it and report back if it fixes it for them or not.

In the file core/model/modx/processors/resource/reload.class.php find the following line (should be 52 or so):

$this->reg->send($topic, array($scriptProperties['create-resource-token']=> serialize($scriptProperties)), array('ttl' => 300));

$this->reg->send($topic, array($scriptProperties['create-resource-token']=> serialize($scriptProperties)), array('ttl' => 300,'delay' => -time()));

Here we're giving it an additional negative delay which basically ends up telling the Registry (which is where the resource data is temporarily stored) that the data is valid for a long time. The problem when the timezones aren't in sync is that the data has already expired before it's being accessed so it just goes back to the last saved state. This fix/workaround prevents that expiring. So while it's not a fix for an improperly configured server, it would prevent essential functionality like this breaking.

Yes, its work!

Thank you very much, Mark! You profesional! While positive feelings come from users! The problem is solved by this hack!.

It works!!!! Thank you so much Mark for giving your time to this "forgotten" but so important fixes!!!!

Rackspace Cloud Sites has this issue because the default timezone is not set on their system but you can add php_value date.timezone "your-timezone-here" to the .htaccess file and it fixes the problem.

I have been receiving alot of 500 errors, connection reset while loading errors and corrupted cache errors. Sometimes I cannot access the manager and/or web until I manually empty the cache through FTP. The MODx installer appears to hang during an update (but an initial install works fine) even though I set the timeout values to over a minute. Is it possible that all of this is related to the timezone not being set?

That has worked for me too. Thanks!!!

I haven't tried the patch yet but the timezone mod did the trick. I had run into this problem a few times and had simply gone into the DB to make the change. It got to be a big enough pain that I saw this post.

Remember to include the quotes. For me, it was 'America/New_York' (with the quotes). Since my server is in the same timezone, I left the server offset alone. I never would have guessed the solution to this one, lol.

M