Gutenberg: Gutenberg Not Working: White Page Admin Area (solved 3 separate issues: theme conflict, file blocked at host level, Apache config blocking anything with "data" in the name)

Created on 17 Sep 2018 · 32Comments · Source: WordPress/gutenberg

Describe the bug

White screen when trying to edit or create new post with gutenberg

To Reproduce
Steps to reproduce the behavior:

Go to posts and edit existing post or create new post
White screeen with wordpress posts area(wp-admin/edit.php)

Expected behavior
normal editor func

Screenshots
None

Desktop (please complete the following information):

OS: Windows 10 Pro
Browser Chrome 69.0.3497.92 64 Bit Edition
Version 3.8.0

Smartphone (please complete the following information):
None

Additional context

Installed Plugins

yuklu-eklentiler

No any errors appear browser and etc, no any errors nginx logs, I'm using php 7.1 (no error) for server side, tried to close plugins and the result did not change, How can I solve this problem?

Redis Extension: 4.1.1
Predis Client: 1.1.1
PHP Version: 7.1.20-1+0~20180910100532.3+stretch~1.gbp17c613
Multisite: No

[Type] Help Request

Source

MertcanGokgoz

👍2

Most helpful comment

The Apache logs led me to the solution: in the configuration file of the vhost, /etc/apache2/sites-available/wp-gutenberg.conf, I had a section

<LocationMatch "/(data|conf|bin|inc)/">
        Order allow,deny
        Deny from all
        Satisfy All
</LocationMatch>

Since the path to the Script /var/www/wp-gutenberg/wp-content/plugins/gutenberg/build/data/index.js has the string "data" in it, this is obviously the problem.
By changing the first line of the snippet above to

<LocationMatch "/(conf|bin|inc)/">

and restarting the apache daemon(!) I could fix it and Gutenberg is now working.
Hope this helps others, too.

andreas-pgss on 20 Sep 2018

👍3 🎉1

All 32 comments

I'm experiencing the same issue. It also occurs when it is the only plugin active in Troubleshooting Mode of the Health Check plugin. The editor works normally when Gutenberg is deactivated, and reinstalling Gutenberg had no effect.

Browser Environment

OS: Windows 10 Pro
Browser: Firefox Developer Edition 63.0b6

WordPress Environment

Gutenberg 3.8.0
WordPress 4.9.8
PHP 5.6

dyllisphiller on 18 Sep 2018

I have the same problem here:
Webserver: apache 2.4.18 on Xubuntu 16.04 with PHP 7.2 and MySQL 5.7
Client A: Windows 10 with either Firefox 62 or Chromium 70.0.3535.0 or PaleMoon 28
Client B: Xubuntu 16.04 with Firefox 62 (64 Bit)

I am currently evaluating WordPress.
After encountering the problem with a test install of WordPress 4.9.8 that has multiple plugins as well as themes installed I set up a clean fresh install of WP 4.9.8 on the same VM and the only plugin I added was the current Gutenberg 3.8.0.
The same problem occurs again. When I try to edit a post or a page with Gutenberg, I get a blank page without any elements and Firefox's web console says:

----8<----
JQMIGRATE: Migrate is installed, version 1.4.1 load-scripts.php:9:542
Laden fehlgeschlagen für das

I've seen several similar reports since 3.8 was released, and I think the problem is often (but not always), because of the new wp-polyfill-ecmascript file introduced by #9643.

It looks like there's a ModSecurity rule that incorrectly flags that file as being an XSS attack. That seems consistent with the console log that @dyllisphiller posted, but is probably a separate issue from what @andreas-pgss posted. You can confirm it's caused by ModSecurity by checking your server logs (probably Apache/Nginx error logs, but wherever ModSecurity is configured to log to); if you're not sure where to look, you can ask your host for help.

Here's some reports on the forums that may be related:

iandunn on 19 Sep 2018

👍3

Thank you for your answer

@designsimply I've tried to turn off plugins one by one, no change in the problem. finally closed the CloudFlare but white page again (No any errors appear browser)

MertcanGokgoz on 19 Sep 2018

@andreas-pgss thank you for including browser console output. In your 2nd test, where Gutenberg was the only plugin installed, what theme were you testing with? Can you think of anything such as a security or firewall settings on your server which may be blocking the API in your case? If you check the Network tab in your browser developer tools, can you see the responses for any failed API calls?

