Filament Simple Draft Laravel Package

Technical Evaluation

Architecture fit

• ronssij/filament-simple-draft is a Filament panel plugin that layers draft/publish state onto Eloquent-backed resources via a trait plus Filament actions. It sits inside the existing Filament admin surface rather than introducing a parallel UI, so it does not add a new architectural tier.
• Fit is strongest where the team already standardises on Filament for back-office CRUD and wants editorial "save without publishing" semantics without building a bespoke versioning layer.
• It is not a general-purpose versioning or content-modelling package: it governs publish state, not arbitrary revision history. Expect to pair it with the application's own audit/versioning story if compliance or rollback is required.

Integration feasibility

• Low integration surface: composer require, register the plugin on the target panel, add the trait and publish-state column to the relevant models, then opt individual resources in. Typical effort is hours per resource, not a migration programme.
• v1.2.0 widens filament/support to ^3.0|^4.0|^5.0. This is the first release that puts Filament v5 in scope, which matters if the roadmap includes upgrading the panel or adopting Livewire v4.
• The v5 verification (Filament v5.7.6 + Livewire v4.4.0) was performed by the maintainer, not independently by us. Treat it as vendor-asserted until reproduced in a spike.

Technical risk

• Single-maintainer dependency. Low bus factor and a small plugin footprint mean abandonment risk is real, but the blast radius is contained: the package is thin and forkable.
• Wide version constraint. Supporting ^3.0|^4.0|^5.0 simultaneously increases the chance of untested combinations. Our specific Filament minor version may not be in the maintainer's verification matrix.
• Ecosystem churn. Filament v5 and Livewire v4 are recent; the plugin's v5 support is one release old. Early-adopter risk is moderate and should be de-risked with a spike rather than assumed.
• Schema coupling. Draft state adds a column and query scoping to host models. Incorrect scoping is a data-exposure risk (unpublished content leaking to public queries), which is the most material technical risk and is ours to control, not the package's.
• No prior assessment exists. This is a baseline evaluation, so historical trend (release cadence, regression rate, issue response) is unknown and should be established before wider adoption.

Key questions

• Which Filament major are we on today, and is a v5 upgrade on the roadmap within the planning horizon? The answer determines whether v1.2.0's headline feature is load-bearing or merely future-proofing.
• Does the product need genuine revision history and rollback, or only a binary draft/published state? If the former, this package is a partial answer.
• What is our policy on single-maintainer packages for admin-surface functionality, and does this clear the bar?
• Who owns the query-scoping contract that prevents unpublished records appearing in public-facing reads?
• Is there an internal fork/maintenance plan if upstream goes quiet?

Integration Approach

Stack fit

• Requires a Laravel app running Filament with Livewire. Fits cleanly if Filament is already the admin framework; if Filament is only used in one corner of the estate, adopt there and do not extend it.
• Composer-native, no external services, no new infrastructure, no queue or scheduler dependencies. Operational footprint is effectively zero.
• Front-end/public delivery is out of scope: the package governs authoring state, so the public read path remains our responsibility.

Migration path

• Greenfield resources: add the trait and publish-state column at creation time.
• Existing resources: additive migration to introduce the draft column with a default of "published" so current rows retain behaviour; opt resources in one at a time behind a config toggle.
• No data transformation of existing content is implied. Rollback is a composer downgrade plus a nullable-column drop, which makes the change reversible.

Compatibility

• v1.2.0 claims Filament 3, 4 and 5 support. Verify against our pinned versions specifically, not the range in aggregate — Composer will resolve a combination, and only that combination is what we run.
• Livewire v4 is a livewire v3-to-v4 transition point for the wider app; sequence this package's evaluation with, not ahead of, the panel's Livewire posture.
• Existing Filament plugins in the panel should be checked for action/modal conflicts, since draft/publish typically injects header actions.

Sequencing

1. Baseline spike: install v1.2.0 on our current Filament version, apply to a single low-risk resource, confirm behaviours and query scoping.
2. If a Filament v5 / Livewire v4 upgrade is planned, repeat the spike on that combination before committing; the maintainer's verification is a signal, not a substitute.
3. Roll out resource by resource, starting with content types where draft state is genuinely editorial (marketing pages, policy docs) and avoiding anything with regulatory publication controls.
4. Establish the public-read scoping pattern and encode it in a shared base query before the second resource ships, not after.
5. Re-evaluate at the next minor release or at the point the maintainer's cadence becomes visible.

Operational Impact

Maintenance

• Low ongoing effort: version bumps are infrequent and the surface area is small. Budget a named owner for the public-read scoping contract, which is the part that can silently break.
• Pin the version in composer.json and let Renovate/Dependabot surface releases for review rather than auto-merging; a widened constraint is exactly the kind of change that can resolve differently on a future composer update.
• The README banner in v1.2.0 is cosmetic and carries no operational significance.

Support

• Upstream support is effectively one maintainer via GitHub issues. No SLA, no commercial backing. Internal first-line support must be able to read the plugin source, which is feasible given its size.
• Escalation plan should include forking: the package is small enough that a fork is a days-not-months proposition, which is the main mitigation for bus-factor risk.

Scaling

• Scales with the admin surface, not with traffic. Draft state adds a column and a scoping predicate; cost is negligible at typical admin volumes.
• Watch index performance if the publish-state column is used in frequent filters — an index on the draft/published column is a cheap precaution.
• Author concurrency on the same record is not a solved problem by this package; if multiple editors touch the same content, that is a separate concern (Filament's own conflict handling, or optimistic locking).

Failure modes

• Unpublished content leaking publicly — highest-severity failure; caused by missing scoping, not by the package. Mitigate with a shared scoping trait and a test asserting unpublished rows are excluded from public queries.
• Silent breakage on Filament upgrade — a Filament minor could change action or form APIs; the wide ^3|^4|^5 constraint means Composer will not protect us. Mitigate with a smoke test on the draft/publish flows in CI.
• Package abandonment — degrades to a frozen dependency; mitigated by fork readiness and the absence of transitive dependency sprawl.
• Divergent state on failed saves — draft writes that partially fail leave ambiguous editorial state; verify transaction behaviour in the spike.

Ramp-up

• Developer ramp-up is short — an afternoon to read the trait and actions and apply to one resource.
• Editorial ramp-up is the real cost: authors must understand draft vs published, and that "saved" is not "live". Budget a short comms/training note and, ideally, clear UI affordances so the distinction is visible at a glance.
• For the TPM: this is a low-cost, low-risk, reversible adoption with one genuine caveat (single maintainer) and one genuine obligation (public-read scoping). Recommend a scoped spike now, with a decision on wider rollout gated on that spike and on clarity about the Filament v5 timeline.