Gutenberg: How to debug "Updating failed" and "Publishing failed"

Created on 28 Aug 2017  Â·  51Comments  Â·  Source: WordPress/gutenberg

Issue Overview

Hi there, I just installed Gutenberg today but am having issues updating an existing post or publishing a post. Basically, Save Draft, Preview and Publish doesn't result in the post being posted. I am only met with a rather unhelpful error message "Updating failed" or "Publishing failed". My WordPress is running on Nginx on Ubuntu 16.04 on a DigitalOcean VPS.

How do I go about debugging Gutenberg? Thank you.

Steps to Reproduce (for bugs)

  1. Create a new post in Gutenberg
  2. Click Save Draft, Preview, or Publish
  3. Error message shows up

Tried both chrome and firefox with same results.

Expected Behavior

It should save draft/ preview/ publish correctly.

Current Behavior

Cannot post/ preview/ publish.

Core REST API Task

Most helpful comment

Sorry to find about this just now. Whenever you find that Cloudflare has blocked a request you consider legitimate, you need to follow the instructions in this article of our Knowledge base and search for the event matching the request that was blocked. Once you have found the corresponding event, click on "Detail" to show the report as screenshotted above. In there, take note of the rule ID of the rule that was triggered (in the present case: "WP0025B").

You now need to decide if it's safe to disable the rule to let these requests through, and if so:

  • visit the "Firewall" section of your domain in your Cloudflare account
  • show the WAF tab
  • scroll down to "Package: Cloudflare Rule Set"
  • click on "Rule details", then "Advanced" at the bottom of the panel that unfolds
  • search for the rule using the rule ID in the overlay that appears (in the present case "WP0025B"), see the screenshot below
  • deactivate the rule

screenshot_2017-09-26_16-50-06

To answer @trenzterra, only users/domain with a Pro plan would have access to the WAF, so this is only a subset of the Cloudflare user base.

All 51 comments

Can you open the chrome dev tools, open the network tab, find the failing request (row in red) and check the response content?

I am getting the same issue. Have dev tools open to network tab, but not sure exactly what data you want from it. Not a dev, so let me know the steps you need me to take.

So, I discovered that CloudFlare is blocking it. Here is the message when I click on the red line under network tab:

Please enable cookies.
Sorry, you have been blocked

You are unable to access cb1.io

Why have I been blocked?

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

What can I do to resolve this?

You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

Cloudflare Ray ID: 3957e4485bee50ce • Your IP: 2602:306:80e9:5b50:c:4274:da70:9977 • Performance & security by Cloudflare •

I was able to whitelist my IP address at CloudFlare so I could publish and keep testing, but that is obviously not a general public solution.

What's the exact reason to block the request, any more details on cb1.io? Is it the "enable cookies" message? Why are cookies not enabled by default?

It seems that the CloudFlare proxy is too aggressive here.

Yep, I realise the thing blocking it is Cloudflare as well. Seems strange that no one brought it up until now.

Went to CloudFlare and exported to RAW the following error message:

{ "id": "395affffddb27026", "country": "SG", "ip": "[redacted]", "protocol": "HTTP/2", "method": "PUT", "host": "www.describee.com", "user_agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0", "uri": "/wp-json/wp/v2/posts/1262", "request_duration": 0, "triggered_rule_ids": [ "WP0025B" ], "action": "block", "cloudflare_location": "SIN", "occurred_at": "2017-08-28T23:20:14.05Z", "rule_detail": [ { "id": "", "description": "MATCHED_VAR" } ], "rule_message": "Prevent abuse against wp-json api Type B", "type": "waf", "rule_id": "WP0025B", "zone_id": "2638dd05ae2835d407d4a8f321145b8f", "cookie": "" }

I really can't speak to the why. I will tell you that my setup is the standard off the shelf CloudFlare free account setup. I did not make any changes to what gets setup when you add a domain to their DNS except my DNS entries. This could be a bit of a problem for Gutenberg though with the level of use that CloudFlare has.

I do not have this problem using Divi with this domain. All publish options work properly in Divi going through CloudFlare, so I suspect something in the way Gutenberg send data is causing the issue.

