Site Editor: Only request templates and template parts for the current theme #27152
Conversation
Copons
requested review from
mattwiebe,
vindl,
david-szabo97,
jeyip,
noahtallen and
Addison-Stavlo
|
Size Change: -12 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
@Addison-Stavlo new ones are created with the current theme set in the Lines 111 to 123 in 1862c62 |
I see. So custom template parts are then tied to a theme, which may not be ideal for users wanting to create custom template parts to use across whatever theme they choose to have active. 🤔 |
|
@Addison-Stavlo I'm sure this has been discussed to death already, but I'm failing at finding where. 🤔 My reasoning here is that having templates and parts always tied to a theme (and never showing other theme's items in the Site Editor), massively simplifies all the flows. Regardless, as far as I can see, we now have all the pieces (post status, theme and For example, I can imagine a scenario where we update the theme tag if a user updates a template while using a different theme than the template's one. |
Im not sure if it has been actually, at least regarding whether custom created template parts should or shouldn't correspond to the theme that was active at the time of their creation. I think in the early stages of the site editor there wasn't much design involvement and a lot of the early development was going on a best guess of what we would need. The earliest stage I can remember regarding template part theme names behaved as: auto-drafts theme files get the theme name, wp-admin creation had the empty string, and in editor creation gave the user an empty input to put whatever they chose for the theme name. So coming in at that point I was assuming we had a need for having some separation between theme and custom and to not necessarily lump them together automatically under the same umbrella. Given that the current state of the site editor best suits theme development, maybe this behavior isn't necessarily a bad thing for now. It does get fuzzy if we think of a user wanting to create a 'custom' type that is usable for their site regardless of any theme. 🤔 How much that makes sense in practice, I'm not sure 🤷♀️
But if we are only showing current theme in the site editor, they would have to navigate to wp-admin to do this? That fragments the experience quite a bit. Anyways, with the way things are currently working I don't see any reason to block this PR. I do think we may need to rethink how/when we are adding the theme tag and that a |
|
I think the end goal of this PR corresponds to the state we are now currently in as a result of #27910 ? Im not sure if you want to close this or if there are still other issues to work out. |
|
Thanks for checking this @Addison-Stavlo, I'll close it as not relevant anymore. |
Description
Fixes #27149
themerequest parameter towp_templateREST request (identical to the existing one forwp_template_part) that allow to filter by theme slug (the built-in taxonomy filter only accepts term IDs).getEntityRecordsin the Site Editor's navigation panel to only request template and template parts belonging to the current theme.The main reason for this is to avoid confusion when using multiple FSE themes, exposing multiple, seemingly duplicate, templates and parts.
How has this been tested?
/wp-admin/edit.php?post_type=wp_templateand take note of all the templates with the same slug belonging to both themes (indexis the best bet).The wp-admin menu for parts doesn't show auto-drafts and theme yet so you can't check there, but it should be enough to make sure there are no duplicates in the navigation sidebar.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: