Open Graph Bundle Laravel Package

Getting Started

netgen/open-graph-bundle is a very thin helper: it gives you a Twig extension (and a small PHP service) that collects property/content pairs and renders them as <meta property="og:..."> tags. That is essentially the entire feature set — there is no admin UI, no field type, no automatic extraction of Open Graph data from eZ/Ibexa content. Expect to spend more time deciding what to put in the tags than wiring the bundle.

Minimal steps:

1. composer require netgen/open-graph-bundle
2. Register it in config/bundles.php:

   Netgen\OpenGraphBundle\NetgenOpenGraphBundle::class => ['all' => true],
   

   (On legacy eZ Platform, enable it in app/AppKernel.php / ezplatform.yml instead.)
3. Render it inside <head> in your pagelayout or detail template — the bundle exposes netgen_open_graph() in Twig; check the README for the exact argument shape, since the extension is a single method and is the whole public API.

Where to look first: vendor/netgen/open-graph-bundle/README.md, then the Twig extension class under Templating/Twig/Extension/. Don't go hunting for config trees — there is very little to configure.

First real use case: an article detail template, populating og:title, og:description, og:image, og:type and og:url from eZ/Ibexa fields:

{% set og = netgen_open_graph() %}
{% do og.addTag('og:title', ez_field_value(content, 'title')) %}
{% do og.addTag('og:description', ez_field_value(content, 'intro')|striptags|slice(0, 200)) %}
{% do og.addTag('og:image', absolute_url(ez_image_alias(ez_field(content, 'image'), content.versionInfo, 'opengraph').uri)) %}
{% do og.addTag('og:url', absolute_url(ez_urlalias(content.contentInfo.mainLocationId))) %}
{% do og.addTag('og:type', 'article') %}
{{ og.render() }}

Implementation Patterns

Split base tags from content tags. Put the site-wide fallbacks (og:site_name, og:type, default og:image = logo, og:locale) in the pagelayout, and let detail templates add/override per-content values. This avoids every template author re-inventing the same five tags — and avoids empty <head> sections on listing pages.

Write one macro and use it everywhere. A _og.html.twig macro taking (content, {type: 'article'}) with sensible fallbacks (title field → content name, intro → trimmed body, image field → site logo) is worth more than the bundle itself. The bundle doesn't know your content model; you do.

Always generate absolute URLs. og:image and og:url must be absolute — most scrapers silently drop relative paths. Use absolute_url() and a dedicated image alias (e.g. opengraph, 1200×630) rather than the original field value, so you control file size and aspect ratio.

Use the service in PHP when Twig isn't enough. For JSON endpoints, sitemap-ish generators, or tags that depend on runtime state, inject the OpenGraph service and add tags programmatically, then render into a string in the response template. This is also the cleaner path if you want to unit-test your tag-building logic.

Verify with real scrapers, not the markup. Facebook Sharing Debugger, LinkedIn Post Inspector, and curl -A facebookexternalhit against a cached page are the only tests that matter. Put a smoke assertion in a functional test (fetch the article page, assert og:title contains the field value) so a template refactor doesn't quietly kill your previews.

Cache-awareness: eZ/Ibexa view cache and HTTP cache store the rendered <head> along with the body. If you build tags from something request-dependent (user, query string, preview), either vary the cache or keep those tags out.

Gotchas and Tips

• License is the biggest risk. GPL-2.0 is copyleft; for a PHP application that links the bundle, this is a real conversation with legal if your product is closed-source. This is more consequential than anything technical in the package.
• Effectively unmaintained. Last release April 2020, 14 stars, zero dependents. Assume no fixes. On Ibexa 4 / Symfony 6 you'll likely hit composer why-not netgen/open-graph-bundle on the symfony/* or ezsystems/* constraints — at which point the pragmatic move is to copy the extension class into your own src/ (it's a few dozen lines) rather than fork and maintain a repo.
• Silent failure mode. If nothing appears in the page source, the usual causes are: the render call is outside <head>, the extension returns markup that Twig auto-escapes (use |raw or the bundle's render method as documented), or addTag was given an empty value and the bundle skips it. Dump the collected tags before rendering to confirm.
• Escaping. Content fields often contain quotes and HTML. Run text through striptags, and let Twig's html_attr escaping handle the attribute — don't hand-concatenate the meta strings.
• Don't expect Open Graph Protocol coverage beyond OG. No Twitter Card, no JSON-LD, no schema.org, no oEmbed. You'll add <meta name="twitter:..."> yourself; consider whether a single macro producing both is cleaner.
• Tag order and duplication. Some scrapers are picky about duplicate og:image (you may legitimately want several) and about og:type appearing after child properties. Emit base properties first, and de-duplicate when merging pagelayout fallbacks with template values — the bundle won't do it for you.
• Extension points are thin. The renderer/service is a normal Symfony service, so you can decorate it or alias it, and if the bundle ships a template you can override it under templates/bundles/NetgenOpenGraphBundle/. Beyond that, don't expect plugin hooks — the bundle is too small to have any.
• Stale previews. Scrapers cache aggressively. After changing og:image, hit the debugger's "scrape again" before concluding the bundle is broken.