Repository navigation
Conversation
Copilot
AI
changed the title
[WIP] Fix Navigation block to auto-convert Page List on new block insertion
Add page creation appender to Page List block within Navigation
Feb 18, 2026
scruffian
reviewed
Feb 18, 2026
| * @param {Object} props Component props. | ||
| * @param {number} props.parentPageID The parent page ID for the new page. | ||
| */ | ||
| export function PageCreatorAppender( { parentPageID } ) { |
Contributor
There was a problem hiding this comment.
@copilot do we need a new component? Can't we just hijack the block appender behaviour in this context to behave differently?
Contributor
Author
There was a problem hiding this comment.
You're absolutely right! I've refactored the implementation to hijack the block appender behavior instead of creating a separate component.
The custom appender now renders a single "+" button that looks identical to ButtonBlockAppender but opens the page creation modal instead of the block inserter. This is much cleaner and eliminates the need for the separate page-creator-appender.js file.
Changes in commit a5ef43f:
- Consolidated all page creation logic into
edit.js - Removed the separate component file
- Custom appender is now just a Button with the standard
block-editor-button-block-appenderclass - Removed custom CSS that's no longer needed
|
Size Change: -31.4 kB (-0.46%) Total Size: 6.84 MB
ℹ️ View Unchanged
|
scruffian
force-pushed
the
copilot/auto-convert-page-list-block
branch
2 times, most recently
from
March 3, 2026 11:05
b2dec61 to
e72f4f7
Compare
|
Flaky tests detected in 81ae745. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22622036273
|
github-actions
Bot
added
[Package] Block editor
scruffian
reviewed
Mar 3, 2026
| } | ||
|
|
||
| .wp-block-page-list__appender-toggle.components-button { | ||
| background: $gray-900; |
Contributor
There was a problem hiding this comment.
Once #76087 merges we'll be able to use a mixin here.
Contributor
scruffian
marked this pull request as ready for review
March 3, 2026 14:46
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @Copilot. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
Co-authored-by: scruffian <275961+scruffian@users.noreply.github.com>
Co-authored-by: scruffian <275961+scruffian@users.noreply.github.com>
Use the existing LinkUIPageCreator from the navigation-link block instead of a custom Modal for creating pages. Extract a shared PageCreatorAppender component that handles menu_order and parent page context. Show the appender when the Page List block or its children are selected, but not when inside a Navigation block. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The existing CSS in content.scss already styles this class with the dark 24px button look. Only override display:none since we control visibility via React rather than CSS selection state. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The appender is a sibling of the block element (useBlockProps is on the <ul>), so existing block-list-appender CSS selectors that require .block-editor-block-list__block ancestry don't match. Use a dedicated class with styles in editor.scss. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The __next40pxDefaultSize prop (required by lint) sets a 40px default that overrides the CSS. Explicitly set size="small" to get the intended 24px button size. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The lint rule exempts components with an explicit non-default size prop. Since we pass size="small", __next40pxDefaultSize is unnecessary. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…mixin Render the page creator appender inside the <ul> as an <li> instead of as a sibling outside the block's DOM wrapper. This prevents a race condition where clicking the appender could cause the block to lose selection and insert a default block instead. Add onClose to the Popover so it dismisses on Escape and outside clicks. Extract shared dark inserter button styles into an inserter-toggle mixin in base-styles, replacing duplicated rules in content.scss, style.scss, and editor.scss. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move the mixin extraction to its own PR to keep this one focused on the page creator appender feature. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
scruffian
force-pushed
the
copilot/auto-convert-page-list-block
branch
from
March 3, 2026 17:08
da5d98b to
de495a8
Compare
github-actions
Bot
added
[Package] Block editor
Copilot stopped work on behalf of
jeryj due to an error
March 3, 2026 19:22
jeryj
reviewed
Mar 3, 2026
jeryj
left a comment
jeryj
left a comment
Contributor
There was a problem hiding this comment.
It's an interesting idea! I think I want @WordPress/gutenberg-design feedback on this, as it's a bit non-standard of an approach to directly use the appender for page creation outside of the navigation block. I like how if you're scaffolding the pages it lets you create more pages.
I can see the most beneficial part being to create new pages from the page list navigation without needing to convert the page list to navigation items or expose the page list internal bit. My worry is that this will make it harder to figure out when to convert it a page list into navigation item blocks though. In that case, is the idea:
- If create a new page from the Link UI, leave it as a Page List
- If they do anything else, convert it to navigation blocks?
I found one bug - when you create a page, there's a focus loss. Focus should get placed back on the appender.
Comment on lines
+67
to
+72
| { onBack && ( | ||
| <BackButton | ||
| className={ backButtonClassName } | ||
| onBack={ onBack } | ||
| /> | ||
| ) } |
Contributor
Author
There was a problem hiding this comment.
Yes, this is necessary. The PageCreatorAppender component reuses LinkUIPageCreator but only provides onClose, not onBack. Making the back button conditional allows the component to be used both in the Navigation Link UI (with back button) and in the standalone Page List context (without back button, just close via Popover).
| onClose, | ||
| onPageCreated, | ||
| initialTitle = '', | ||
| menuOrder, |
Contributor
There was a problem hiding this comment.
Could we get away without passing this param? It'll always be the last item.
Contributor
Author
There was a problem hiding this comment.
The menuOrder param is needed to ensure newly created pages appear at the end of the list. Without it, WordPress defaults menu_order to 0, which would place new pages at the beginning.
The calculation finds max(menu_order) + 1 from existing pages. We pass it via Context rather than calculating inside LinkUIPageCreator because that component is shared with Navigation Link UI, where ordering needs might differ.
| <ul { ...innerBlocksProps }> | ||
| { innerBlocksProps.children } | ||
| { showAppender && ( | ||
| <li className="wp-block-page-list__appender-container"> |
Contributor
There was a problem hiding this comment.
I don't think this should be an <li>. It should likely be a div outside the <ul>
Contributor
Author
There was a problem hiding this comment.
Fixed in 6743c14. The appender is now a <div> outside the <ul>, properly wrapped in blockProps. I separated the blockProps from innerBlocksProps so the structure is now:
<div {...blockProps}>
<ul {...innerBlocksProps}>
{innerBlocksProps.children}
</ul>
{showAppender && (
<div className="wp-block-page-list__appender-container">
<PageCreatorAppender />
</div>
)}
</div>
Contributor
There was a problem hiding this comment.
I had it like this before, but the problem was that sometimes it triggered a new block creation instead of opening the appender. Hopefully this time it doesn't!
Co-authored-by: jeryj <967608+jeryj@users.noreply.github.com>
Co-authored-by: jeryj <967608+jeryj@users.noreply.github.com>
Co-authored-by: jeryj <967608+jeryj@users.noreply.github.com>
Contributor
|
It is a bit of a novel approach indeed, but I generally echo the motivation, and I think @fcoveram has specifically pondered a feature like this exact thing. I think the main question is: instead of this being yet-another way to add pages, can it be this dialog instead? 
Without "Add block" if need be. |
Contributor
Thanks for the screenshot. I don't think that flow makes sense though, because Page List would already show a list of all the pages on the site, so the only possible action is to add another one! |
Contributor
|
Ah makes sense, I missed the "Page list" aspect. Another thought then; we have a unified "Draft new page" modal. This is the one that is invoked when you click "add page" in that screenshot I showed you before, it should be accessible from additional locations like the Site editor > Pages add button. It was created specifically to be a modal so that it could be accessible from anywhere. Can we simply invoke that same modal here? 
|
Contributor
I expect we could. Is there a rationale behind using a modal in this context, rather than using the create page UI that we have in the navigation block already? Should we replace that one with the modal as well? |
Contributor
You're referring to this one, which I had missed: 
The modal was initially created, and I believe it was also used, for the navigation block create-page action too. The motivation is to both allow that same action to be completely generic and agnostic: you can create pages from so many different flows; sometimes you just want to create teh draft, sometimes you want to draft and edit. The modal was created to be the one thing to point to for all those different places. Because I forgot that other new UI, I don't personally have a strong opinion. If the same UI is reusable, I suppose we could use either, the one we like the most. But because I believe we used to use the modal in the nav block too, I sense there's some context I'm unaware of, for why we moved away from it. So it might be worth tracking down that context so we don't go in circles. What's your preference? |
Contributor
My primary concern is consistency - I think we should try to re-use the same components and patterns as much as we can, so in one sense I'm happy with either approach, as long as we are consistent. For this reason though I am leaning away from the modal, just because that's not a pattern we use very much - maybe it would be good to have a heuristic about when we would / would not use a modal. |
Contributor
|
If consistency is the aim then I'd lean toward the modal appraoch. It's a pattern that is already used in several creation flows (pages, templates, template parts) and will be used in many other scenarios as more sections (e.g. posts) are added to the site editor. Speaking generally I almost always favour modal-based creation flows for the following reasons. I recognise not all of them necessarily apply in this particular flow :)
|
getdave
reviewed
Mar 5, 2026
getdave
left a comment
getdave
left a comment
Contributor
There was a problem hiding this comment.
My opinion is that we should take a pause here and consider the overall experience for Page List especially in the context of Navigation.
It's easy to add these features but I think for 7.1 we should just hold off and work to provide an experience which is cohesive overall.
I don't see any harm in just taking a moment here.
This branch has not been deployed
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
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?
Part of a suggested fix for #73964
Adds an inline page creation appender to the Page List block (when used outside of Navigation), allowing users to create new WordPress pages directly from the block.
Why?
Currently, when users want to add pages to a Page List block, they must leave the editor and create them through the WordPress admin. Inside a Navigation block, the existing "Convert to Links" flow offers an alternative — but standalone Page List blocks have no equivalent.
This feature lets users create pages without leaving the editor, while keeping the Page List synchronized with actual site content (unlike static Navigation Links). I think it will be interesting to try this approach within the Navigation block too, but let's get it working in this context first.
How?
PageCreatorAppendercomponent — renders a "+" button below the page list. Clicking it opens aPopovercontaining the reusableLinkUIPageCreatorform. The popover dismisses on Escape, outside click, Cancel, or successful page creation.<div>outside the<ul>— properly wrapped in blockProps to maintain correct DOM structure and styling.nextMenuOrdercomputation — finds the maxmenu_orderof existing pages and adds 1, so newly created pages sort at the end.isChildOfNavigationguard onuseEffect— prevents standalone Page List blocks from triggering the "Convert to Links" modal when inner blocks are selected.LinkUIPageCreatorextended — addedonCloseandmenuOrderprops for reuse outside the Navigation Link UI. Back button is now conditional ononBackbeing provided.inserter-togglemixin for the appender button to match other inserter buttons across the editor.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Screen.Recording.2026-03-03.at.13.46.55.mov
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.