Metadata Laravel Package

Product Decisions This Supports

• CMS selection, not library selection. enhavo/metadata is not a standalone Laravel package — it is a read-only subtree split of the Enhavo CMS (Symfony). The real decision it informs is "do we standardize on Enhavo and inherit its metadata layer?", not "should we npm/composer-install this?" Treat it as an input to a platform bet.
• SEO/editorial metadata as a product surface. The package models per-resource metadata (SEO titles, descriptions, extensible custom fields) with admin/form integration. If Enhavo were on the table, this is the enabler for roadmap items like "marketers edit SEO fields without engineering," "social/search preview control," and "localizable meta content." That's a real product capability — just one you'd get from the CMS, not from this repo.
• Build vs. buy vs. build-natively. Because the implementation is Symfony-coupled and the repo is a mirror, the practical options are: (a) adopt Enhavo wholesale, (b) reimplement the concept natively in Laravel behind our own interface, or (c) skip metadata modeling for now. This package is evidence for option (b) more than anything else — it's a reference for the shape of the problem, not a dependency to buy into.
• Editorial workflow and ownership. Attaching metadata as an object to a content resource (rather than hard-coding it into templates) implies a clean separation between marketing-owned SEO content and engineering-owned rendering. That's a workflow and permissions decision worth capturing regardless of vendor.
• Prioritization hygiene. 0 stars, 0 dependents, no description, no independent issues, no independent release cadence — the market data does not support putting this on a roadmap as a dependency. Any commitment here is really a commitment to upstream Enhavo's priorities and release schedule, which we don't control.

When to Consider This Package

Consider it when:

• Enhavo is already the CMS. Then this is framework plumbing — consume it via the Enhavo distribution/monorepo, don't hand-pick it as a point dependency, and don't fork it.
• You're formally evaluating Enhavo and want to inspect how it models SEO metadata before committing to the platform.
• You need a design reference. The metadata-object pattern (attach structured descriptive fields to any resource, editable via admin, renderable via template helpers) is a sound pattern worth borrowing for an in-house implementation.
• You want an MIT-licensed example of metadata modeling to inform your own schema and interface design.

Look elsewhere when:

• You're on Laravel. This is Symfony/Enhavo. No service provider, no config stub, no Laravel conventions. Prefer a maintained Laravel-native SEO/metadata package or a short in-house implementation using Eloquent JSON casts and a polymorphic metadata table.
• You need independent maintenance or support. A read-only mirror with zero dependents has no triage, no community, no SLA, no security response path. Contributions go upstream, on upstream's timeline.
• You need metadata outside a CMS context (API resources, multi-tenant routing, headless content) — the scope is Enhavo's content model.
• You need predictable release cadence or long-term support. No commercial backing is visible.

Diligence gate before any adoption: confirm the split's tags track the Enhavo release line, inspect composer.json for PHP/Symfony/Doctrine constraints, check whether Enhavo core actually consumes this package (load-bearing vs. orphaned helper), and read src/ to see whether it's contracts-only or a full bundle with ORM mappings and DI wiring.

How to Pitch It (Stakeholders)

To executives: This is a small, read-only module of the Enhavo CMS — not a product-ready dependency for our Laravel stack. It has no community, no independent release process, no support path, and no external adopters. That means adopting it isn't a library decision, it's a CMS selection decision. Doing nothing is low risk. Pulling it into a Laravel codebase in isolation would add a dependency we don't control, can't get help with, and would have to own outright the moment we fork it. Recommendation: don't adopt standalone; revisit only as part of a broader Enhavo evaluation. If the underlying capability — marketer-editable SEO metadata on content — is on the roadmap, we can deliver it natively in Laravel in roughly 1–2 engineer-weeks with full control and test coverage.

To engineering: Treat this as vendor code we don't own — a Symfony/Enhavo monorepo split (MIT, 0 dependents, 0 stars), so versioning, fixes, and issue triage live upstream. Two paths: (1) if we run Enhavo, consume metadata via the distribution and don't fork; (2) if we're on Laravel — which we are — extract the pattern, not the code: define our own metadata interface, back it with a polymorphic table or JSON column, wire it through Eloquent casts and a small admin surface, and keep it behind our own contract so a future swap is a one-file change. Run a half-day source audit first (composer constraints, coupling, storage format, whether Enhavo core consumes it) to confirm there's no non-trivial logic worth forking. Watch for the usual failure modes of foreign CMS components: Symfony version conflicts on framework upgrades, unserialize() in the storage path (object-injection surface), N+1 metadata fetches on listing pages, and silent schema drift if the package owns migrations. Budget a named internal owner either way — undocumented API plus single maintainer is a real handover risk.