-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Remove unstable max pages attribute from Nav block #36877
Conversation
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.
Good step in the right direction.
I notice that it works in the frontend only, we should take some to follow-up and also make it work in the editor after the beta is cut.
$nested_pages = array_slice( $nested_pages, 0, $block->context['__unstableMaxPages'] ); | ||
// Limit the number of items to be visually displayed. | ||
if ( ! empty( $attributes['__unstableMaxPages'] ) ) { | ||
$nested_pages = array_slice( $nested_pages, 0, $attributes['__unstableMaxPages'] ); |
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 wonder if it should be an argument to get_pages
, usually that supports adding a limit.
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.
Good point. Let's consider a followup.
* Move to attr on Page List and remove from Nav block * Use empty check incase attr is falsey but present
There's now a feature request (#37340) for finishing this feature off in the page list block. |
Description
In #36724 we added a
__unstableMaxPages
attribute to both Page List and Navigation blocks. When used inside the Nav block the Page List would receive the property value via context from the Nav block.This seems like overengineering things...and it is(!), but only because we assumed that a lack of existing attributes on the Page List block was an intentional architectural decision so we decided using context was more appropriate and followed prior art in the code.
In hindsight all we achieved was propagating a potentially unstable attribute onto two blocks instead of one. Moreover @talldan explained to us that the Page List block is entirely open for extension using attributes and does not need to rely on context.
This PR reverses the original decision and removes the attribute from the Nav block. It retains it on the Page List block and updates the Nav block front end rendering to set the attribute directly on the Page List block itself rather than via context on the Nav block.
How has this been tested?
wp_navigation
Posts from your site.Save
.4
items displayed.Screenshots
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).