Add filter for different open graph image

[deckerweb]

At first: thanks for your wonderful plugin, I love it! :-)

I want to suggest to add a filter for the open graph image.
That I way an image can be set for custom post type archives.
Alternative: add a setting so an image could be added via media library.

Example use case:
On a site for one of my plugins I have a CPT "docs" and also "changelog". For both I want to set a different open graph image - and not use the "global" website fallback image (from your settings).
So when I share those URLs, like example.com/docs/ or example.com/changelog/ that it will only use my set open graph images from the filter or alternatively from the settings.

Since I could not find any filter for this in the current version (v3.2.2) I am proposing this change here.

Thanks a lot in advance!

[sybrew]

Hi David,

Cheers 😄

There's a filter in place: the_seo_framework_ogimage_output

the-seo-framework/inc/classes/render.class.php

Lines 296 to 310 in 4374529

	/**
	* @NOTE: Use of this might cause incorrect meta since other functions
	* depend on the image from cache.
	* @since 2.3.0
	* @since 2.7.0 Added output within filter.
	* @param string $image The social image URL.
	* @param int $id The page or term ID.
	*/
	$image = \apply_filters_ref_array(
	'the_seo_framework_ogimage_output',
	[
	$this->get_image_from_cache(),
	$id,
	]
	);

Note that I'm going to overhaul the image rendering in the next major release. I doubt the filter above will be affected; however, it is why I'm not encouraging using alternatives (which would resolve the @NOTE). Ref: #403

As for your suggestion for integration: I'm slowly working towards this, and it's implied in the issues below.

1. Post Type Archive options meta box #20
2. ability to add/modify meta info for post format archives #275

[karex]

I'd like to suggest an improvement/fix, especially if the rewriting of this subsystem is in the works.

What I tried to do is to generate a special (overlay'd) image to use as og:image. I used the Facebook-default 1200x630 image size in this case, because it made things much easier while generating the image with the overlay. So it's actually a custom size of an attachment (this way it is more "standard" as I see, and for example I don't have to have another image with a lot of sizes, which would be an overkill). I used the the_seo_framework_ogimage_output mentioned above to specify that size's URL.

But the og:image dimensions are coming from the full image now. It seems that I'm neither able to filter them, nor to remove them. Am I right? The latter would be fine as well for a workaround for now, because as far as I know the og:image:width and og:image:height are not mandatory.

[sybrew]

@karex Are you suggesting that I should add a filter that defines the optimal dimensions when automatically optimizing the image, and/or when the user wants to crop the image? e.g., "I want it to be either square or large"?

If so, could you open a new issue?

The og:image:* dimension output isn't mandatory. It does help Facebook generating a sharing preview much quicker when those tags are supplied.

As for filtering the sizes on-demand, yes, TSF uses 'full'. You can filter that via the_seo_framework_og_image_args, changing the 'size' argument. Note that the filter will go away in the upcoming major update.

[karex]

@sybrew thanks a lot for the superfast reply and the solution! Yeah, the_seo_framework_og_image_args is the filter I have to use in my case.

I think I haven't suggested what you mentioned. Well, I don't know if I understood it fully. But generally I think it's ok that TSF goes with 'full' by default.

Hope the transition will be easy to the new filter. Thanks again!

[Glashkoff]

Will there be a replacement for the_seo_framework_og_image_args in future releases? I generate Open Graph Images through a separate plugin and would like to make compatibility with yours.

[sybrew]

Hi @Glashkoff,

Yes. But how this will work is still to be determined, and whether the old filter will still be available is also TBD.

Please subscribe to #403, where I'll present a full list of related API changes for v3.3.0. Just like I've done here.