Statamic Preference Center Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic/Laravel addon that until now had no Control Panel surface at all — four public routes plus a config/preference-center.php file. v1.8.0 introduces a CP settings section (Settings → Addon Settings) with 15 values across five groups: Magic link, Throttling, Sender, page blocks, and Audit trail. The critical architectural detail is that it stores only deviations and continues to inherit everything else from the config file. That is the right model for a package that must stay upgrade-safe and multi-brand aware, and it keeps the config file as the deployable source of truth.

Integration feasibility. Moderate, and gated by one hard dependency: goldnead/statamic-brand-context ≥ 1.13. The package also ships a new permission, manage preference-center settings, granted to nobody by default. That is a deliberate, defensible rollout gate but it converts "feature shipped" into "feature invisible until an admin acts," which is a support-ticket generator unless communicated.

Technical risk.

1. Silent override loss on older brand-context. Up to 1.12, a second save of the same section deleted the first save's override without any message, and on single-brand installs the settings of last-registered addons never reached config. Anyone who set values before this release must verify them afterwards. This is the highest-severity item in the release: a UI that accepts input and does not persist it is worse than no UI.
2. Security-sensitive knobs are now one click deep. "Links to unknown addresses" is an open mail sender with extra steps; the per-origin throttle is what prevents the endpoint being used to mail a list the operator doesn't own; the response-time floor is an account-enumeration mitigation, not a polish item. Exposing these to a UI widens the blast radius of a misconfiguration. The permission default-off is the only guardrail described — no confirmation step, warning, or capability split is mentioned.
3. Two-tier effectiveness. routes.enabled, routes.prefix, routes.middleware and the marketing-block source switch are read at route-creation time, so they are correctly excluded. But this means some settings require a deploy and some take effect immediately. Operators will conflate the two, and the resulting "I changed it and nothing happened" class of incident is guaranteed unless documented loudly.
4. Excluded settings have consequences. delivery.mail_headers and delivery.ignored_query_parameters belong to the provider protocol; audit.log_channel stays host-owned because a free-text field is one typo from an audit trail writing nowhere. Sound reasoning, but it means audit integrity depends on host-side log configuration the package does not control.
5. Lint baseline fix is contributor-only, zero runtime risk. It does signal that the project maintains a lint baseline, which is a modest positive quality indicator.

Key questions.

• Where are the overrides persisted (database, JSON, flat file)? Are they per-brand and per-site, and do they survive addon upgrades?
• Does the settings surface validate inputs — throttle of zero, absurd session lifetimes, malformed sender addresses, negative response-time floors?
• Is "to unknown addresses" protected by anything beyond default-off (confirmation, separate capability, warning copy)?
• What backs the throttle counters — cache, Redis, database? How do they behave across multiple web nodes, and is the failure mode open or closed when the store is unavailable?
• Is brand-context ≥ 1.13 a hard Composer constraint, or a runtime check that only produces a notice?
• Is there an export/import or config-cache path so overrides can be promoted staging → production, or is the CP the only way to set them?
• Which roles can receive the new permission, and is it grouped so it is discoverable in the permission list?
• Does the package's own throttling complement or duplicate edge/infrastructure rate limiting?

Integration Approach

Stack fit. Native for Laravel + Statamic shops already using brand-context. The package is additive: no CP screen of its own, no new routes, no schema migration called out. It occupies the same conceptual slot as other Statamic addon settings and inherits the brand identity the host already establishes.

Migration path. Ordered, not parallel:

1. Raise goldnead/statamic-brand-context to ≥ 1.13 first, then the addon. Reversing this — or leaving brand-context stale — produces exactly the failure the notes describe: the page renders, the save appears to succeed, the values do not apply.
2. Upgrade the package and clear config/route caches, since a subset of settings are baked in at route registration.
3. Re-verify every override that existed before the upgrade, per brand. Treat this as a required checklist item, not a sanity check.
4. Grant manage preference-center settings to a named role; confirm the section appears for that role and stays hidden for others.

Compatibility. Brand-context 1.13 is a hard floor. The failure mode on older versions is the worst kind — UI present, writes unreliable — so the constraint should be enforced in composer.json, not in prose. Confirm the package's PHP, Laravel, and Statamic version bands against the fleet, plus whether the statamic-brand-context requirement pulls any transitive upgrades.

Sequencing across environments. Because overrides live in storage rather than in Git, they are invisible to code review and do not travel with a deploy. Establish a staging-first pass that exercises a multi-brand scenario (the bug class in ≤1.12 was brand-dependent), then production with the permission limited to a small admin role for the first week.

Config-vs-CP ownership. Publish an explicit matrix: which settings are CP-managed, which are config-only and require a deploy, and which are host-owned (audit.log_channel, mail-provider headers). Without it, the team will split settings across two places inconsistently and debug the wrong layer.

Operational Impact

Maintenance. The package graduates from "config file you set once" to "product surface with a settings page." Fifteen values, five groups, one permission, one dependency floor — modest, but it is now something that has to be reviewed on every upgrade rather than something that quietly sits there. The deviation-only storage model keeps the maintenance burden low; the brand-context dependency is the main ongoing exposure.

Support. Expect three ticket archetypes and pre-write the runbook entries:

• "The settings section doesn't exist" → permission not assigned.
• "I changed a setting and nothing happened" → a boot-time or excluded value (routes.*, marketing-block source, mail headers, log channel).
• "My overrides vanished" → brand-context below 1.13, or the second-save deletion bug.

Scaling. Two things to size before broad rollout. The per-origin throttle is the control that stops the endpoint being used to mail a third party's address list — verify the counter store is shared across all web nodes, or the limit is per-node and effectively multiplied by fleet size. The response-time floor adds deliberate latency to every magic-link request; that is a constant cost in the request budget and should be measured under expected peak load, not assumed.

Failure modes.

• Rate-limiter or cache backend unavailable: behaviour must be known in advance — fail-open exposes an unmetered mail endpoint, fail-closed locks out legitimate users.
• "Unknown addresses" enabled: the endpoint becomes an open mail sender, throttled only by the second counter.
• Sender misconfiguration: deliverability and DMARC problems that surface as user complaints, not errors.
• brand-context regression: overrides silently stop applying, with no error and no log line.
• Audit channel retargeted on the host: audit reporting survives in the UI but writes nowhere useful.
• Operator changes a boot-time value in the CP (not possible by design, but they will try elsewhere) and expects immediate effect.

Ramp-up. Small and well-bounded. Administrators need a one-page guide covering the five groups, the permission, and — emphasised — the two security-sensitive toggles and the difference between immediate and deploy-time settings. Engineers need the config-vs-CP matrix and the list of values read at boot. Half a day of admin enablement plus a short runbook section is proportionate.

Recommendation. Adopt. The release turns an opaque .env-only addon into something an operator can actually govern, which is a genuine reduction in operational risk — provided the brand-context floor is enforced in Composer, existing overrides are verified post-upgrade, the new permission is granted narrowly at first, and "links to unknown addresses" stays off.