-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Enable block "click through" overlay for Navigation block in contentOnly mode #72248
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: +9 B (0%) Total Size: 2.04 MB
ℹ️ View Unchanged
|
jeryj
left a comment
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.
I'm not sure this is a good idea until we can have a drilldown/list view for the navigation block showing in the contentOnly sidebar when the navigation block is selected. At the moment, if I want to edit the text of a navigation item, I'd have to click it 3x:
- First click goes into the template
- Second click selects the navigation block to show the Add page
- Third click places the caret on the navigation item
So, as is, I think it's optimizing too heavily for an Add page flow. Once we have the drilldown or better representation for editing navigation items from the sidebar in contentOnly, I think this forced selection for the top level item could work.
|
I agree with your points @jeryj. We need to decide if optimising for the This would almost certainly be worth it if the Editable List View was available int he |
By simplified editing, does that means the contentOnly unsynced patterns experiment? It's not clear that this will land in WordPress 6.9, at the moment it looks like it probably won't as there are still lots of tasks remaining. The code for contentOnly unsynced patterns is behind an experiment toggle, so should these PRs also use the experiment toggle or are they good enough to ship in trunk as the default experience? |
What?
Fixes #71757
This PR enables overlay click-through behavior for Navigation blocks in
contentOnlyediting mode. This is a short-term fix to ensure Navigation blocks are ready for the Simplified Editing experience in WordPress 6.9.Why?
Without the overlay active, clicks on Navigation Link children immediately select those child blocks, bypassing the parent Navigation block selection.
In trunk this stops users from seeing the
Add pageutility button we've added to the block toolbar.When the full drill down experience is implement, it will prevent users from discovering and accessing the off-canvas editing experience, making Navigation editing more confusing in
contentOnlymode.We want to guide users towards selecting the Nav block in order that they can see the affordances we have put in place to help them add new links. This is hidden if the first click selects a sub block.
With this change:
This interaction pattern already works correctly in
defaultediting mode, and this PR extends it tocontentOnlymode specifically for Navigation blocks.How?
Modified the
__unstableHasActiveBlockOverlayActiveselector inpackages/block-editor/src/store/selectors.jsto add a targeted exception for Navigation blocks incontentOnlymode. The fix:contentOnlymodeThis is intentionally implemented as a minimal, block-specific conditional to unblock the immediate use case for WP 6.9. The code includes clear comments indicating this is a temporary solution.
Future Work
Post-6.9, we should refine and stabilize a proper block support API (e.g.,
__experimentalBlockOverlay: { contentOnly: true }) that allows any block to opt into overlay behavior per editing mode. This would make the feature extensible and remove the need for block-specific conditionals in core editor code.Testing Instructions
contentOnlymode)contentOnlymode maintain their current behavior (no overlay)defaultediting mode continue to work as beforeScreenshots / Screencast
Screen.Capture.on.2025-10-10.at.15-19-57.mp4