[wp-trac] [WordPress Trac] #55288: Site Editor on 5.9.1 fails to find homepage template for FSE themes, on WP subdirectory installation

[WordPress Trac]

#55288: Site Editor on 5.9.1 fails to find homepage template for FSE themes, on WP
subdirectory installation
--------------------------+-----------------------------------------
 Reporter:  andronocean   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.9.3
 Severity:  critical      |  Resolution:
 Keywords:  dev-feedback  |     Focuses:  javascript, administration
--------------------------+-----------------------------------------
Changes (by andronocean):

 * keywords:   => dev-feedback
 * focuses:  administration, template => javascript, administration
 * version:  5.9.2 => 5.9.3


Comment:

 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).
 [https://github.com/WordPress/gutenberg/blob/640dbf25acd755a70a0f8baffa3a4b67d34b5bea/packages
 /core-data/src/resolvers.js#L368-L373| 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55288#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform