Filament Blog Laravel Package

Product Decisions This Supports

The "ship it and measure" bet on content-led growth. This package is the frontend half of a blog install: posts, categories, tags, slugs, and basic meta fields render as public Blade pages without commissioning custom CRUD, routing, or template work. The PM decision it enables is not "blog or no blog" — it's whether a blog moves a specific metric (organic sessions, signup attribution, launch-communications reach) fast enough to be worth funding properly. Define the success threshold before the spike, and be explicit that "we shipped it in a sprint" is not itself evidence the content strategy works.

Build vs. buy vs. assemble — this is "assemble." Content modeling and editorial workflow stay in tomatophp/filament-cms; presentation is borrowed here under MIT and overridden via Blade views. The honest framing for the roadmap conversation: two engineering weeks for a bespoke themeable blog, versus a two-day spike plus a documented fork/exit path. Spend the saved capacity on differentiators, not on a blog nobody has yet proven they read.

A forcing function for content-model scope discipline. The CMS/render split is the useful boundary. Requests for author bios, series groupings, reading time, or related-post rules should land as CMS fields — not as new Blade conditionals. Make that a standing acceptance criterion, because the failure mode is a second CMS with no admin, no owner, and no migration path.

A deliberate "not now" on decoupled delivery. Server-rendered Blade with route config (prefix, middleware, pagination, layout in config/filament-blog.php) is a decision against headless/omnichannel delivery for the current phase. Record the deferral in the decision log so it's a choice, not an accident — future mobile apps or syndication partners will re-open it.

Cheap, bounded surfaces worth greenlighting: marketing subdomain, release notes/changelog, internal content portal, founder/personal site, stakeholder demos — anywhere the team already runs Filament and the blast radius is a subdomain or feature flag.

What it explicitly does not buy you — scope these before they become sprint surprises: scheduled publishing, revision history, multi-language, granular roles/permissions, sitemap generation, RSS/Atom, canonical tags, redirects from old URLs, and structured data. All of those are application features you build. Scheduling alone is a published_at column, a scope, and a scheduled command — in the CMS layer.

When to Consider This Package

Adopt it when:

• The stack is already Laravel + Filament + TomatoPHP CMS Builder. Outside that stack the integration benefit collapses and this stops being a shortcut. It is a two-part install; installing the blog alone produces an afternoon of missing-table debugging, not a blog.
• The near-term need is small and conventional: editor-managed posts, categories, tags, slugs, basic SEO metadata, draft/publish. Modest design ambition that can be met through published view overrides in resources/views/vendor/filament-blog/.
• Engineering can own the dependency. Ten stars, zero dependents, single maintainer, no community changelog. Pin exact versions of both packages, treat Filament major upgrades as planned projects rather than routine bumps, and name the person accountable for upgrades and for forking if upstream stalls. Keep overrides thin — thinness is the actual insurance policy, because it keeps the exit a two-day rewrite instead of a two-month one.
• The blast radius is bounded: subdomain, pilot, or staging behind a flag. Not the revenue-critical primary domain.

Look elsewhere when:

• The team isn't on Filament/CMS Builder, or is on a different Filament major. Plugin registration, resource signatures, and form/table APIs break across majors, and fixes may not exist upstream yet.
• Requirements include mature editorial workflow — scheduling, revisions, localization, granular permissions, or vendor support with an SLA. None are evidenced here.
• The property is high-traffic or SEO-critical. You inherit slug and meta fields, not search infrastructure; canonicals, sitemap, feeds, redirects, and structured data are yours to build and maintain.
• Any untrusted or imported content reaches the editor without a sanitization story. Post bodies render unescaped — decide now whether that's trusted-staff-only or needs HTML sanitization on save, and write the one test that proves it.
• Content structure is expected to churn. If every quarter brings new content types and relationships, a thin single-maintainer frontend becomes a permanent tax; a first-party build or a better-supported CMS earns its cost.

Two checks before committing: run php artisan route:list | grep -i blog to confirm the public prefix doesn't collide with existing routes (change the package prefix in config, never rename your own routes), and do one end-to-end pass — create a post in the admin, hit the public URL, confirm it renders — before anyone opens a CSS file.

How to Pitch It (Stakeholders)

To executives: "This is a presentation layer we assemble, not a platform we buy. It gets a real, editor-managed blog live in days on a stack we already run, so we can test whether content actually drives traffic or signups before committing budget to a CMS program. The cost is bounded — MIT licensed, ~10 stars, one maintainer — so we pin versions, keep our customizations thin, and can replace it in about two days if upstream stalls. What it does not include is the expensive part of content operations: scheduling, revisions, localization, permissions, sitemap, feeds, and redirect strategy. If those are near-term requirements, the decision is a different, larger one, and I'd rather surface that now."

To engineering: "Two packages, not one — CMS first, then blog — with exact version pins on both and Filament majors treated as upgrade projects. Extension model is published view overrides, never edits to vendor/; vendor:publish --force will destroy our work, so it's off-limits after day one. Route prefix and middleware come from config, not from touching package routes. Public pages are cacheable Blade, invalidated on CMS model saved/deleted events via an observer in our app; draft preview sits behind auth with no-store so a preview never lands in a shared cache. We need one named owner and a one-page runbook: how to upgrade, how to test, which views we've overridden, who forks if upstream goes quiet. Also plan for the SEO and sanitization work the package doesn't do — that's real backlog, not polish."

The one-line version for a roadmap review: a low-cost option to get a testable content surface live this quarter, explicitly deferring headless delivery and mature editorial workflow, contingent on a named owner and a cheap exit.