Is there an existing issue for this?
Related / prior art:
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:
- Is Project Pages folder organization still reserved for paid plans?
- If CE is open to it (or a slimmed CE version), should we open a PR against
preview from smell-of-curry/plane@pokebedrock?
- 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.”
Is there an existing issue for this?
Related / prior art:
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
Wikifolder with pages like Structures, Pokémon, Items, New player guide — instead of one flat, unsearchable list.The data model already supports this:
Page.parentexists today. We added a thinnode_type(page|folder) discriminator and a small CE UX on top:Pages > Wiki > …)Working fork (production):
smell-of-curry/planebranchpokebedrockKey commits: page folders feature + modal/breadcrumb polish (
bab309c2c3and 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
Wikifolder 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)
node_typeonPage(pagedefault, orfolder); reuseparent+sort_orderparent=root/ UUID); validation for folder-only parents, sibling name uniqueness, cycle prevention, empty-folder delete?folder=<uuid>navigation; breadcrumbs on list + detail; Move-to-folder modalPageFoldertableQuestion for maintainers
Given #7522 was closed as paid roadmap / not coming to CE:
previewfromsmell-of-curry/plane@pokebedrock?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.”