feat(admin): allow hiding built-in core features from admin sidebar

[afonsojramos]

Summary

Allow Astro projects to opt out of built-in core features (Pages, Posts, Comments, Menus, Redirects, Widgets, Sections, Categories, Tags, Bylines) so they don't appear in the admin sidebar.

Motivation

Many sites use only a subset of EmDash's content surface. For example, a content site with custom collections (authors, blog, events, gallery, locations) may never use Pages, Posts, Comments, Menus, Redirects, Widgets, Sections, Categories, Tags, or Bylines.

Today every install ships with all of these visible in the sidebar, even when empty. For non-technical editors this adds noise — they see eleven nav entries when only five are relevant — and increases the surface area for "what is this for?" support questions.

The current emdash() integration exposes database, storage, plugins, fonts, auth, authProviders, siteUrl, trustedProxyHeaders, maxUploadSize, but no admin/feature-visibility knob. The plugins array adds plugins; there's no symmetric way to omit core features.

Proposed API

A disabledFeatures (or features: { posts: false, ... }) option on the integration:

emdash({
  database: d1({ binding: "DB" }),
  storage: r2({ binding: "MEDIA" }),
  disabledFeatures: ["posts", "pages", "comments", "menus", "redirects", "widgets", "sections", "categories", "tags", "bylines"],
});

Disabling a feature should:

• Hide its sidebar entry and routes in the admin UI
• Skip its REST/API endpoints (or 404 them)
• Optionally skip its DB migrations (best-effort; non-destructive on existing data)

Alternatives Considered

• CSS injection via a custom plugin — fragile, breaks on UI updates, doesn't remove API surface.
• Forking the admin — far too heavy.
• Custom plugin overriding nav — no documented hook for removing core entries.

Context

Real-world install: an Astro site migrated from a git-based CMS to EmDash for the database-first publishing model, using only a small set of custom collections. The unused core features are inert but visible.

[ascorbic]

I've moved this to a discussion, as it's a feature request. This is a good idea. The pages and posts part you can do today though: they're just content types, which you can remove if you want.

[vikramrojo]

I did something similar with the taxonomies by dropping it from the table. Even with a seed without posts/pages their taxonomies still appeared.

[marks-zyz]

One concrete case for this, measured on 0.37.0, and a smaller default that would cover it without any new option.

Our three sites set commentsEnabled: false on every collection. The public widgets go away, but the Comments item stays in the sidebar for every Editor: it is hardcoded in manageItems in packages/admin/src/components/Sidebar.tsx with minRole: ROLE_EDITOR, and Editor is exactly the role the client needs to edit and publish. So the client opens a moderation screen that can never receive anything, and asks what it is for.

The same file already does the conditional thing for two other items: Registry and Marketplace only appear when the manifest says they are available. Comments could follow that rule with zero config: show the item only when at least one collection has commentsEnabled. That does not replace the opt-out list proposed here (Menus, Redirects, Widgets have no natural "unused" signal), it just removes the most visible false positive by default.

Related on the plugin side: plugin admin pages have no minRole at all, so an Editor sees every plugin page, including ones whose routes are Admin-only (#3033 for the forms plugin).