Add Navigation Add Page Button #71192
Merged
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] Enhancement
getdave
requested review from
andrewserong,
jeryj,
richtabor,
scruffian and
talldan
getdave
commented
Aug 13, 2025
Comment on lines
3
to
4
| kind: 'post-type', | ||
| type: 'page', |
Contributor
Author
There was a problem hiding this comment.
This isn't strictly related, but I've noticed over the course of several PRs that the default block shoudl also include these attributes in it's definition to ensure the "page" variation is added with the correct attributes from the get-go.
|
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: +200 B (+0.01%) Total Size: 1.92 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 8435b29. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17440755540
|
Contributor
|
I'm not sure about showing the LinkUI on the canvas in Write Mode - the alternative is to open it in the InspectorControls. The advantage of doing it in the canvas is that the connection between the button and the UI is clear. My hesitation is that we don't have other instances of inserting blocks when in |
Contributor
|
I also discovered a problem whereby, if I don't select a page, and navigate away the link itself and LinkUI stay open on the page. |
Contributor
Author
|
Yeh I didn't think of that. We need my other PR which normaliazes the behaviour between canvas and list view. Then we can see how this behaves in write mode. |
Contributor
Author
|
I think we need:
That said, the new block will still end up being focused in the canvas. To make it work in the sidebar we'd need to tap into the same manual insertion tracking that we use there which is going to be very challenging 😬 |
getdave
added
the
[Status] Blocked
- Creates a new hook that adds an Add page button to Navigation blocks - Button appears in the block toolbar when Navigation block is selected - Clicking the button inserts a new navigation-link block at the end - Hook follows the same pattern as navigation-link-view-button.js - Button works in all editing modes (not just contentOnly)
- Added useBlockEditingMode hook import - Used useBlockEditingMode() to get current block editing mode - Fixed undefined blockEditingMode variable error - Navigation Link Block now properly respects contentOnly mode
- Moved NavigationAddPageButton component directly into Navigation block edit/index.js - Added required imports: ToolbarButton, ToolbarGroup, page icon, createBlock, __unstableBlockToolbarLastItem - Removed old navigation-add-page-button.js hook file - Removed import from hooks/index.js - Component now renders directly in Navigation block when isEntityAvailable is true - Maintains same functionality: only shows in contentOnly mode
- Import DEFAULT_BLOCK from ../constants - Replace hardcoded 'core/navigation-link' with DEFAULT_BLOCK.name - Makes the code more maintainable and consistent with constants usage
- Pass kind and type attributes from DEFAULT_BLOCK constant to createBlock - Ensures new navigation link blocks are created with consistent default attributes - Makes the block creation more robust and aligned with constants
getdave
force-pushed
the
try/add-page-button-nav-block
branch
from
03e4cee to
9ea7f4d
Compare
Contributor
|
Not related to this PR, but this change makes this tool tip look more obviously wrong - I think we should change it to "Add page", but in a followup of course :) |
Contributor
Author
I agree. Please see #71502 |
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
This PR adds a Navigation Add Page Button that appears in Write Mode (contentOnly mode).
Why
Make it obvious how to add a new Page item to the Nav bar in content only. Part of #65699
Also related:
How
Add button to the toolbar in content only.
Testing
Important: Required block.json Changes
**For the Navigation block to be selectable in contentOnly mode, the following diff must be applied:
This change adds
"role": "content"to therefattribute, which is essential for:Related Issues
This PR addresses part of the requirements in Issue #65699 - "Navigation Block: develop a content-only representation". While this PR doesn't close that issue, it implements the foundational changes needed for the Navigation block to be properly selectable and editable in contentOnly mode.
Screenshots
Screen.Capture.on.2025-09-03.at.18-10-49.mp4