-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide suitable frontend fallback for the Navigation block when no Menu is selected #36721
Comments
List of top x pages might feel arbitrary and probably broken in some cases (why isn't my fifth page showing?). Using a saved |
How about we:
My understanding is that it's better to render something but I'm curious to know if that isn't what folks are expecting. I think either way it's going to be feel fairly arbitrary but possibly better than having no navigation rendered at all. |
Ok I have a followup PR in #36740 which
This mirrors what |
What to render also depends on how the template / pattern is built. If it uses specific link placement, the fallback should be more granular. That's where retrieving a single page could be fine. |
@getdave @mtias This approach does not mirror what The first and main reason is that outputting a list of pages in today's WordPress makes zero sense. Maybe this was good when WordPress was still mainly a blog, and pages were the new and shiny. See Twenty Twenty-One, Twenty Twenty, Twenty Nineteen, Twenty Seventeen, Twenty Sixteen to witness how even Core doesn't use the page menu fallback. The second reason is that The third issue, and this one is with the PR, is that the code naively assumes that the Page List block is available, which might not very well be. Blocks can be unregistered, or removed from the inserter. Either way this means developers don't want the block to be used, so you can't just fallback to the Page List assuming it is a desired fallback. Finally I wonder if this isn't putting the cart before the horse. Surely I should be able to place a Navigation block without any menu items? Or how else am I going to be able to indicate to users where to place a menu? |
Also I looked deeper at the PR, and just taking the first non empty Nothing is worse than software doing something you didn't want to do. And just willy-nilly displaying whatever menu happens to be pulled from the database is definitely software taking decisions it shouldn't take. |
Update: I missed your comment here #36721 (comment). Let me come back to you. Thanks for your feedback @fklein-lu. I understand why you say that. However, the fallback pattern implemented here is already in place in WP Core for classic Themes that use See https://developer.wordpress.org/reference/functions/wp_nav_menu/#more-information The functionality will go into WordPress 5.9 Beta 1 (release schedule here) at which point folks can test it and provide feedback. If folks want us to drop this behaviour for Full Site Editing and deviate from the established pattern then we can look at this again. Nothing is set in stone yet. Thanks again for taking the time to provide this feedback. |
Re-opening as I want to track these final tasks: |
@getdave So how can I as a theme developer disable this fallback in a block-based theme? |
You can't...yet. We will add a hook to allow for that and/or the ability to filter what is rendered as a fallback. Update: here is a PR for that #36850 |
With these complete I'm closing this one out as done. |
What problem does this address?
When the Navigation block is inserted there is a setup/placeholder state that requires the user to select a Menu to be used in the Navigation.
The result of this is that it is possible to insert a Navigation block and not have a Menu selected.
The most important scenario where this might occur is when switching Themes. As we cannot guarantee the Navigation block will be preserved on Theme switch (especially if Nav Areas are omitted from 5.9) it is entirely possible that we might end up in a state where a Navigation block exists in the content but it has no menu assigned to it.
Currently in this scenario the block will render nothing on the front end. This isn't great. Imagine if the Navigation block is in your header and then you switch Themes. Suddenly the front of your site is "broken" because there is no Navigation block.
What is your proposed solution?
In the case that no menu is assigned to a Nav block we should provide a suitable fallback on the site front end (only). Suggestions:
list of the first 4 top level pages.show the firstwp_navigation
Post (if available)something else...?Let's follow the pattern set in Core by
wp_nav_menu
as closely as possible.To be clear, it's absolutely fine to have the editor in a "setup state" (i.e. requiring user interaction) but the front end should render something to avoid "broken" states on the front of the website.
The text was updated successfully, but these errors were encountered: