Jetpack share og: tags missing in FSE themes if you do not enable legacy sharing - JP 13.8-beta

[verytwisty]

Impacted plugin

Social

Quick summary

Not sure if this is a bug or expected behaviour and just some text needs to be updated.

I am working on a FSE theme and want to add the share button blocks to my templates, which all works well :)

I enabled the JP sharing toggle in wp-admin/admin.php?page=jetpack#/sharing and the following message appears:

You are using a block-based theme. We recommend that you disable the legacy sharing feature above and add a sharing button block to your themes’s template instead

So I disabled the sharing toggle and just added the share buttons to my theme template, however I noticed that with the sharing toggle switched off, no og: tags appear in the html on any post or page.

If I switch the share toggle back on the og: tags appear as expected. I'm not sure if it is expected behaviour that when the share toggle is off, the og: tags should not appear in which case perhaps revise the error message as it is a bit confusing as is.

If og: tags should appear on FSE themes when the share toggle in off, they need to be added to the header...

Steps to reproduce

1. Install a FSE theme & jetpack
2. Add share icons to the FSE theme templates or posts / pages
3. notice there are no og: meta tags in the html of any post or page
4. Enable the legacy sharing feature in wp-admin/admin.php?page=jetpack#/sharing
5. Notice the error message saying you should switch off legacy sharing on FSE themes
6. Go to any post or page and notice the og: meta tags are present in the html

A clear and concise description of what you expected to happen.

og: meta tags should appear on FSE themes OR clearer instructions on how to get this to work on FSE themes

What actually happened

No response

Impact

All

Available workarounds?

Yes, easy to implement

If the above answer is "Yes...", outline the workaround.

Enable the legacy share button

Platform (Simple and/or Atomic)

No response

Logs or notes

Using JP 13.8-beta

[jeherve]

The Open Graph Meta tags are indeed only added when either the Sharing or the Jetpack Social feature is active: https://github.com/Automattic/jetpack/blob/aa816c8667a92c30815b794d6eeb5ad19732e776/projects/plugins/jetpack/class.jetpack.php#L1961

While this made sense when the only way to add the sharing buttons was to enable the module, the logic is no longer correct when you can also add sharing buttons to your dashboard via a simple block. We'll need to fix this.

[spsiddarthan]

@jeherve, Would it make sense to have a separate section or module dedicated to managing OG tags? As you pointed out, we currently depend on whether a post has share buttons or the publicize section enabled. I'm wondering if being more explicit about this would be beneficial.

Something like:

if ( in_array( 'og_tags', self::get_active_modules(), true ) || in_array( 'publicize', self::get_active_modules(), true ) || in_array( 'sharedaddy', self::get_active_modules(), true ) ) {

[jeherve]

Instead of adding new settings, I'm wondering if we shouldn't just expand the logic to check:

• If Sharing is enabled
• If Publicize is enabled
• If the theme if a block-based theme (wp_is_block_theme) and a sharing button block can be found in any of the page templates.

[spsiddarthan]

If Sharing is enabled If Publicize is enabled If the theme if a block-based theme (wp_is_block_theme) and a sharing button block can be found in any of the page templates.

Thanks, that's better.

[verytwisty]

@jeherve This sounds good, but I just wanted to note that you can add the social sharing icons to any post, page or CPT without adding them to a page template and they should also have Open Graph Meta tags if they have been added in this way :) (and not added via a page template)

[jeherve]

@verytwisty That's true. I'm not sure that's a scenario we'd want to support in Jetpack though. I don't believe it is how most site owners will use the sharing buttons, and most importantly, checking for the presence of sharing buttons on each post and page would mean an additional query on each page load, parsing the post content to look for a specific block. This could have a performance impact that wouldn't be ideal.

Is it how you've added the buttons to your site so far?

[verytwisty]

@jeherve I have just been adding the buttons to the templates, but I think a lot of site users would probably just add them manually.

Obviously checking for buttons on each page load is not great, perhaps we could have a toggle whereby the social sharing icons block is not available until you hit it so you can check whether this has been activated for FSE themes.

Or possibly adding a toggle to the social sharing block itself asking if they want to add the Open Graph Meta tags with this option saved in the DB?

[jeherve]

I'm wary of adding one more option / toggle, especially for something that doesn't appear anywhere on the site, and that is a bit technical for folks who are only getting started with website management.

@keoshi I'd be curious to have your take on this.

tl:dr: Until now, we've automatically enabled Open Graph Meta tags on any site using either the Publicize or Sharing module on their site, and as long as they weren't already using another plugin to manage Open Graph Meta tags. In today's block-based theme world and with the newer Sharing buttons block in Jetpack, you end up enabling sharing buttons and thus encouraging your visitors to share your posts on Facebook, even when no Jetpack module has been activated yet. In that scenario, how should we enable Open Graph Meta tags in your opinion?

