Hierarchy on pages opens children instead of the document

[noahporfidocampfire]

I'm on Payload 4.0.0-beta.6. I want a to build page tree, where a page can sit under another page. The URL should follow that, like /about/team.

I turned on hierarchy for the pages collection. parent points at another page, and slugField is slug. The _h_slugPath field is what I need for the URL.

In the pages list, the By Page view does not open the page. Clicking the title shows that page's children. To edit the page I have to use the gear icon, or go back to All Pages.

Is hierarchy on the pages collection the right way to build this? And is there a way to open the page itself from that view?

[Sagargupta16]

Yes, hierarchy on the pages collection is the intended way to build that tree, and the click behaviour is how the hierarchy view works in beta.6, not something in your config. In that view the name cell of a child row is a link to the hierarchy URL for that document, /admin/collections/pages?parent=<id>&view=hierarchy, so clicking the title drills into its children (ChildNameCell.tsx and getHierarchyListURL.ts). The document itself opens from the row's actions menu, or from the Edit link under each card in the grid layout; the table code picks group.isChildren ? hierarchyURL : editURL for the main link. There is no switch to flip it: hierarchy.admin only has components, injectSidebarTab, treeLimit and useHeaderButton (types.ts). All Pages keeps opening the document.

For the URL your setup is right. slugField: 'slug' makes _h_slugPath join the ancestors' slug values as they are, so a page with slug team under a page with slug about gets about/team. The field is virtual and opt-in: ask for it with computeHierarchyPaths=true on the REST call, or select: { _h_slugPath: true } in the Local API, otherwise it is not computed (hierarchy docs).

[olefritsch]

I tried hierarchies and immediately noticed the same thing. While I understand this may be useful for some scenarios like complex taxonomy trees, it doesn't feel natural as a replacement for the nested docs plugin. The same applies to (and is amplified by) the collection being removed from the default collections view in the sidebar instead moving to the tags tab. It would be good if some settings were exposed to make these behaviors more customizable.

[noahporfido]

Agreed, for a simple page tree I’d expect a different UX: editing content should stay the main action, with the tree as navigation on the left.

I saw the option to disable the tab navigation and put everything back under Collections, but then we lose the tree view, which is a really useful way to understand your page architecture.