-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Explore Navigation Block contentOnly mode UX via Content Panel #71137
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
base: trunk
Are you sure you want to change the base?
Conversation
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: +1.9 kB (+0.1%) Total Size: 1.94 MB
ℹ️ View Unchanged
|
1bac4f9
to
8a971b4
Compare
Some more ideas to try:
|
1954e7b
to
633b200
Compare
633b200
to
61171c2
Compare
Idea for implementing the "let's treat the Nav block inner blocks as content" is outlined here #52018. I don't think the inner blocks should be active unless they themselves pass the |
61171c2
to
2f6d705
Compare
2f6d705
to
a135eb4
Compare
I've updated this PR to revert the code that disabled sub blocks of the Nav block. This temporarily regresses the UX until we add the "overlay" / "click through" behaviour to the Nav block. The UX I am envisioning is
The key facet is that the complexity of the "Nav Item" blocks should be hidden from you initially in contentOnly. It should guide you towards the most simple path (adding a page). |
d417292
to
8008e87
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bringing over this feedback from @annezazu from the other PR:
Tested this out and have a few items of feedback:
I found it odd I couldn't delete a menu item but I could add one. I'd expect to be able to remove items.
The bold, italics, etc feel out of place to include here as we'd want folks styling their menu holistically. I think we can remove from the default experience but am curious why it was included in the first place.
I wonder how clearly editable these items are without anything showing up in the block settings. At a glance, it feels hard to tell that you can just directly get in there and item things compared to the alternative approach you've worked on.
56b1dba
to
48641ab
Compare
48641ab
to
87252d4
Compare
Let's rebase this and bring in the |
This change makes navigation menu item labels editable in Write Mode by adding role: 'content' to the label attribute for both core/navigation-link and core/navigation-submenu blocks. This allows users to: - Edit menu item text/labels in Write Mode - Maintain the content-focused editing experience - Keep layout and styling controls disabled in Write Mode Part of the Navigation Block Write Mode improvements.
This change treats Navigation blocks like Template Parts in Write Mode by giving them 'contentOnly' editing mode when outside of sections. This allows Navigation blocks to be selectable and editable in Write Mode while maintaining the content-focused editing experience, similar to how Template Parts work.
…panel - Modified block inspector logic to show Navigation block controls when selected - Added condition to check for 'core/navigation' block type - Ensures Navigation block inspector is shown instead of parent section block - Enables direct access to Navigation block's List View tab from Content panel
- Import chevronRight icon from @wordpress/icons - Add blockName detection to BlockQuickNavigationItem - Show chevron icon only for 'core/navigation' blocks - Provides visual indication that Navigation blocks have click-through behavior
- Add logic to detect when Navigation block is in contentOnly mode - When in contentOnly mode, back button targets parent section instead of parent Navigation block - Use getParentSectionBlock() to find the nearest section block - Maintain existing behavior for other Navigation block contexts - Improves navigation flow when editing Navigation blocks from Content panel
- Add buttonLabel logic to useSelect hook - When in contentOnly mode: 'Go to parent section' - When in normal mode: 'Go to parent Navigation block' - Use dynamic buttonLabel in Button component - Provides clear context about where the back button will navigate
…logic to check if current block is a child of a Navigation block\n- Use getBlockParentsByBlockName to find Navigation block parents\n- Force blockEditingMode to 'disabled' for Navigation block children\n- Ensures child blocks of Navigation blocks cannot be edited directly\n- Maintains existing editing behavior for all other blocks
This is a prototype hack to prevent direct editing of Navigation block children while still allowing them to be selectable and managed through the Navigation block's List View interface. ## What this hack does: 1. **Detection**: Uses getBlockParentsByBlockName() to check if the current block has any 'core/navigation' block parents 2. **Override**: If a block is a child of a Navigation block, forces its blockEditingMode to 'disabled' regardless of other editing mode logic 3. **UI Control**: Updates multiple properties to respect the disabled state: - blockEditingMode: Set to 'disabled' for Navigation children - isSubtreeDisabled: Disables the entire subtree - isEditingDisabled: Prevents editing interactions - hasEditableOutline: Removes editable outline styling - mayDisplayControls: Hides editing controls ## Why this hack is needed: The Navigation block's child blocks (navigation links, submenus) have role: 'content' attributes which would normally make them editable in Write Mode. However, for the Navigation block UX, we want these children to be managed through the Navigation block's List View interface rather than being directly editable in the canvas. ## Limitations: - This is a prototype solution that may need refinement - Only affects direct children of Navigation blocks - May need additional logic for deeper nesting scenarios - Could be replaced with a more elegant solution in the future
…al on contentOnly mode
- Add Edit navigation button to Template Part blocks when Navigation blocks are present - Button only shows in contentOnly mode and selects first Navigation block - Disambiguate button labels: Edit template part vs Edit navigation - Update Navigation block Edit button to use sentence case for consistency - Fix enableComplementaryArea import from interfaceStore
- Change button label from 'Edit template part' to 'Edit {Title}' - Use template part entity title (e.g., 'Edit Header', 'Edit Footer') - Fall back to 'Edit template part' if no title is available - Maintain existing functionality for Navigation editing
- Wrap each button in ToolbarGroup components for proper visual separation - Use standard WordPress UI components (ToolbarGroup) instead of custom CSS - Maintain existing functionality while improving visual organization - Follow WordPress design system best practices
- Replace ToolbarGroup approach with different BlockControls group props - Use group='block' for Template Part Edit button and group='other' for Navigation Edit button - WordPress automatically adds visual separators between different groups - Add documentation comment explaining the prototype hack approach - Maintain existing functionality while improving visual organization
- Convert template part titles to lowercase for consistent sentence case - Button now shows 'Edit header' instead of 'Edit Header' - Maintains fallback to 'Edit template part' when no title is available - Improves visual consistency with other button labels
602232e
to
fc1f1c9
Compare
What
This is a PROTOTYPE exploring an alternative UX approach for Navigation blocks in Write Mode, different from the approach in #70977.
Instead of making Navigation block children directly editable in the canvas, this prototype explores a Content Panel → List View workflow where:
Closes #65699
Why
This explores an alternative to the direct canvas editing approach in #70977. The goal is to provide a more structured menu editing experience while maintaining Write Mode's content-focused philosophy.
How
HACK: Force disabled editing for child blocks of Navigation blocksTesting
Screenshots
Screen.Capture.on.2025-08-12.at.12-04-08.mp4
Prototype Hacks and Limitations
Hacks Implemented:
Block Inspector Override: Modified to show Navigation block inspector instead of Content panel when Navigation block is selected
Content Panel Click Behavior: Added chevron icon and click-through logic in
Back Button Logic: Modified to navigate to parent section for Navigation blocks in contentOnly mode
UI State Management: Multiple properties updated to respect the disabled state (, , , etc.)
Overlay ("Click through"): added nav block specific condition
supports.__experimentalForceBlockOverlay
which blocks can use to opt into overlay even when incontentOnly
.Why These Are Hacks:
What Would Be Needed for Production:
Alternative Approach
This prototype explores a different UX than #70977:
Both approaches have merit and this prototype helps evaluate the trade-offs between direct editing vs. structured menu management.
Next Steps
This prototype is for feedback and discussion. If this UX direction is pursued, the hacks would need to be replaced with proper APIs and systems.