Seo Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package: it ships Kunstmaan\SeoBundle\KunstmaanSeoBundle, a DependencyInjection compiler extension, Doctrine ORM entities, and Sonata/Kunstmaan admin-list classes. None of this autoloads into or executes within a Laravel application container.
• Domain logic is thin and portable: a small set of SEO/OpenGraph/metadata fields attached to content entities, plus a free-text "custom header" field. The value is the data model and editor UX concept, not the code.
• Its real dependency graph is the Kunstmaan CMS (NodeBundle, AdminBundle, PagePartBundle). Adopting the bundle without that stack is not a supported configuration; adopting the stack means replacing the Laravel application.

Integration feasibility

• Direct composer require into a Laravel app is effectively infeasible: service providers, config loading, and entity mapping all assume Symfony kernels and Doctrine.
• A viable path is conceptual port: replicate the metadata schema as an Eloquent polymorphic table (metadatas with metadatable_type/id), expose it via a trait, render with a Blade partial in <head>, and provide a Filament/Nova field group for editors. Estimated effort: 3–5 engineering days for a scoped MVP.
• Licensing is permissive (MIT), so reuse of schema concepts and even copied field lists is legally unencumbered.

Technical risk

• Abandonment: last release 2014-04-17, ~11 years stale; 24 stars and 0 dependents confirm no community. No security policy, no maintained branch, no PHP 8 / Symfony 5+ support.
• Runtime incompatibility: PHP 5.3-era syntax and annotations against Doctrine ORM 2.x; won't survive PHP 8.x + ORM 3 without a rewrite.
• Security surface: the advertised "free field to add custom header information" is a stored XSS / header-injection vector if rendered unescaped. Any port must whitelist tags or sanitize with an HTML purifier; treat the original implementation as an anti-pattern, not a reference.
• Regulatory/feature drift: Metriweb tags are a Belgian audience-measurement artifact; OpenGraph and meta-keyword handling have moved on (keywords are ignored by major engines). The bundle encodes 2014 SEO practice.

Key questions

• Is the requirement actually "SEO metadata for Laravel content," or "port a Kunstmaan CMS site"? Only the former is addressable here.
• Which metadata set is in scope — title/description/canonical/robots, OpenGraph, Twitter cards, JSON-LD structured data, hreflang? The bundle covers none of the modern essentials (canonical, JSON-LD, sitemap).
• Who is the editor-facing consumer — Filament, Nova, or custom Blade forms — and does the team already have a media/asset model for og:image?
• Do we need multi-locale and multi-tenant metadata, which the bundle's single-entity annotation model does not handle?
• Is there budget to build and own a ~400-line internal package, or should we buy a maintained SaaS/plugin?

Integration Approach

Stack fit

• Target stack: Laravel 10/11, PHP 8.2+, Eloquent, Blade, optional Filament v3 admin panel. The bundle contributes requirements and field taxonomy only.
• Recommended build: app/Seo trait + seo_metadata polymorphic table (title, description, keywords, canonical, robots, og_, twitter_, json_ld, custom_head) + a SeoRenderer service + <x-seo-meta :model="$page" /> Blade component.
• Editor UX: a reusable Filament form section with a repeater for OpenGraph overrides and a sanitized code editor for custom head tags, gated behind a permission.

Migration path

• Phase 1 (1–2 days): inventory existing metadata needs against the bundle's field list; discard Metriweb, keyword meta, and free-text headers.
• Phase 2 (3–5 days): schema + trait + renderer + Blade component with defaults and per-model overrides.
• Phase 3 (2–3 days): admin UI, validation, sanitization (e.g., HTMLPurifier or an allowlist of <meta>, <link>, <script type="application/ld+json">).
• Phase 4: JSON-LD templates and sitemap/canonical correctness; add feature tests asserting rendered <head> output.
• If a Kunstmaan site already exists, treat the bundle table as a read-only source for a one-off data migration script, then decommission.

Compatibility

• No shared runtime; compatibility is limited to "same domain concepts." Field names and semantics can be preserved 1:1 for the simple scalar fields.
• Serialization concerns: the bundle stores values as Doctrine-mapped columns; an Eloquent JSON column plus accessors is a cleaner target and avoids per-locale column sprawl.
• Avoid any transitive pull of kunstmaan/* packages — the dependency tree drags in Symfony 2 components that conflict with Laravel's symfony/* constraints and will cause Composer solver failures.

Sequencing

• Do the renderer and sanitization before exposing editor input; otherwise the custom-header field ships as an unresolved security defect.
• Ship read-only rendering first (defaults derived from content title/excerpt/image), then enable overrides, then structured data.
• Defer JSON-LD and hreflang to a second iteration; they are not represented in the source package and need SEO/Content stakeholder sign-off.

Operational Impact

Maintenance

• The upstream package is unmaintained and must be treated as frozen reference material. Zero ongoing dependency maintenance is a benefit of the port approach; the cost moves to an internally owned package (~400–600 LOC), which is tractable but requires a named owner and a versioning policy.
• Watch items: PHP major upgrades, Filament major versions, and SEO guidance changes (structured data schema.org updates, deprecation of meta keywords).

Support

• No vendor, no maintainer, no issue triage, no CVE process. Any defect is ours. Ensure the decision record states this explicitly so future maintainers don't assume upstream fixes.
• Internal support model: owning team as first line, platform team for schema changes to the shared seo_metadata table.

Scaling

• Trivial at the runtime level: one extra indexed polymorphic read per page render, cacheable with the page payload. Add a seo_metadata cache key and eager-load the relation to prevent N+1 on listing pages.
• The only real scale concern is editorial throughput — every content type needing metadata requires a trait addition and a form section; standardize via a base model or interface to keep it O(1) per new type.

Failure modes

• Stored XSS via custom head field — highest-severity risk; mitigations: sanitizer allowlist, CSP, output escaping, permission-gated field, audit logging.
• Missing/blank metadata producing broken social previews — mitigate with deterministic fallbacks (title → page title, image → default OG image) and a CI check on key routes.
• Duplicate or conflicting tags when both the component and hardcoded Blade emit <meta> — enforce single-source rendering and assert in tests.
• Canonical/robots regressions (e.g., accidental noindex persisted in a shared row) causing organic traffic loss — add validation, preview tooling, and a revert path.
• Composer conflict if a developer attempts to install the original bundle — add an explicit conflict entry or a documented prohibition.

Ramp-up

• Low for a Laravel engineer: the port is conventional Eloquent + Blade work, ~1 day to become productive, with the sanitizer and JSON-LD work being the only specialist areas.
• Requires ~2 hours of SEO stakeholder time to agree the field set, fallback rules, and structured-data types before Phase 2 begins.
• Recommendation: do not adopt the bundle; use it as a requirements checklist. If a maintained solution is preferred over building, evaluate a current Laravel SEO package or headless CMS metadata layer instead — the 2014 provenance, zero dependents, and Symfony coupling make this a reference artifact, not a dependency.