AddonsScreen
Corex\Config\Addons\AddonsScreen · class · Config layer
The “Corex Add-ons” screen: a submenu under the Corex menu that lists every Corex add-on with its state and lets an admin enable/disable each (plugin + feature flag together), dependency-aware. The decisions are the pure AddonRegistry/AddonManager; this screen only renders, gates (via the shared AdminGuard), and delegates the writes to the activator — the same shape as the settings + setup-wizard screens.
Public API
Section titled “Public API”__construct(AddonRegistry $registry, AddonManager $manager, AddonToggleService $toggles, AdminGuard $guard, KitProvisioner $provisioner, PendingKits $pending, AdminPage $page, DocsUrl $docs, AddonCatalogService $catalog, ?ProviderSetup $providers)
Section titled “__construct(AddonRegistry $registry, AddonManager $manager, AddonToggleService $toggles, AdminGuard $guard, KitProvisioner $provisioner, PendingKits $pending, AdminPage $page, DocsUrl $docs, AddonCatalogService $catalog, ?ProviderSetup $providers)”register(): void
Section titled “register(): void”menu(): void
Section titled “menu(): void”maybeEnqueue(string $hook): void
Section titled “maybeEnqueue(string $hook): void”The Add-ons screen styling — only on this screen (Principle VI), declaring the scoped —corex-admin-* adapter as a dependency so it never restyles wp-admin globally and never loads on the public frontend.
render(): void
Section titled “render(): void”maybeToggle(): void
Section titled “maybeToggle(): void”isInstalled(string $slug): bool
Section titled “isInstalled(string $slug): bool”Whether an add-on’s plugin file is present on disk. Kept as a public method on this screen because it is passed as a callable to AddonManager::views(); the derivation itself now lives on the manager, which is also where the capability summary reads it from.