@designsimply: I was using the default theme, Twenty Seventeen; I even uninstalled the two default plugins that come with the base installation package.
Firewall: iptables-save gives exactly one empty line of output, so there are obviously no ports blocked.

wordpress-4.9.8.-gutenberg-3.8.0_network-log.har.json.txt.zip

andreas-pgss on 19 Sep 2018

PS: I forgot to say:

this is probably the really interesting part:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /wp-content/plugins/gutenberg/build/data/index.js
on this server.<br />
</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at wp-gutenberg.pgss.lan Port 80</address>
</body></html>

But: on the file system level this file is definitely accessible (read by all, this is a test machine in the local network after all). Might there be anything wrong with the rewrite settings? (Settings -> Permalinks is set to %baseurl%/%postname%/).

.htaccess is:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

andreas-pgss on 19 Sep 2018

@dyllisphiller thank you for the extra information! This is worth digging into:

Loading failed for the

@MertcanGokgoz thank you for testing with plugins turned off.

I've tried to turn off plugins one by one, no change in the problem. finally closed the CloudFlare but white page again (No any errors appear browser)

Apologies to ask again. You are sure there are no errors showing in Chrome inside the View > Developer > JavaScript Console panel? I was expecting there to be some errors there for your case!

May I ask for one additional troubleshooting step if possible? Can you turn off other plugins and then also clear browser cache before trying to go to Posts > Add New?

designsimply on 19 Sep 2018

@designsimply I tried to turn off all plugins but the white page, I tried to turn off Cloudflare(also turn off all plugins) but the white page again this is an interesting situation because I don't get the error. (server side and client side)

When I press F12, I saw Gutenberg codes(HTML and js) in the developer console elements tab but It cannot be rendered to the browser

MertcanGokgoz on 20 Sep 2018

@MertcanGokgoz are you saying that if you turn off all plugins and also Cloudflare that creating a new post works normally at that point?

designsimply on 20 Sep 2018

@andreas-pgss, a 403 Forbidden error is indeed a point of interest.

You don't have permission to access /wp-content/plugins/gutenberg/build/data/index.js
on this server.

If the file permissions are correct then I am not sure why you would see this. 😞 Are you certain there are no other security or firewall rules which could be affecting your local sever?

Might there be anything wrong with the rewrite settings? (Settings -> Permalinks is set to %baseurl%/%postname%/).

I tried testing this by updating Settings > Permalinks > Custom Structure to /%postname%/ on my local install, and I couldn't get the Posts > Add New page to break. I still see the editor normally when I update that setting. However, I do know that at least one other person reported that flushing rewrite rules helped them solve a similar problem (https://github.com/WordPress/gutenberg/issues/8960#issuecomment-412830219) so perhaps give that a try. Another person mentioned that enabling the rewrite module in Apache solved the issue in their case (https://github.com/WordPress/gutenberg/issues/8534#issuecomment-410795297) and you could double check that.

Are you testing on master with the latest commits pulled? Since you are testing with a local install, perhaps you can try the last tip at https://make.wordpress.org/test/handbook/gutenberg-testing/get-setup-for-testing/#useful-commands to make a fresh install or maybe you would be willing to try a new build completely? If you are testing with a local dev setup and we can't find a way to make the problem happen for others with local setups, it feels like it has to be something specific to your local dev env!

designsimply on 20 Sep 2018

@designsimply Fix this problem,

Only edit my functions.php and remove this snippet

https://gist.github.com/loorlab/7a5b81c121e74fe7d4060b60d868352c

MertcanGokgoz on 20 Sep 2018

@MertcanGokgoz Where exactly did you find this snippet in your code? I grepped my whole wordpress folder for it and did not find it anywhere.

andreas-pgss on 20 Sep 2018

@andreas-pgss, a 403 Forbidden error is indeed a point of interest.

You don't have permission to access /wp-content/plugins/gutenberg/build/data/index.js
on this server.
If the file permissions are correct then I am not sure why you would see this. 😞 Are you certain there are no other security or firewall rules which could be affecting your local sever?
I have double checked the directory permissions of the file's path and itself. They are good.
As I said, there are no fire wall rules set up (iptables). I do not see what should block access if not some setting of apache (vhost, .htaccess).

