Gutenberg: 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 https://github.com/WordPress/gutenberg/issues/23915#issuecomment-667059749, 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.