• Should we automatically add them as long as we find them in a block theme's page templates (i.e. if the site owner has added sharing buttons in the site editor)
• Should we introduce a new toggle in Jetpack > Settings > Sharing? This toggle would have to support all scenarios (legacy and new) as well as the conflicting plugins we automatically manage today.
• Should we introduce that toggle somewhere else?
• Should we do something else entirely?

Thank you!

[keoshi]

Hey, @jeherve — thanks for the ping.

As I understand it, we have two different issues at play here:

• The toggle above is incorrectly connected to outputting OG meta tags.
• We need a more robust system to support OG meta tags function, regardless of theme type.

Is that correct?

Ideally, it would all just work. But I understand that running a query on every single page to see whether Jetpack should output OG meta tags is very expensive and therefore a non-starter. I agree with you that that is a scenario we wouldn't want to support, being mindful of the impact it could have on site performance.

Should we automatically add them as long as we find them in a block theme's page templates

This seems to hit a sweet spot between expected Gutenberg/site editor functionality without being a hit to site performance. Seems like the smart solution and one that feels future-proof.

Making it a more explicit option (e.g.: “☑️ Enable Open Graph meta tags on your site”) could also be an alternative for bringing more visibility to this benefit. It's a bit on the brute force side of things, but could help differentiate the two settings: sharing buttons and OG meta tags.

What would be the impact in this latter scenario? I imagine it's just enabled in all pages, so the performance hit is negligible (apart from the obvious generating of the tags)?

[jeherve]

Is that correct?

Yes.

This seems to hit a sweet spot between expected Gutenberg/site editor functionality without being a hit to site performance. Seems like the smart solution and one that feels future-proof.

Agreed. This would be my favorite solution.

Making it a more explicit option (e.g.: “☑️ Enable Open Graph meta tags on your site”) could also be an alternative for bringing more visibility to this benefit. It's a bit on the brute force side of things, but could help differentiate the two settings: sharing buttons and OG meta tags.

What would be the impact in this latter scenario? I imagine it's just enabled in all pages, so the performance hit is negligible (apart from the obvious generating of the tags)?

I'd say the biggest impact of such an option would be cognitive. Site owners would have to purposefully go and enable the option (unless we were to automatically enable it I suppose), understand what it does. I'm not that worried about the performance impact (like you said, apart from obviously generating the tags).

[verytwisty]

Another option I have just thought of (but perhaps for the future if you refactor the sharing buttons to use the interactivity API) is that you can output the icons on the front end via the render.php function, and as part of that file you can add an action that will output the Open Graph Tags in the wp_head.

<?php

add_action( 'wp_head, 'add_jp_og_tags' ); // sorry not sure on the actual JP function name

?>

<!-- HTML of sharing icons go here -->

I have done something similar for a custom block I was working on and it does work to do it this way :) A little hacky to be sure but thought I'd put it out there!

[keoshi]

I'd say the biggest impact of such an option would be cognitive.

Agreed, @jeherve.

This would be my favorite solution.

Sounds like we have a winner then!

For the future, the solution above proposed by @verytwisty also sounds great.

[pablinos]

I've been looking at this, and I'm not sure of the best way of doing it. The share block might not be rendered until the footer of the page, and could be embedded in a pattern, which would make detecting it during the render of the wp_head very difficult.

I was thinking we could do some sort of initial scan of template files, which could be re-run as templates and patterns are saved, and cache whether the block is present in the database, but that would still require some thought as you need to know which patterns and templates will be rendered as part of the page.

For the actual post content we can use a has_block check, but that has the same shallow search problem.

I've been thinking about OG tag rendering a bit and how it would be good to standardise an API for adding meta tags to the head of the document, but that's a much more long term solution.

Maybe we could hook into wp_head very late, and check (using the new HTML parser API) if OG tags are present, and if not then always render the Jetpack ones? It seems generally useful and we'd only render them if another plugin hasn't already done so.

[jeherve]

Maybe we could hook into wp_head very late, and check (using the new HTML parser API) if OG tags are present, and if not then always render the Jetpack ones? It seems generally useful and we'd only render them if another plugin hasn't already done so.

I like this idea. It may be the most useful approach, assuming we still allow folks to disable Jetpack's OG tags like we currently do with https://developer.jetpack.com/hooks/jetpack_enable_open_graph/

I suppose that another approach could be to "just" add a new toggle in the Jetpack settings, letting site admins toggle the feature on and off.