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.
|