I also cannot speak with any expertise as to the cookie message. I don't have anything special setup related to cookies though in that WordPress instance. I setup a brand new instance of WordPress to test Gutenberg. This install is in a subdirectory of the primary domain which has its own installation of WordPress using Divi.

Here is my Raw Export from CloudFlare. If anyone on your team would like to see any specific files, please feel free to reach out. Happy to help. Site is hosted with SiteGround in shared hosting.

{
"id": "3957f46bbaf450ce",
"country": "US",
"ip": "2602:306:80e9:5b50:c:4274:da70:9977",
"protocol": "HTTP/2",
"method": "PUT",
"host": "cb1.io",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36",
"uri": "/guttenbergtest/wp-json/wp/v2/posts/5",
"request_duration": 3000064,
"triggered_rule_ids": [
"WP0025B"
],
"action": "block",
"cloudflare_location": "MIA",
"occurred_at": "2017-08-28T14:28:02.51Z",
"rule_detail": [
{
"id": "",
"description": "MATCHED_VAR"
}
],
"rule_message": "Prevent abuse against wp-json api Type B",
"type": "waf",
"rule_id": "WP0025B",
"zone_id": "b4b940faede0b52b8a99678ad1d0c31c",
"cookie": ""
}

Here's a screen from CloudFlare. Have a long list of blocks, but after randomly looking through, all the messages look the same.
ip_firewall___firewall__cb1_io___cloudflare_-_web_performance___security

Yep, I'm surprised this is the first time we see this, especially since we're using the standard API client which should be used elsewhere. I assume this is a general REST API concern and we should investigate why we're being blocked.

I'm getting a similar error ("Publishing failed.", "Updating failed.") after installing Gutenberg 1.0.0 today. My test site is NOT behind CloudFlare, so perhaps this is a different issue.

I _am_ using WordPress 4.8.1 in Multisite mode. I did the usual Network Admin -> Plugins -> Add New to add the plugin. I did _not_ "Network Activate" but instead went to one of my test sites (deepdark.blue) and activated the plugin for that site. I then went to "Gutenberg -> Add New" and began writing a post. I'm using Google Chrome on a Mac.

However, as soon as I dragged an image from my Mac desktop to Chrome, it said "Updating failed." and wouldn't let me add the image. I _was_ able to go into the regular Media Library (from within Gutenberg), drag the image from my Mac desktop into there, and then insert into Gutenberg. I then wrote some more text and tried to save, at which point I got "Publishing failed."

