Filament Blog Laravel Package

Technical Evaluation

Architecture fit. This is not a blogging engine — it is the presentation layer of a two-part install. tomatophp/filament-blog supplies the public-facing Blade routes and templates; tomatophp/filament-cms owns the content model (posts, categories, tags, media, SEO fields). That split is the single most important architectural fact for planning. It fits cleanly only when the team is already on Laravel + Filament + CMS Builder. Outside that stack, the value proposition collapses: you inherit a coupling to a 10-star package to avoid writing maybe two weeks of CRUD and templates.

Integration feasibility. Mechanically straightforward: two Composer requires, plugin registration in the panel provider (CMS first for readability), publish config/migrations/views, php artisan migrate, then verify with php artisan route:list | grep -i blog. The real work is not installation — it is the override layer and the SEO surfaces the package does not ship (sitemap, RSS/Atom, canonical tags, Open Graph, redirects, structured data). Budget a two-day spike to prove content end-to-end: create one post with title, slug, body, and featured image in /admin, confirm it renders at the public route unstyled-but-correct, then theme. Theming before that wiring is confirmed is wasted effort.

Technical risk. Enumerated for the risk register:

• Bus factor 1. Ten stars, zero dependents, no community changelog. A silent minor release crossing a Filament major is a plausible breakage with no early-warning signal. Mitigation is exact-version pinning of both packages (1.0.x, not ^1.0).
• Filament major coupling. A v3→v4 bump breaks panel plugin registration, resource signatures, and table/form APIs. Treat as a project, not a composer update.
• XSS on rich content. Post bodies render unescaped. Acceptable with trusted staff editors; a real vulnerability the moment imported legacy content or any untrusted author reaches the editor. Sanitize on save and write the one test that covers it.
• Route collisions. /blog is a popular prefix. Check route:list before and after; change the package prefix in config rather than renaming existing app routes. Watch for model-binding conflicts if the app already defines Post or Category.
• Capability gaps that will arrive as stakeholder requests: scheduled publishing, revision history, localization, and granular permissions are not evidenced. Each is a scope change built in the CMS layer, not a config toggle. Surface this before it becomes a sprint surprise.
• Release metadata is suspect. The listed last release (2026-09-17) is in the future relative to the dependency's apparent maturity. Verify actual release cadence and tag history on Packagist before committing the roadmap to it.

Key questions to close before committing:

1. Which exact Filament major does this target, and does our platform match it today?
2. Are the filament-blog-migrations and filament-blog-views publish tags actually shipped, or does the README overstate the install?
3. Where does media live in CMS Builder, and does public URL generation work on S3 without signed-URL expiry on cached pages?
4. Is there any preview/draft mechanism, and is it behind auth with no-store?
5. Who is the named internal owner, and what is the funded exit path — the claim of a "two-day rewrite" should be validated by the spike, not taken on faith.

Integration Approach

Stack fit. Adopt as "assemble," not "buy." Borrow the presentation layer (MIT, forkable), keep content modeling and editorial workflow in CMS Builder, and spend engineering capacity on differentiators. Adopting this is also a decision against headless/omnichannel delivery for now — server-rendered Blade with route config, no content API. Write that deferral into the decision log deliberately rather than letting it happen by default.

Migration path. If migrating from a legacy CMS: export posts/categories/tags into the CMS model shape, populate a database-backed redirects table during the move, and apply it in global middleware. Imported HTML is the classic XSS vector — sanitize on ingest, not on render. Validate image/asset resolution through the CMS media relation rather than reconstructing paths.

Compatibility. Pin both tomatophp/filament-blog and tomatophp/filament-cms to exact patch ranges on day one. This is the highest-leverage risk control available. Rehearse any Filament major upgrade in a branch, never on main.

Sequencing. Five gates, each with a clear exit:

1. Spike (2 days): install both, register plugins, migrate, create-and-render one post. Validates wiring and the override model.
2. Boundary definition: agree in writing that new content asks (author bios, series, reading time, related posts) become CMS fields, not frontend conditionals. Put it in story acceptance criteria. This is what prevents the blog becoming a second, unowned CMS.
3. Design shell: publish views into resources/views/vendor/filament-blog/, split the layout shell from post-card and post-detail partials so reskins don't force re-pulling upstream into card markup. Maintain UPSTREAM.md listing overrides and rationale.
4. SEO as application features: scheduled sitemap command, small feed controller, canonicals/OG in the layout override, redirects middleware. Do not assume the package covers these — it doesn't.
5. Caching and CDN: response cache or versioned keys on public index/detail routes, invalidated by CMS model saved/deleted observers in our app (not a package edit). Explicitly exclude draft/preview from cache.

Route prefix and middleware change through config/filament-blog.php, never by editing the package routes file — that is what lets the same install serve at /blog, a subdomain root, or behind a feature flag.

Operational Impact

Maintenance. Ongoing cost is low but non-zero, and it is manual diffing — there is no community to tell you what changed. Required artifacts: pinned versions, UPSTREAM.md, an upgrade runbook (how to bump, how to test, who forks if upstream stalls), and a standing budget line for Filament major upgrades. Keep overrides thin; that thinness is the actual insurance policy and the thing that keeps a fork in days rather than months. Never run vendor:publish --force after customization begins — it overwrites overrides.

Support. No SLA, no vendor, no forum. Support is entirely internal: one named owner accountable for the dependency. That is a manageable arrangement if the name is written down and the exit path is funded. It is not manageable if the package quietly becomes load-bearing for a revenue channel with nobody on the hook. Debugging sequence to document so it isn't relearned each incident: route:list for the URI → confirm CMS migration ran and content exists → view:clear → check expected layout name → confirm the public route's middleware matches the app's web group → config:clear / optimize:clear.

Scaling. Pages are largely static per post and server-rendered — favorable for response caching and CDN offload. The scaling risk is not throughput, it is cache correctness: drafts and authenticated previews must never land in a shared cache (auth middleware plus no-store on preview routes), and cache tags must flush on content save/delete rather than on a timer. Verify with an incognito request to an unpublished slug that it 404s.

Failure modes to pre-plan:

Ramp-up. A Laravel/Filament-fluent engineer should be productive in one to two days given the spike; the learning curve is the CMS/blog boundary and the view-override precedence rules, both of which are documented cheaply in the runbook. Content editors need only standard Filament admin familiarization. Plan a short handover for whoever inherits the override files, and treat the first Filament major upgrade as the real readiness test — that is when you learn whether the exit plan is genuinely a two-day rewrite.