40 lines
2 KiB
YAML
40 lines
2 KiB
YAML
decisions_log:
|
|
- question: >
|
|
Should the same Automatic Basic Security Audit that applies to Plugins also
|
|
apply to uploaded Themes and to any file saved via the in-place Theme Editor,
|
|
given that `theme.md`/`layout.php`/partials can contain arbitrary PHP?
|
|
decision: >
|
|
Yes — the same security audit used for Plugins (no eval, no exec, no remote
|
|
code execution) also applies to Themes, both on ZIP upload and on files saved
|
|
via the in-place Theme Editor. The only difference from the plugin flow is that
|
|
a failed audit throws a `ThemeSecurityException` instead of a
|
|
`PluginSecurityException`.
|
|
rationale: >
|
|
Themes can contain just as much arbitrary PHP as Plugins (`theme.md`,
|
|
`layout.php`, partials), so leaving them unaudited would be an inconsistent
|
|
security gap.
|
|
- question: >
|
|
Should theme files be versioned/backed up before each save through the Theme
|
|
Editor, so an accidental bad edit can be reverted without needing the full Site
|
|
Restore feature?
|
|
decision: >
|
|
Yes — versioning is implemented on each Theme Editor save (see the "Theme
|
|
Editor File Versioning" note above).
|
|
rationale: >
|
|
Gives a lightweight, per-file undo path for editor mistakes instead of forcing
|
|
a full Site Restore for a single bad save.
|
|
- question: How will theme assets be handled?
|
|
decision: >
|
|
Theme assets (CSS, JS, images) will be served directly by the web server,
|
|
with support for versioning to prevent caching issues.
|
|
rationale: >
|
|
Direct serving of assets provides better performance than PHP-based serving
|
|
while still allowing for proper version management.
|
|
- question: How will theme customization be implemented?
|
|
decision: >
|
|
Themes will include a built-in editor that allows direct modification of
|
|
template files through the admin interface.
|
|
rationale: >
|
|
This provides an easy way for users to customize their themes without needing
|
|
to modify files directly on the server.
|