Answered Weird Edit Problem (not saving changes)

MODX 2.4.3 with the latest Code Mirror editor installed.
Update (2016-04-17 03:56 GMT): Problem does not occur on different server. Corrected the preg_replace() statement. Details in the revised description.

Update (20-04-17 23:56 GMT): More weirdness — see update at bottom of this post.

I've been using the latest MODX on two different servers (different hosting services and different domain names for the website) up until yesterday with no problems, then huge frustration because...

On the one installation, used for testing:

I edit the code in a snippet and save it. It appears to be saved (the progress indicator is displayed). However, when it is finished, I click on a different snippet and then back to the original snippet and my change has disappeared.

I have tried logging out, clearing my browser cache, exiting my browser (Firefox under Linux Mint) and starting over again. Same result. I have also tried this using a different computer. I tried clicking on Manage->Remove Locks (which reported it had) -- no joy.

After a bit of experimenting, it looks like whenever I attempt to code a PHP preg_replace() function in the code, my edit gets trashed (i.e. not saved). Just to see if that was the case, I coded a PHP substr() function and the edit took.

This simply doesn't make any sense to me...

FWIW, the preg_replace() statement I'm trying to insert is:



I know it works because, I tested it stand-alone (not in MODX, but on the same hosting server) . What I did insert as a test to prove some updates work, is:


_______________________________________________________

My current conclusion is that something, somewhere does not like preg_replace() in MODX on my testing server
_______________________________________________________

Here are steps I have taken (not necessarily in the order I took them — but in a hopefully easy to understand order) to narrow the problem and support my hypothesis.

On the testing server:
I uninstalled Code Mirror. That made no difference, so I re-installed it. At least I've eliminated Code Mirror as the problem.

I copy-and-pasted the preg_replace statement into the snippet and then edited it to read fuzzy_replace. I saved, switched to another snippet, switched back and the edit had taken. So now I edited it to read preg_replace, saved... The edit did not take (still read fuzzy_replace). So the issue has something to do with the preg_replace() function being in the code (simply the actual text of the snippet).

On the live server:
While, for obvious reasons, I dislike running tests on a live website, I did try this change. I have a copy of the text of the snippet in a file on my computer (I often do updates by editing on my computer and then copy-and-paste into MODX). So I copy-and-pasted the updated snippet (with the preg_replace() function) into the corresponding snippet on the live website server.

The edit took and the the snippet performed as expected.
_______________________________________________________

I need ideas. I do not know if backing up the MODX database, copying back the MODX setup directory and running setup again will have any effect. Since I am in the midst of developing a new website, I'm loath to deal with this distraction. But I hate loose ends and this problem is bugging me!
_______________________________________________________

Update (2016-04-17 23:56 GMT):
If I make the code a // comment, then the update gets trashed; however, if I make the comment a /* … */ comment, it is accepted! The following code illustrates the exact two examples (in that order).


So "something" is doing a half-assed PHP parse and trashing an update when it thinks it has encountered the preg_replace() function. [ed. note: jrg last edited this post 10 years, 5 months ago.]

First guess would be a character encoding conflict of one sort or another. Any chance there's a disconnect between your MODX config include and your database character set? I could be way off, but it does kinda sound like a character encoding problem to me.

Quote from: claytonk at Apr 17, 2016, 12:08 PM

First guess would be a character encoding conflict of one sort or another. Any chance there's a disconnect between your MODX config include and your database character set? I could be way off, but it does kinda sound like a character encoding problem to me.

I do not believe so. Both databases were created with the same parameters and the tables in one were created by an import of a .sql file created by exporting the tables of the other (i.e. backed up one database, restored in the other).

Also, more telling, the problem started occurring in the original MODX installation, whereas the copied site is fine. Changing "fuzzy" to "preg_replace" is not likely to trip up on a character encoding conflict. Whether I copy-and-paste or type it in, the result is the same.

Thanks for thinking about the problem.

That sounds like a typical mod_security issue.

Quote from: BobRay at Apr 17, 2016, 03:19 PM

That sounds like a typical mod_security issue.

Both the "live" website and the "test" website are running on exactly the release of MODX (and the Login extra). My code, with the exception of this problem — preg_replace() in the live site, substr() in the test site — are identical, including resource ids, element names and ids (one database is an import of the other).

If it is a security issue, that would mean it has something to do with the domain name, hosting provider (live site is on godaddy.com; test site on site5.com) OR the live site uses HTTPS and the test site uses HTTP.

This is all weird. I'd like to simply re-install MODX on the test site, but that's a pain (I have a "package" to support using xPDO for an external database whose tables cannot be moved into the MODX database — the tables I access are stored in a Zen Cart database and are used both by Zen Cart and an API that I wrote).

If I get desperate, I'll go that route at some stage, but I'm also worried it won't resolve anything.

I think BobRay is referring to Apache's mod_security. I've had bountiful issues with that sucker in the past.

Quote from: claytonk at Apr 17, 2016, 03:43 PM

I think BobRay is referring to Apache's mod_security. I've had bountiful issues with that sucker in the past.

Think about what is happening:

• One visits a MODX website, using the Manager. However you cut it, once you are in the Manger, there are restricted things the code can do that will be impacted by Apache.
• You enter text into a glorified textarea that is part of a, probably very complex, form. There is probably JavaScript and who knows what else running in your browser on your computer. Again, however it works, it's still text, even if it represents PHP code. "Nobody" but you and MODX (because you are editing a snippet) knows it is PHP code unless the text is being intercepted and parsed.
• At some point you click the SAVE button (or use a keyboard shortcut) and the browser sends the fields to the server (i.e. MODX receives the fields and processes them).
• MODX then updates the MODX database using xPDO as its access mechanism. Unless MODX is parsing or filtering snippets before saving them or an xPDO function is doing so, I fail to see why one little bit of text in snippet breaks the update. I also fail to understand why, if MODX is trashing the update, it is not displaying an error.

So now I've thought of three more little tests I can do:

• Check the MODX error log in the Manager. Damn, I should have done this at the very beginning
• Put the preg_replace() function in a PHP comment.
• Put the preg_replace() function in a singly quoted string (in theory, if something is parsing the PHP code before allowing it to be saved, it should ignore the text between single quotes).

I'll do those things, see what happens and report back (by updating the initial post).

There is nothing in the MODX error.log — it is completely empty.

Quote from: jrg at Apr 17, 2016, 05:35 PM

Think about what is happening:

• One visits a MODX website, using the Manager. However you cut it, once you are in the Manger, there are restricted things the code can do that will be impacted by Apache.
• You enter text into a glorified textarea that is part of a, probably very complex, form. There is probably JavaScript and who knows what else running in your browser on your computer. Again, however it works, it's still text, even if it represents PHP code. "Nobody" but you and MODX (because you are editing a snippet) knows it is PHP code unless the text is being intercepted and parsed.
• At some point you click the SAVE button (or use a keyboard shortcut) and the browser sends the fields to the server (i.e. MODX receives the fields and processes them).
• MODX then updates the MODX database using xPDO as its access mechanism. Unless MODX is parsing or filtering snippets before saving them or an xPDO function is doing so, I fail to see why one little bit of text in snippet breaks the update. I also fail to understand why, if MODX is trashing the update, it is not displaying an error.

mod_security monitors in realtime, so if it is running on your server, depending on configuration it is absolutely intercepting and analyzing your form submissions. I'm sure you've already checked, but any errors relating to what you're experiencing are very likely to be reported in your server's error log not the manager error log.

Hi Claytonk¸

I could not see anything untoward in the server log, certainly nothing that looked like an error.