FSE Template resolution doesn't not work for auto-draft posts.

[youknowriad]

Say you have an auto-draft post with id = 42. Appending _wp-find-template=true to the post URL example: http://localhost:8889/?p=42&_wp-find-template=true is supposed to trigger the template resolution for that link and return the FSE template used to render that post. I would expect that by default, the returned template would be "single" or "post". Instead, it seems the algorithm is fetching the 404 template (which defaults to index if inexistant).

The current resolution algorithm is a hook on top of the frontend resolution that comes from Core and I believe this must fallback to 404 for a reason but it doesn't translate well for us.

Also, ideally, template resolution should be extracted from Core into a nice low-level API we could work with resolveTemplate( url ) instead of a hack on top of the frontend rendering.

I also believe having a dedicated REST API endpoint would be better than what we currently have. (hacking a regular page load and return JSON)

cc @WordPress/gutenberg-core @noahtallen @vindl

[noahtallen]

I also believe having a dedicated REST API endpoint would be better than what we currently have. (hacking a regular page load and return JSON)

This would be awesome. I definitely think that low-level API would be a pre-req. IIRC, template resolution happens implicitly at runtime based on the context of the request, which is why we have to use the page load approach now. Unfortunately WordPress doesn't just call something like get_template( $postId ) behind the scenes during the lifecycle -- it's a lot more intertwined with everything else that happens. :/

The current resolution algorithm is a hook on top of the frontend resolution that comes from Core and I believe this must fallback to 404 for a reason but it doesn't translate well for us.

Yeah... I guess if the current post is an autodraft, then WordPress just renders 404 anyways, which means the 404 template would be resolved. A byproduct having to use an actual page-render to get the template info

[youknowriad]

I think this issue could use some help with friends more aware of Core internals. cc @azaozz @noisysocks @TimothyBJacobs

[aristath]

I think we should wait for #27321 before dealing with this one.

[azaozz]

I think this issue could use some help...

Historically the way auto-draft posts were used on the old Add New Post screen is only as placeholders that "reserve" the post_ID. They are (typically) an empty row in the DB and are not considered "real" posts until the user saves a draft or the first autosave (which also saves as a draft). The reason auto-drafts exist is because having a post_ID before the old Add New Post screen is outputted from PHP makes it work better/simpler by allowing AJAX saving of post meta, etc.

As auto-drafts are placeholders only intended for use in the editor they are non-displayable on the front-end. As far as I see core's template resolution (which assumes front-end) correctly returns the 404 template, same for revisions and other non-displayable post types and post statuses.

One "workaround" perhaps would be to transition the auto-draft to a (real) draft, or even start by creating a draft post when loading FSE or even when "starting a new post" through the REST API. Seems that will fit better with the existing logic around use of auto-drafts (i.e. they are just post_ID placeholders, not "real" posts). On the other hand that would depend on "guessing" the user intent, which may not be to start a new post...

ideally, template resolution should be extracted from Core into a nice low-level API

Yep, big +1. This is tied to permalinks, post slugs, etc. and may not be an easy task :)

[youknowriad]

As auto-drafts are placeholders only intended for use in the editor they are non-displayable on the front-end. As far as I see core's template resolution (which assumes front-end) correctly returns the 404 template, same for revisions and other non-displayable post types and post statuses.

The thing is, we're still in the editor and we're not in the frontend and we're on the post editor. The idea is to be able to zoom-out to template level while creating the post.

If such a low-level API exists, can it just work for auto-drafts similarly to drafts? or at least be configurable to work that way. Granted that for the frontend it should still be a 404 but this requirement seems different to me than "retrieving what template would apply to the post when published".

[TimothyBJacobs]

This wouldn't solve the actual issue at hand, but regarding a REST API endpoint. I think we could probably abstract this bit of code https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/template-loader.php#L57 down to the apply_filters call into a reusable function without issue to regular WordPress Core usage. You'd still have to setup the global query manually in the REST API endpoint. But it could provide a nicer interface to that data, without going as far as completely rewriting the template resolution to be stateless.