Templates: Allow browsing by source, grouping all Custom templates #58946
Conversation
THIS IS NOT YET FUNCTIONAL. It is a UI change foremost, which exposes the underlying limitation that templates have no `source` field to filter on. With this commit, the "all", "theme" and "plugin" views work, but the "custom" doesn't -- it only shows a single user's templates.
mcsf
added
[Type] Enhancement
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +120 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
youknowriad
added
the
Backport to WP 6.7 Beta/RC
| const sources = useMemo( () => ( { | ||
| theme: __( 'Theme' ), | ||
| plugin: __( 'Plugin' ), | ||
| user: __( 'User' ), |
There was a problem hiding this comment.
In the sidebar of the site editor, it says "custom" and here it says "user". I believe we should use the same label no?
There was a problem hiding this comment.
Good question, that's one thing I'd like to get feedback on:
- In the sidebar, "Custom" feels more intuitive to me. In WP jargon we typically see "custom templates", and rarely "user templates". We could switch to "User", but that feels confusing.
- However, in the filter, Source is Custom felt like a weird rendering, so I kept it true to the internal naming: Source is User.
What should we do? Both directions seem weird to me.
There was a problem hiding this comment.
I think "User" templates in the sidebar is fine by me too. But would love feedback from @jameskoster
There was a problem hiding this comment.
Thanks for the ping. Given this filter shows any user-generated templates, I agree it's fine for the label in the sidebar to be 'User'.
However, it would be good to have a 'Custom' view as well, which should show any $custom templates according to the template hierarchy. This would match the 'Custom' section in the current template list. I acknowledge there's no way to filter in this manner yet, so I guess it'll need to happen separately. Perhaps we should add a 'type' taxonomy?
There was a problem hiding this comment.
I mean if the goal is to have separation according to "custom", "non custom" templates, that's possible to, it's just a different field. But the question is also what to do for "plugin templates" because these also can be custom or not.
So I guess before moving on here, let's get some clarity about what we want for 6.5 from a design perspective.
There was a problem hiding this comment.
If a plugin (or theme) template is custom then it should appear in the "Custom" view, just as those templates appear currently under the "Custom" heading in the Templates sidebar:
For 6.5, at the least, I would suggest replicating the current list, IE a view for custom templates, and a view for each plugin that adds templates. Source = user is a nice-to-have, but since it doesn't exist already not essential.
|
Thanks for adding the counts :) The placement seems slightly different to the appearance on the Patterns page, ideally they should match.
|
|
Some of the interactions between Author / Source filters are a little confusing. Many configurations are entirely incompatible and will never produce any results, e.g.:
I don't have a solution in mind, but wanted to surface the concern as this makes me a little anxious about merging. |
There's one other possibility, which is to keep the source as a strictly hidden field, so that it doesn't ever show up, not even as "Source is ___", so that only by navigating the sidebar can you change sources. As far as I can see, there is no such API in Data Views yet. So we could consider adding it... ... or, by simply not declaring source as a field (comment out the with-no-source-definition.mp4Yes, it's a hack. But I'm just saying... ;) However, hiding/unsetting the field doesn't solve the issue of the author enum including theme and plugin names. |
I don't think we need an API for that, we can just force the filter without putting it in the "filters" object. |
Yes, that's what I was suggesting/showcasing, if you don't think it's hacky. |
Pushed in 7fbf72ed49, give it a go, feel free to revert. |
|
Flaky tests detected in 7fbf72ed496df1256f0000aa22ef76eb16e0e82e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7876424552
|
|
Thanks for giving that a shot @mcsf. There are still a couple of quirks though; In the "Custom" view you can filter by Author and choose a Plugin or a Theme. If Custom = user-generated then themes and plugins can never be the author. Additionally with the hidden Source filter it's a bit unclear what is reset when you click 'Reset filters' in the "Custom" and "Theme" views. This may be too simplistic, or expensive to implement, but could the options in the Author filter change based on the selected source?
I appreciate this could create awkward flows, like selecting |
|
I think that what we want to do here is more of a The adhoc grouping that exists in sidebar right now is taking into account more than one specific
IMO we should not rush this and maybe have a filter like |
|
I think we need both grouping (#57967) and filtering, eventually. E.g. you could filter to show custom templates, then group by author. Or the inverse, filter by author and group by template 'type'. The 'type' filter might include options like 'single', 'archive', 'custom', or something more granular, or something even simpler like Nik suggested, but obviously that will need investigation and seems unlikely to be included in 6.5. Given it's generally easier to add things than remove them, perhaps for 6.5 we include the following views:
This resembles the organisation of the current list most accurately. It's a shame not to include the 'Custom' view, but I agree it shouldn't be rushed if there's not a clear path. I'm unsure how useful the user-based view is compared with the others. Seems like something you'd do situationally from the All templates view. I'm not entirely convinced about the active theme view either given it's not possible to view templates from any other theme yet. Also because on fresh installs 'All templates' and 'Active theme' views will be identical. What do y'all think? |
|
I think your reasoning makes sense, but I can also understand wanting "Theme" to be there if that gives users a lay of the land, i.e. what to expect as they start customising their site. So I don't really have an opinion here. :)
So the main problem here is that Custom is a grouping of templates from certain sources, possibly across authors, etc. Well, what if we simplify and take a hint from Patterns? Over there, we have All patterns followed by My patterns. Would there be enough value in a My templates view? Internally, this would work around the grouping limitation, as we would just filter on author to match the current user. With or without the Theme item: 
|
mcsf
force-pushed
the
update/templates-dataview-sidebar
branch
from
7fbf72e
to
14a264c
Compare
|
I'm not sure we should follow the patterns example here. It's my understanding that "My patterns" was intended to be a transitional name for Reusable blocks, until they've converged more completely with theme patterns. "My patterns" should include all patterns created by any user, rather than a specific user. I've also seen feedback about moving away from language that suggests personal ownership as it doesn't work so well for sites with multiple admins. If we did follow the patterns example, that would mean creating a view within templates that displayed all user-generated templates ( Since the end goal isn't 100% clear, for 6.5 I still lean towards starting with less, and replicating the organisation of the existing template list (the one in the dark sidebar) as closely as we can. So in lieu of the "Custom" view that would be; All templates, and views for each plugin. |
|
Given that RC1 is today, I'm removing this from 6.5 as non essential. |
youknowriad
removed
the
Backport to WP 6.7 Beta/RC
Ah yes, in my mind it was already out of 6.5. |
|
Hey, @jameskoster, do you think there's still something of value here for 6.6? If not, happy to close. |
|
@mcsf it would be great to at least get the counts in :D With the 6.5 deadline past, does it make sense to resume exploring the 'Custom' view for 6.6? That one still feels important to me. On that topic, I think a "Type" filter (with options like "Custom", "Archive", "Page", "Post", "Utility") could work well. I suppose the tricky thing is that there aren't any fields currently associated with templates that we can use for this purpose. If you wanted to explore, let me know and I'm happy to suggest how we might sort templates. |
What?
Fixes #58111
Follows up on #58124
Implements the following remaining improvements suggested in the parent issue:
How?
source, corresponding to records'original_sourceproperty.theme,plugin,user. The latter corresponds to custom templates.hiddenFields,enableHidingandenableSorting.activeViewlocation param to encode source data as follows:all: same meaning as beforeuser: filter by source to reveal custom templatestheme: filter by source to reveal current theme's templates (previously, we simply filtered by author and hoped that no other source's items could overlap with the theme's name).plugin:My Plugin Namefilter by source (plugin) and author (My Plugin Name)Testing instructions
Screen capture
templates-browse-by-source.mp4