New "Pages" Block: Display a list of links to a site's pages

[shaunandrews]

A simple block that lists all your site's pages could be useful in a number of cases, including as a default block within the Navigation block (#23207). A Pages block would be (at first) restrictive and simple. It only does a few things:

1. Lists all of your site's pages, respecting page order and hierarchy.
2. Offer two style variants; Horizontal and vertical.
3. Allows you to enable/disable the use of submenu dropdown for top-level pages with child pages.

You wouldn't be able to reorder, change page names, or otherwise make edits to the list of pages within the block content.

At some point we could...

• ...allow changes to page order and nesting.
• ...allow changes to page titles or adding a new option for separate page labels.
• ...offer a way to open pages in the block editor.
• ...offer a way to hide (and then show) individual pages in the display.
• ...offer a way to transform or otherwise "breakup" Pages into separate, editable (Link?) blocks.

Be sure to checkout the Figma file to see explorations for the above additions, along with a prototype for the essential shown in the GIF.

[MichaelArestad]

This is a thoughtful solution that will be a huge asset to 90% of folks building websites. Nice work.

Side note: I do wonder if we should align the horizontal/vertical layout with the solution for the Nav block (which currently uses two blocks to solve that issue).

[ZebulanStanphill]

@MichaelArestad Actually, the Navigation block doesn't technically use two blocks. Those are just two different block variations (a fairly recent API allowing different pre-configured versions of a block to be listed separately in the inserter).

[jasmussen]

This should be fairly trivial to build, so no reason not to blaze a trail and try it in code.

[noisysocks]

The challenge here is how to have the Pages block output multiple links as if those links were children of the Pages block's parent.

Potentially we could have Pages render something like this:

<div class="wp-block-pages" role="presentation">
	<div class="wp-block-pages__link" role="menuitem">
		<a href="...">...</a>
	</div>
	<div class="wp-block-pages__link" role="menuitem">
		<a href="...">...</a>
	</div>
</div>

.wp-block-pages {
	display: contents;
}

The parent block could, using an API like the one proposed in #23915 (comment), see that a child is a Pages block and then: a) not surround that block with a <li>; b) use <div role="menu"> instead of <ul> for the inner blocks.

[noisysocks]

Removing this from the Navigation project board as I don't think we should focus on it for WP 5.6 which is nine weeks away. I think it's definitely a required feature for Full Site Editing, though.

[shaunandrews]

Worked up another iteration on the design for this one. I've moved towards labelling the block "Page Listing," exposed the sub-menu toggle into the toolbar, and added a new inspector option for setting an explicit parent.

This GIF runs through a few things:

• The parent select option allows you to choose from "No parent" (which would list all top-level pages) and a list of pages with children. In the GIF my site only has one page with children, the Services page.
• The toolbar now contains a new button to toggle the display of sub-menus. When turned on, any top-level pages with children will display an indicator (a down-facing chevron by default) next to its label. When hovering (or focusing), the sub-menu will appear.
• This uses the normal "Transform" option in the block's menu, similar to the way you can transform a Gallery into multiple Image blocks. I did add an additional detail that shows the number of blocks that will be created when transforming.

[jasmussen]

"Page Listing" is good!

[ZebulanStanphill]

"Listing" generally means a single item out of a list, doesn't it? Hence why we say things like "job listings" (notice the "s"). I think "Page List" would make more sense.

[tellthemachines]

Offer two style variants; Horizontal and vertical.

How does this work when the Pages block is a child of a Navigation block set to either vertical or horizontal? Should this setting still be shown or should we just follow the orientation of the parent?

[ZebulanStanphill]

Offer two style variants; Horizontal and vertical.

How does this work when the Pages block is a child of a Navigation block set to either vertical or horizontal? Should this setting still be shown or should we just follow the orientation of the parent?

This sounds pretty similar to the issues being tackled with the attempt to refactor the Gallery block to use nested Image blocks. There, the problem is how to handle controls like Image block width/height and alignment when the Image blocks are moved in/out of a Gallery block. I guess that whatever the proper solution is there should also apply here.

[tellthemachines]

Just had a thought about displaying child pages in dropdowns: if we're able to use the Pages block outside of a Navigation block, I'd expect it to work like the Categories block, and like the legacy Pages widget, and display a nested list instead. Could we perhaps make dropdowns optional for this block, as a setting? Or... open to ideas here 😅

[shaunandrews]

How does this work when the Pages block is a child of a Navigation block set to either vertical or horizontal? Should this setting still be shown or should we just follow the orientation of the parent?

The Pages block does not need to have a vertical/horizontal style. Instead, it should respect the settings of its parent block; The Navigation block should control the layout making the Pages block an invisible wrapper around a collection of Page blocks. (Related: #27324)

Could we perhaps make dropdowns optional for this block, as a setting?

I think this is a similar situation to the layout control.

On its own, the Pages block could render a normal ordered list using indentation to signify sub-lists. As a child of a Navigation block, the Pages block gains new "magic powers" and respects any options around the display of sub-menus and their indicators, as set by the parent Navigation block.