You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Patterns using a Navigation block have ref set #545
For example, Centered header with logo — the pattern code has a navigation block with a ref set, and when that's used on a different site, the referenced menu does not exist, causing an error:
I'm not sure how to approach this, but sharing some thoughts..
In Pattern Directory we can insert a Navigation block in the UI(as user), but with no permissions it feels broken.. Should we remove the block from the inserter there? 🤔
In Pattern Directory we can insert a Navigation block in the UI(as user), but with no permissions it feels broken.. Should we remove the block from the inserter there? 🤔
If the nav block is hidden from the inserter, then no one can use it (including the wporg user) and it can't appear in the core/bundled patterns (because we would also need to validate patterns to remove it, since some pattern authors build elsewhere and paste in content). When the directory launched, a bunch of site editing blocks were disabled including Navigation, and it was considered a blocker for GB bundled patterns - see #489, p9ue0y-Sc.
Since 6.1, the Nav block should not require a ref to look "correct". It has various fallbacks to ensure some content is displayed (in the following order):
If there is a Nav Menu (wp_navigation post) then display that (or the latest one).
If there is a Classic Menu then display that.
If there are Pages then display those.
Therefore I'd suggest testing that removing the ref provides a suitable experience.
Note also that ref is currently an ID reference. In the future we expect to migrate that to a slug, from which we will look up the most suitable menu (if you have one).
I hope that helps? Feel free to loop me in and I'll help as I can.
Reacted by Ben Dwyer, Rich Tabor and Nik Tsekouras
@getdave I think the issue is that the editor always adds the ref when the pattern is saved. I haven't found a way to save an empty Navigation Block without the ref id as suggested in this comment by Matias.
Patterns that aim to display whatever is the user's main menu should leave an empty navigation block (no id, no inner blocks); patterns that have a very specific layout should use Link Item at will with whatever placeholders make the most individual sense.
An option is to find and remove the ref on the server side before saving the pattern for the case of creating/editing patterns in the Pattern Directory or other sources like mine.
Other alternatives are adding a Page List or static Navigation Link within the Navigation Block. I have been using static navigation links in the navigation blocks used in a collection of header patterns in our project to ensure that the previews are uniform.
I think the preview of navigation blocks in the pattern inserter in Gutenberg should have some defaults or be configurable in some way to help promote patterns before they are inserted in the editor view. What do you think?
I was just able to publish a pattern with a navigation block, withoutref applied. When applied to a page, the navigation menu falls back to the page list, as expected.
@richtabor I tried in Gutenberg v14.9.1 and v15.0.0-rc.1 in WordPress 6.1.1.
In my project, I create patterns as posts on a WordPress site using Gutenberg. I'll open an issue there. When my patterns with navigation are applied to a page, I get the same error as in this issue because of the ref.
I just tried in the Pattern Directory and got an error because I don't have permission to add navigation blocks.
@richtabor I'm guessing that you were able to create that pattern in the PD without ref because of the error Classic menu import failed, and that's why the Menu dropdown keeps loading. See it on the Settings sidebar:
This use case suggests there's value in allowing users to toggle off the auto creation of the Nav Menu posts which back the data for the Nav block (that;s what the ref references).
I think patterns should never contain a ref because ref is specific to one site. Pattern previews of the navigation block should work with placeholder content that is replace with the block's fallback when the pattern is inserted.
@draganescu I believe we don't currently have placeholder content in the block. So my understanding of what you're saying is that we need to add a placeholder content so in the future patterns can display without ref or relying on the block's fallbacks.
However in the editor canvas how would the block know when to use the fallbacks mechanic vs use placeholders?
@getdave yes, we should add that, if the example attribute is not enough, because there has to be a way for a pattern to preview a "default" state in the directory but fallback to user's data when inserterd. Controlled inner blocks should only be used if the pattern is overly specific (e.g. needs exactly 4 links).
However in the editor canvas how would the block know when to use the fallbacks mechanic vs use placeholders?
We should maybe expand the example attribute or add a new one?
Activity
tellyworth commentedon Dec 15, 2022
What's the solution here - strip the
refout on save, and then do a one-time update of any existing patterns withref?ryelle commentedon Jan 2, 2023
I think so, the messy part will be making sure that doesn't break anything. Other blocks have
ref(like images) but those should also be null/removed.ntsekouras commentedon Jan 17, 2023
I'm not sure how to approach this, but sharing some thoughts..
In Pattern Directory we can insert a Navigation block in the UI(as user), but with no permissions it feels broken.. Should we remove the block from the inserter there? 🤔
Would removing the
reffrom these patterns: WordPress/gutenberg#46017 (comment) resolve the issue for thecorepatterns for now?@getdave do you have any thoughts about this, since you've worked a ton in Navigation block?
ryelle commentedon Jan 17, 2023
If the nav block is hidden from the inserter, then no one can use it (including the wporg user) and it can't appear in the core/bundled patterns (because we would also need to validate patterns to remove it, since some pattern authors build elsewhere and paste in content). When the directory launched, a bunch of site editing blocks were disabled including Navigation, and it was considered a blocker for GB bundled patterns - see #489, p9ue0y-Sc.
That would solve the immediate blocker for GB, yeah - how would you remove it (in a way that wouldn't come back if the pattern needs to be edited)?
getdave commentedon Jan 18, 2023
Since 6.1, the Nav block should not require a
refto look "correct". It has various fallbacks to ensure some content is displayed (in the following order):wp_navigationpost) then display that (or the latest one).Therefore I'd suggest testing that removing the ref provides a suitable experience.
Note also that ref is currently an ID reference. In the future we expect to migrate that to a slug, from which we will look up the most suitable menu (if you have one).
I hope that helps? Feel free to loop me in and I'll help as I can.
miksansegundo commentedon Jan 18, 2023
@getdave I think the issue is that the editor always adds the
refwhen the pattern is saved. I haven't found a way to save an emptyNavigation Blockwithout therefid as suggested in this comment by Matias.An option is to find and remove the
refon the server side before saving the pattern for the case of creating/editing patterns in the Pattern Directory or other sources like mine.Other alternatives are adding a
Page Listor staticNavigation Linkwithin theNavigation Block. I have been using static navigation links in the navigation blocks used in a collection of header patterns in our project to ensure that the previews are uniform.I think the preview of navigation blocks in the pattern inserter in Gutenberg should have some defaults or be configurable in some way to help promote patterns before they are inserted in the editor view. What do you think?
richtabor commentedon Jan 18, 2023
@miksansegundo Have you tried recently?
I was just able to publish a pattern with a navigation block, without
refapplied. When applied to a page, the navigation menu falls back to the page list, as expected.Here's the pattern markup, copied from .org:
miksansegundo commentedon Jan 18, 2023
@richtabor I tried in Gutenberg v14.9.1 and v15.0.0-rc.1 in WordPress 6.1.1.
In my project, I create patterns as posts on a WordPress site using Gutenberg. I'll open an issue there. When my patterns with navigation are applied to a page, I get the same error as in this issue because of the
ref.I just tried in the Pattern Directory and got an error because I don't have permission to add navigation blocks.
Adding.a.pattern.with.navigation.in.the.PD.mov
richtabor commentedon Jan 18, 2023
Same here. I created that one on the latest pattern directory directly.
Same, though it does still show up in the pattern itself. Not ideal.
miksansegundo commentedon Jan 18, 2023
@richtabor I'm guessing that you were able to create that pattern in the PD without
refbecause of the errorClassic menu import failed, and that's why theMenudropdown keeps loading. See it on the Settings sidebar:getdave commentedon Jan 18, 2023
This use case suggests there's value in allowing users to toggle off the auto creation of the Nav Menu posts which back the data for the Nav block (that;s what the
refreferences).I can see how the current situation is not ideal.
draganescu commentedon Jan 19, 2023
I think patterns should never contain a
refbecauserefis specific to one site. Pattern previews of the navigation block should work with placeholder content that is replace with the block's fallback when the pattern is inserted.getdave commentedon Jan 19, 2023
@draganescu I believe we don't currently have placeholder content in the block. So my understanding of what you're saying is that we need to add a placeholder content so in the future patterns can display without
refor relying on the block's fallbacks.However in the editor canvas how would the block know when to use the fallbacks mechanic vs use placeholders?
draganescu commentedon Jan 19, 2023
@getdave yes, we should add that, if the example attribute is not enough, because there has to be a way for a pattern to preview a "default" state in the directory but fallback to user's data when inserterd. Controlled inner blocks should only be used if the pattern is overly specific (e.g. needs exactly 4 links).
We should maybe expand the
exampleattribute or add a new one?