Filament Meta Laravel Package

Product Decisions This Supports

• Feature enablement — editor-managed SEO/meta: The package gives Filament admin panels a way to manage meta/SEO fields (title, descriptions, social/OG tags) without engineering hand-offs. This unblocks "content team owns SEO" roadmap items that otherwise stall in the backlog.
• Build vs. buy: For teams already on Laravel + Filament, it's a small, targeted add-on rather than a bespoke meta-field subsystem. The v0.1.1-beta.1 release is a signal both ways: the maintainer is responsive (fix + regression test), but the release pipeline shipped an artifact that crashed php artisan optimize — so the cheapest "buy" option still needs a production-build verification step in your pipeline.
• Deployment-risk gate: The bug only surfaced in production-like flows (view:cache / optimize), not in local dev. That makes this a release-engineering decision, not just a feature decision: any adoption should be gated on CI running php artisan optimize and view:cache against the packaged artifact.
• Version/pinning policy: At 0.1.x-beta, treat this as a pilot dependency. Pin to an exact version (0.1.1-beta.1), consume upgrades deliberately, and keep a fallback path (custom fields / alternative SEO plugin) if the package stalls.
• Use cases worth piloting first: Marketing/CMS-style sites where editors need per-page meta overrides; internal admin panels where SEO is secondary but "good enough" tags matter. Not a fit for SEO-critical, multi-locale, structured-data-heavy sites without a deeper evaluation.

When to Consider This Package

Consider it when:

• Your stack is Laravel + Filament and your editors already work inside the admin panel; the marginal integration cost is low.
• You need basic meta/OG tag management, not a full SEO suite (no sitemaps, canonicalization logic, schema.org generation, or redirect management implied).
• You can tolerate beta (0.1.x) churn: pin the version, review release notes before bumping, and accept that APIs may shift before 1.0.
• Your CI already (or can cheaply) run a production-like build — php artisan optimize, view:cache, config:cache — so packaging regressions are caught before deploy.
• You want a small, replaceable module rather than a bespoke meta subsystem you'd have to maintain.

Look elsewhere when:

• You need stability guarantees, an LTS cadence, or vendor support/SLA — a 0.1.1-beta.1 release with one maintainer is a single point of failure.
• SEO is a core business capability requiring audit trails, multi-locale hreflang, structured data, or analytics integration.
• You're not on Filament (the value proposition largely collapses) or your deploy pipeline can't validate the packaged artifact.
• The view:cache crash pattern repeats in subsequent releases — one packaging bug is a fix; a pattern is a maturity problem.
• Your team would need to fork to get required behavior; at beta, forking is a maintenance tax with no upstream stability to inherit.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, narrow capability that lets content editors manage page metadata (titles, descriptions, social preview tags) directly in the admin panel — removing an engineering dependency from routine marketing work. It's early-stage software (0.1.x beta), so the recommendation is a contained pilot, not a platform commitment: pin the version, run it on one property, and revisit at 1.0. The latest release fixed a production-deploy crash and added a regression test, which is the right response, but it also confirms the package isn't yet at a maturity level where we'd standardize on it.

To engineering: One-line summary: Filament meta-field plugin; v0.1.1-beta.1 fixes a deploy-time crash caused by registering an empty filament-meta views namespace absent from the release archive, which broke php artisan optimize / view:cache (Finder.php:663). Fix plus regression test is a positive responsiveness signal, but the root cause is release-artifact packaging — the kind of defect local dev never catches. Ask before adoption: pin an exact version, add a CI stage that runs optimize and view:cache against the built artifact, and confirm the maintainer's release process now validates packaged builds. Keep the integration thin (treat it as replaceable) because pre-1.0 APIs can move.