Answered Resource will not save - progress bar simply loops

Hi Folks

I have a home page consisting of around a dozen chunks that simply refuses to save.
And the only way out of the greyed screen is to close the window and start afresh.
I've tried all the suggestions that Bob and others have made…
ie
Continually cleared MODX cache,
Emptied core/cache,
Removed content altogether,
Swapped templates.
Removing extras or page elements one by one seems a redundant line of enquiry
seeing as the blank page refuses to save.

However when I create a new document and paste the same content it saves as expected.
So would there perhaps be something about the document itself, with/without content
that could be causing this?
Have to say that this seems to coincide (though cannot be 100% sure) with upgrading from 2.3.5 - 2.4.2.
At the same time I've also, as officially suggested, 'hardened up' MODX by placing the core folder a level up
and renaming the manager and connectors folders.
I'm also wondering (straw-clutching) if there may be some deprecation between the two MODX versions
that now no longer likes the code I'm using. Although as I say, this only consists of a few chunks of html.
The rest of my documents and components save as expected.

My setup is:
MODX 2.4.2
MAMP (latest (3.0.7.3))
PHP (5.5.18)
MySQL (5.5.38)
Chrome: Std and Canary (latest versions)
Mac OX (Lion-10.7.5).

Any help would be great
Many Thanks [ed. note: geordiechris last edited this post 11 years ago.]

Have you tried downgrading to 2.4.1 to see if it might have something to do with the latest update?

It's very unlikely that a chunk's content would cause the issue, since the actual content of the chunks is not saved when the resource is saved. TV values, however, are saved when the resource is saved. Are there TVs associated with the Resource? When you tested the same content in another resource, did you set the TV values?

The endless save for a particular resource or element is often a sign of violating a mod_security rule, so maybe a TV value is causing the issue. If you have an @EVAL TV, that would be a likely suspect.

Your host can probably tell you if a mod_security rule was violated at the time of an attempted save.

Hi Steffan,
No I haven't as yet.
I was thinking along those lines that there might
be some deprecated code that the latest version didn't like.
I was hoping to explore other possibilities and was therefore going to leave that
kind of wholesale change stuff until later.
And so in light of your thinking Bob,
yes the resource has TV's associated with it.
So I've unchecked the template access to these TV's
and it now saves as expected.
I've done some reading up on the @EVAL binding but have to come clean...
that's beyond my grasp.
I haven't coded anything per se.
I've simply added half a dozen TV's via the manager.
How might I find out whether a TV contains an @EVAL statement?

Would this situation be exclusive to the remote host and their setup,
as the locally mirrored site shows no problems.

And with reference to questioning my host concerning 'mod_security',
is that as simple as you suggest Bob?…
ie Attempt to make the save. Note the time. Raise a ticket?
Please forgive my lack of nouse when it comes to the PHP stuff.
I know a bit…which I also know can be dangerous!

Many thanks for your time guys [ed. note: geordiechris last edited this post 11 years ago.]

If you haven't created an @EVAL TV yourself, there probably isn't one. More likely it's a word, phrase, or bit of code in the TV value that mod_security doesn't like. It can be very wacky. The mod_security rules stopped one user from saving anything containing the word 'casino'. A common restriction is the use of script tags.

Whether noting the time and raising a ticket works depends on the quality of the hosting service, but it usually does.

This all may be a huge coincidence. Just this morning I had a similar problem on a site that I just moved from the MODX Cloud to a SkyToaster live server. The site is still on 2.4.1. Close examination of the problems showed that no resources or elements with an email address could be saved. Contact with SkyToaster resulted in the information that they just updated a new mod_security rule set, and it's been causing problems like this. They have to hear about it before they can remove the offending over-zealous ruleset. So your hosting may have done the same thing, these mod_security rulesets are widely distributed.