Improve Site Editor error state - prevent blank screen on REST API error

[mkaz]

What problem does this address?

If there is an API error loading templates for the site editor, the user is left with a completely blank screen. No visible error messages or ability to click towards next steps.

Original ticket: https://core.trac.wordpress.org/ticket/54507

From @noisysocks:

At the very minimum we should handle the potential failure of the request to /wp/v2/templates more gracefully.
From memory there's an object destruct somewhere in the edit-site initialisation which needs a null check.

Testing

One way to trigger an API error, though there are others I'm sure, is to misconfigure your server rewrites. I did so using Apache and setting permalinks within WordPress but without having an .htaccess file with the needed rewrite rules.

What is your proposed solution?

Display an error message or ability to navigate.

There might be several ways to solve - I did notice the is-fullscreen-mode class is added to the body which hides the sidebar, if that class is added after the page loads than if it fails to load, the user will still have the standard /wp-admin/ sidebar. The drawback is the UI flashes during the load.

I think another option would be to remove this class on a failure if that can be detected. If the is-fullscreen-mode body class is removed the sidebar would show, at least giving the user a way to navigate elsewhere.

[Mamaduka]

You can also comment out this line to reproduce the issue:

gutenberg/lib/compat/wordpress-5.9/block-template.php

Line 78 in 1b15cf1

wp_send_json_success( $block_template );

[noisysocks]

It looks like a non trivial amount of people encounter this error (see #36687) so definitely something we need to improve.

We should display the JSON error that comes back from _wp-find-template. This error also needs to be more detailed. Currently it only says No matching template found. which is not very useful for debugging. I'd include the path that we attempted to look up in the error message.

Here's how I patched locate_block_template to repro the issue.

diff --git a/src/wp-includes/block-template.php b/src/wp-includes/block-template.php
index 264c1181c0..6d0f278387 100644
--- a/src/wp-includes/block-template.php
+++ b/src/wp-includes/block-template.php
@@ -73,6 +73,9 @@ function locate_block_template( $template, $type, array $templates ) {
 
 	$block_template = resolve_block_template( $type, $templates, $template );
 
+	$template       = null;
+	$block_template = null;
+
 	if ( $block_template ) {
 		if ( empty( $block_template->content ) && is_user_logged_in() ) {
 			$_wp_current_template_content =

[talldan]

#38655 should add error handling.

I still feel like we need a good understanding of what causes the errors (there have been a few reports).

If it's only caused by a misconfiguration (like mentioned in https://core.trac.wordpress.org/ticket/54507), is there anything we can do in site health to assist in detecting the problem?

[Mamaduka]

I think one cause of the error is PHP template fallbacks.

Steps to reproduce:

• Create front-page.php in TT2.
• Try accessing the Site Editor.

More details can be found in #35560

[bobbingwide]

One way to trigger an API error, though there are others I'm sure, is to misconfigure your server rewrites. I did so using Apache and setting permalinks within WordPress but without having an .htaccess file with the needed rewrite rules.

@mkaz Could you show you what you didn't have in your .htaccess file? It would help with my attempt to reproduce the problem I reported in #38699

[mkaz]

Just a standard htaccess file redirecting all non-files to WP

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

[noisysocks]

I think we can close this as fixed by #38655. We're no longer showing a BSOD.

We can fix bugs that result in an error being shown in separate GitHub issues e.g. #35560.

I think one cause of the error is PHP template fallbacks.

Steps to reproduce:

• Create front-page.php in TT2.
• Try accessing the Site Editor.

More details can be found in #35560

I followed these steps and confirmed that an error was shown and not a BSOD.