Site Editor on 5.9.1 fails to find homepage template for FSE themes, on WP subdirectory installation

[andronocean]

I'm getting an error when launching the site editor on 5.9.1, stating “The editor is unable to find a block template for the homepage”. This happens on both Twenty-Twenty-Two and a custom FSE theme (otherwise functional, has templates/single.html and templates/index.html). My WP installation is in a subdirectory, using the ​Bedrock site structure, so the editor URL is https://example.test/wp/wp-admin/themes.php?page=gutenberg-edit-site

I've tried it on PHP 7.4.25 and 8.0.14. I've confirmed it still happens with all plugins deactivated.

Notably, activating the Gutenberg plugin version 12.6.1 eliminates the error and the editor loads correctly.

There are several other reports of the same error in this Twenty-Twenty-Two forum thread: ​https://wordpress.org/support/topic/the-editor-is-unable-to-find-a-block-template-for-the-homepage/

The error code output from the copy button is

Error: `getHomepageParams`: HTTP status error, 404 
    at https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8766:13
    at async getHomepageParams (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8762:20)
    at async redirectToHomepage (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8797:28)
    at async reinitializeEditor (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:9067:5)

[Enchiridion]

I'm also getting this error. My stack trace is a little different, probably because I'm using Firefox. Like others in the linked forum thread, I'm using WordPress in a subdirectory. What's odd is both 5.9 and 5.9.1 make an XHR request to /wp?_wp-find-template=true, which 404s but also returns the requested JSON data. Seems only 5.9.1 actually fails because of this.

On 5.9.1 I can't edit any templates the site editor just crashes unless I have an direct link to the template to edit /wp/wp-admin/site-editor.php?postId=site%2F%2F404&postType=wp_template

I've had to roll back to 5.9 in order to keep site dev going.

Error from the Copy Error button:

IqXm/zr/r<@https://example.com/wp/wp-includes/js/dist/edit-site.min.js?ver=403e01f2b098b6a656118a51787581cb:2:121078
promise callback*IqXm/zr/t<@https://example.com/wp/wp-includes/js/dist/edit-site.min.js?ver=403e01f2b098b6a656118a51787581cb:2:121054
async*zr@https://example.com/wp/wp-includes/js/dist/edit-site.min.js?ver=403e01f2b098b6a656118a51787581cb:2:121424
qr@https://example.com/wp/wp-includes/js/dist/edit-site.min.js?ver=403e01f2b098b6a656118a51787581cb:2:121896
$r@https://example.com/wp/wp-includes/js/dist/edit-site.min.js?ver=403e01f2b098b6a656118a51787581cb:2:122936
@https://example.com/wp/wp-admin/site-editor.php:2201:16
EventListener.handleEvent*r@https://example.com/wp/wp-includes/js/dist/dom-ready.min.js?ver=ecda74de0221e1c2ce5c57cbb5af09d5:2:1121
@https://example.com/wp/wp-admin/site-editor.php:2200:4

[westonruter]

I'm also seeing this issue. My WP install is in a subdirectory (using the ​GoogleChromeLabs/wordpressdev environment).

My home URL is http://wordpressdev.lndo.site/ but my site URL is https://wordpressdev.lndo.site/core-dev/src/.

When I open the Site Editor at https://wordpressdev.lndo.site/core-dev/src/wp-admin/site-editor.php the console gives an error:

Mixed Content: The page at 'https://wordpressdev.lndo.site/core-dev/src/wp-admin/site-editor.php' was loaded over HTTPS, but requested an insecure resource 'http://wordpressdev.lndo.site/core-dev/src/?_wp-find-template=true'. This request has been blocked; the content must be served over HTTPS.

The request using HTTP instead of HTTPS is the problem for me. If I try manually going to https://wordpressdev.lndo.site/core-dev/src/?_wp-find-template=true then the request succeeds. I haven't been able to pinpoint where the wrong URL scheme is being supplied.

[westonruter]

I don't get this issue in Gutenberg, however.

[Enchiridion]

This bug still exists is WP 5.9.2 and according to posts on the original support thread, occurs even with the stock Twenty-Twenty-Two theme.

[andronocean]

Also still occurring on WP 5.9.3, in all block themes.

@westonruter I'm guessing the mixed content error's source is different. Any chance that part goes away if you change the home URL to https://?

@Enchiridion I dug into that 404 request a little more. I'm also seeing 404 with the correct data nonetheless returned. What's rather curious is the actual request series I'm seeing:

1. getHomePageParams() in the wp-includes/js/dist/edit-site.js file (more info below) initiates the async GET request for https://example.test/wp?_wp-find-template=true.
2. The response is a 301 redirect to https://saratogaocean.test/wp/?_wp-find-template=true. Note the slash before ?
3. The redirect request /wp/?_wp-find-template=true returns the data ({"success":true,"data":{"type":"wp_template"....}}) but with a 404 status. That status makes the response fail and throw an error.

The exact lines in wp-includes/js/dist/edit-site.js where the request is made are 9539-9547:

const template = await window.fetch(Object(external_wp_url_["addQueryArgs"])(siteUrl, {
    '_wp-find-template': true
  })).then(response => {
    if (!response.ok) {
      throw new Error(`\`getHomepageParams\`: HTTP status error, ${response.status} ${response.statusText}`);
    }

    return response.json();
  }

The Error object thrown there is caught inside the reinitializeEditor() function at line 9845, which is what stops rendering and prints the message "The editor is unable to find a block template for the homepage."

The 404 is causing the problem.

With Gutenberg activated, here's what's changed:

The Gutenberg request gets https://example.test/?_wp-find-template=true. It's using the public site URL as the base, not the admin URL. That returns 200, and everything is happy.

The function generating the request is different: it's now __experimentalGetTemplateForLink(), and instead of using the site URL in the XHR request, it simply uses a / to get a relative URL (via the link parameter). ​These lines do the work.

The problem is the use of siteUrl

Even without Gutenberg active, GET https://example.test/?_wp-find-template=true returns 200 and the JSON data. The endpoint is there, but those of us using subdirectory installs are hitting the wrong path and probably being messed up by redirect rules.

I tried hackily replacing siteUrl with "/" and sure enough it worked without Gutenberg. Seems like this would be a simple fix for Core, unless/until the experimental API function from G can be merged.

[westonruter]

Replying to andronocean:

@westonruter I'm guessing the mixed content error's source is different. Any chance that part goes away if you change the home URL to https://?

My home URL actually is already HTTPS.

It turns out that the editor actually works fine when I have the latest Gutenberg active, that is when I go to /path/to/wp/wp-admin/themes.php?page=gutenberg-edit-site. When I have Gutenberg deactivated and go to /path/to/wp/wp-admin/site-editor.php then I get the error. So maybe something in the latest Gutenberg version(s) have fixed the issue.

[coreyw]

Any fix for this coming soon? Seems very odd that WordPress would release a version that effectively cuts off the full site Editor for subdirectory installs, as that method of installing WordPress has been supported for a very long time now.

[Enchiridion]

I think this had been fixed in 6.0.1. Can anyone else confirm it's not just me?

I upgraded from 5.9 to 6.0.1 and the site editor page is working and the call to /wp?_wp-find-template=true returns 200 and the JSON data. Seems when you visit site-editor.php now it does a 302 redirect to site-editor.php?postType=page&postId=2

[coreyw]

@Enchiridion yes I noticed it starting working like that as well after recent update, either 6.0 or 6.0.1.

[deothemes]

Surprisingly I'm still getting this error even in 6.5.2. Any solution?