Gutenberg: Editor Crashes with Custom permalinks

[meepingblog]

The editor crashes when a new post is made/edited. It seems to be linked to permalinks. (see below)

To Reproduce
Steps to reproduce the behavior:

1. Change permalinks to /category/post-name/custom or anything other than plain
2. Attempt to add a new post
3. Editor Crashes
4. See error

TypeError: Cannot read property 'show_ui' of undefined
at index.js?ver=1541283461:50
at i (lodash.min.59550321.js:6)
at An.filter (lodash.min.59550321.js:99)
at index.js?ver=1541283461:50
at yh (react-dom.min.82e21c65.js:95)
at lg (react-dom.min.82e21c65.js:120)
at mg (react-dom.min.82e21c65.js:120)
at gc (react-dom.min.82e21c65.js:127)
at vb (react-dom.min.82e21c65.js:126)
at ub (react-dom.min.82e21c65.js:126)

Desktop (please complete the following information):

• OS: Windows 8.1
• Google Chrome (latest version)

Smartphone (please complete the following information):

• Device: iphone7
• OS: iOS 11
• Safari

Plugins/Other

• Latest version of Gutenberg
• Latest version of Wordpress
• Jetpack
• iThemes
• Media Cloud
• Multi-site

Disabling all plugins but Gutenberg produces same behavior.

Fix?

Changing permalinks to plain stops the crashing.
This doesn't happen with pages.

[p2er]

I have the same Issue on Gutenberg version 4.2.0
As soon as I change the permalink to postname or custom (/%postname%/) the editor crashes. Same Problem if changed to a custom configuration like /%category%/%postname%/
Thats renders Gutenberg currently unusable, due to the SEO impact of using the default configuration with post id via GET parameter.

Desktop:
OS: macOS 10.14.1
Google Chrome 70.0.3538.77

This Problem does not occur on our staging server, where WP is hosted on a subdomain.
This Problem does occur on our live server if wordpress is served from a subdomain.
This Problem does also occur on the live server, if the subdomain is redirected to a directory /de/magazin/ and WP base URL is set to the redirected path instead of the subdomain.

Might be related to: https://github.com/WordPress/gutenberg/issues/8802 or https://github.com/WordPress/gutenberg/issues/8456#issuecomment-410433454

I double checked, but I couldn't find any failed XHR requests. I expected to find them if either the server configuration would break a request by not passing through the parameters or the firewall would prevent calls. But user, taxonomy and so on showed the correct data as response while debugging.

[p2er]

Found the Problem: I had the base URL set to https since the page is being served from https. Now i've changed the protocol to http and the editor finally allows me to create new posts and does no longer crash, even if the permalinks are configured with /%category%/%postname%/

[p2er]

Turns out I was a bit quick to think this problem would be resolved. I did set my home path to http, but now the preview und save function won't work, since those request would be sent from an https admin panel to http endpoints and those mixed content requests aren't allowed. Tried to use define('FORCE_SSL_ADMIN', true); to trick the system into using the http base url while serving content from https, but the result was a somewhat expected return to the initial problem stated by meepingblock.

[p2er]

I dug a litte deeper and found out that some of the data required by gutenberg isn't present on the taxonomy call on one server. I've attached a screen shot to show the difference.

[p2er]

As long as the custom permalinks are disabled the JSON request is fetched from /index.php?rest_route=%2Fwp%2Fv2%2Ftaxonomies&per_page=100&context=edit&_locale=user, which works just fine. After the custom permalinks are enabled the JSON is fetched from /wp-json/wp/v2/taxonomies?context=edit&_locale=user where the desired fields are missing.

[ia-webmaster]

I noticed the same problem testing Gutenberg 4.4.0 on Wordpress 4.9.8. I discovered that my issue was my server lighttpd was not populating the $_SERVER['QUERY_STRING'] or the $_GET global when my rewrite file was "^(.*)$" => "index.php". A quick grep search of the code shows $_GET values are used frequently, so why wasn't Wordpress parsing them?
It turns out Wordpress has no interest in parsing the query string from $_SERVER['REQUEST_URI'} when permalinks are used, because permalinks don't use query strings ...right? Except when Gutenberg needs category info or needs to update a draft.
I didn't like fiddling with the rewrite filter, since it was a global file and required a server restart to apply the changes. Something you may not be able to do on a shared server.
I thought there should be a plugin solution, so here's mine.

class QueryFix { 

