Answered Cannot save resource changes in MODX Revo 2.3.2

Apologies if it is an error to begin a new thread. The problem looks the same as the difficulty some had saving changes to templates, where a change can be made using Quick Edit but can't be made using the full edit functionality. When trying to save changes to a resource the saving bar displays into perpetuity and the resource is not updated. Same behaviour in Firefox, Chrome and IE. No problems saving changes to templates. It is only resources that cannot be updated except by Quick Edit.

The solution for the similar problem with templates was here:

http://tracker.modx.com/issues/6931

The workaround from Mark Hamstra involved changing a line in a PHP file in the core. I see the core in 2.3.2 now includes that workaround.

Mention is also made of time zone issues, especially that the time zone used by MySQL should be the same as that in the MODX System Settings. I have checked the time zone on MySQL using:



It returns GMT (the server is in London, UK), so have entered GMT in the system settings time zone field, and checked that the offset is set to 0. Also deleted the cache files in the core. Cleared the sessions and logged out. The logged in and cleared the browser's cache. No improvement.

Repeated the procedure for Europe/London in place of GMT in the system settings, both without and with single quotes. The problem remains.

Also tried adding the line below to the .htaccess file



Using that in place of php_value date.timezone "Europe/London" because the latter threw 500 errors.

I have a number of sites using MODX Revo on the same server, so far without this problem.

PHP 5.3.29
Linux pluto.uksrv.co.uk 2.6.18-374.12.1.el5.lve0.8.54 #1 SMP Wed Jan 4 18:40:17 EET 2012 x86_64
MySQL Server version: 5.5.40-cll - MySQL Community Server (GPL)


Any ideas?

If you're not sure if the date/timezone issue is fixed, SiteCheck will do a definitive check on the MySQL, PHP, and MODX date/timezone settings to verify that they match.

If it's not a date/timezone issue, mod_security is the best bet as the culprit as whitebyte suggests. If you record the time when the problem occurs, your host can probably tell you if mod_security logged an event at that point.

Thanks for the suggestion, WhiteByte, but the developer tools in Firefox, at least, don't flag any errors, there is just an infinite series of:


Bob, The sales pitch persuaded me and I paid for the SiteCheck, but what's missing there is a sentence for MODX dummies (coz there are a few around) who don't know how to use it. That isn't a traditional package, I take it. Is the sitecheck folder (contained within your zip file) supposed to be uploaded to the core/components folder of the MODX installation? Hve tried setting the Force PLC ZIPArchive setting to Yes, but cannot upload the zip file of SiteCheck inside the package management facility. Trying to upload leads to "Permission Denied".

Apologies for the above. Clicking the link in your forum signature helped me find the info:
http://bobsguides.com/sitecheck-tutorial.html#InstallingSiteCheck

The site check works nicely. The results show time zones are okay.

The only problems are two characterset and collation errors in the database table:

Checking Table: modx_actions_fields
1 columns with charset mismatches
1 columns with collation mismatches
Checking Table: modx_fc_sets
1 columns with charset mismatches
1 columns with collation mismatches

Will try to fix those and see if I can save the rest of my forehead from the damage caused by all this violent confrontation of flesh and keyboard.

Thanks.

Update: Fixed the collation and characterset errors using another impressive Bob Ray script, but the problem remains. Will try contacting the hosting folks to ask about mod_security. [ed. note: cottagestuff last edited this post 9 years, 3 months ago.]

Thanks for buying SiteCheck.

I've seen those exact same four character-set issues reported before. I wonder what causes them. What was the character set of your DB?

You should also go into PhpMyAdmin, select the MODX DB, click on the SQL tab. Put the code below in the window and click on the Go button -- see what you get.

Thank you again, Bob, for all your help and the impressive scripts. In the end, the problem was a mod_security issue. I contacted the host, they confirmed that and whitelisted the site. So problem solved.

You ask about the characterset issue. But since the diagnosis given by SiteCheck I took the opportunity to change all the table over to UTF8. Previously it was Latin1 - the default. When running the check you suggest now, the results are:



Thanks again.

Looks good. That should prevent future trouble. IIRC, character_set_server only comes into play if you create a new DB and forget to set its character set in the creation process.