I saw yesterday that package apparmor is installed on the VM because it was required by the package mysql-server-5.7 package. I have no experience with apparmor. Package apparmor-profiles is not installed. Could apparmor be the culprit?

This morning I remembered I had installed Gutenberg in a local test install at home, too, a while ago. I quickly checked: it is working fine with version 3.80 on WP 4.9.8. My machine at home is running apache 2.4.something, MariaDB instead of MySQL and 7.2ish PHP on Xubuntu 18.04 (as compared to 16.04 in the test setup I reported the bug with above). As I had no time this morning I will try to make a comparison of set-ups and settings on the weekend if I can manage.

By the way, I am using the German packages from https://de.wordpress.org/ - e.g. https://de.wordpress.org/wordpress-4.9.8-de_DE.tar.gz
But AFAIK they differ only by adding German language translations.

Might there be anything wrong with the rewrite settings? (Settings -> Permalinks is set to %baseurl%/%postname%/).
I tried testing this by updating Settings > Permalinks > Custom Structure to /%postname%/ on my local install, and I couldn't get the Posts > Add New page to break. I still see the editor normally when I update that setting. However, I do know that at least one other person reported that flushing rewrite rules helped them solve a similar problem (#8960 (comment)) so perhaps give that a try. Another person mentioned that enabling the rewrite module in Apache solved the issue in their case (#8534 (comment)) and you could double check that.

I have done that a couple of times already. It did not fix the problem.

Are you testing on master with the latest commits pulled?

No. I used the default plugin installation option from within the WordPress instance.

Since you are testing with a local install, perhaps you can try the last tip at https://make.wordpress.org/test/handbook/gutenberg-testing/get-setup-for-testing/#useful-commands to make a fresh install or maybe you would be willing to try a new build completely? If you are testing with a local dev setup and we can't find a way to make the problem happen for others with local setups, it feels like it has to be something specific to your local dev env!

Currently I do not have the time for that, or at least not in the office.
I agree that it is probably something related to the specifics of the operating system, software versions and settings. But I would really like to find out why it doesn't work on this Xubuntu 16.04 VM, but does at home on Xubuntu 18.04.
Actually, I shall take home a copy of the wordpress+gutenberg instance and check if it behaves differently there.

andreas-pgss on 20 Sep 2018

@andreas-pgss I turned off the wp-oembed feature. Because I wasn't using it. that's it

MertcanGokgoz on 20 Sep 2018

@andreas-pgss I turned off the wp-oembed feature. Because I wasn't using it. that's it

Sorry, but I do not understand you.

I tried several plugins that claim to switch of the oembed feature, but none of them helped.
How did you turn it off? Where?

andreas-pgss on 20 Sep 2018

The Apache log files say:

==> error.log <==
[Thu Sep 20 10:20:08.771121 2018] [access_compat:error] [pid 28175] [client 192.168.1.183:57840] AH01797: client denied by server configuration: /var/www/wp-gutenberg/wp-content/plugins/gutenberg/build/data/index.js, referer: http://wp-gutenberg.pgss.lan/wp-admin/post-new.php

==> access.log <==
192.168.1.183 - - [20/Sep/2018:10:20:08 +0200] "GET /wp-content/plugins/gutenberg/build/data/index.js?ver=1537274969 HTTP/1.1" 403 560 "http://wp-gutenberg.pgss.lan/wp-admin/post-new.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0"

andreas-pgss on 20 Sep 2018

The Apache logs led me to the solution: in the configuration file of the vhost, /etc/apache2/sites-available/wp-gutenberg.conf, I had a section

<LocationMatch "/(data|conf|bin|inc)/">
        Order allow,deny
        Deny from all
        Satisfy All
</LocationMatch>

<LocationMatch "/(conf|bin|inc)/">

and restarting the apache daemon(!) I could fix it and Gutenberg is now working.
Hope this helps others, too.

andreas-pgss on 20 Sep 2018

👍3 🎉1

@designsimply I'm using A Small Orange. I haven't been able to view the server logs in cPanel, so I've opened a ticket to fix the issue. Once I can review those logs, I'll post an update here.

dyllisphiller on 25 Sep 2018

👍1

