Download the PHP package mage2kishan/module-social-meta without Composer

Panth Social Meta — Open Graph + Twitter Card Tags for Magento 2 (Hyva + Luma)

[]()

*Out of the box Magento emits five og: tags on product pages and zero on categories or CMS pages — and on Hyva the core product/view/opengraph/general.phtml template happily duplicates whatever a theme, a third-party SEO module, or a manual layout snippet has already added. The visible result is a Facebook preview that picks the wrong image, a Twitter card that omits the @handle, and view-source output with entity-encoded @ where you wrote @yourstore. Panth Social Meta* fixes the stack end-to-end: one resolver computes `og:andtwitter:*from the current entity (product / category / CMS) with progressive image / title / description fallbacks, an observer onlayout_generate_blocks_afterstrips Magento and Hyva's native OG blocks so duplicates can never render, and the templates useescapeUrl()for URL-valued attributes andescapeHtml()(ENT_QUOTES | ENT_HTML5) — not Zend Escaper — for text-valued ones so@yourstore` stays readable while still being XSS-safe. Five store-scoped admin fields cover the entire configuration surface. Zero JS, zero theme overrides, identical output on Hyva and Luma.

Product pages additionally emit product:price:amount, product:price:currency, product:availability (derived from $product->isSalable() → instock | oos) and product:brand (from the manufacturer attribute) so Facebook Shop and every major product-feed ingester pick up pricing and stock state without a separate feed plugin. og:locale tracks each store's general/locale/code, so a UK store view ships en_GB while the US store view ships en_US from the same codebase.

Need Custom Magento 2 Development?

Table of Contents

• Preview
• Features
• How It Works
• Compatibility
• Installation
• Verify
• Configuration
• Storefront Rendering
• Testing Your Social Tags
• Troubleshooting
• Support

Preview

Admin

System configuration — Stores → Configuration → Panth Extensions → Social Meta. Five store-scoped fields: Enable Open Graph Tags, Enable Twitter Card Tags, Twitter Card Type (summary | summary_large_image), Twitter Site Handle (@yourstore), and Default OG Image (uploaded under media/panth_seo/og/). Every field is [store view]-scoped so a multi-store install can ship a different handle, card type and fallback image per storefront.

Features

How It Works

Four cooperating pieces, one request:

1. Observer\Social\RemoveNativeOgObserver runs on layout_generate_blocks_after in the frontend area. Before any block is rendered it walks the layout tree twice — once by well-known block names (opengraph.general, opengraph.product, opengraph.category, opengraph.cms), once by pattern (opengraph substring, og. prefix) — and unsetElement()s each match. This module's own blocks start with panth_social_meta. and are skipped by name, so only native Magento / Hyva / third-party OG blocks disappear. The observer runs unconditionally: when a merchant disables the module's OG output they expect zero og:* on the storefront, not Magento core's 5-tag native template filling the vacuum.
2. Model\Social\OpenGraphResolver::resolve() is the read path. It detects the current entity from the Magento registry, walks the title / description / image / URL fallback chains, pulls og:site_name from general/store_information/name, pulls og:locale from general/locale/code, and — when the entity is a product — adds product:price:amount, product:price:currency, product:availability (from isSalable()) and product:brand (from the manufacturer attribute). Returns a flat ['og:property' => 'value'] array with empty values filtered out.
3. Model\Social\TwitterCardResolver::resolve() wraps the OG result. twitter:title / twitter:description / twitter:image mirror the OG equivalents so the two preview cards always agree. twitter:card is the admin-configured type, twitter:site is the configured handle (omitted when empty). Returns an empty array if the OG resolver returns empty — so disabling OG silently disables Twitter too.
4. The two phtml templates (view/frontend/templates/head/opengraph.phtml + .../twittercard.phtml) iterate the resolved array and emit one <meta> tag per entry. URL-valued attribute names (hardcoded allowlist) go through $escaper->escapeUrl(), everything else goes through $escaper->escapeHtml(). The property / name value itself is always escaped with escapeHtml() because the allowlist is fixed to ASCII. When the resolver returns empty (module disabled, no entity, etc.) the template early-returns and writes nothing.

The EAV patch (Setup\Patch\Data\AddOgAttributes) is a one-shot install that runs during setup:upgrade — it adds og_title, og_description, og_image to every product and category attribute set, under the "Search Engine Optimization" group. The attributes are read by the resolver via the standard getData() path when set.

Compatibility

Installation

Verify

Visit Stores → Configuration → Panth Extensions → Social Meta to see the admin panel.

Configuration

Navigate to Stores → Configuration → Panth Extensions → Social Meta.

Every field is [store view]-scoped. Ship a different twitter_site_handle, card type and Default OG Image per storefront to match each brand's social presence.

After saving, flush the config and full_page caches — the observer output is baked into FPC so a cached page keeps whichever configuration was active when it was cached:

Storefront Rendering

view/frontend/layout/default.xml attaches both head blocks to head.additional:

Product page (PDP)

Category page

CMS page (About Us, Contact, Shipping Policy, …)

Luma store view — identical resolver output, different host

