Easy Seo Bundle Laravel Package

Getting Started

First, the framework reality check. Despite the "SEO Bundle" label, this is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no extra.laravel block, and no package auto-discovery. As a Laravel developer you cannot composer require mitopp/easy-seo-bundle and expect it to boot — Symfony bundles are registered in config/bundles.php via a Bundle subclass, which Laravel never reads. Plan on treating this as reference material to port, not a dependency to install.

Where to look first (5–10 minutes):

1. composer.json — confirm the symfony/framework-bundle and PHP version constraints. With 2 stars and 0 dependents, the version pins are the most likely blocker if you ever attempt a Symfony install.
2. The bundle class (*Bundle.php) — shows what getContainerExtension() and getPath() wire up.
3. DependencyInjection/Configuration.php + Extension.php — this is the real map of configurable options (titles, descriptions, OG tags, etc.).
4. Any Twig/ extension — tells you which template helpers exist, which is what you'll mirror in Blade.

First use case to validate: setting a page title, meta description, and Open Graph tags for a single controller action, then rendering them in a layout template. If the bundle can't cleanly do that in its own Symfony test app, don't invest further.

If you're actually on Symfony: register the bundle in config/bundles.php, import the bundle's config under config/packages/, inject the relevant SEO service into a controller, and call the Twig helper from your base layout.

Implementation Patterns

In Symfony (native usage):

• Register the bundle, then configure via YAML under config/packages/. Most SEO bundles expose a config tree of defaults (site name, title separator, default image) plus per-page overrides.
• Inject the SEO service into controllers and set metadata imperatively:

  $seo->setTitle('Product: '.$product->name)
      ->setDescription($product->summary)
      ->setCanonical($router->generate('product_show', ['id' => $product->id], true));
  

• Render in Twig via a bundle-provided extension (e.g. {{ seo_title() }}, {{ seo_meta() }}), typically in <head> of base.html.twig.
• Sitemap/robots generation, if present, is usually a console command or a controller route you schedule and cache.

Porting the pattern to Laravel (the day-to-day path for you):

• Create a SeoManager singleton bound in a SeoServiceProvider — this replaces the Symfony DI service.
• Translate the config tree into config/seo.php with the same defaults.
• Replace Twig helpers with Blade directives/components:

  @seoTitle @seoDescription @seoOgImage
  

  or a single <x-seo-meta /> component that renders the whole <head> block.
• Populate metadata from controllers or, more idiomatically in Laravel, via a middleware or a View::composer that reads route defaults/actions.
• Mirror any per-entity overrides with a small trait (HasSeoMeta) or an interface on Eloquent models.
• For sitemaps, expose a route returning XML and cache it; for robots.txt, a static route or public/robots.txt.

Integration tips:

• Keep the manager stateless per-request (bind as singleton is fine since PHP is per-request, but never persist across jobs/queues).
• Set sensible defaults in config/seo.php so layouts always render something valid — missing <title> is worse than a generic one.
• Add canonical URL generation centrally (from url()->current()), not per-view, to avoid drift.

Gotchas and Tips

• The biggest gotcha is the framework mismatch. A 2-star Symfony bundle with 0 dependents is not a viable Laravel dependency. Treat the repo as a spec for what a small SEO layer should do, and write 100–200 lines of Laravel code instead of fighting the autoloader.
• Maintenance risk. Stars: 2, dependents: 0. Assume no upstream fixes, minimal tests, and no docs beyond the README. Audit every class you port for edge cases (null titles, unicode, HTML escaping in meta content).
• Escaping. SEO bundles frequently mishandle HTML entities in content="" attributes. When porting, escape with e() in Blade and strip tags from descriptions.
• Config quirks. Symfony config trees use ->scalarNode()->defaultValue(...) semantics with strict merging — don't assume the YAML defaults map 1:1 to a PHP array; read Configuration.php literally.
• Debugging (if on Symfony): bin/console debug:container | grep seo and bin/console debug:config <bundle_alias> are your fastest checks that the extension loaded. Neither exists in Laravel — use php artisan tinker and app(SeoManager::class) instead.
• Extension points worth copying: a Twig/Blade rendering hook, a config tree for site-wide defaults, and an event/listener for post-processing (e.g. appending OG tags on every response). Those three cover ~90% of real SEO needs.
• Don't over-engineer. For most Laravel apps, a seo.php config, a singleton manager, a Blade component, and a sitemap route is the entire job. If you find yourself porting the bundle's DI compiler passes, stop — you've left the scope of "easy SEO."