Filament Consent Control Laravel Package

Technical Evaluation

Assessment: conditional pilot — low blast radius, non-trivial compliance exposure. v0.1.0 is an optional admin convenience layer, not a required dependency. The core message ("a single config file is still all you need") means adoption risk is capped: if the plugin proves immature, you drop it and keep the underlying runtime. That materially lowers the cost of trying it. What raises the stakes is the domain — consent gating is a legal control, not a UI nicety. A silently ungated embed is a compliance incident, so immature tooling in this path deserves more scrutiny than its 0.1.0 version number alone would suggest.

Architecture fit. Three-layer stack: consent-control (npm runtime, browser), laravel-consent-control (PHP/Laravel integration, auto-pulled), and this package (Filament v5 admin surface). The separation is sensible — presentation/admin concerns are isolated from the consent decision logic, and the npm runtime remains the single source of truth for gating behaviour. The data-src blocked-markup pattern is the standard, correct approach: content is inert in the DOM until the runtime hydrates it post-consent. Fits a standard Laravel + Filament panel with no bespoke infrastructure.

Integration feasibility. Straightforward for a team already on the target stack: composer require, two vendor:publish calls, plugin registration. Registration is a no-op until opt-in, so the install itself is inert — you can ship the dependency and enable features later. Requirements are strict but coherent: PHP 8.2+, Laravel 11.28+/12, Filament 5.

Technical risk.

• Filament 5 coupling. Built against the v5 Schema API, itself new. Third-party plugins tracking a young major version's internal API are the most likely thing to break on a patch release. This is the primary maintenance risk.
• Odd Laravel floor (11.28+). A specific patch-level minimum usually signals reliance on a mid-cycle fix. It also means panels on Laravel 11.0–11.27 are blocked for reasons not obvious from the notes.
• Single-maintainer, pre-1.0. Semver below 1.0 permits breaking changes on minor bumps. No stated support window, deprecation policy, or CI/test coverage.
• A "Fixed" section on a first release implies the package was extracted from a larger working tree and that the RichEditor action had a JS/PHP command mismatch. Good that it is called out and reconciled (setConsentIframe), but it confirms the editor integration is the least-settled surface — and an asset/markup version skew is precisely how that class of bug recurs.
• Bypass risk. Gating applies to content authored through the plugin's editor action. Raw HTML source paste or legacy content in the same field is not inherently gated. This needs explicit editorial policy, not just a package install.
• Legal defensibility. The package gates embeds; it does not appear to address consent record-keeping/audit. If your DPA or counsel expects provable consent logs, that is your build, not theirs.

Key questions for the maintainer / your own team.

1. License and support expectations — is there any commitment, or is this best-effort?
2. Test coverage and CI matrix for the Filament 5 Schema API surface; what is the upgrade policy across Filament 5.x minors?
3. Why Laravel 11.28+ specifically — which fix is required, and what fails on 11.0–11.27?
4. Are package assets versioned/cache-busted on release, or does every upgrade require a manual re-publish?
5. Does ConsentControlPlugin::make()->settingsPage() with the eloquent driver publish a migration, and is the settings read cached (and invalidated on save)?
6. Does the runtime handle consent withdrawal — re-blocking already-hydrated iframes in an open page?
7. Multi-tenant panels: are settings global, per-panel, or per-tenant?
8. No-JS / CSP posture: what does a visitor see if the runtime fails to load, and does youtube-nocookie pass your Content-Security-Policy?

Integration Approach

Stack fit. Only viable if your admin panel is Filament 5 on Laravel 11.28+/12 and PHP 8.2+. On Filament 3/4 this is a hard no — no backport path exists, and none is signalled. For teams already on the target stack, fit is clean: it is a panel plugin plus an editor action plus an optional settings page, all opt-in.

Migration path. Two distinct migrations:

• Package: add the Composer dependency and register the plugin with no features enabled. This is a zero-behaviour-change step and should be treated as such — it proves install/publish/asset pipeline before anything depends on it.
• Content: existing iframes in RichEditor fields are almost certainly raw <iframe> markup and will not be gated. Stored content must be re-authored through the plugin (or scripted into the data-src / .consent-message--wrapper shape) before you rely on gating. Budget for a content audit, not just a deploy.

Compatibility. Pin Composer constraints narrowly (exact minor on the Filament plugin, caret on the base package) and treat every upgrade — including patch releases — as a change requiring a staging smoke test of the editor and the render path. Verify the npm runtime version actually shipped to the browser matches the PHP-side expectations; the fixed JS/PHP command mismatch is the canary.

Sequencing.

1. Spike in a throwaway branch: install, publish config + assets, register plugin inert, confirm panel boots.
2. Enable settingsPage() in staging against a non-production DB; confirm migration, caching, and permission behaviour.
3. Enable the RichEditor consent-iframe action in one low-traffic content type only.
4. Author a small set of test embeds (YouTube, Vimeo, Maps); verify blocked markup in the DB, blocked render pre-consent, hydrate on consent, and correct behaviour on consent withdrawal.
5. Content audit + migration for existing embedded media.
6. Editorial guidance and a lint/review rule preventing raw iframe paste.
7. Production rollout per panel.

Operational Impact

Maintenance. You inherit a three-package dependency chain with three release cadences, on top of a young Filament major. Realistic ongoing cost is small but recurring: someone must watch releases, re-publish assets, and re-test the editor after each Filament or plugin bump. At v0.1.0 expect at least one breaking change before 1.0; do not float the version constraint.

Support. Best-effort upstream, no SLA. Compliance questions ("is this enough for GDPR/ePrivacy?") will land on your team regardless of what the package does. Assume you own the audit trail, consent-record retention, and any counsel sign-off; scope the package as a UI facilitator only.

Scaling. Server-side load is negligible — settings reads plus editor saves. Two things to watch:

• Page caching: gating is client-side, so cached HTML is safe to serve to everyone, but do not start varying cache keys by consent state or you will fragment your cache for no benefit.
• Settings writes: if the eloquent driver backs the settings page, ensure reads are cached and invalidated on save; a per-request settings query in the render path is an avoidable cost on high-traffic pages.

Failure modes (ranked by consequence).

1. Ungated embed reaches production — via raw HTML paste, legacy content, or a save that wrote the iframe without data-src. Highest severity; mitigate with content audit and a review rule.
2. Asset/JS version skew after upgrade — the exact bug this release fixed. Symptom: markup renders but never hydrates, or gates never release. Mitigate by making asset re-publish a mandatory post-upgrade checklist step and testing the editor in staging every time.
3. Filament minor bump breaks the Schema API — editor action or settings form silently fails to render. Contained to admin UX; caught by a smoke test.
4. Runtime JS fails to load — fails closed for privacy (no third-party requests) but the visitor sees a dead placeholder. Acceptable, but the placeholder should be informative and accessible.
5. Stale settings after a save — consent copy/behaviour lags behind what an admin configured. Low severity, high confusion; verify cache invalidation in the spike.

Ramp-up. Low for a Filament-fluent developer: roughly half a day to the end of step 4 in the sequencing above, plus the content audit, which is editorial effort rather than engineering and is usually the real cost. Two audiences need briefing: developers (upgrade ritual: composer update → re-publish assets → smoke test editor) and content editors (always insert embeds via the RichEditor action, never paste raw iframe HTML). Absent a documented path for the second, assume it will be violated.