Again, the test site ( http://deepdark.blue ) is NOT behind CloudFlare, so this may be something different. (Has Gutenberg been tested to work with multisite? with new gtlds?) Any suggestions on how to debug would be welcome. Thanks.

UPDATE - I activated the Gutenberg plugin on a second test site on the exact same WP Multisite server and had no problem using the plugin and creating a new post using Gutenberg. A potential difference is that the other site is danyork.ORG, so a traditional gTLD. It also uses a different theme so there could be other issues.

@danyork I suggest following the debug steps here https://github.com/WordPress/gutenberg/issues/2565#issuecomment-325289062 if possible and then if it's a different problem, feel free to create a new issue.

@youknowriad - Thanks. When I do that and look on the Headers tab at the red line under "Network" when I do a "Publishing failed", I see this (I removed the IP addresses):

Request URL:http://deepdark.blue/wp-json/wp/v2/posts/84 Request Method:PUT Status Code:404 Not Found Remote Address: <removed>:80 Referrer Policy:no-referrer-when-downgrade
when I try to drag and drop an image, I get:

Request URL:http://deepdark.blue/wp-json/wp/v2/media Request Method:POST Status Code:404 Not Found Remote Address: <removed>:80 Referrer Policy:no-referrer-when-downgrade

When I look under the "Response" tab I see all the HTML that makes up the Gutenberg editor page.

FYI, I am _also_ seeing red errors (on BOTH test sites) for "newest-note-date" with the header:

Request URL:wss://public-api.wordpress.com/pinghub/wpcom/me/newest-note-data Request Method:GET Status Code:403 Forbidden

But that is happening on both the site where Gutenberg is working, and where it is not.

As noted in that issue 2596, my issue seems to have been fixed - and to have had nothing to do with the Cloudflare issue mentioned here.

Just a heads-up: this is still happening. I'm currently experiencing the issue with three separate WPMU installations.

Request URL:https://customerinforedacted.com/wp-json/wp/v2/posts/353 Request Method:PUT Status Code:403

The Cloudflare incident message is the same reported above (rule WP0025B), but here it goes:
{ "id": "39f1d845ad104acd", "country": "BR", "ip": "Ip.Redacted", "protocol": "HTTP/2", "method": "PUT", "host": "customer.info", "user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36", "uri": "/wp-json/wp/v2/posts/353", "request_duration": 5999872, "triggered_rule_ids": [ "WP0025B" ], "action": "block", "cloudflare_location": "GRU", "occurred_at": "2017-09-16T06:42:16.58Z", "rule_detail": [ { "id": "", "description": "MATCHED_VAR" } ], "rule_message": "Prevent abuse against wp-json api Type B", "type": "waf", "rule_id": "WP0025B", "zone_id": "6e1fd92f8dcf1c32f654191579951f7e", "cookie": "" }

What didn't fix it

  • Clearing cookies and cache,
  • Re-installing Wordpress and Gutenberg,
  • Creating a new Wordpress installation from scratch,
  • Creating Page Rules disabling _Performance, Security, Cache and Browser Integrity Checks_ at _wordpresspath/wp-json_ and _wordpresspath/wp-admin_

What did "fix" it

  • Whitelisting the client IP or IP range in Cloudflare's Application Firewall. While this works, surely this isn't a good solution.
  • Not using Cloudflare. Also not really a solution.

As @youknowriad mentioned, given how Cloudflare is very widely adopted, I'm surprised we're not hearing more complains about this. I'm a bit dumbfounded by the whole thing.

Sorry to find about this just now. Whenever you find that Cloudflare has blocked a request you consider legitimate, you need to follow the instructions in this article of our Knowledge base and search for the event matching the request that was blocked. Once you have found the corresponding event, click on "Detail" to show the report as screenshotted above. In there, take note of the rule ID of the rule that was triggered (in the present case: "WP0025B").

You now need to decide if it's safe to disable the rule to let these requests through, and if so:

  • visit the "Firewall" section of your domain in your Cloudflare account
  • show the WAF tab
  • scroll down to "Package: Cloudflare Rule Set"
  • click on "Rule details", then "Advanced" at the bottom of the panel that unfolds
  • search for the rule using the rule ID in the overlay that appears (in the present case "WP0025B"), see the screenshot below
  • deactivate the rule

screenshot_2017-09-26_16-50-06

To answer @trenzterra, only users/domain with a Pro plan would have access to the WAF, so this is only a subset of the Cloudflare user base.

Confirmed, disabling WP0025B allows Gutenberg through.

Unfortunately, this means that Cloudflare free users will be left in the cold. Is there a workaround for this?

Confirmed indeed; disabling WP0025B works.

@trenzterra one workaround available to all users is using a pagerule to disable all Cloudflare security for the API's suburl:

  • Disable security
  • Browser integrity check: Off
  • Cache Level: Bypass
  • Disable Apps
  • Disable Performance

cloudflarerulesgutenberg

This does consume one of the three pagerules available for a free user, but it works.

I'm getting the same issue. Once in a while on the same article it goes through, but most of the time I get the "Updating failed" message. Only thing that i change between attempts to update are minor, like changing/adding text to paragraphs.

Notes

  • Changing theme has no impact
  • Gutenberg v 1.5.2
  • Wordpress v 4.8.2
  • Classic editor works just fine

What stands out is the AJAX call result that is being sent to the WP API:

Request URL:http://localhost/wp-json/wp/v2/posts/1674
Request Method:PUT
Status Code:200 OK
Remote Address:127.0.0.1:80
Referrer Policy:no-referrer-when-downgrade

This gives me the following response body:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 404 </title>
</head>
<body>
<h2>HTTP ERROR: 404</h2>
<p>Problem accessing /nrksuper. Reason:
<pre>    Not Found</pre></p>
<hr /><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.3.2.v20150730</a><hr/>
</body>
</html>
{JSON Object as usual which is also returned when everything is fine}

I have the same problem, but I think for a different cause (though it also relates to the API).

As I described here, because my site URL and my WP URL are different, anything to do with REST gets me this error:

Request header field X-WP-Nonce is not allowed by Access-Control-Allow-Headers in preflight response.

Followed by repeated

Failed to load resource: the server responded with a status of 403 (Forbidden)

I fixed the second one by disabling Jetpack and iThemes Security (as you say, firewall/cdn-related probably), but the Nonce remains a problem.

I have a similar issue with cross-origin JS errors blocking the post content block and meta blocks in Gutenberg v1.6.1 running it on nginx/1.10.3 through Cloudflare with add_header X-Frame-Options SAMEORIGIN; set in the nginx.conf file.

Refused to display 'https://zeropointdevelopment.com/wp-admin/post.php?post=7898&action=edit&classic-editor=1&meta_box=normal' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, DENY, SAMEORIGIN'). Falling back to 'deny'.

Uncaught DOMException: Blocked a frame with origin "https://zeropointdevelopment.com" from accessing a cross-origin frame.
at t.value (https://zeropointdevelopment.com/wp-content/plugins/gutenberg/editor/build/index.js?ver=1509679811:39:52712)
value @ index.js?ver=1509679811:39

Edit: Cloudflare is not blocking these requests above - I checked the firewall and nothing there.

Hello, I'm trying to refine the Cloudflare WAF rule that is blocking these requests. Could someone provide me with a sample JSON payload that getting blocked?

I have released a refinement of the rule in question which should resolve this. Please let me know if this problem persists and I will reopen my ticket and continue investigating

I have the same problem described here but i don't use Cloudflare, to help you guys this is the error showing in my Chrome:

VM5263:1 PUT https://www.example.org/wp-json/wp/v2/pages/209 403 (Forbidden) (anonymous) @ VM5263:1 send @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 ajax @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 e.ajax @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:17 e.sync @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:17 sync @ wp-api.min.js?ver=4.9:1 save @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:17 save @ wp-api.min.js?ver=4.9:1 REQUEST_POST_UPDATE @ index.js?ver=1510860286:39 (anonymous) @ index.js?ver=1510860286:39 (anonymous) @ index.js?ver=1510860286:39 (anonymous) @ index.js?ver=1510860286:28 d @ index.js?ver=1510860286:28 td @ react-dom.min.cc6ec027.js:66 invokeGuardedCallback @ react-dom.min.cc6ec027.js:117 invokeGuardedCallbackAndCatchFirstError @ react-dom.min.cc6ec027.js:117 Bd @ react-dom.min.cc6ec027.js:72 executeDispatchesInOrder @ react-dom.min.cc6ec027.js:119 rd @ react-dom.min.cc6ec027.js:65 df @ react-dom.min.cc6ec027.js:64 Ha @ react-dom.min.cc6ec027.js:65 processEventQueue @ react-dom.min.cc6ec027.js:125 handleTopLevel @ react-dom.min.cc6ec027.js:130 hf @ react-dom.min.cc6ec027.js:74 batchedUpdates @ react-dom.min.cc6ec027.js:26 Ed @ react-dom.min.cc6ec027.js:73 kc @ react-dom.min.cc6ec027.js:66 batchedUpdates @ react-dom.min.cc6ec027.js:121 dispatchEvent @ react-dom.min.cc6ec027.js:123 load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246 Uncaught TypeError: Cannot read property 'hasClass' of undefined at HTMLDocument.<anonymous> (load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246) at HTMLDocument.dispatch (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at HTMLDocument.r.handle (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.a.event.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:9) at HTMLDocument.<anonymous> (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Function.each (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2) at a.fn.init.each (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2) at a.fn.init.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.<anonymous> (load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245) (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246 dispatch @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 r.handle @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 a.event.trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:9 (anonymous) @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 i @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 fireWith @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 y @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 c @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 XMLHttpRequest.send (async) (anonymous) @ VM5263:1 send @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 ajax @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 j @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 setTimeout (async) k @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 m @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 n @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 dispatch @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 r.handle @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246 Uncaught TypeError: Cannot read property 'hasClass' of undefined at HTMLDocument.<anonymous> (load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246) at HTMLDocument.dispatch (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at HTMLDocument.r.handle (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.a.event.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:9) at HTMLDocument.<anonymous> (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Function.each (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2) at a.fn.init.each (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2) at a.fn.init.trigger (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3) at Object.<anonymous> (load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245) (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:246 dispatch @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 r.handle @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 a.event.trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:9 (anonymous) @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 trigger @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 i @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 fireWith @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:2 y @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 c @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 XMLHttpRequest.send (async) (anonymous) @ VM5263:1 send @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 ajax @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:4 j @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 setTimeout (async) k @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 m @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 (anonymous) @ load-scripts.php?c=0&load[]=hoverIntent,common,admin-bar,svg-painter,heartbeat,wp-auth-check&ver=4.9:245 dispatch @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3 r.handle @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-api-request,wp-util,wp-backbone,media-models,moxiejs,plupload,wp-pluploa&load[]=d,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable&ver=4.9:3

@memuller thank you for this: https://github.com/WordPress/gutenberg/issues/2565#issuecomment-334346927

It works (for gratis CloudFlare accounts), but also exposes all wp-json calls. As I and others encounter this issue generally with Gutenberg, is there a more-specific Gutenberg list of calls we can bracket to via that pagerule regex?

I'm also encountering this issue. I keep having to go to cloudflare and whitelist my IP. After doing that, it's still not working, and I'm getting the rest_cookie_invalid_nonce response in my Network tab when I try to debug etc.

As a CloudFlare (free) user, I'm being encumbered by this issue, too.

Strangely, no variation of page rule will "fix" it. I have to whitelist my IP, specifically. Can't just whitelist my country (for convenience) – I have to whitelist by IP, which is cumbersome.

Added detail: the problem occured once I added _Image_ blocks to my post.

I hope this can be fixed?

Closing as it doesn't appear there are specific actionable items in this issue — feel free to open new issues for subsequent reports.

Issue was resolved when Cloudflare updated the WAF rules to accommodate the issue. See gutenberg/#2704 for more information on the issue

2704 has been re-opened since the issue is still persisting.

@MichielDeMey Unfortunately it is not something Gutenberg can fix.

I understand, but some repos prefer to keep an issue open until it has been fixed by the third party so you don't end up with multiple duplicate issues because other continue to open new ones. 🙂

I am facing the same issue.

Changed different themes, disabled all other plugins but no luck :(
Here is an screenshot of my console log http://prntscr.com/kett91

@azadrpi

it's an issue with Gutenberg and Cloudflare. Does disabling the Gutenberg plugin solve the issue?

Having the same issue

@caraya Yes disabling the Gutenberg plugin solve the issue.

I've checked it with a fresh WordPress installation in localhost. Still same problem. Though there is showing the update failed error, the post/page is updated to the database. After a few wasted hours of my time seeking the solution, I decided to skip the problem for now. Cause I'm learning the Gutenberg API so the problem is not a big deal, but that bothers a lot :(

I too am facing the problem. I installed it on fresh 4.9.8 and latest nightly build installs. Whenever I go to Add New Post, Chrome developer tool shows this:

react-dom.24169eaf.js:526 Warning: Unsafe lifecycle methods were found within a strict-mode tree:
    in Unknown (created by e)
    in e (created by RemountOnPropChange(e))
    in RemountOnPropChange(e)
    in WithSelect(Component)

componentWillUpdate: Please update the following components to use componentDidUpdate instead: t

Learn more about this warning here:
https://fb.me/react-strict-mode-warnings

@azadrpi I hear you... I stopped working with Gutenberg because I got too frustrated. If you work with Cloudflare as your CDN it seems that it was fixed on their end. I'd suggest trying it again and reporting if it still gives you the same error

@emfluenceindia this seems to be a different issue. I'd suggest opening a separate issue ticket with this information as this doesn't seem to be related to this particular issue

Here is a video screen-cast I did. Not the problem I was talking about until the problem being talked about here starts happening in the middle of reporting another possible small misunderstanding or false problem. Anyhow check this out. Is this what keeps happening to you? Updating fail, Auto Saved, Generation preview but does not? Fresh install of Wordpress too. http://youtu.be/yVWYDcWXsfA?hd=1

One Solution found here works immediately! https://wordpress.org/support/topic/gutenberg-blocked-by-wordfence/ Wordfence Security was cause mine and it is said to configure the firewall to learning mode and immediately tested and works!

Video showing how it is done! https://screencast-o-matic.com/watch/cFQnexqa1y

I was having the same issue, first i thought it was happening because i set up rules on cloudflare to chance http to https but disabling them didn't helped. I tried solutions above for free CF users but they didn't helped either. In the end i made these changes and gutenberg works this way.
Speed Tab
Rocket Loader - off
Brotili - off
Firewall Tab
Security Level - essentially off (might be different level in my opinion)
Crypto Tab
Authenticated Origin Pulls - off
Automatic HTTPS Rewrites - off

I haven't tried cross-solutions actually, just disabled them and it worked out. Still i'm not happy to disable CF ssl, hope there will be a proper solution soon.

I had a related issue - for me it was ModSecurity firewall configuration in Plesk found via the apache errorlog

@jamesmthornton, did that just start after upgrading to 3.8? If so, then #9979 might be the cause.

@iandunn bleh yeah I wrote a post about it 2 days ago, of course google didnt index it tho https://inboundfound.com/solution/cannot-open-edit-post-wp-admin-connection-refused/

I was having this issue (unable to save or publish a post via gutenberg). I was able to get around it by NOT signing in via WordPress. When logging in via username and password, it works.

I am having this issue on nginx SSL enabled, with no cloudflare, this seems to be a persistent bug. I am going to return to classic editor while this is fixed because no webserver settings should prevent such a tool built into the CMS.

@diveyez the CMS lives in a web server and there may be one or more proxy servers between you and your server. Can you post server logs that may help troubleshoot the problem? If it's not Cloudflare related then it's not the same issue as that was specifically connected to Cloudflare Application Firewall and their blocking some commands from Gutenberg, that has been solved.

As noted over in https://github.com/WordPress/gutenberg/issues/2596 this "Updating failed" issue seems to also be able to be fixed by changing the Permalink setting. (I had this happen to me on one of my sites today after an upgrade to WordPress 5.0 and the permalink change fixed my issue.)

I'm getting the same "publish/update/save" failed message, however I get no errors in the dev console and despite the message the post does in fact succeed in publishing/updating/saving. I have confirmed this multiple times by publishing, getting the message, going to the list of posts and seeing the post listed as published.

My server is hosted on DigitalOcean, I don't know if they use CloudFlare or not, all I know is that it's an ubuntu server running apache.

On my dev machine running XAMPP and after updating wordpress to 5.0.1 I was receiving "Update Failed" when trying to create a new page.

I updated my XAMPP and verified all file and folder permissions were correct and was still getting this error so I setup letsencrypt to get a valid ssl cert and then the message changed to "Publish Failed" when trying to create a new page.

I checked the error.log and found LimitInternalRecursion logs which led me to this stackoverflow article

I checked the .htaccess file which was invalid so clicked on Settings > Permalinksand clicked Save Changes knowing this would rewrite the .htaccess file and this resolved the issue for me on my dev environment.

It seems that I have some other issue that wasn't fixed until now.

I use mangeto with wordpress under (using fishpig plugin).

I have just updated wp to 5.0.1 version, and there is Updating Failed when I try to save draft or update post.

The problem in here, to make work correctly wordpress under magento I need to define other url for home and other url for siteurl in options table in wordpress.

So magento is using /blog to display the content of blog, and the path for wordpress installation is /news, so option home is set to http://domain/blog and option siteurl is set to http://domain/news. Until now I didn't have this problem.

In backend of wordpress when editing post it seems that there are 4 urls of ajax request that use wrong path to the wordpress installlation, they use /blog in place of /news and it gives js conflicts and post is never saved.

If someone have a solution I will be greatful...

404 errors

Was this page helpful?
0 / 5 - 0 ratings