Patterns: remove "Template parts" sidebar group #60359
Conversation
oandregal
added
[Type] Enhancement
oandregal
requested review from
mcsf,
youknowriad,
jameskoster,
SaxonF,
jorgefilipecosta and
ntsekouras
|
Size Change: -20 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
|
@SaxonF this implements the changes to template parts as described in #59659 I notice a few inconsistent things between the "Manage all template parts" page and the template parts pages in patterns. I think we may need to
Thoughts? |
|
I think it helps to keep #57011 in mind here, which this PR definitely moves us towards. Some consequent considerations:
With that said, I agree about adding an author filter before merging this. |
Oh, thanks for sharing, wasn't aware of that. I'm going to check and will be back. |
oandregal
force-pushed
the
remove/manage-template-parts-link
branch
from
b4219f5
to
72074a4
Compare
|
Pushed an update that implements this design and updated the TODO. |
oandregal
changed the title
|
Oh neat, I didn't mean to necessarily do that here. The original approach can work too if we want to be more iterative. No strong feelings there. If we commit to this approach then we'll need to follow-up and think about how some other details converge such as; duplicative categories ('Header', 'Headers'), creation flows, the 'General' template part category. I'll leave a note on the original issue about that. I'll defer to Saxon on how to proceed. |
|
#60372 adds the author field & filter to the template parts in the Patterns page. |
|
I looked more into this and there are a few other inconsistencies (updated PR description with full details). The CTRL+K commands open the details pages for patterns, but we need to update the backpath: it should go back to patterns, not to template_parts/all. I'll work on this separately. I've also got two questions:
|
Yes I think so.
Probably yes, but one to explore separately? |
|
#60659 adds |
|
#60667 sets the backPath for Template Parts to the Patterns page. |
|
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. |
oandregal
force-pushed
the
remove/manage-template-parts-link
branch
from
8688daa
to
22914c4
Compare
|
This feels a little jumbled to me now. It's quite unusual to see two "All" views right next to one another this way. I'd be tempted to hold off on this until:
A simpler approach could be to move the template parts section above the patterns section, but keep the separation: 
This would give greater prominence to important site areas (header/footer) which seems worth a try. |
This PR prepares the code to remove the "Manage template parts" in the other PR, so, for this one, I'd rather ship a simple approach and iterate later to see how/whether we can combine the two entities.
Pushed this: 
|
Agreed. What's the plan for improving this? It feels a bit backwards/in limbo as-is: The whole template parts up top feels unexpected.
|
|
We could almost leave the "Manage all template parts" navigation item at the footer (name it "Template parts >" and remove the top section. And add more filters in that existing view for header, footer, general, etc. |
As per #59659 the next step is to actually to remove that link/section (see #60689). The direction is to consolidate patterns&parts in a single screen. |
|
Yup, in practical terms template parts and patterns share almost all functionality. Presenting them as two separate concepts adds a lot of complexity to the experience ("Why should I use a template part over a synced pattern?", "What is a 'general' template part?"). There's also navigation menus and templates – it's a lot of overlap.
There's been feedback around making header / footer more prominent since they're frequent touch points. I think the end goal is something more like: 
Headers/Footers are just pattern categories, and details like html element/area can be inferred automatically from those categories. |
|
We can't functionally remove template parts until a theme can provide synced patterns though, right? |
|
It's not about functionally removing them, I don't know that it will ever be possible to do that. It's more about how they are presented, and how users interact with them. The code may be slightly different (though ideally that converges too), but I think the UX when working with a header template part should be the same as working with a synced pattern in the "Headers" category. I don't see a lot of benefit to these being surfaced as separate concepts? |
|
I suppose I'm not understanding the idea state of this patterns view. What will the grid on the right look like if header template parts and patterns sit side-by-side? As a site owner, I'll see X headers, but which is mine? How do I know what the others are for, or if I'm using any of them across my site? Are those going to be filterable? I'm missing some context I think. Do you consider #55911 a blocker for merging patterns and template parts as well? |
You'd see all headers—synced (template parts) and unsynced (patterns).
You can ask these questions of the current "Header" template part category. It's already unclear which one(s) are in use and what the others are for in situations where; a theme supplies multiple header template parts, or when plugins install more, or when you've created a couple of your own. Ideally yes, usage should be filterable/sortable, and we should probably sort by usage in the default config. But we need to begin tracking usage first (#60205).
Not sure if it's a blocker – usage tracking is slightly more important imo – but yes ideally the UX around editing any theme-supplied asset (templates, template parts, and patterns) aligns. |
Well today you know that none of those are technically your header; only what's in the "Template Parts > Header" category. |
But even now a header can exist in "Templates Parts > Header" and not be in use. There's no way of knowing which ones are "your header" at the moment, except when there's only a single header at the site. I do see the point – if you want to edit "your header", and there's only one registered header template part, then seeing all other header patterns could be distracting. But given the previous point I'm not convinced that perpetuating separate overlapping concepts is the solution. A more data-views-centric approach would be the inclusion of a primary "in use" filter for template part categories so that anything not in use is hidden by default. |
It's not that it's distracting, you don't even know which is your actual header(s). I want to think about it more, but I still question if wholesale mixing the concepts of template parts and patterns is the right approach. I think we need to keep some sort of separation, even if the "Header" category has two grids, with "Template Parts" as the first gallery, and "Patterns" as the second below it—essentially as the alternates to choose from. |
We could potentially order by the Another consideration I've been thinking about is whether there should be two categories;
|
|
Eventually, I'd love there to be wayfinders attached to template parts and patterns surfaced in the Data Views for easier discovery of:
This wayfinding can make it easier to update various aspects of a site design (especially more complex sites that have multiple landing pages and or content trees). This is likely something that could be implemented incrementally too (focus on header/footer template parts first initially). |
These are both tracked in #60205 |
Part of #59659 and #55083
What?
Removes the "Template parts" group in the sidebar:
Why?
This is part of the consolidation between Patterns & Template parts.
See target design at #57011 (comment) and tracking issue at #59659.
How?
Testing Instructions
Visit the Patterns page and verify the changes.
Related work
The link & related code is being removed at #60689
There was some other build-up work for this PR to be viable:
listlayout for parts in patterns? This can be looked at as a follow-up if necessary.