Laravel Filament Publishable Laravel Package

Product Decisions This Supports

• Scheduling content lifecycle features: Any roadmap item involving draft → scheduled → published → expired states (blog posts, announcements, landing pages, product visibility, help-center articles) has an admin-UI portion that this package largely collapses into a Composer install. It surfaces an existing state machine in Filament; it does not define the lifecycle — so it informs effort and scope, not strategy.
• Build vs. buy for the admin surface: The build option is four form fields, a table column, a status filter, a bulk action, plus translations, validation, and authorization glue. The buy option is composer require. The hinge is not this package — it's whether the team has already committed to novius/laravel-publishable as the model-level trait. If yes, buying is straightforward. If no, evaluate the pair, not the package alone: adopting this means adopting that too.
• Roadmap sequencing and resourcing: Adoption is incremental — form fields first, then column and filter, then bulk actions, one resource at a time. That makes it a contained sprint item with a stop/go gate, not a migration or replatforming bet. It's suited to a current-cycle slot, not a quarterly commitment.
• Standardization decision: Choosing it sets a convention — publication semantics live in one trait plus one set of Filament components across every content resource. That reduces per-resource drift and design churn, but locks in a pattern the team must follow and a version coupling they must maintain through Filament/Laravel upgrades.
• Buy-vs-extend boundary: Conventional publishing UX is covered (status fields, published/expired dates, status column, status filter, bulk publish/unpublish, translations). Anything richer — approval chains, editorial roles, role-gated publishing, publish-triggered notifications/webhooks/cache invalidation, audit trails, per-record feedback on bulk partial failures — is extension work. Budget it explicitly in the estimate rather than assuming coverage.
• Risk and compliance triage: AGPL v3 is a gating product decision, not an engineering detail. For a proprietary or distributed SaaS product it can be a hard blocker; for internal-only tooling it may be acceptable. That single question can kill or unlock the initiative before any sprint time is spent — resolve it first.
• Maturity/risk triage for a low-signal dependency: 4 stars, 0 dependents, single maintainer, no commercial support. This is not a reason to reject, but it is a reason to treat adoption as a pilot-with-exit-plan rather than a platform commitment, and to price the exit (roughly ~100 lines of custom Filament components against the same trait) into the decision.

When to Consider This Package

Adopt when all of these hold:

• Target models already use — or the team has decided to adopt — novius/laravel-publishable, with publication_status / published_at / expired_at columns in place.
• The admin panel is Filament 4+ on Laravel 11+ / PHP 8.2+.
• The desired publishing UX is conventional: status, publish date, expiry date, status column, status filter, bulk publish/unpublish.
• Publishing controls are table stakes for your admin rather than a differentiator, so pre-built components beat hand-rolled ones.
• Legal has cleared AGPL v3 for your distribution model, or the product is internal/open-source.

Look elsewhere — or build in-house — when:

• The product needs editorial workflow beyond state toggles: approval chains, multi-step review, role-gated publishing, audit trails. You are writing that logic regardless, and the package buys you only the basic status UI.
• The stack is below the hard floors (Filament < 4, Laravel < 11, PHP < 8.2) and upgrading is not on the roadmap.
• AGPL v3 is incompatible with your distribution model and cannot be signed off.
• The team is not prepared to pin the dependency and treat Filament majors as coordinated upgrades that include a compatibility check.
• You need vendor support, SLAs, or a maintainer relationship — none of that exists here.

Treat as a pilot, not a platform commitment: validate on one low-risk resource and keep a thin local wrapper (App\Filament\Components\Publish\* extending the package components) so replacement is a one-directory swap rather than a search-and-replace across every resource. The wrapper costs roughly 30 lines and buys replacement optionality — that is the cheapest risk mitigation in the whole plan.

How to Pitch It (Stakeholders)

To executives — one paragraph: For any content in our admin panel that needs a draft/published/expired lifecycle, this package lets us ship the publishing UI — status fields, a status column, a filter, and bulk publish/unpublish — by installing a library instead of building it. It is a bounded, revertible change: pilot on one resource, measure, then decide on wider rollout. The two things we need from leadership before code starts are (1) legal sign-off on the AGPL v3 license, which can be a hard blocker for proprietary or distributed products, and (2) acceptance that this is a small, single-maintainer dependency we will wrap and pin rather than standardize on blindly. The exit cost is low — roughly an afternoon of custom Filament work per the same integration points — provided we do the wrapper.

To engineering — framing and the ask: This is a UI adapter, not a library. It binds Filament components to the novius/laravel-publishable trait; the state machine, scopes, and timezone semantics live in the parent. Before committing, we need a short spike on one resource to (a) verify the component class names and the column arguments — the README ships two real bugs, a wrong column on PublishedFirstAt and a stale Nova-era provider class name, so src/ is the source of truth; (b) confirm the bulk action's behavior under load — per-record saves vs. single update, event dispatch, transaction wrapping, partial-failure feedback; (c) establish a policy convention for role-gated publishing, since the package ships none. We then roll out form fields → column → filter → bulk action per resource, behind a thin local wrapper so a swap is contained if the maintainer disappears or licensing fails.

The decision in one line: low cost to adopt, low cost to reverse, real value if we already need publishing state in Filament — but gated on AGPL clearance and treated as a wrapped pilot, not a platform bet.