ActivePlugins

Which plugin classes actually boot, from two sources that answer two different questions. **What a host has** is declared in code — a plain list a developer edits and reads in a diff. **What is switched on** is state, and state has to be writable at runtime for an admin panel to switch anything at all. Keeping them apart is what lets a panel manage plugins without ever writing PHP back to disk: a page that rewrites its own source is a code-execution write surface, and it breaks the moment a deploy is read-only or opcache holds the old file. The rules, in the order they matter: - A declared class with no record **boots**. Adding a line to the list is still all it takes, and a host that never installed anything never grows a state file. - A declared class the store says is disabled **does not boot**. - A record that is installed, enabled, and whose class resolves **boots**, even though nobody declared it — that is a plugin installed at runtime. - A record whose class does not resolve is skipped in silence: it is installed but not autoloadable yet, which is a composer problem and not a reason to take the whole boot down.

public static function from(array $declared, string $statePath): array

The effective list, ready to hand to `$config['plugins']`.

Parameters

public static function wire(Milpa\Interfaces\Di\DIContainerInterface $container, array $declared, string $statePath): array

Puts activation into a container and returns the list to boot — the one call a host makes, so the store the kernel booted from and the store the management operations write to cannot end up being two different files.

Parameters

public static function resolve(array $declared, Milpa\Plugin\Contracts\PluginRegistryInterface $registry): array

The same decision against any registry — the seam a host with a different store (a database, say) uses instead of {@see self::from()}.

Parameters