@dyllisphiller thank you for the extra info. I found one other case of someone using A Small Orange for hosting who is having the same problem https://github.com/WordPress/gutenberg/issues/9990#issuecomment-423158877 so contacting them and asking them for help figuring out why the https://[domain]/wordpress/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js file is not being loaded properly is the best route in your case. Let us know what you find!

designsimply on 28 Sep 2018

In summary, it looks like there were three separate problems reported in this thread:

@MertcanGokgoz worked around the issue by turning off the wp-oembed feature in their functions.php file in their theme.
@dyllisphiller is contacting their host, A Small Orange, to ask them to unblock the wp-polyfill-ecmascript.min.2ae96136.js file.
@andreas-pgss solved the problem by updating Apache configuration files so they do not block paths with the word "data" in them.

I am going close this issue as resolved and say that I really appreciate everyone here who is testing Gutenberg at this early stage and taking the time to dig into the details. Thank you!

designsimply on 28 Sep 2018

The Apache logs led me to the solution: in the configuration file of the vhost, /etc/apache2/sites-available/wp-gutenberg.conf, I had a section

@andreas-pgss, I'm glad you've solved the problem! Out of curiosity, do you remember where you got that Apache vhost configuration from? I mean, the one with <LocationMatch "/(data|conf|bin|inc)/">.

mcsf on 28 Sep 2018

@dyllisphiller I'd be curious to hear what you find out. I use A Small Orange as well, and I'm seeing this same issue. I think there must be some sort of blockage of the word "ecmascript". When I alter the file name to remove the "t" at the end, then I can see the file.

For instance: wp-polyfill-ecmascrip.min.2ae96136.js returns 200 while wp-polyfill-ecmascript.min.2ae96136.js returns a 404. Both files exist, though:

awayken on 1 Oct 2018

@dyllisphiller I'd be curious to hear what you find out. I use A Small Orange as well, and I'm seeing this same issue. I think there must be some sort of blockage of the word "ecmascript". When I alter the file name to remove the "t" at the end, then I can see the file.

@awayken: Did you see my "solution"? I found there was a filter of certain paths/file names in the vhosts config, there might also be something like this somewhere in .htaccess or the base configuration of your webserver.

andreas-pgss on 1 Oct 2018

The Apache logs led me to the solution: in the configuration file of the vhost, /etc/apache2/sites-available/wp-gutenberg.conf, I had a section

@andreas-pgss, I'm glad you've solved the problem! Out of curiosity, do you remember where you got that Apache vhost configuration from? I mean, the one with <LocationMatch "/(data|conf|bin|inc)/">.

I have only got a vague memory that there was some blog article about a good set of apache directives to put in .htaccess and/or vhost configs. Has been a while. Usually I include a commet quoting the source of such stuff, but in this file I sadly forgot. So it is quite unlikely I find it again. If I do, I will let you know.

andreas-pgss on 1 Oct 2018

@awayken Unfortunately, I’ve made no progress with their support.

I wrote:

Within the WordPress Gutenberg plugin, the file located at [directory]/wp-polyfill-ecmascript.min.2ae96136.js is supposed to be accessible at [domain/directory]/wp-polyfill-ecmascript.min.2ae96136.js but instead returns a 404. I have reason to suspect the server is simply blocking the file.

A Small Orange support replied:

I have checked your issue and I could see that you are trying to access the Java script file. Unfortunately, Java script is not supported on our shared server.

(I’m definitely changing hosts, but that’s neither here nor there.)

Based on this discussion, I’m inclined to think the server thinks wp-polyfill-ecmascript.min.2ae96136.js is a security threat. In the meantime I could rename the JS file and replace every reference to it in the plugin, but that’ll be overwritten when Gutenberg is updated, and it’s probably a bad idea to attempt that after Gutenberg is integrated into WordPress.

dyllisphiller on 9 Oct 2018

Is there some htaccess equivalent version of that locationmatch fix? I spoke with my host and don't have access to my Apache vhost configuration, so I'm left trying to deal with this at the htaccess level.

jbwharris on 12 Oct 2018

In Plesk (Plesk Onyx 17.0.17 Update #59), changing my ModSecurity setting from "On" to "Detection Only" fixed this for me/ loaded the Gutenberg editor on a fresh install of Wordpress running the TwentySeventeen theme. I installed Wordfence as well - all is good.

Although I definitely need ModSecurity to be fully "On" - is there a security rule I can add at the server level?