Gutenberg doesn't fully support WordPress installed in a subdirectory [solved]

bedrock
1

I’ve been having issues with Gutenberg on some actions within the Bedrock/Sage9 setup.

I’ve already posted about this on Sage 9/Bedrock + Gutenberg Error and I admit I probably did not provide enough information.
In any case I’ve tried with the most recent version and on a clean Bedrock/Sage9 install, same issues.

The error mainly appears when using the HTML block (or editing the HTML of a existing block):
image

Checking the console, I get the following:

image
image958×102 9.22 KB 

index.js?ver=1524076616:12 GET https://domain.tld/wp-admin/load-scripts.php?load=wp-codemirror,code-editor,htmlhint,csslint,jshint 404 ()

post.php?post=333&action=edit:1 Refused to apply style from 'https:///domain.tld/wp-admin/load-styles.php?load=wp-codemirror,code-editor' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

post.php?post=333&action=edit:1 Refused to execute script from 'https:///domain.tld/wp-admin/load-scripts.php?load=wp-codemirror,code-editor,htmlhint,csslint,jshint' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

I think the issue is on the path, it is calling https:///domain.tld/wp-admin/load-scripts.php and on a bedrock install we have the same script on https:///domain.tld/wp/wp-admin/load-scripts.php

My issue is that the path is, I believe, hardcoded on the Gutenberg .js files.
The file in question can be seen here: gutenberg/components/code-editor/index.js:24 (GitHub)

There is also a Open issue on Gutenberg project for this (Issue 5892 @ WordPress/gutenberg).

While I understand this is mostly something that should be fixed on the Gutenberg side, is there anything I can do in the meanwhile to workaround this?

Thank you very much.

2

Could be related to this thread: MIME type ('text/html') not a supported stylesheet MIME type …?

3

I do not think so.
That happens because the script is not being loaded.

4

If I add a nginx redirect like this:

location /wp-admin {
    return 301 /wp/wp-admin;
}

It works :slight_smile:

2 Likes
5

Updated post title to better reflect the issue. Hopefully they fix this upstream soon…

6

Another reason to be concerned w/ an impending Gutenmerge.

7

Same issue here with Bedrock (not Sage). The same solution than the one found by @apintocr is working for me. On Apache, that means :

RewriteRule ^(wp-admin/.*) wp/$1 [L,R=301]
1 Like
8

Please note that the issue is only present on the bleeding edge version of the gutenberg plugin. This type of issue will be solved before including gutenberg to the core, with community effort.

1 Like
9

I don’t expect Gutenberg to merge with bugs like this still present. I do however see the fact that these bugs exist at this point as indicative of the relative maturity of the project. I think the timeline for merging Gutenberg to core is overly optimistic, and I wish they wouldn’t hold up the next major release for it and give it more time to soak before merging. They were super cautious about merging the REST API, which was far more mature than Gutenberg is, so I’m not really sure what the rush is.

10

That was a really wise answer. I share you thought about this, and I have confidence that Gutenberg will not ship into core until it is really mature. I just fear that the rush is only about shipping it on the 5.0 milestone that is only an ordinary release between 4.9 and 5.1 for the community but that has a bigger meaning for the outside world.

1 Like
11

Yeah, there’s definitely something symbolic about landing it in a big x.0 release like that but then again, WordPress has always proceeded numerically. 4.0 wasn’t a “special” release, so 5.0 doesn’t have to be. I’m mostly worried they’re also holding up new features (since features land in majors) to wait for Gutenberg to mature, and WordPress is going to stall while we wait.

12

I believe Gutenberg 3.0 fixed this issue.

1 Like