Hierarchical / Nested Pages with Drag-and-Drop Page Tree

[angelokeirsebilck]

Summary

It would be great if EmDash could support hierarchical / nested pages as a first-class feature.

Instead of all pages existing at the root level:

Home
About
Team
Services
Web Development
Contact

pages could be organised into a tree:

Home
About
    Team
    History
Services
    Web Development
    Branding
Contact

This hierarchy could then optionally be reflected in the generated URL structure:

/about
/about/team
/about/history

/services
/services/web-development
/services/branding

For websites built with Astro, this would make EmDash much more suitable for traditional marketing / corporate websites where pages commonly have a parent/child relationship.

Motivation

EmDash already works really well for flat collections such as posts, projects, categories, etc.

For a typical company website, however, pages often naturally form a hierarchy.

A common example:

About
├── Team
├── History
└── Careers

Services
├── Strategy
├── Design
└── Development

At the moment these pages can of course exist as individual entries, but their structural relationship has to be recreated separately in navigation or application code.

Having the hierarchy available directly on the content itself would make it possible to use the page tree for:

• nested URLs
• breadcrumbs
• page navigation
• child-page listings
• sitemaps
• automatic navigation generation
• redirects when a page moves
• better organisation for editors

It would also make the Pages experience feel closer to CMSs such as Craft CMS or WordPress, while still keeping EmDash's much simpler architecture.

Proposed admin UX

Ideally the normal Pages content list could optionally switch to a tree view.

Something like:

☰ Home

☰ About
    ☰ Team
    ☰ History
    ☰ Careers

☰ Services
    ☰ Strategy
    ☰ Design
    ☰ Development

☰ Contact

Pages could be reordered using drag and drop.

Dragging vertically would reorder siblings.

Dragging a page underneath / into another page would make it a child:

About
Team

becomes:

About
    Team

Moving it back out would make it a root page again.

Ideally arbitrary nesting would be supported, although a configurable maximum depth could also make sense.

Existing precedent in EmDash

There already seems to be a very similar concept in the menu system.

Discussion #314 describes nested menu items with drag-and-drop and mentions that the backend already supports things like:

• parent_id
• hierarchical tree building
• reordering
• children on menu items

So potentially some of the same tree / drag-and-drop concepts could also be reused for hierarchical content.

This would essentially bring the same structural concept to Pages or other collections.

Possible data model

Conceptually, a hierarchical entry could have two additional system properties:

parent_id: string | null
sort_order: number

For example:

Page:
title: Team
slug: team
parent_id: <About page ID>
sort_order: 1

The important distinction would be that the page's own slug remains:

team

while its resolved path becomes:

about/team

This keeps the slug independent from the page's current position in the tree.

Moving the page:

About
    Team

to:

Company
    Team

would therefore change the resolved path:

/about/team

to:

/company/team

without changing the page's own slug.

Path / URL resolution

A useful API property could be a computed or stored path, for example:

{
  "title": "Team",
  "slug": "team",
  "path": "about/team"
}

This would make frontend routing very straightforward.

For example, Astro could use:

src/pages/[...slug].astro

and resolve:

/about/team

against:

path = "about/team"

rather than requiring each frontend implementation to recursively resolve all parents itself.

Whether path should be persisted or computed is obviously an implementation detail.

Duplicate slugs under different parents

One thing worth considering is slug uniqueness.

For a hierarchical page system, these should ideally both be valid:

/company/team
/sports/team

because their complete paths are unique even though both pages use:

slug = team

If slugs are currently unique within the entire collection/locale, hierarchical collections may need uniqueness to take the parent into account, conceptually:

parent_id + slug + locale

or alternatively enforce uniqueness on the complete resolved path.

This would be especially useful for larger sites.

Localisation / i18n

It would also be useful to define how hierarchy behaves with translated content.

For example:

EN
/about/team

NL
/over-ons/team

Ideally moving Team underneath another page would move the corresponding translated page relationship as well, rather than requiring editors to rebuild the tree separately for every locale.

Exactly whether the parent relationship should belong to an individual locale row or to the translation group would need some consideration.

Ordering

The same hierarchy could also solve manual page ordering.

For example:

About
    History       sort_order: 0
    Team          sort_order: 1
    Careers       sort_order: 2

This would make queries such as:

get children of About ordered by sort_order

possible without maintaining a second navigation structure.

API / querying

Some useful possibilities could be:

page.parent
page.children
page.path

or query options such as:

getContent("pages", {
  parent: page.id
})

and possibly:

getPageByPath("about/team")

The exact API is less important than having the hierarchy available consistently to both the admin and frontend.

Moving and deleting pages

There are a few edge cases worth handling.

When moving a parent page, all descendant paths would need to resolve through the new hierarchy.

For example:

/about/team
/about/team/john

moving Team underneath Company would result in:

/company/team
/company/team/john

For deletion, EmDash could either:

• prevent deleting a page that still has children
• ask whether the children should also be deleted
• move the children to the deleted page's parent

Any of those would be preferable to leaving invalid parent references.

Circular relationships should obviously be prevented as well.

For example, this should never be possible:

About
    Team
        About

Redirects

As a future enhancement, moving or renaming a page could potentially integrate with redirects.

For example:

/about/team

moves to:

/company/team

and EmDash could offer to create:

/about/team -> /company/team

automatically.

This would be particularly useful for production sites, although redirects do not necessarily need to be part of the initial implementation.

Tree view as an optional collection feature

This might also be useful beyond a hardcoded pages collection.

Potentially a collection could opt into hierarchical behaviour:

{
  name: "Pages",
  slug: "pages",
  hierarchical: true
}

That would allow developers to use the same functionality for other structures such as:

Documentation
├── Getting started
│   ├── Installation
│   └── Configuration
└── API
    ├── Authentication
    └── Endpoints

or:

Locations
├── Belgium
│   ├── Bruges
│   └── Ghent
└── France
    ├── Paris
    └── Lille

This could make the feature more generally useful than making hierarchy specific to Pages.

Possible first implementation scope

A first version could stay relatively small:

1. Allow a collection to be marked as hierarchical.
2. Add a parent relationship to entries in that collection.
3. Add sibling ordering.
4. Render hierarchical collections as a tree in the admin.
5. Support drag-and-drop reordering / reparenting.
6. Expose parent, children and resolved path through the API.
7. Prevent circular parent relationships.
8. Support hierarchy correctly across locales.

Redirect creation, breadcrumbs and navigation generation could then remain separate features built on top of the hierarchy.

Why this would be useful

For blogs and content-heavy websites, flat collections make perfect sense.

For agency-built marketing websites, though, Pages is often one of the central collections and hierarchy is a very common requirement.

Being able to model:

About
    Team

Services
    Web Development
    Branding

Contact

directly in EmDash — and naturally expose it as:

/about/team
/services/web-development
/services/branding

would remove quite a bit of custom application logic and make EmDash significantly more comfortable to use as a CMS for traditional company websites.

Would there be interest in supporting this as a first-class hierarchical collection / page feature?

[viztor]

I don't think this is the best way, hierarchical page using parental id basically just become collection. You are basically re-implementing collection on top of pages.