84 lines
4.8 KiB
YAML
84 lines
4.8 KiB
YAML
decisions_log:
|
||
- question: What language and minimum version should the app target?
|
||
decision: PHP 8.4+
|
||
rationale: >
|
||
8.4 is as far back in PHP versions as we want to support; targeting a recent
|
||
minimum keeps the codebase modern instead of carrying compatibility baggage
|
||
for older, less-supported PHP versions.
|
||
- question: Should the backend use an existing framework (e.g. Laravel, Symfony) or a custom/home-brewed codebase?
|
||
decision: Laravel 13.x
|
||
rationale: >
|
||
Leveraging Laravel 13.x provides robust routing, authentication, service container,
|
||
and ecosystem packages that accelerate development and reduce maintenance burden.
|
||
- question: Which CSS framework should the UI be built on?
|
||
decision: Fomantic UI
|
||
rationale: >
|
||
Fomantic UI is an actively maintained fork of Semantic UI (which is no longer
|
||
maintained), and semantic class names are strongly preferred over
|
||
structural/utility class names for CSS.
|
||
- question: Which JavaScript approach/framework should the frontend use?
|
||
decision: >
|
||
Vue — but used specifically via its Components feature only (similar in spirit
|
||
to how Svelte components are used), not as a full-fledged SPA framework.
|
||
rationale: >
|
||
General preference for Vue over React or Angular. Svelte would also have been an
|
||
acceptable choice for a components-only approach, but Vue was the one picked.
|
||
- question: Which tool should manage PHP dependencies?
|
||
decision: Composer
|
||
rationale: Composer is the de facto standard package manager for PHP.
|
||
- question: >
|
||
Is SiteWeaverCMS intended to be self-hosted only for v1, or should the
|
||
"Multi-tenancy ready" note under `architecture` mean a hosted/SaaS offering
|
||
is also on the roadmap?
|
||
decision: >
|
||
Self-hosted only. Multi-tenancy has been removed from consideration entirely
|
||
(see `architecture.decisions_log`), so there is no hosted/SaaS offering on the
|
||
roadmap and no tenant-isolation/billing concerns to capture.
|
||
rationale: >
|
||
Once multi-tenancy was ruled out as an architectural direction, a hosted/SaaS
|
||
offering (which would require it) is ruled out along with it.
|
||
- question: >
|
||
When the "Automatic Basic Security Audits for Plugins" check fails (eval/exec/
|
||
remote code execution detected), what happens — is the ZIP upload rejected
|
||
outright, or is the plugin installed with an "Install - Error" status (as
|
||
implied by the Plugins List Page in `plugins_architecture`) for an Admin to
|
||
review?
|
||
decision: >
|
||
The upload is rejected outright, not installed with an "Install - Error" status.
|
||
Flow: the ZIP is unzipped, files are analyzed; if no security issues are found,
|
||
the plugin's migrations run and it is marked installed; if security issues are
|
||
found, the unzipped plugin files are immediately deleted and a
|
||
PluginSecurityException is thrown. The same audit and rejection flow applies to
|
||
Themes (throwing a ThemeSecurityException instead) — see
|
||
`plugins_architecture.decisions_log` and `themes_architecture.decisions_log`.
|
||
rationale: >
|
||
Files must be unzipped before they can be scanned, so a full "Install - Error"
|
||
list entry is unnecessary — a failed audit is treated as a hard rejection with
|
||
no trace left on disk.
|
||
- question: How will dependency injection be implemented in the app?
|
||
decision: >
|
||
Laravel's built-in service container will be used, following the framework’s
|
||
service provider pattern. This provides robust DI, lazy loading, and integration
|
||
with Eloquent, routing, and other core services.
|
||
rationale: >
|
||
Leveraging Laravel's container eliminates the need for a custom DI solution,
|
||
reduces boilerplate, and aligns with the ecosystem's conventions.
|
||
- question: What license (if any) will SiteWeaverCMS be released under (e.g. MIT, GPL, proprietary)?
|
||
decision: >
|
||
No public license for now — SiteWeaverCMS stays sole-ownership/proprietary. It
|
||
is being used to build client websites, with the clients themselves administering
|
||
the sites built for them; a public release/license may be revisited later.
|
||
rationale: >
|
||
Matches the current usage model (agency-built client sites) rather than a
|
||
publicly redistributable product, so there is no need to pick a license yet.
|
||
- question: >
|
||
Should a target audience/deployment size be stated up front, since it
|
||
influences caching, storage backend, and search decisions made later in the
|
||
spec?
|
||
decision: >
|
||
Yes — the initial target audience is self-employed business owners, small
|
||
craft makers, and small new bloggers, with room to grow toward larger sites
|
||
and capabilities over time.
|
||
rationale: >
|
||
Gives later caching/storage/search decisions a concrete initial scale to design
|
||
against, while leaving room to grow. |