Filament Content Builder Laravel Package

Product Decisions This Supports

• Conditional content delivery without custom code. The new visible() / hidden() methods on blocks let editors and developers gate a block's rendering on runtime conditions (feature flags, user role, locale, schedule, A/B cohort). This turns "hide this section for logged-out users" from a custom Blade conditional into a declarative, per-block configuration — a feature-level decision that reduces bespoke view logic in the CMS layer.
• Roadmap input for a page/block builder. If you are scoping or evolving a block-based content system, this release confirms the package is trending toward render-time block control rather than schema-only blocks. That is a signal for sequencing roadmap items such as scheduled publishing, segment-targeted landing pages, and per-market content variants.
• Build vs. buy. The feature set (blocks plus conditional visibility) covers a meaningful slice of what a headless CMS or a commercial page-builder would charge for. Evaluate the remaining gaps — revision history, editorial workflow/approvals, block-level permissions, preview environments — as the true buy-vs-build delta.
• Use cases to validate first: marketing landing pages with audience-targeted sections, gated content behind entitlements or paywalls, seasonal/embargoed announcements, and gradual rollouts of new page sections behind flags.
• Risk triage. This is a minor, additive release. No breaking changes, no deprecations, and the dependency churn is confined to CI/release tooling plus removal of a field-library dev dependency. No migration or regression budget required, so it should not displace committed roadmap work.

When to Consider This Package

Adopt when:

• You are on Laravel and already use (or plan to use) Filament for admin, and you want editors composing pages from discrete, reusable blocks instead of hand-built Blade templates.
• You need per-block visibility conditions and would otherwise write one-off conditionals scattered across views.
• Your team is small and you would rather own a thin, auditable package than integrate a heavyweight external CMS.
• You can pin versions and absorb minor upgrades — the dependency and CI churn in this release is routine, and the maintainer is actively trimming unused dependencies, which is a healthy maintenance signal.
• You accept that conditional visibility is presentation-layer control; it is not a substitute for authorization or data-level access control.

Look elsewhere when:

• You require enterprise editorial workflow (multi-stage approvals, comments, audit trails), formal content modeling standards, or vendor SLAs — a commercial CMS or a dedicated content platform is the safer buy.
• Your content surface is highly structured/relational rather than page-compositional; blocks add indirection you will fight.
• You are not on Filament and have no appetite for its admin conventions — the coupling cost outweighs the benefit.
• You cannot tolerate a single-maintainer package in a long-lived, business-critical path without a fork/vendoring plan.
• Blocks are expected to drive security-relevant gating; visibility helpers should not be trusted as the enforcement boundary, so plan server-side checks regardless of package choice.

How to Pitch It (Stakeholders)

For executives: A small, low-risk upgrade to our page-building toolkit adds the ability to show or hide individual content blocks at render time — the mechanism behind audience targeting, scheduled content, and flag-gated rollouts of new page sections. It is a minor version with no breaking changes and no deprecation risk, so there is no migration cost and no impact to current delivery commitments. The strategic value is optionality: this capability covers a share of what a licensed CMS or page-builder would charge for, and it lets marketing and content teams ship segmented pages without engineering tickets. The open decision is not whether to upgrade — it is safe to do so — but whether we invest further in this package versus buying a managed CMS; the deciding factors are editorial workflow and audit requirements, not content composition.

For engineering: Purely additive release. New visible() / hidden() methods on blocks give a declarative hook for render-time conditionals, replacing ad-hoc Blade branching and centralizing the logic where blocks are defined. Everything else is housekeeping: Dependabot bumps to release-drafter and setup-php, and removal of van-ons/filament-field-library, which is a dependency-surface reduction rather than a behavior change. Action: bump the constraint, run the suite, add a test asserting hidden blocks do not render and that conditions are evaluated per-request rather than cached. Two guardrails worth stating explicitly: visibility is not authorization, so entitlement and role checks still belong in policies and queries; and any condition depending on request state needs coverage for cached responses so blocks are not inadvertently baked into a shared cache.