[feature]: Nested folders for Project Pages — working CE implementation, seeking contribution guidance

Is there an existing issue for this?

• I have searched the existing issues

Related / prior art:

• #7511 — Folders for pages (open)
• #5620 — Tree structure for Pages (open)
• #4442 — Subpages / nested pages (closed; Nested Pages shipped on Business)
• #7522 — prior CE PR for folders (closed; maintainers noted this was on the paid roadmap)

This issue is not a cold “please invent folders” ask. We already ship a working CE implementation in production and want guidance on whether a clean upstream PR would be welcome.

Summary

Add shared nested folders to Project Pages so teams can organize documentation the way they already think about it — e.g. a Wiki folder with pages like Structures, Pokémon, Items, New player guide — instead of one flat, unsearchable list.

The data model already supports this: Page.parent exists today. We added a thin node_type (page | folder) discriminator and a small CE UX on top:

• Add folder → proper modal (not a browser prompt)
• Nested navigation with breadcrumbs (Pages > Wiki > …)
• Move to folder / move back to root
• Rename folder
• Folders listed before pages; Public / Private / Archived tabs unchanged
• Empty-folder delete only (no silent data loss)
• Same-project, matching-access, cycle-safe moves

Working fork (production): smell-of-curry/plane branch pokebedrock
Key commits: page folders feature + modal/breadcrumb polish (bab309c2c3 and parents).

We are happy to open a clean PR against preview (feature only — no fork deploy tooling) if the team wants this in CE / is open to reviewing it. If it remains paid-only, that’s useful signal too — just want to know before spending rebase cycles.

Why should this be worked on?

1. Flat Pages fall apart past ~50–100 docs
Self-hosted project teams that use Plane as the source of truth for product/wiki docs hit a wall. Filters and search help, but they don’t replace hierarchy. Folders are the difference between “Pages is usable” and “we keep a second wiki elsewhere.”

2. Users already asked — repeatedly
#7511 / #5620 capture the same pain. Nested Pages on Business (#4442) proves the product direction; Project Pages in CE still feel flat for long-lived projects.

3. The hard part is mostly already in the schema
Page.parent, sort order, and recursive archive/unarchive already exist. A folder is a first-class node in that tree, not a parallel subsystem. That keeps the design small, upgrade-safe (additive migration), and aligned with how nested pages already work.

4. This unlocks the “project wiki” use case without leaving Plane
Real production example from our self-host: one project’s Pages became a Wiki folder with structured guides. Breadcrumbs make the path obvious; Move-to-folder makes reorganization cheap. That is exactly what people reach for Notion/Confluence/Outline for — and it keeps docs next to the work items.

5. Implementation risk is already de-risked
We’ve been running this on a live CE instance (hundreds of pages). Happy to contribute tests + a focused PR if maintainers want it upstream.

---

Screenshots (production CE)

Pages list with folders + Add folder

Create folder modal

Page actions include Move to folder

Move to folder modal (Root or target folder)

Inside a folder

Page detail breadcrumbs include the folder

---

Proposed approach (if a PR is welcome)

Area	Approach
Model	Additive node_type on Page (page default, or folder); reuse parent + sort_order
API	Parent-scoped list (parent=root / UUID); validation for folder-only parents, sibling name uniqueness, cycle prevention, empty-folder delete
UI	Folder create/rename modals; ?folder=<uuid> navigation; breadcrumbs on list + detail; Move-to-folder modal
Scope	Shared project-wide folders; Public/Private access stays aligned with existing tabs
Non-goals (v1)	Drag-and-drop, cross-project folder trees, separate PageFolder table

Question for maintainers

Given #7522 was closed as paid roadmap / not coming to CE:

1. Is Project Pages folder organization still reserved for paid plans?
2. If CE is open to it (or a slimmed CE version), should we open a PR against preview from smell-of-curry/plane@pokebedrock?
3. Any design constraints we should match (sidebar tree vs list-folder navigation, naming, permissions) before we polish a contribution?

Thanks for Plane — happy to contribute this properly if it’s useful upstream, or keep it in the fork if the answer is “paid only.”

Start by reviewing the working pokebedrock branch and commits bab309c2c3 and its parents, then inspect the existing Page.parent model and the proposed API and UI areas. Confirm whether Project Pages folders are acceptable for CE, identify the required design and permission constraints, and establish whether a clean PR against preview is wanted.