Because the resolver is driven entirely by store-scope config (general/locale/code, general/store_information/name, panth_social_meta/social/*) and the registry-detected entity, two store views on the same install produce correct-per-store output without any per-store layout XML. The EAV fallback (og_title / og_description / og_image) is also store-scoped via the standard ScopedAttributeInterface.

What disable looks like

When both master switches are off, the page ships zero social meta — not a fallback to Magento core's native OG template:

Testing Your Social Tags

A working setup requires the tags to be (a) present, (b) unique (one per property per page), (c) rendered with readable values (URLs not entity-encoded, @ handles not over-escaped) and (d) preview-correct in the scraper tools. Validate all four.

Official preview validators

The authoritative tools — paste any URL from the storefront:

• Facebook Sharing Debugger — scrapes the URL, shows the exact og:* values Facebook ingested, and lets you "Scrape Again" to force a cache refresh after deploying changes.
• Twitter/X Card Validator (now rolled into X's developer portal) — renders the exact card the Twitter/X timeline will show, surfaces missing / broken tags.
• LinkedIn Post Inspector — inspects OG tags for LinkedIn previews, with a "Force re-scrape" control.
• opengraph.xyz — multi-platform preview (Facebook, Twitter/X, LinkedIn, WhatsApp, Slack, Discord, iMessage) from a single URL paste.

In-browser spot check

Open any storefront URL and run in DevTools console:

CI smoke test

A minimal curl-based test you can wire into deploy:

Run on both Hyva and Luma hosts after every deploy that touches social meta, theme layout, or the RemoveNativeOgObserver.

Confirm the observer is stripping native blocks

If this returns anything other than 0 when disabled, either a third-party module is re-adding an OG block under a name that doesn't match the opengraph / og. patterns, or FPC is still serving a cache entry from before the flush. Hard-flush with bin/magento cache:clean and re-test.

Troubleshooting

No og:* or twitter:* tags on the storefront

Three things to check, in order:

1. Master switches — Stores → Configuration → Panth Extensions → Social Meta → Enable Open Graph Tags / Enable Twitter Card Tags = Yes at the current store scope. When No, the resolver returns empty and the template writes nothing. Flush config + full_page caches after flipping.
2. FPC cache — the page was cached before the config change. Run bin/magento cache:flush config full_page and re-test. The resolver is only invoked on uncached renders.
3. Theme overriding head.additional — a custom theme's layout XML can null out the head.additional container. Search your theme package for <referenceBlock name="head.additional" remove="true"/> and remove it. The same layout XML is what hosts Magento's native OG tags, so removing it breaks those too.

og:title or og:image rendering twice

A third-party SEO / Hyva module is re-adding an OG block under a name that doesn't match the observer's patterns. Check with:

If two different lines appear, identify the offending module (bin/magento module:status + grep -r "og:title" vendor/<vendor>/) and either (a) open an issue with the offending module to adopt a predictable block name (opengraph.* or og.*), or (b) add its block name to Observer\Social\RemoveNativeOgObserver::NATIVE_OG_BLOCKS and PR upstream.

twitter:site shows @yourstore instead of @yourstore

Your theme is shipping an override of view/frontend/templates/head/twittercard.phtml that uses $escaper->escapeHtmlAttr() instead of $escaper->escapeHtml(). Magento's escapeHtmlAttr() runs Zend\Escaper which aggressively encodes every non-ASCII-safe byte, so the @ sign becomes @. Social scrapers decode entities so the handle still works, but it looks wrong in view-source and some linters flag it. Fix: remove the theme override, or mirror the module's escape strategy (escapeUrl() for URL-valued names, escapeHtml() for everything else).

product:availability always instock even for out-of-stock products

The resolver reads $product->isSalable(). If this returns true for an out-of-stock product, you have a stock configuration issue, not a social meta one — check Stores → Configuration → Catalog → Inventory → Stock Options → Display Out of Stock Products and the product's own stock status. Confirm by loading the product in a bin/magento script:

If this prints true but the frontend shows Out of Stock, the resolver is reporting isSalable() correctly and the storefront display is driven by stock inventory — bring the two in line via the product's Stock Status.

og:site_name = "Default Store View"

Nothing has been set in Stores → Configuration → General → Store Information → Store Name. The resolver prefers that value (the merchant-facing brand name) and only falls back to the Magento store view label when it's empty. Set the Store Name per store view and re-flush caches.

og:image returning an absolute URL for the placeholder even though a Default OG Image is uploaded

The uploaded file must live under media/panth_seo/og/ — the backend model Magento\Config\Model\Config\Backend\Image stores it there automatically when uploaded via the admin form. If you moved the file by hand, move it back or re-upload via the admin. The resolver also rejects values containing .., backslashes, leading /, or null bytes as a path-traversal guard.

Tests pass but Facebook's preview still shows the old image

Facebook aggressively caches OG data. Open the Sharing Debugger, paste the URL, and click Scrape Again. Twitter/X and LinkedIn have equivalent controls. The resolver does not cache OG data itself — the stale preview is server-side on the scraper, not the store.

Support

• Agency: Panth Infotech on Upwork
• Direct: kishansavaliya.com — Get a free quote