Try using a template part in the navigation block #35418
Conversation
|
Size Change: +4.57 kB (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
| "slug": { | ||
| "type": "string" | ||
| }, | ||
| "theme": { |
There was a problem hiding this comment.
Why would we need to keep a reference to "theme"?
There was a problem hiding this comment.
The PR is very copy/paste from the template part block at the moment. I'll look at removing this 👍
There was a problem hiding this comment.
Yes, makes sense :D I think we should be as lean as possible when it comes to borrowing from the template part structure.
There was a problem hiding this comment.
Yet to find an easy way to achieve this, it seems as though a template part can only be fetched when it has a theme.
There was a problem hiding this comment.
We should probably remove that limitation, it's coupling template parts too much with themes, and it should be entirely feasible (maybe even the norm down the road) to have template parts that are not associated with any specific theme at all.
There was a problem hiding this comment.
So this is very cool. Thanks so much for exploring it.
I gave it a test drive and the link to the video below has some commentary which explains what I found.
🎥 Test Drive Video (it was too large for Github!)
TL;DR
- The basic process works well - the "data" (ie: the items in your Nav) are saved to template part without the wrapping
core/navigationblock. - You can reuse the same navigation in different places on the same site and updates in one location will be reflected in another.
- You can access the navigation in the Isolated Template Part Editor and you will see only the "inner" navigation block items (no Navigation block).
Things we will need to address (I know you are aware of many of these):
- When in Isolated Template Part editor you cannot add child navigation-type blocks (e.g.
core/navigation-linkbecause there is no wrapping parent Navigation block and these blocks are set to only appear if they are a child of that block. - I couldn't seem to access the nav template part on another Theme. This might be a limitation of the Template Parts themselves at the moment. The good thing is we will inherit much of the improvements if we reuse some/all of the Template Part mechanics.
- UI/UX - this obviously needs refinement to mask the "Template Part" specific UI and tailor towards Navigation. I think the user shouldn't necessarily need to know we are using Template Parts.
Overall however this is a great start and everyone should experiment with it to get a sense of where it could take us.
|
Very cool! Surprising to see it work so well at this early stage.
This exposes an interesting question. Do we want the settings which are stored on the If yes, then I think the solution here is to store the If not, then I think the solution here is to use a different CPT for navigation so that it doesn't appear in the template part editor. We can build a custom template part editor for navigation which provides the wrapping |
The goal right now is to keep the inner blocks separate from the settings as you mention here, the idea being that menu data can be reused but given a different appearance depending on the location. The navigation block also has the inverse problem that you shouldn't be able to choose non navigation block template parts from the placeholder. Either the template part could have a way to identify the block type it's associated with, or as you say a separate CPT could be used. Some previous discussion here - #34612 (comment). |
|
Good questions @noisysocks!
I think we wouldn't want this. For example if I have a primary menu I want to display that in the header and the footer but in totally different ways. For example, the header might be horizontal with dropdown menus. The footer might be horizontal but with all submenus shown vertical below each item (like a "fat footer"). The data should be the same but the styling/layout might need to be completely different. IMHO the layout/appearance rules applied to the Nav block itself should be specific to the insertion location in the Template where it is added. That means not storing it alongside the inner blocks within the post entity. The keeps styling/layout (Nav block as "Template Part") separate from "data" (the navigation items as inner blocks). This also means we could reuse "just the data" in the the Navigation Editor without having to undo/disable a load of layout/styling config coming from the Nav block itself. @talldan Does the above sound like what you are thinking too? |
|
Great work @talldan, keep it coming!
I actually like being able to have it vertical on one page and horizontal on another. If I want to share that, nothing stops me from creating a new wrapping template part just for the Navigation block.
I'm all for that, but I can't think of an approach that doesn't involve duplicating a lot of the code from the nav block. Exporting |
I assume you mean CSS and also some of the JS utilities that come baked into the Nav block? I starting to think perhaps having the CSS of the Nav block decoupled from the editor is a good thing. If the inner blocks' styles are similarly decoupled from the parent Nav block then this should mean they will "still work" with just a little custom CSS in the Nav Editor. In terms of utilities I assume we could look to share a lot of this via some kind of shared package such as Just initial thoughts - I haven't dived into any of this yet. |
I meant all the JS from the Navigation block and NavigationInnerBlocks component, there is a fair bit of work done there.
👍
It would work, although |
|
Aww 😍 we're moving to the place!
We'd be back to having to configure the block from outside settings and we'd also step away from the "reuse data" idea. I think we should just not make it a "template part" but a "navigation" .... part, case in which we can tweak the behavior a lot: auto wrap in a nav block, correct what blocks are available to insert and so on. |
I think you might have missed the comment I made just before yours commenting on that question, might have been a simultaneous post - #35418 (comment) It seems like there are a lot of good advantages from not saving the navigation block wrapper in the template part. It does mean wherever that template part is edited in isolation (navigation editor, template part editor, and potentially the template part focus mode) has some complexity, similar to what we've already been experiencing in the navigation editor. If left as it is now, we'd have a situation where only the inner blocks can be edited. This breaks some concepts like how the Navigation Link has a 'parent' property. The 'direct insert' behavior that was just implemented no longer works and would need to be replicated. The other option is to include a navigation block as a locked wrapper in these isolated editors. This fixes the things that were just mentioned, but also has some drawbacks. All the styling options on the navigation block need to be disabled (except for in template part focus mode, where this might still be relevant). Another conundrum is that the navigation block will likely have an option to switch to a different template part, but does that make sense when editing a single template part already? It would seem like that's the job of the editor. |
|
This looks very promising 🚀 I think conceptually at least it makes sense for Navigation to be its own custom post type, because template parts by definition are freeform, all-blocks-allowed areas, whereas what we want here is a block that is constrained to accept only certain types of blocks, and has a bunch of custom behaviour (direct insert and so forth). It would also mean we could have a "Navigation" section in the Appearance menu, which would make it easier to manage menus in the admin. As it is, we need to go looking for them in the Template Parts page. And perhaps, when opening a Navigation CPT from the Appearance menu, we could show it in a navigation editor type interface 😄 Would creating a new CPT imply a lot of duplication of logic that we already have in the Template Part? |
That's definitely the concern. |
This reverts commit 2adbdf7.
How does a new CPT compare to having template parts "variations" with limited capabilities e.g. configurable |
|
Thank you very much for diving into this exploration. It seems the most important decision is whether the template part abstraction is a good enough fit, and provides enough value that it offsets the extra work needed to accommodate the specificities and differences that will inevitably arise between navigation and general purpose template parts. Some of these differences might be pointing at shortcomings of the template part structure, which we should improve (for example, how tied things are to a We should probably list those considerations, both concrete benefits we get and negatives we incur when using |
Template parts do already use variations for semantic areas (Header, Footer). |
Yep, agreed. Here's an attempt to define some of the problems we're currently facing
|
This would be relatively straightforward from the perspective of the navigation block, and would follow how specific areas can be swapped. Here you only see "headers" for example and not other template parts:
I think the challenge is more about the cases where all template parts are shown, and whether we need to exclude navigation from those. That's what could start to get things a bit convoluted in my view.
The latter. Currently the coupling is overbearing and a self-imposed limitation. I should be able to access template parts I've saved on my site regardless of what theme I'm using. The theme a template part was created in can be useful information but should not be used as a strong filter.
The area in this case would also loosely refer to
I think the |
#31971 goes a long way towards fixing this. |
|
I've made an alternative PR that uses a |
@mtias Yes, I agree with this, it's definitely where things are getting complicated. If there were a way to solve this a lot of the other problems would also be easier to solve, but I question if it's something that should be solved. Feels like it would be introducing lots of granularity to template parts in order to reuse some of the existing systems like areas. Instead, maybe some of those systems should be abstracted to work more easily with different post types. As mentioned above, I've made #35746, which naturally provides a separate page for listing menus: But we still have the same issue that the post editor isn't currently suitable for editing these menus. I guess this is where we see the 'Isolated Editor' being used? Should this listing even be available in the admin?
Looks like @adamziel has created a PR to solve this (#35666) 🎉
Would you be able to elaborate on 'loosely refer to nav'?
Yeah, that would be interesting. In the Navigation (and to some degree Widgets) editors, hardcoded locked templates were used, but that approach wasn't perfect. It feels like the block should instead be assuming the role of the root block list. |
Description
Closes #34612
This is a very unrefined PR that adds template part storage to the nav block.
Current problems:
How has this been tested?
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).