Filament Simple Draft Laravel Package

Product Decisions This Supports

• Build vs. buy for editorial workflow. This package covers a narrow, well-defined slice of content operations — a simple draft/publish state on Filament resources — so it lets you defer a custom implementation decision until you actually need versioning, multi-stage approval, or scheduled publishing.
• Admin panel roadmap sequencing. If your roadmap includes "content goes live only after review," this is a cheap way to ship that milestone now and revisit authoring UX (preview links, diffing, revision history) as a separate, better-scoped bet.
• Compatibility and platform upgrade planning. The v1.2.0 release widens the filament/support constraint to ^3.0|^4.0|^5.0, which removes a blocker for teams planning a Filament 4 → 5 and Livewire 4 migration. That makes adoption viable for teams that would otherwise have to wait or fork.
• Risk budget allocation. Single-maintainer, small-surface dependency for a non-differentiating capability — a reasonable place to accept vendor risk in exchange for speed, provided you keep the integration thin enough to replace.
• Use cases it fits: internal tools and marketing/admin panels where editors need a "save without publishing" toggle; MVPs where the alternative is is_published boolean sprawl across resources.

When to Consider This Package

Consider it when:

• You are on Filament 3, 4, or 5 and need a lightweight draft/publish toggle rather than a full CMS.
• You want a Filament-native plugin with no separate service, no external content store, and no schema-heavy migration footprint.
• You are actively planning or evaluating a Filament 5 / Livewire 4 upgrade — the widened constraint and the maintainer's verification against Filament v5.7.6 + Livewire v4.4.0 is exactly the evidence you want before committing.
• You can keep the integration shallow (a trait, a column, an action) so that swapping it out later is a day of work, not a quarter.

Look elsewhere when:

• You need revision history, side-by-side diffs, editorial approval chains, role-gated publish permissions, or scheduled/embargoed publishing. These are the features that turn a plugin decision into an architecture decision — budget for a bespoke build or a fuller content platform instead.
• You need localized drafts or per-locale publish state.
• Your procurement process requires a support contract, SLA, or a maintainer with bus-factor mitigation.
• You are on Filament 2.x or pinned below the supported constraints.

Release-specific read on v1.2.0: this is a compatibility and hygiene release. The constraint widening is forward-compatible and low-risk; the maintainer explicitly reports no plugin code changes were required because Filament 5's changes are concentrated in Livewire 4 support rather than the Filament API surface. The README banner is cosmetic. Net: no new product capability, but a meaningful reduction in upgrade risk and a positive signal that the maintainer tracks upstream Filament releases. Treat it as maintenance health evidence, not as a feature justification.

How to Pitch It (Stakeholders)

For executives: We can add a review-before-publish safeguard to our admin panel with a small, free, open-source add-on instead of building it. It keeps content mistakes out of production without committing us to a CMS migration or a paid platform. Because it's a thin layer we can remove, the downside is limited to the cost of the integration itself — and the latest release confirms it already works with the Filament version we're moving to, so it doesn't create an upgrade dependency.

For engineering: A Filament plugin adding simple draft/publish handling to resources. v1.2.0 widens filament/support to ^3.0|^4.0|^5.0 and was verified against Filament v5.7.6 with Livewire v4.4.0; the maintainer reports zero plugin code changes were needed, since Filament 5's deltas sit in the Livewire 4 support layer rather than the Filament API. Adoption is a composer constraint plus a trait/action per resource. Keep the integration behind a thin abstraction so a future move to a full revision/approval system is a contained refactor. Watch items: single-maintainer project, small contributor base, and no built-in versioning or approval chains — if the roadmap calls for either, we should scope a build rather than stretch this package.