58 lines
3.3 KiB
YAML
58 lines
3.3 KiB
YAML
|
decisions_log:
|
||
|
|
- question: Should Composer-based installation of plugins be supported alongside ZIP upload?
|
||
|
|
decision: >
|
||
|
|
No — Composer installation of plugins has been removed, at least for v1. The
|
||
|
|
only installation process now is ZIP file upload.
|
||
|
|
rationale: >
|
||
|
|
Keeps a single, admin-friendly install path consistent with the "even a non-tech
|
||
|
|
person finds inviting" goal in `app`; CLI/Composer access isn't assumed to be
|
||
|
|
available to site admins.
|
||
|
|
- question: >
|
||
|
|
What is the resolution path when the Automatic Basic Security Audit rejects a
|
||
|
|
plugin — is the upload blocked outright, or installed with an "Install - Error"
|
||
|
|
status (as implied by the Plugins List Page) for the Admin to inspect further?
|
||
|
|
decision: >
|
||
|
|
The upload is blocked outright. Since the upload has to finish before the
|
||
|
|
system can unzip and inspect its contents, the flow is: the ZIP is unzipped,
|
||
|
|
files are analyzed; if no security issues are found, the plugin's migration
|
||
|
|
files run and the plugin is marked installed; if security issues are found,
|
||
|
|
the unzipped plugin files are immediately deleted and a PluginSecurityException
|
||
|
|
is thrown. There is no "Install - Error" status resulting from a failed
|
||
|
|
security audit — that status is reserved for other install-time errors (e.g. a
|
||
|
|
migration failure).
|
||
|
|
rationale: >
|
||
|
|
A plugin that fails the security audit should leave nothing installed or
|
||
|
|
listed; only errors unrelated to security (e.g. a broken migration) warrant
|
||
|
|
surfacing an "Install - Error" entry for the Admin to inspect.
|
||
|
|
- question: >
|
||
|
|
Is there a plugin dependency/versioning mechanism (e.g. a required core version,
|
||
|
|
or dependencies between plugins) that needs to be declared in `plugin.md`?
|
||
|
|
decision: >
|
||
|
|
Yes — a Core Version dependency is declared in `plugin.md` (added to its
|
||
|
|
required metadata list in `directory_structure`), mirroring the same field
|
||
|
|
already present in `theme.md`/`admin.theme.md`.
|
||
|
|
rationale: >
|
||
|
|
Lets the install process reject a plugin that requires a newer core version
|
||
|
|
than what's installed, consistent with how themes already declare a Core
|
||
|
|
Version.
|
||
|
|
- question: What approach will be used for plugin installation?
|
||
|
|
decision: >
|
||
|
|
Plugins will be installed as ZIP files that are extracted to a plugins directory,
|
||
|
|
with the plugin's service provider registered automatically.
|
||
|
|
rationale: >
|
||
|
|
This approach provides a simple and familiar installation process for users
|
||
|
|
while ensuring proper service registration through the DI container.
|
||
|
|
- question: How will plugin dependencies be handled?
|
||
|
|
decision: >
|
||
|
|
Plugins can declare their dependencies in their metadata files. The plugin
|
||
|
|
manager will handle loading plugins in the correct order based on dependencies.
|
||
|
|
rationale: >
|
||
|
|
This ensures that required services are available when a plugin is loaded,
|
||
|
|
preventing runtime errors.
|
||
|
|
- question: How will plugin configuration be handled?
|
||
|
|
decision: >
|
||
|
|
Each plugin can register its own configuration settings, which will be
|
||
|
|
automatically merged with the main configuration system.
|
||
|
|
rationale: >
|
||
|
|
This allows plugins to maintain their own settings while integrating cleanly
|
||
|
|
with the core configuration system.
|