  public static function filter_parse_uri($value) {    
    if(strpos($_SERVER['REQUEST_URI'],'?') === false) {return ($value);} 
    if(($qs=parse_url($_SERVER['REQUEST_URI'],PHP_URL_QUERY)) == $_SERVER['QUERY_STRING']){return ($value);}
    $s = "Request =".$_SERVER['REQUEST_URI']."\nSERVER['QUERY_STRING']=".$_SERVER['QUERY_STRING'];
    $_SERVER['QUERY_STRING']=urldecode($qs);
    $s.="\nSERVER['QUERY_STRING'] set to: ".$_SERVER['QUERY_STRING'];
    $kvarry = wp_parse_args($_SERVER['QUERY_STRING'],$_GET);
    foreach($kvarry as $k => $v ){
            $_GET[$k] = urldecode($v);
            $s.= "\nGET['".$k."'] = ".$_GET[$k];
    }
    wp_magic_quotes();   //merge with $_REQUEST array 
    if(WP_DEBUG_LOG ){error_log($s."\n");}     
    return($value);    
  }
}
add_filter('do_parse_request',array('QueryFix','filter_parse_uri'),20,1);

This is the output from my debug.log file for the link you posted.

[21-Nov-2018 03:16:03 UTC] Request =/wp-json/wp/v2/taxonomies/category?context=edit&_locale=user
SERVER['QUERY_STRING']=
SERVER['QUERY_STRING'] set to: context=edit&_locale=user
GET['context'] = edit
GET['_locale'] = user

Now things are working well. I know there's more to parsing the query string beyond this (see php.net - parse_url Notes), but it only needs to work for Wordpress permalinks for now.

[micele]

same bug here.

Wordpress 5.0.2
FreeBSD 11
Apache 2.4.37

I use "Month and name" as permalink structure. Changing this to plain, resolves the issue. However I cannot just change this, as there are a lot of permalinks out there which would become deadlinks.

I assume, there are a lot more people affected by this, but ended up stuck here: #12655

[flowl]

Same problem, same Javascript error.

Wordpress 5.0.2 served by nginx
My structure is/%year%/%postname%/.

Curious: I have disabled the Gutenberg plugin. Changing the permalink structure is not really an option.
Could you fix this, or revert latest changes? There must be millions of people now beeing unable to use Wordpress...

Update:
I thought it was sufficient to deactivate the Gutenberg plugin but actually you have to manually install the Classic Editor to keep using Wordpress while a fix is in the making.

[aduth]

I don't know that it's the permalink setting alone which is causing this issue, as I'm unable to reproduce the error myself when testing a custom structure (/%year%/%postname%/) on my own site, nor a throwaway site from poopy.life.

Based on previous comments, server configuration may be a factor.

The visibility property would be missing from the taxonomies response if the server were not able to interpret the context query parameter from the request, as the field is only made available for context=edit requests.

https://github.com/WordPress/WordPress/blob/8ac2091f5dc605e90365593c3c8d95ae1f3e9110/wp-includes/rest-api/endpoints/class-wp-rest-taxonomies-controller.php#L344

[flowl]

As long as the custom permalinks are disabled the JSON request is fetched from /index.php?rest_route=%2Fwp%2Fv2%2Ftaxonomies&per_page=100&context=edit&_locale=user, which works just fine. After the custom permalinks are enabled the JSON is fetched from /wp-json/wp/v2/taxonomies?context=edit&_locale=user where the desired fields are missing.

This.

On /wp-json/wp/v2/taxonomies?context=edit&_locale=user, $_SERVER['QUERY_STRING'] is empty and the visibility field is missing.

In nginx, I'm only using try_files $uri $uri/ /index.php; which has been sufficient until now for permalinks and rewrites... in my FASTCGI_PARAMS the query_string is set, but it's empty with the request.

Solution for nginx is to append arguments to the try_files index:

try_files $uri $uri/ /index.php$is_args$args;

[aduth]

This is also documented in the Nginx configuration documentation for WordPress:

include the "?$args" part so non-default permalinks doesn't break when using query string

https://codex.wordpress.org/Nginx#General_WordPress_rules

[aduth]

Unless demonstrated otherwise, I'm going to close this as attributable to server misconfiguration in losing query arguments as part of a rewrite rule.

Refer to the following documentation for more information:

Apache: https://codex.wordpress.org/htaccess
nginx: https://codex.wordpress.org/Nginx
Others: https://codex.wordpress.org/Using_Permalinks#mod_rewrite:_.22Pretty_Permalinks.22

If continuing to be an issue, it would be most helpful to share server configuration relevant to pretty permalinks rewrite rules, or to contact your host if managed on your behalf.