Publishing / Updating Failed (5.2.2 clean install, default theme, SSL off, no plugins)

[chrispink]

New install Wordpress 5.2.2 on localhost, no SSL, default TwentyNineteen theme, no plugins.

Error; Updating failed
Save Draft: Says it's successful but page does not appear. (Wordpress know this because I get the warning "Are you sure you want to leave this page?"

And, of course, loading the Classic Editor plugin solves the problem.

This is the console log;

[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (taxonomies, line 0)
[Error] Unhandled Promise Rejection: [object Response]
dispatchException (data.min.js:1:22123)
(anonymous function) (data.min.js:1:24291)
n (data.min.js:1:19513)
a (data.min.js:1:19752)
promiseReactionJob
[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (users, line 0)
[Error] Unhandled Promise Rejection: [object Response]
dispatchException (data.min.js:1:22123)
(anonymous function) (data.min.js:1:24291)
n (data.min.js:1:19513)
a (data.min.js:1:19752)
promiseReactionJob
[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (post_tag, line 0)
[Error] Unhandled Promise Rejection: [object Object]
dispatchException (data.min.js:1:22123)
(anonymous function) (data.min.js:1:24291)
n (data.min.js:1:19513)
a (data.min.js:1:19752)
promiseReactionJob
[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (9, line 0)

It seems that Wordpress developers are in denial because this well-documented bug still exists and turning off issues in GitHub does not resolve the issue.

[designsimply]

This doesn't happen to me in testing with the same setup you described (except my test was not a localhost setup). The 403 Forbidden errors probably mean the problem is due to some kind of protective setting in your local web server setup or possibly a local or network firewall that is blocking something needed.

I found one example at #2565 (comment) mentioning that re-saving Settings > Permalinks helped solve the problem in their case.

In other cases, I've noticed some people's settings for things like Cloudflare were configured in a way that blocked the editor itself. It can be a bit difficult to find the source of the problem with such a general error message returned by the server. In your case, since you are using a localhost setup, do you have a firewall installed locally which might be blocking some types of traffic wanting to be sent by the WP API by chance?

[chrispink]

I'm not sure why the thread was closed just after adding a "Needs more info" status. I am not sure what more information is needed. This is a known bug. Refusal to update is cured by adding the Classic Editor plugin.

@designsimply, there is no firewall, Cloudflare or otherwise and permalinks > save did not work. As I say the only thing that (I can find that) works is adding the Classic Editor plugin.

[youknowriad]

This thread was closed because there's something in your WordPress install or server config that's preventing the scripts from being loaded.

Unfortunately, that's not something we can help with and the root cause is different from one install to another.

As our repository management doc states, the issues are left open if actionable and relevant.

What I'd recommend is trying to look at similar threads and try the different changes to the configs... people have tried.

[chrispink]

You can say that and it's singularly unhelpful. This is a well documented bug.

Although the triggering may be different configurations, despite my long experience of managing Wordpress hosting I am unable to see any consistency around occurrences; it can happen locally or remotely, on new installations or old ones. It does happen - with the same lack of consistency - with vanilla installations without plugins and using built-in themes).

The thing that makes it a bug that needs attention is the simple fact that installing the Classic editor solves the problem. Consistently and absolutely.

There seems to be a bit of political 'we won't accept criticism of Gutenberg' going on here. I have no problem with the editor, it seems a logical next step. Unfortunately in a small but significant number of cases it causes this problem.

That's it, you can go back to ostrich mode. I shall continue using Gutenberg when it works and Classic editor when it doesn't.

[chrispink]

I will give you one example, which prompted me to reply to you. I have this afternoon, cloned a site on a server to a subdomain for staging. Cloned as in copied everything as is. I duplicated the database and changed the references. To all intents I have two identical sites. One has the issue, one doesn't.

I would be grateful if you could tell me how on earth this could be a problem described as "there's something in your WordPress install or server config that's preventing the scripts from being loaded

[youknowriad]

The thing that makes it a bug that needs attention is the simple fact that installing the Classic editor solves the problem. Consistently and absolutely.

I understand the frustration and share a lot of it to be honest especially because I saw people struggle with a lot and blame Gutenberg for it which is fair because for people it's Gutenberg the responsible because as you said installing Classic editor solves the issue.

The reality is completely different though, Gutenberg is the only Core feature that relies on the REST API. A lot of WordPress installation don't really take care about making sure the Rest API works properly, and it wasn't that important to ensure before Gutenberg.

There might be things Core can do to make the Rest API less fragile and you'd be better served by opening a trac ticket for it. Gutenberg being broken is the consequence, not the issue.

Gutenberg is also the only Core feature that relies on these new scripts (packages). I'm pretty sure if you check your installation you'll find the file that is being fetched data.min.js at the right place but for some reasons the browser is not capable of fetching it. 403 means there are rights issues maybe or potentially wrong server config or things like that. I can't go deeper unfortunately because I don't have access to your install to debug it.

I understand that you feel that we don't like critics but that's not the case. With my explanations above, what do you think we can do in Gutenberg?

[chrispink]

Firstly, thank you for taking the time, understanding a problem is the first stage to resolving it.

Is there a simple test of the REST API (other than Gutenberg not working)?

As to your question, 'what do I think you could do', perhaps some test that either 1. warned the user that there is a problem with the REST API or 2. some fallback in the event of it not working (a bit like Contact Form 7 falls back to HTML if JSON fails). Although in the case of 2, some indication that there's a problem would be helpful.

My issue is that every time I encounter this problem I'm nose-deep in production workflow and have little time to debug the issue. If I could reliably reproduce the issue (you'll notice I say issue rather than bug to be a bit more respectful ;-) I could spend some time out of the production workflow but I have yet to find a reliable way of recreating it. As I say it happens, apparently randomly, on local installs, my development server and my live server alongside working versions of Gutenberg.

[chrispink]

Just to note, next time it happens, I shall look more closely at data.min.js