Filament Meta Laravel Package

Product Decisions This Supports

Build vs. buy vs. defer on metadata authoring. This package is a thin polymorphic key/value side table (model_type, model_id, key, value) plus a trait and a Filament relation manager. That is roughly one to two days of an engineer's time, packaged. The value is not capability — nothing here validates, types, filters, or aggregates — it is speed and convention. So the honest framing is: this collapses a "should we build a meta system?" debate into a one-week spike with a working artifact. Use it to answer the question rather than to avoid it.

Scope decisions on SEO. The package's clearest job is per-record SEO: title, description, keywords, Open Graph and Twitter card values, editable inline on an existing resource. If SEO is on the roadmap, adopt it to produce a real editor experience for one content model (Page or Post) with a handful of keys. That artifact — a screenshot of an editor filling in a title and description on a Page — is worth more in a planning meeting than another estimate.

Roadmap sequencing: which model gets it first. The trait is one line, so the marginal cost of enabling another model is near zero, but the marginal cost of supporting it is not. Pick one owner model deliberately; treat each additional model as a separate small decision with its own key allowlist.

Key schema governance as a product decision, not a technical one. The package accepts free-text keys, which becomes seo_titel, seo-title, and seoTitle within a sprint. A PM should own the approved key list and its formats (title ~60 chars, description ~155, separator conventions) as a written conventions doc. This is the single highest-leverage thing you can do here — editors become the schema if you don't.

Localization / market-launch decisions. If localized SEO is a future requirement, model the locale in the key (seo_title.en, seo_title.fr) rather than committing to new schema. It costs nothing today and keeps the door open. Use it to defer a localized-content architecture decision without painting yourself into a corner.

Whether metadata needs to be a query surface. Meta is an authoring and rendering store, not a reporting store. The moment a stakeholder asks to filter, sort, export, or report on a meta value, that is a signal to promote that key to a real column — not to extend the meta system. Write this down before the first request arrives, because saying yes to a meta-based report is how these pilots quietly die.

Prioritizing editor completeness work. Fallback chains, character-limit validation, and a "SEO complete" badge in the resource table are small pieces of product work that make a bare key/value store feel finished. Editors fill ~60% of fields and expect the rest to look right; the fallback chain is what turns a pilot into something you can ship. Budget for it — it is not in the package.

Buying an exit option, not a dependency. MIT plus a single maintainer and 0 dependents means you should adopt with a vendor/fork plan on day one. That is a one-command exit strategy and it makes the adoption decision cheap and reversible, which is exactly what you want for a capability experiment.

When to Consider This Package

Adopt when all or most of these hold:

• You are on FilamentPHP and want SEO fields editable inside existing resources, not in a separate admin screen.
• SEO is a candidate roadmap item, not a committed one. This is a spike vehicle: one model, a handful of keys, one named owner, then a go/no-go.
• Metadata is authoring/rendering only. No filtering, sorting, exporting, or reporting on meta values at volume, and no near-term plan to add it.
• You have no existing meta plumbing — no JSON meta column, no settings package already owning these keys. Two storage locations for "metadata" is the most common way this pilot fails six months later; if you already have one, decide now which owns which keys, in writing.
• Engineering can absorb ownership. You can assign an internal owner by name, pin the version, keep a fork buildable, and treat upstream as a convenience rather than a support contract. With ~15 stars and 0 dependents there is no community buffer for a bad release.
• You can verify four things in ten minutes before committing: the Filament major it targets, whether the value column and unique index are sane, what the trait actually exposes, and whether the relation manager respects policies and tenancy. If nobody can answer those, you are not ready to adopt.

Look elsewhere — or build the day of work yourself — when:

• You need filtering, sorting, or reporting on metadata. The EAV join degrades and the abstraction leaks. Promote keys to real columns or a JSON column with a generated index.
• You need typed values, validation, or structured/nested fields. Values round-trip as strings; putMeta('is_featured', true) becomes "1". Keep booleans, numbers, and anything structured in real columns.
• You need a fixed 4–6 field SEO form, not a row-per-key editor. The relation manager is row-per-key, which is a clumsy editor for a known schema. A plain field group in the resource form is nicer — but do not build two write paths that skip the same validation.
• You run strict multi-tenancy or fine-grained authorization and cannot override the relation manager's policy hooks. Polymorphic meta rows have no tenant column; they inherit from the owner only if the owner lookup is scoped.
• You need localized/multi-market metadata as a committed requirement now. Model it in keys as a stopgap, but plan the real migration.
• Upstream health is a hard blocker. Single maintainer, no public production evidence, a last-release date worth verifying directly on Packagist, and a history of Filament relation managers breaking across majors (v3→v4). If you cannot fund a fork owner, do not adopt.

How to Pitch It (Stakeholders)

To executives — one paragraph.

There is a small, MIT-licensed package that lets editors manage SEO titles, descriptions, keywords, and social-sharing tags directly on the pages they already edit in our admin panel, instead of us building that editor from scratch. It gets us a working, demoable SEO authoring experience for one content type in about a week, at effectively no licensing cost, and because it's MIT we can walk away from it cheaply if it doesn't fit. It is not a platform commitment — it's the cheapest way to find out whether SEO authoring is worth investing in, and the exit cost is low and known.

To engineering — the honest trade.

This is the one-to-two-day implementation we'd write ourselves, packaged: a polymorphic key/value table, a trait, and a Filament relation manager. Adopt it for speed and convention, not capability. Three conditions: we wrap it behind our own trait so package types never leak into resources or Blade, we add a unique index on (model_type, model_id, key) before writing a single row (and use updateOrCreate everywhere), and we allowlist keys via an enum so editors can't invent them. We pin the version and keep a fork buildable; the fork is the support contract. First spike: one model, ~5 keys, exercised end-to-end including as a user who shouldn't have permission, with a query-count check on the list view so we catch the N+1 before it ships.

What success looks like (the acceptance criteria to agree up front):

• A Page editor can set title, description, keywords, and OG values inline and see them render correctly with sensible fallbacks.
• Query count on the resource list view does not grow per row (meta is eager loaded).
• A user who can view but not edit a Page cannot edit its meta.
• A written one-page conventions doc exists: approved keys, their formats and length limits, which storage owns what, and the rule that meta is not a query surface.
• Rollback has been run in a sandbox, and the cost of moving to a JSON column or dedicated columns is scoped — while there are forty test rows, not forty thousand.

What to watch, in plain terms: duplicates silently winning ("wrong title in production"), N+1s in table and Blade loops, orphaned rows when a record is deleted, free-text keys fragmenting within a sprint, and Filament major upgrades breaking the relation manager. Each has a named owner and a calendar item, or the pilot isn't ready.