Block editor requests to `?_wp-find-template=true` result in a 404 error

[noisysocks]

Originally reported in ​https://github.com/WordPress/gutenberg/issues/36986.

If you create a new post (Posts → Add New) and open the Network tab in DevTools you'll see a request made to ?_wp-find-template=true with a 404 error.

This causes some unexpected behaviour in the post editor, described in the issue above.

I see code which looks like it should handle this query param but the function locate_block_template doesn't appear to be hooked into wp_loaded or anything like that.

​https://github.com/WordPress/wordpress-develop/blob/5fa8d73b1b22ff72f06ae53c07cf2887a4f4b60a/src/wp-includes/block-template.php#L61

I suspect something was missed while backporting the block theme infrastructure in #54335 cc. @bernhard-reiter.

[Bernhard Reiter]

I'll look into this!

[Bernhard Reiter]

It seems like we basically need to backport ​https://github.com/WordPress/gutenberg/pull/32442, which was only merged briefly after the initial backport of custom block templates for pages (​https://github.com/WordPress/wordpress-develop/pull/1267).

I'll file a PR!

Originally reported in ​https://github.com/WordPress/gutenberg/issues/36986.

If you create a new post (Posts → Add New) and open the Network tab in DevTools you'll see a request made to ?_wp-find-template=true with a 404 error.

This causes some unexpected behaviour in the post editor, described in the issue above.

As @noisysocks correctly suspected in https://core.trac.wordpress.org/ticket/54553, this is because of a missing filter that calls locate_block_template upon wp_loaded.

The fix is to basically backport ​https://github.com/WordPress/gutenberg/pull/32442, which only made it into Gutenberg briefly after the custom block templates for pages infrastructure was backported to Core (​https://github.com/WordPress/wordpress-develop/pull/1267).

Trac ticket: https://core.trac.wordpress.org/ticket/54553

cc/ @carolinan since you reported WordPress/gutenberg#36986 🙂

[costdev]

Test Report

Environment

• WordPress 5.9-beta1
• Chrome 96.0.4664.45
• Windows 10
• Theme: Twenty Twenty Two
• Gutenberg Editor
• Plugin: None activated

Steps to reproduce

1. Navigate to Posts > Add New.
2. Open DevTools.
3. ✅ A 404 error appears:

?p=31&_wp-find-template=true 404 (Not Found)

Steps to test PR 1997

1. Apply ​PR 1997.
2. Navigate to Posts > Add New.
3. Open DevTools.
4. ✅ The 404 error no longer appears.

Thanks a lot @hellofromtonya and @noisysocks for reviewing and polishing! ❤️

[hellofromTonya]

Self assessing for testing and, if all goes well (which is should), commit.

[hellofromTonya]

Test Report: Able to reproduce before. Fixed after.

[hellofromTonya]

Test Report

Env:

• OS: macOS Big Sur
• WordPress: trunk
• Theme: Twenty Twenty-Two (TT2)
• Plugins: none activated
• Localhost: wp-env
• Browser: Edge, Firefox, Chrome, Safari

Steps to reproduce

• Open DevTools and go to the Console in your browser
• Go to Posts > Add New
• No error should appear in the console
• Switch to the Network tab
• No 404 for should appear

Test Results

Before applying PR:

• A 404 error appears:

  GET http://localhost:8889/?p=22&_wp-find-template=true 404 (Not Found)
  

After applying the PR:

• No error

[hellofromTonya]

In 52316:

Editor: Resolve template request ?_wp-find-template=true for new posts and pages.

The template resolution system makes a request like /?page_id=1234&_wp-find-template=true, depending on WP_Query to resolve a page or post using the page_id or p (post_id) in the query string. With new posts/pages, a placeholder post with the status auto-draft is created. But by default WP_Query will not resolve these posts, unless the query is specifically set to look for them.

This commit handles the query string to properly resolve a page or post. It adds 2 private callbacks for the processing.

Props poena, noisysocks, bernhard-reiter, costdev, hellofromTonya.
Fixes #54553.

Committed via https://core.trac.wordpress.org/changeset/52316.