Weave Code
Metadata Laravel Package
enhavo/metadata
Metadata component for the Enhavo content framework, providing models and services for storing, resolving, and rendering resource metadata such as titles, descriptions, and SEO-related attributes across pages.
[READ-ONLY] Metadata
Frequently asked questions about Metadata
- Is enhavo/metadata a Laravel package?
- No. It is a component of Enhavo, a Symfony-based CMS, published as a read-only subtree split of a larger monorepo. It is Composer-installable in any PHP project, but it ships no Laravel service provider, facade, publishable config, or artisan commands. Treat any Laravel fit as something you would have to build yourself.
- What does enhavo/metadata actually do?
- It provides an object-oriented API for attaching structured metadata, such as titles, descriptions, and SEO-related attributes, to objects and resources in the Enhavo ecosystem. Metadata is read and written through configurable metadata sources, so application code stays decoupled from the storage backend. The design is extensible, allowing custom metadata types and providers.
- Can I use enhavo/metadata in a Laravel application?
- You can install it, but integration would be manual wiring at best. Symfony bundles typically ship Doctrine mappings, DI compiler passes, and event subscribers, which do not map cleanly onto Laravel's Eloquent and service container. Before considering it, confirm whether the package is a thin set of interfaces and value objects or a full bundle with persistence, because that answer decides whether the effort is days or weeks.
- Does enhavo/metadata handle SEO titles, descriptions, Open Graph, and canonical URLs?
- The component is designed for storing and resolving resource metadata such as titles, descriptions, and SEO-related attributes across pages. The concept maps well onto Laravel idioms, for example Eloquent JSON casts, a polymorphic metadata table, and model observers. However, the concrete field set and rendering behavior come from Enhavo's implementation, so verify the actual contracts in the source rather than assuming Open Graph or canonical support.
- Which PHP, Symfony, and Doctrine versions does enhavo/metadata require?
- There is no Laravel version support matrix, because the package targets Symfony. Check composer.json for constraints on PHP, Symfony components, and Doctrine, and compare them against the Symfony versions pinned by your Laravel release. Version drift between the package and your framework is a silent breakage risk on upgrade.
- How do I install and configure enhavo/metadata?
- Installation is a standard composer require, but configuration is Enhavo-specific: you register and configure metadata sources through Symfony services rather than a publishable Laravel config file. There is no facade, no auto-discovery, and no artisan scaffolding. Expect to read the source and upstream Enhavo documentation to understand how sources are resolved.
- Is enhavo/metadata actively maintained and safe for production?
- The dominant market signals are weak: zero stars, zero dependents, and no external production validation to mine for failure modes. It is a single-vendor project, and split publishing depends on monorepo CI you do not control. Review the release history over the last 24 months and confirm whether the package is load-bearing inside Enhavo itself; if it is an orphaned helper, treat it as already dead.
- How do I report a bug or submit a pull request for enhavo/metadata?
- The GitHub repository is a read-only subtree split, so it is not the contribution surface. Issues and pull requests belong upstream in the Enhavo monorepo. Patching the split locally creates a permanent divergence you will have to carry on every update.
- What are the alternatives to enhavo/metadata for metadata in Laravel?
- For most Laravel applications the native approach is simpler: a polymorphic metadata table with JSON columns, Eloquent casts, and model observers to keep metadata in sync with content. Dedicated Laravel SEO and metadata packages also exist and will have clearer support paths. Choosing a Symfony CMS component instead means adopting a foreign framework dependency with no support route.
- How should I evaluate enhavo/metadata before adopting it?
- Start with a short source audit: determine whether it is contracts only or a full bundle with ORM mappings and DI wiring, review composer.json constraints, and check whether the Packagist release is in sync with the monorepo main branch. Then establish whether it defines a storage contract, such as a table schema or serialization format, that would constrain your data model. Answer these before any spike or roadmap discussion, because this is a CMS selection decision rather than a library decision.
Weaver
How can I help you explore Laravel packages today?