Произошла ошибка при попытке сохранить ресурс modx

splittingred submitted:

Please do not assign target versions. Thanks.

MokoJumbie submitted:

Can somebody assign a target version to some of these super old major bugs? this is a serious bug which can result in a loss of data and is over 2 years old. There are a lot of really old issues which are being forgotten about and would really do to be resolved in new versions of MODX. I don’t know how to feel about requests to aid in finding new bugs to squash in upcoming releases when the old bugs are just getting buried.

I can verify that this still exists in 2.2.5. If it helps, I believe it can be produced by having a connection drop before saving is completed. This is probably not the only cause, however.

opengeek submitted:

I cannot reproduce this bug. I suspect this was related to mod_security rules applied in the server environment and preventing POST requests containing certain HTML tags or other content matching it’s filters.

MokoJumbie submitted:

I will try to look into this some more so I can give you more details.

Your suspicion may be correct, but if so, I don’t believe mod_security is the culprit in at least some (if not most) of the cases I’ve seen. It has happened on several different servers and not consistently. Often the problem can be fixed by restarting the user’s browser or computer. Can someone corroborate this aspect of the bug for me?

I think there are two issues here. First is the question of what’s causing the issue in the first place, which seems a bit ambiguous. But secondly, I don’t feel enough is being done by the manager to prevent submitted data from being lost should a request fail. Can a request which takes too long be canceled, notifying the user of the failure and allowing them the opportunity to save their entered content. Even better would be to save the submission content in sessionStorage or localStorage for recovery in the event of such a failure.

Thanks for looking into this.

MokoJumbie submitted:

Still looking into this, but forcibly attempting to remove access to the server during a save yields the results seen in Issue #9147, not the result seen in this bug. Anyone have any luck in reliably reproducing this?

MokoJumbie submitted:

I just got this bug again. No idea why. But this is a huge issue, leading to loss of entered data. It’s really frustrating to see your data behind a grey curtain knowing there is no way to retrieve it before having to reload the page and force yourself to have to enter it all over again. Is there at least some way we can dismiss the ‘Please Wait: Saving…’ dialog so that we can attempt a save at a later time or at least recover some of our data?

I can confirm that i still have access to the server and the manager in another tab. I have also been able to save to this resource many times recently.

MokoJumbie submitted:

FYI, I noticed in this instance that upon attempting to save, I am getting the following error in my console:

NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHTMLDocument.implementation]
[Break On This Error]   
...xt():n.prev()))}}}if(l){if(o.nodeType===3&&r===0){x(true)}if(o.nodeType===1){q=o...
http://mymodxwebsite.com/assets/components/tinymce/jscripts/tiny_mce/tiny_mce.js?v=225pl (line 1)
uncaught exception: [object Object]

l’ll report back if i see any other potential causes.

Pfeifakopf submitted:

I have the same Problem. This happens on multiple sites, if they where upgraded from an older version (< 2.1). Most times it happens in combination with MIGX and editing there something.

Wanted to add a little more to this — we’re still experiencing this intermittently on a few sites being served from a couple of different server environments. The issue doesn’t seem to be tied to any particular browser, but what we’ve noted is that using Chrome or Safari’s built in developer tools, when we right-click and inspect the «Saving» overlay, by changing the element’s display to «none» we’re able to access the save button again — and clicking it again has worked 100% of the time.

Obviously it’s not an optimal solution to pass on to our clients, but I’m curious if others are still experiencing this and whether this might narrow down the possible causes.

@BlueJayTech I would like to mention that you can use CTRL+S or CTRL+SHIFT+S (windows) as a shortcut to save the content. Not a solution but it will save you going into dev tools for the time being.

IMO, most probably it is due to network going haywire for split second.

I just had this issue in MODX 2.4.2 on Firefox 42 and noticed that it coincided with a JS error in Firebug:

uncaught exception: [object Object]
domain.com/assets/components/tinymce/jscripts/tiny_mce/tiny_mce.js?v=242pl
Line 1, col 118324

Inspecting col 118324 in the minified JS file leads me to the statement o.cloneNode(true) in the following code fragment:

if(d&&i.select("script,style,select,map").length>0){n=o.innerHTML;o=o.cloneNode(false);i.setHTML(o,n)}else{o=o.cloneNode(true)}

Looking at the unminified file, I believe this correlates to line 10336 of https://github.com/splittingred/TinyMCE/blob/develop/assets/components/tinymce/jscripts/tiny_mce/tiny_mce_src.js (node = node.cloneNode(true);

...

// Return public methods
return {
    schema : schema,

    addNodeFilter : htmlParser.addNodeFilter,

    addAttributeFilter : htmlParser.addAttributeFilter,

    onPreProcess : onPreProcess,

    onPostProcess : onPostProcess,

    serialize : function(node, args) {
        var impl, doc, oldDoc, htmlSerializer, content;

        // Explorer won't clone contents of script and style and the
        // selected index of select elements are cleared on a clone operation.
        if (isIE && dom.select('script,style,select,map').length > 0) {
            content = node.innerHTML;
            node = node.cloneNode(false);
            dom.setHTML(node, content);
        } else
            node = node.cloneNode(true);

...

Do you receive any kind of errors saving the same content when TinyMCE is not installed?

Unfortunately it appears to be an intermittent bug. I was updating a bunch of 10 documents and it happened about 4-5 times within 5 minutes. After that, no problems at all.

I presume not using TinyMCE will fix the problem. Will try that the next time this problem surfaces.

For what it’s worth, I don’t think the actual content within the TinyMCE editor is a factor (could be wrong of course). The documents contained one p tag containing 10-20 words. No links, tables, images, nothing fancy at all.

I am going to close this for following reasons:

• Original issue can deal with multiple underlying issues (see below list)
• Some (sub)problems has to do with extras
• No error log or extended information.

The manager interface is heavily ajax-based, now, without inspecting the network data, a wide range of reason could prevent a resource from saving. These include (but not limited to): javascript errors (request is never sent), PHP error (fatal error resulting in invalid JSON response), web server error (apache/nginx fails to deliver response).

Feel free to comment or reopen if you disagree with my decision.

@modxbot close

splittingred submitted:

Please do not assign target versions. Thanks.

MokoJumbie submitted:

Can somebody assign a target version to some of these super old major bugs? this is a serious bug which can result in a loss of data and is over 2 years old. There are a lot of really old issues which are being forgotten about and would really do to be resolved in new versions of MODX. I don’t know how to feel about requests to aid in finding new bugs to squash in upcoming releases when the old bugs are just getting buried.

I can verify that this still exists in 2.2.5. If it helps, I believe it can be produced by having a connection drop before saving is completed. This is probably not the only cause, however.

opengeek submitted:

I cannot reproduce this bug. I suspect this was related to mod_security rules applied in the server environment and preventing POST requests containing certain HTML tags or other content matching it’s filters.

MokoJumbie submitted:

I will try to look into this some more so I can give you more details.

Your suspicion may be correct, but if so, I don’t believe mod_security is the culprit in at least some (if not most) of the cases I’ve seen. It has happened on several different servers and not consistently. Often the problem can be fixed by restarting the user’s browser or computer. Can someone corroborate this aspect of the bug for me?

I think there are two issues here. First is the question of what’s causing the issue in the first place, which seems a bit ambiguous. But secondly, I don’t feel enough is being done by the manager to prevent submitted data from being lost should a request fail. Can a request which takes too long be canceled, notifying the user of the failure and allowing them the opportunity to save their entered content. Even better would be to save the submission content in sessionStorage or localStorage for recovery in the event of such a failure.

Thanks for looking into this.

MokoJumbie submitted:

Still looking into this, but forcibly attempting to remove access to the server during a save yields the results seen in Issue #9147, not the result seen in this bug. Anyone have any luck in reliably reproducing this?

MokoJumbie submitted:

I just got this bug again. No idea why. But this is a huge issue, leading to loss of entered data. It’s really frustrating to see your data behind a grey curtain knowing there is no way to retrieve it before having to reload the page and force yourself to have to enter it all over again. Is there at least some way we can dismiss the ‘Please Wait: Saving…’ dialog so that we can attempt a save at a later time or at least recover some of our data?

I can confirm that i still have access to the server and the manager in another tab. I have also been able to save to this resource many times recently.

MokoJumbie submitted:

FYI, I noticed in this instance that upon attempting to save, I am getting the following error in my console:

NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHTMLDocument.implementation]
[Break On This Error]   
...xt():n.prev()))}}}if(l){if(o.nodeType===3&&r===0){x(true)}if(o.nodeType===1){q=o...
http://mymodxwebsite.com/assets/components/tinymce/jscripts/tiny_mce/tiny_mce.js?v=225pl (line 1)
uncaught exception: [object Object]

l’ll report back if i see any other potential causes.

Pfeifakopf submitted:

I have the same Problem. This happens on multiple sites, if they where upgraded from an older version (< 2.1). Most times it happens in combination with MIGX and editing there something.

Wanted to add a little more to this — we’re still experiencing this intermittently on a few sites being served from a couple of different server environments. The issue doesn’t seem to be tied to any particular browser, but what we’ve noted is that using Chrome or Safari’s built in developer tools, when we right-click and inspect the «Saving» overlay, by changing the element’s display to «none» we’re able to access the save button again — and clicking it again has worked 100% of the time.

Obviously it’s not an optimal solution to pass on to our clients, but I’m curious if others are still experiencing this and whether this might narrow down the possible causes.

@BlueJayTech I would like to mention that you can use CTRL+S or CTRL+SHIFT+S (windows) as a shortcut to save the content. Not a solution but it will save you going into dev tools for the time being.

IMO, most probably it is due to network going haywire for split second.

I just had this issue in MODX 2.4.2 on Firefox 42 and noticed that it coincided with a JS error in Firebug:

uncaught exception: [object Object]
domain.com/assets/components/tinymce/jscripts/tiny_mce/tiny_mce.js?v=242pl
Line 1, col 118324

Inspecting col 118324 in the minified JS file leads me to the statement o.cloneNode(true) in the following code fragment:

if(d&&i.select("script,style,select,map").length>0){n=o.innerHTML;o=o.cloneNode(false);i.setHTML(o,n)}else{o=o.cloneNode(true)}

Looking at the unminified file, I believe this correlates to line 10336 of https://github.com/splittingred/TinyMCE/blob/develop/assets/components/tinymce/jscripts/tiny_mce/tiny_mce_src.js (node = node.cloneNode(true);

...

// Return public methods
return {
    schema : schema,

    addNodeFilter : htmlParser.addNodeFilter,

    addAttributeFilter : htmlParser.addAttributeFilter,

    onPreProcess : onPreProcess,

    onPostProcess : onPostProcess,

    serialize : function(node, args) {
        var impl, doc, oldDoc, htmlSerializer, content;

        // Explorer won't clone contents of script and style and the
        // selected index of select elements are cleared on a clone operation.
        if (isIE && dom.select('script,style,select,map').length > 0) {
            content = node.innerHTML;
            node = node.cloneNode(false);
            dom.setHTML(node, content);
        } else
            node = node.cloneNode(true);

...

Do you receive any kind of errors saving the same content when TinyMCE is not installed?

Unfortunately it appears to be an intermittent bug. I was updating a bunch of 10 documents and it happened about 4-5 times within 5 minutes. After that, no problems at all.

I presume not using TinyMCE will fix the problem. Will try that the next time this problem surfaces.

For what it’s worth, I don’t think the actual content within the TinyMCE editor is a factor (could be wrong of course). The documents contained one p tag containing 10-20 words. No links, tables, images, nothing fancy at all.

I am going to close this for following reasons:

• Original issue can deal with multiple underlying issues (see below list)
• Some (sub)problems has to do with extras
• No error log or extended information.

The manager interface is heavily ajax-based, now, without inspecting the network data, a wide range of reason could prevent a resource from saving. These include (but not limited to): javascript errors (request is never sent), PHP error (fatal error resulting in invalid JSON response), web server error (apache/nginx fails to deliver response).

Feel free to comment or reopen if you disagree with my decision.

@modxbot close