Hide 'Add block' control in Link UI when Navigation Link block is in contentOnly mode #71213
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
getdave
changed the title
getdave
added
[Type] Bug
|
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: -3 B (0%) Total Size: 1.92 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in a6776a0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17427048930
|
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
This appears to be testing well for me:
Before
After
Whether this approach should be extended to other blocks in contentOnly mode
If the conditional rendering logic should be moved to a higher level component
I don't mind the check where it is, it keeps things contained for now and could always be moved further up the tree in follow-ups if needed?
Comment on lines
161
to
163
| // Check if we're in contentOnly mode | ||
| const blockEditingMode = useBlockEditingMode(); | ||
| const isContentOnlyMode = blockEditingMode === 'contentOnly'; |
Contributor
There was a problem hiding this comment.
I notice in some of the other blocks we're doing a truthy check for === 'default' when showing controls, rather than an "not contentOnly", e.g. in the post title block. Would that be a better fit here?
Contributor
There was a problem hiding this comment.
Could we just extract a shared hook, useIsContentOnlyMode?
Contributor
Author
There was a problem hiding this comment.
@andrewserong I've adjusted. It's probably a better check because it's more about allowing certain functionality only in default editing mode rather than restricting it for contentOnly.
Contributor
|
Thanks for working on this. Does it also make sense to hide the [+] block inserter? 
|
Contributor
Author
|
I think the thinking is that the Add block is not content where as the plus inserter is. So no. |
getdave
force-pushed
the
feature/hide-add-block-in-content-only-mode
branch
from
7736bdc to
7552fc8
Compare
Contributor
Author
|
@andrewserong @scruffian What do you think about merging this one? |
andrewserong
approved these changes
Sep 3, 2025
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
Thanks for the ping @getdave! I think this will need a rebase to get tests passing, but this LGTM 🚀
… mode - Import useBlockEditingMode hook from @wordpress/block-editor - Check if block is in contentOnly mode using useBlockEditingMode() - Conditionally render LinkUITools only when not in contentOnly mode - Improves UX by hiding non-content UI when appropriate
getdave
force-pushed
the
feature/hide-add-block-in-content-only-mode
branch
from
9e5ea97 to
a6776a0
Compare
This was referenced Sep 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Fixes navigation link block UX by hiding the 'Add block' control when the block is in contentOnly mode.
Why
When the Navigation Link block is in contentOnly mode (which hides non-content UI), the 'Add block' button should also be hidden to provide a cleaner, more focused editing experience. This prevents users from seeing UI elements that are not relevant in content-only editing mode.
How
useBlockEditingModehook from@wordpress/block-editoruseBlockEditingMode()Testing
Manual Testing Steps
Block.json Testing (Temporary Hack)
IMPORTANT: The following block.json changes are for testing purposes only and should NOT be committed. They are a temporary workaround to allow Navigation block selection in Write Mode while waiting for a definitive solution.
Why This Temporary Hack is Necessary
The Navigation block currently cannot be selected in Write Mode due to block editing mode restrictions. Adding
role: contentto specific attributes allows temporary selection for testing purposes.How to Apply the Temporary Changes
Apply these diffs to your local files for testing (DO NOT COMMIT):
Navigation Block:
Navigation Link Block:
Testing with the Temporary Changes
Screenshots
[Screenshots to be added]
Breaking Changes
None - this is a UX improvement that maintains existing functionality.
Uncertain Elements