generated from bisco/codex-bootstrap
bisco
61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
# ADR-0001: WordPress single-page architecture
|
|
|
|
Date: 2026-06-24
|
|
|
|
Status: Accepted
|
|
|
|
## Context
|
|
|
|
Azione!Lab needs a warm editorial single page whose primary content can be edited by
|
|
non-developers. This branch explicitly explores WordPress as an alternative product
|
|
architecture and starts independently from `main`.
|
|
|
|
## Decision
|
|
|
|
Use pinned WordPress 7.0/PHP 8.3 with MariaDB 11.8 LTS. Build a dependency-free custom
|
|
classic theme for exact semantic markup and responsive design. Store homepage fields as
|
|
sanitized theme modifications, while a must-use plugin owns Shows and Gallery custom
|
|
post types so structured content is not lost when changing themes.
|
|
|
|
NGINX is the only public entry point. WP-CLI provides an idempotent opt-in bootstrap;
|
|
Certbot provides opt-in direct TLS. Docker networks isolate the database. Runtime state
|
|
uses host-based bind mounts with a preparation script for ownership/mode, while
|
|
functional tests use separate Docker volumes.
|
|
|
|
## Consequences
|
|
|
|
- Editors use familiar WordPress screens without a page builder or required plugin.
|
|
- WordPress renders the page directly; there is no headless API/frontend deployment.
|
|
- WordPress and MariaDB replace Astro, Wagtail, Django, and PostgreSQL in this branch.
|
|
- Core/theme/plugin patches require an image rebuild in production.
|
|
- Fixed participation cards remain code until editorial requirements justify another
|
|
structured content type.
|
|
|
|
## Alternatives considered
|
|
|
|
- A block theme was not selected because the first version prioritizes controlled
|
|
markup and a compact implementation over full-site editing.
|
|
- A commercial/custom-fields plugin was rejected as an unnecessary dependency.
|
|
- A headless WordPress frontend was rejected because it would recreate the operational
|
|
complexity this variant is intended to remove.
|
|
|
|
## Security impact
|
|
|
|
The architecture inherits WordPress's public CMS attack surface. The implementation
|
|
reduces it with network isolation, no direct application port, disabled file editing
|
|
and XML-RPC, production immutability, sanitization/escaping, rate limiting, security
|
|
headers, and fail-closed TLS. Admin MFA and allowlisting remain external controls.
|
|
|
|
## Operational impact
|
|
|
|
Database and WordPress files are coordinated state and must be backed up together.
|
|
Host bind-mount paths must be permissioned for the image users before startup.
|
|
Operators must monitor upstream security releases and rebuild pinned images. SMTP and
|
|
off-host storage are not part of this minimal base.
|
|
|
|
## Rollback
|
|
|
|
Revert the implementation commit and rebuild. Preserve the configured WordPress,
|
|
database, and certificate host directories unless data deletion is intentional. Restore
|
|
data only from a verified coordinated backup.
|