Edit Site: Add routes or query args to get URIs for individual templates

[ockham]

We're currently using the template selector dropdown to switch between individual templates (and template parts), which uses component context and state to set the currently selected template, while the URL stays the same (/wp-admin/admin.php?page=gutenberg-edit-site).

I think we should provide a way to point to the Site Editor with a specific template selected, so that we can link to it e.g. from other parts of wp-admin, or other admin panels and contexts.

---

This could be something like /wp-admin/edit-site.php?template=page&action=edit&amp. We should take into account how to modify the route once we implement context loading (and want to specify which context/entity should be loaded). We could make it /wp-admin/edit-site.php?template=page&action=edit&entity=123, where entity is the ID of the page/post/category/... we're interested in. I'm not entirely sure if this route format can scale to all parts of the template hierarchy, even if we decide to leave out a few template types, since some template types cannot be specified via an ID (think a yearly archive). The most natural way to refer to an entity would be that entity's route, so maybe we should consider something like /wp-admin/edit-site.php?template=page&action=edit&entity=/about.

(There's a point to be made that this route may be overdefined: The route to an entity already implies the part of the template hierarchy that matches it best; and some templates are incompatible with some entities (can't use a page template for a category archive). So we could theoretically drop the template arg from the route. But this gets us into somewhat deep waters where we might end up reasoning about where to draw the line between site and content editing 😬 )

[epiqueras]

The context is specified by WP_Query parameters.

But this gets us into somewhat deep waters where we might end up reasoning about where to draw the line between site and content editing 😬 )

I don't see why.

[ockham]

The context is specified by WP_Query parameters.

Not sure I understand -- how comes WP_Query into play in a scenario like #19257 (where we want to allow the user to pick context that we use to populate placeholders in a template)?

But this gets us into somewhat deep waters where we might end up reasoning about where to draw the line between site and content editing 😬 )

I don't see why.

Imagine a route to the Site Editor that specifies a context to render, but infers the corresponding template from that (such as /wp-admin/edit-site.php?action=edit&entity=/about -- where the relevant template is page). Now we point to the site editor showing the page template, with the About page content loaded. I think that this has the potential of making the corresponding post editor view -- that just shows the About page content -- obsolete, since the user can now choose between editing both presentation and content at once, or only the content. Assuming that the UX would be great in both (and inline editing of the content would work in the site editor) -- why would a user still want to use the post editor to edit that page?

[epiqueras]

Not sure I understand -- how comes WP_Query into play in a scenario like #19257 (where we want to allow the user to pick context that we use to populate placeholders in a template)?

?p=id
?category_name=name

why would a user still want to use the post editor to edit that page?

If they don't have permission to edit the layout, for example, the editors could also merge in the future.

[vindl]

This has been added in #27124.