Summary
Allow user-defined collections to be hidden from the admin sidebar via a flag on the collection definition. Complements #863 (which addressed built-in features).
Motivation
When a plugin manages a collection end-to-end (autocreating entries, providing its own admin UI), the raw collection list view becomes redundant clutter. Editors should be guided to the plugin's UI, not the auto-generated CRUD page.
Concrete example: A lead-notes-autofill plugin owns two collections — contact_submissions (autopopulated by the contact API) and lead_notes (1:1 with submissions, also autocreated). The plugin ships a "Lead Inbox" admin page (/_emdash/admin/plugins/lead-notes-autofill/inbox) with search, sort, assignee, and inline editing. The raw Content > Contact Submissions and Content > Lead Notes sidebar entries are never used in practice but show up next to legitimate editable collections like Blog Posts and Employees, confusing editors.
Per the current docs, "Navigation is generated from your collections and installed plugins" — but there's no opt-out per collection.
Proposed API
A hidden: true flag on the collection definition (mirroring the supports array):
{
slug: "contact_submissions",
label: "Contact Submissions",
icon: "mail",
supports: ["search"],
hidden: true, // ← new: collection still exists, sidebar entry omitted
fields: [ /* ... */ ]
}
Setting hidden: true should:
- Omit the sidebar entry under
/content/ in the admin
- Keep the collection fully functional via the REST API, MCP tools, plugin hooks, and direct
/content/:collection URLs (so plugins can still manage the data and admins can navigate directly if needed)
- Not affect schema, migrations, or query behavior
Alternatives Considered
- CSS injection — fragile, breaks on UI updates.
- Repurpose
label to discourage clicks ("Lead Notes (managed by Inbox)") — hacky and the entry still consumes a slot.
- Roles — too coarse; would affect more than these collections.
Context
Real-world install: an Astro site with a custom lead-notes-autofill plugin that fully owns its two collections. Pairs well with the recent adminPages support in plugin descriptors.
Summary
Allow user-defined collections to be hidden from the admin sidebar via a flag on the collection definition. Complements #863 (which addressed built-in features).
Motivation
When a plugin manages a collection end-to-end (autocreating entries, providing its own admin UI), the raw collection list view becomes redundant clutter. Editors should be guided to the plugin's UI, not the auto-generated CRUD page.
Concrete example: A
lead-notes-autofillplugin owns two collections —contact_submissions(autopopulated by the contact API) andlead_notes(1:1 with submissions, also autocreated). The plugin ships a "Lead Inbox" admin page (/_emdash/admin/plugins/lead-notes-autofill/inbox) with search, sort, assignee, and inline editing. The rawContent > Contact SubmissionsandContent > Lead Notessidebar entries are never used in practice but show up next to legitimate editable collections like Blog Posts and Employees, confusing editors.Per the current docs, "Navigation is generated from your collections and installed plugins" — but there's no opt-out per collection.
Proposed API
A
hidden: trueflag on the collection definition (mirroring thesupportsarray):Setting
hidden: trueshould:/content/in the admin/content/:collectionURLs (so plugins can still manage the data and admins can navigate directly if needed)Alternatives Considered
labelto discourage clicks ("Lead Notes (managed by Inbox)") — hacky and the entry still consumes a slot.Context
Real-world install: an Astro site with a custom
lead-notes-autofillplugin that fully owns its two collections. Pairs well with the recentadminPagessupport in plugin descriptors.