Config to disable unused built-in admin features (WordPress Import, Widgets): nav, palette, and route

[cyface]

Problem

Every EmDash admin permanently shows the WordPress Import and Widgets entries — sidebar nav and Cmd+K command palette — with no way to turn them off. For a site that was never a WordPress migration and uses no widget areas, they're pure noise for editors, and the import screen is an attractive nuisance (an editor one palette-Enter away from a WordPress import wizard on a production site).

There's no off switch today: the nav entries are hardcoded (buildNavItems / the sidebar's adminItems in @emdash-cms/admin), and the /import/wordpress + /widgets routes are always mounted.

What we do now, and why it's not good enough: we hide both entries from a local plugin via DOM-level hiding of the sidebar items and palette rows. It works, but it's fragile against upstream markup changes, the routes stay mounted, and there's an unfixable wart — hidden palette rows stay registered in the composite keyboard list, so arrow-keying across the gap can land on an invisible row and Enter navigates to the "hidden" screen.

Proposal

A site-level config to disable built-in admin features the site doesn't use, e.g.:

emdash({
	admin: {
		features: {
			wordpressImport: false,
			widgets: false,
		},
	},
})

Disabling a feature removes its nav item, its palette entry, and unmounts its route (404), in one place. Additive and backward-compatible: both default to true.

Adjacent in spirit to the white-labeling RFC #1493 (tailoring the admin to the site), but this is feature visibility, not branding — so filing it separately rather than piling onto that thread.

Open questions

• Which features are eligible? We need wordpressImport and widgets; comments already have a plugin story; are there others worth gating (e.g. the marketplace) or is a minimal two-flag start better?
• Config flag vs. a plugin capability ("this plugin declares feature X hidden") — config feels right since it's a site-owner decision, not a plugin behavior.
• Should a disabled feature 404 or redirect to the dashboard? We'd vote 404 — quieter for security scanners.

Disclosure: drafted with AI assistance (Claude Code / Claude Fable 5); the use case, verification, and follow-up are human (@cyface).