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)

[mertcangokgoz]

Describe the bug

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

To Reproduce
Steps to reproduce the behavior:

1. Go to posts and edit existing post or create new post
2. 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

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

[dyllisphiller]

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

[andreas-pgss]

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 <script> mit der Quelle "http://wp-gutenberg.pgss.lan/wp-content/plugins/gutenberg/build/data/index.js?ver=1537274969". post-new.php:119
[Mitteilungsdetails anzeigen/ausblenden] TypeError: wp.data is undefined[Weitere Informationen] post-new.php:124:2
[Mitteilungsdetails anzeigen/ausblenden] TypeError: a is undefined[Weitere Informationen] index.js:2:132043
[Mitteilungsdetails anzeigen/ausblenden] TypeError: wp.blocks is undefined[Weitere Informationen] post-new.php:132:1
[Mitteilungsdetails anzeigen/ausblenden] TypeError: a is undefined[Weitere Informationen] index.js:1:8537
[Mitteilungsdetails anzeigen/ausblenden] TypeError: u is undefined[Weitere Informationen] index.js:1:1548
[Mitteilungsdetails anzeigen/ausblenden] TypeError: c is undefined[Weitere Informationen] index.js:1:1145
[Mitteilungsdetails anzeigen/ausblenden] TypeError: d is undefined[Weitere Informationen] index.js:12:59186
[Mitteilungsdetails anzeigen/ausblenden] TypeError: Object(...) is not a function[Weitere Informationen] index.js:12:8067
[Mitteilungsdetails anzeigen/ausblenden] TypeError: u is undefined[Weitere Informationen] index.js:12:6427
[Mitteilungsdetails anzeigen/ausblenden] TypeError: wp.editPost is undefined[Weitere Informationen] post-new.php:1680:5
window._wpLoadGutenbergEditor</<
http://wp-gutenberg.pgss.lan/wp-admin/post-new.php:1680:5
----8<----

This output is the same in the fresh install with Gutenberg the only installed plugin and the previous install where I tested numerous plugins and themes before (and still have many plugins (re)activated after experimenting with Gutenberg and switching them off)

[designsimply]

Thank you for reporting this! I tested trying to create a new post using WordPress 4.9.8 and Gutenberg 3.8.0 using Firefox 62 on Windows 10 via browserstack.com and also using Edge 42 and on Windows 10 installed on a VM, and I found that I was able to create new posts without any problems and editing existing posts also worked normally in my tests.

@mertcangokgoz and @dyllisphiller, are you able to check the web console in your browser developer tools to see if there are errors that match the ones that @andreas-pgss has reported?

If you are using Cloudflare, there have been some past conflicts which have been resolved, but I see in #2704 that there still may be some problems ongoing. If you are able to check your Cloudflare WAF log to look for any rules that are causing requests to be blocked, can you please make a note of that on the #2704 issue?

@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]

@mertcangokgoz oh! I almost missed it before, but can you please test again after deactivating the following plugin? The REST API must be enabled in order for Gutenberg to work.

Disable REST API by Dave McHale version 1.4.3

[dyllisphiller]

@designsimply here's the browser console error log. I've redacted the domain with [domain].

JQMIGRATE: Migrate is installed, version 1.4.1 load-scripts.php:9:542
Jed localization error: 
Error: Domain `ASE` was not found. index.js:5:18586

Loading failed for the <script> with source “https://[domain]/wordpress/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js”. post-new.php:78:1
ReferenceError: regeneratorRuntime is not defined index.js:12:86582
TypeError: Object(...) is not a function index.js:12:8067
TypeError: Object(...)(...) is undefined, can't access property "getBlockSelectionStart" of it index.js:12:15977
TypeError: wp.editPost is undefined, can't access property "initializeEditor" of it post-new.php:2054:5

I am not using Cloudflare.

Also, a correction (I'm not sure if it's relevant, so I'm including it anyway): Trying to enable Gutenberg in Health Check's Troubleshooting Mode gives an error:

When enabling the plugin, gutenberg, a site failure occurred. Because of this the change was automatically reverted.

[iandunn]

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:

• https://wordpress.org/support/topic/white-screen-of-death-after-migration/
• https://wordpress.org/support/topic/after-updating-3-8-cant-write-new-posts/
• https://wordpress.org/support/topic/white-screen-of-death-when-opening-or-creating-a-page-using-gutenberg-editor/
• https://wordpress.org/support/topic/github-vs-forums/

[mertcangokgoz]

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)

[andreas-pgss]

@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]

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

[designsimply]

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

Loading failed for the <script> with source “https://[domain]/wordpress/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js”.

May I please ask what web hosting service you are using?

[designsimply]

@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?

[mertcangokgoz]

@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

[designsimply]

@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]

@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 (#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.

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!

[mertcangokgoz]

@designsimply Fix this problem,

Only edit my functions.php and remove this snippet

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

[andreas-pgss]

@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]

@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.

[mertcangokgoz]

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

[andreas-pgss]

@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]

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]

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.

[dyllisphiller]

@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.

[designsimply]

@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 #9990 (comment) 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]

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

1. @mertcangokgoz worked around the issue by turning off the wp-oembed feature in their functions.php file in their theme.
2. @dyllisphiller is contacting their host, A Small Orange, to ask them to unblock the wp-polyfill-ecmascript.min.2ae96136.js file.
3. @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!

[mcsf]

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)/">.

[awayken]

@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:

[andreas-pgss]

@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]

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.

[dyllisphiller]

@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.

[jbwharris]

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.

[benthomasmaine]

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?

[vitektm]

My problem was that I had a function which minifirewall the html code, removing comments and so on.

//$buffer = preg_replace('!/*[^*]*+([^/][^*]*+)*/!', '', $buffer); /** delete comments **/

[rkalzaglool]

here same problem...