"Please Wait. Saving ..." loops and doesn't do anything (Revo)

Was there a resolution to this? I’m having this problem on a number of sites but I think I found where the problem lies. I posted an issue in the bug tracker.

I could type text into Tiny no problem and it would save but as soon as I copied this 1 line into Tiny it hung - Select from our choice of two great weekends or four full-week family conferences. Then I copied the line again WITHOUT the word Select and it saved no problem. As soon as I typed the word Select at the beginning it hung again. Then I typed the words "Select a" and it saved fine. Then I typed the words "Select from" and it hung.

So the bug seems to be with the words "Select from" Does MODx think it’s code and crashes it?

It is mod_security blocking the POST on your server. You’ll need to adjust/remove the rules that are being triggered by the word SELECT.

I just upgraded to revo 2.1.3 and I too can no longer save, It just loops on and on. Previous version was 2.08.

PHP 5.2
mysql 5.1
Same in FF and Chrome

I tried saving resources (both containers and resources )and neither save. I checked Firebug and I get 500 internal server error and the URL listed was /connectors/resources/index.php . No idea what Im supposed to do with this info so Im hoping someone here can provide some insights.

\If more info is required please let me know.



[ed. note: graves007 last edited this post 12 years, 8 months ago.]

If you used FTP to move the files, some directory permissions may have been changed. Make sure the core/cache directory is writable.

Unfortunately, I came up with a similar problem with 2.0.8. In some resources when I make a change, it sits on the saving dialogue box for eternity. If I refresh the page, it does save however. I am not sure why this is. I have not upraded to 2.1.x because of compatibility issues with our scripts.
My problem does not have anything to do with what kind of content is in the resource.

Could this be some sort of permissions issues on the server filesystem? [ed. note: sonicpunk last edited this post 12 years, 8 months ago.]

I verified "/core/packages","/core/cache", "/core/import", and "/core/export" are writable.

This only seems to apply to resources/containers. I can save changes to TVs, Chunks etc.

More on my dev environment:

Win2k Server (dev)
PHP 5.2.1
MySQL 5.1.32-community
MySQL client version: 5.0.51a
pdo_mysql = yes

The Error log only shows this:

[2011-08-28 21:03:54] (ERROR @ /index.php) `` is not a valid integer and may not be passed to makeUrl()

but this could be related to the fact that I have to include index.php after manager (ie: mydomain.com/manager/index.php) otherwise I get 404. I do have the proper default document setup in IIS, and this glicth only applies to the manager url (fURLs work everywhere else) so no idea what the deal is here, but I dont care about this inconvenience at the moment. My client needs to be able to save!

Any other suggestions? As it stands my option is to just revert back to 2.0.8, but this isnt a good option.

I want to add to this in case someone else hits the same issue: the word 'select' in the content is triggering a fail to save, with no actual error message or warning, it simply just sits there pretending to save forever.

Obviously, no word in the content should trigger any behavior at all, and should particularly not do so without telling the end user that an issue has been triggered.

It took us a few days of back and forth emails etc to work this issue out, but finally by eliminating all other possible causes, and going in paragraph by paragraph, then line by line, I discovered that the 'select' key word makes modx fail to save.

This can't possibly be a feature of anything, content is the language, and select is a member of the set of english words, so it should not ever trigger anything if it's a string, in fact, no string should trigger anything beyond maybe some html/html characters rules in the content at all, since content is just content.

If someone can point me to the original bug report on this issue I'll file a bug report, hopefully nobody is going to try to say that using a standard english word should require some special handling for end users who should be able to put normal english/abnormal/programming/science/whatever into the content block and have it save as expected without having to go in and do a painstaking debugging procedure to work out the issue.

MODX Revolution 2.2.6-pl (advanced)

Aside from this bizarre bug, modx revo is looking very very good, a lot of small fixes and glitch handling that smoothes out the dev process even better than in the past, hard to understand how something so fundamental as treating all content strings as strings could have slipped by however.

It's not a bug. It's almost certainly the mod_security configuration at your host.

MODX pays no attention to the words in your text.

Indeed. Not long ago there was a similar situation with someone who had the word "casino" in his content. The mod_security settings can be arbitrarily set to refuse to permit a POST with any words or parts of words that the admins at your hosting company want to ban. http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/modsecurity-manual.html#N1032F

BobRay, sottwell, thanks for taking the time to clarify and explain, groan, I was afraid of that, after I posted, but I so want to believe that I will not encounter yet another issue with our hoster. But thank you for confirming that modx is fully innocent, given this is the only issue I thought we had discovered with modx, that makes modx more impressive still, there's been some very nice cleanup and tightening of revolution since my last install, subtle things, but all good.

Sadly, Liquid Web cpanel hosting is showing me more and more what a very bad idea liquid web cpanel hosting is as we progress through its failures and errors, I'll add this to the count of bad things they do by default.

I really did not want to believe that they (liquid web) would do this at the server level, but sadly, it's getting all to easy for me to believe that failures are due to bad server configurations and defaults, along with cpanel knocking us offline just to keep things amusing now and then, and then to spice things up, random bad configuration decisions that we are left to discover on our own as we go along.

But thanks for correcting my assumption, I knew that logically there was no reason for modx to care about the content, and I'm glad to see that logic prevails, modx is innocent.

One more negative however, it's looking more and more likely we will have to move to Pair networks vps servers to avoid this seemingly endless voyage of discovery of just how bad something can be.