I’m getting an endless Saving message when trying to save resources, but only for users that don’t have full admin permissions (“editors”, based on the Administrator Template). The resource does get saved, despite the message. Updating the permissions for editors to include all the permissions in the Administrator Template also doesn’t fix the issue, nor does recreating the Editors group from scratch. Adding the Administrator ACL to editors at the Super User level and updating an editor to super user also doesn’t work. Switching the user’s access permissions to the Administrator group is the only thing that fixes it.
This was working fine before; no permissions have been changed. I’m wondering if some plugin update did something, although disabling plugins doesn’t fix the issue.
This is happening on two or three of my sites. The great majority of them don’t have this issue.
Observed behavior
Javascript console shows this after clicking the Save button:
POST https://www.healthandenvironment.org/connectors/index.php 500
VM1412:1 Uncaught SyntaxError: Unexpected token '<'
at doDecode (ext-all.js:21:53110)
at Object.decode (ext-all.js:21:54709)
at Ext.form.Action.Submit.handleResponse (utilities.js:358:21)
at Ext.form.Action.Submit.processResponse (ext-all.js:21:629307)
at Ext.form.Action.Submit.success (ext-all.js:21:631040)
at o (ext-all.js:21:52418)
at Ext.data.Connection.s (ext-all.js:21:52430)
at HTMLIFrameElement.I (ext-all.js:21:57750)
These console error messages are not very useful most of the time.
Usually there is an AJAX request and javascript expects a JSON result. If there is an error, the result is not JSON and javascript outputs an error message.
So instead, go to the “Network” tab in the developer tools, and look at the response of the request that fails. Is there something useful in the response?
If not, as this seems to be a 500 error, check the server error log for any related error messages.
Because the resource gets saved, I don’t think it’s a firewall issue. (I also don’t see how MODX permissions would influence the behaviour of the firewall.)
My guess is, that a plugin on the event “OnDocFormSave” generates an error.
But without an error message, it’s impossible to know for sure.
Errors in plugins, even serious syntax errors, almost never generate an error message. They just die. And in the case of OnDocFormSave, you usually get the endless progress bar after the resource has been saved.
Really? What is so special about code in a plugin that PHP wouldn’t log an execution error?
@snowcreative When you save a resource in the manager, a request occurs that executes the resource/update processor. This processor runs the event “OnBeforeDocFormSave”, saves the resource, then runs “OnDocFormSave”.
You could try to narrow down where the error happens by creating a custom plugin (or adding log-lines to existing plugins).
For example:
Create a plugin with this code and select the checkboxes for the events “OnBeforeDocFormSave” and “OnDocFormSave”.
After the error, check the MODX error log. What gets logged?
Change the priority of the custom plugin (or other plugins that run on the same event) to see if that changes the output. Plugins with a low priority number run first.
I tried the custom plugin. The log records it running OnBeforeDocFormSave, but not OnDocFormSave, unless I’m logged in as Administrator / Super User, in which case it runs on both.
modSecurity is turned off for this site.
I disabled every plugin, and the problem persists.
And now things have gotten even worse. I noticed when clearing the cache through an editor account that one resource was listed as inaccessible at the end of the displayed cache clearing log. That resource was assigned to the group “admin”, so it’s hidden from editors. In a different browser, I logged in as admin and removed this resource from the admin group. Then, the editor account could access this resource, but every other resource became inaccessible! At first, there as just an “access denied” message, now there is nothing but a white screen when trying to edit a resource. Further, the admin account now can’t access resources either — I just get the white screen. Something is seriously messed up.
I restored the databases from a recent backup, and that didn’t fix anything. I then reinstalled MODX 2.8.4 using UpgradeModx, and everything is back the way it was — I can edit resources again, but there is still the endless saving problem for editors.
OK, update: I again removed the two resources that were in the Admin group from that group, and now editors can save resources properly. It seems that clearing the cache is what triggers the problem. Resources in a group that is inaccessible to editors are trying to be cleared from the cache, and can’t because they don’t have permission to access those resources, so it just hangs up.
Something must have been corrupted in the MODX installation, so reinstalling fixed that, but the cache issue remains. Did some update in 2.8.4 make some change to the way clearing the cache works or the way ACLs or resource groups work? I didn’t have this problem prior to 2.8.4.
However, there is another weird thing with clearing the cache on this site. The clear cache console shows a string of messages like this:
10 was requested but no alias was located.
Resource with id 10 was not found in context mgr
Every resource shows up in this list. The cache does get cleared, but why does MODX think there is “no alias” and why is it looking for them in the “mgr” context instead of the “web” context?
@halftrainedharry I don’t know why it happens, but I’ve seen it many times.
The invokeEvent() method of the modX class is pretty complex. It creates ad hoc events, calls modPlugin->process(), which calls ob_start() and tacks the output onto the plugin object as $this->_output.
I think any fatal error just stops things dead (possibly the PHP error has been converted to an exception that’s not handled). The code that stops the progress bar never executes.
