When using a shortcode in the page or post editor that executes images on the front end, will not hook into the meta property og: image or alt or title

[X] I've read and understood the contribution guidelines.
[X] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

When using a shortcode in the page or post editor that executes images on the front end, will not hook into the meta property og: image or alt or title. Infact no information from a shortcode in the post - page editors executed by shortcode can hook into the Yoast Metas or any known OG plugins. There are no known WPSEO filters that allow this to work either. There are no other Shortcode Plugins that can make this work. Even the stock Gallery [gallery ids="1, 2, 3"] wordpress out-of-box shortcode will not make this work. Having suspicions that this is a Wordpress CORE issue, if it cannot be patched or fixed via 3rd party plugins or functions added to the themes functions.php file. I am classifying this as a bug report instead of a featured request, because I did actually find one featured request here asking about this issue, however I am sincerely asking for support from Yoast to classify this as a bug, in which I am believing it might be possible for a new version of your plugin to be released that can potentially fix this, maybe it cant without many cumbersome measures as suggested by one developer already, then I would continue to bug Wordpress Core to see if their is anything they can do in their future releases.

Please describe what you expected to happen and why.

Developers need to be able to execute dynamic content and media via shortcodes in the wordpress post and page editors and have yoast be able to interpret the content executed by the shortcodes correctly to parse image attributes for the open graph meta and protocols for social networks and search engines when applicable. PLEASE PLEASE let this be classified as a bug. This is extremely disheartening to developers. Maybe its a wordpress core issue, im uncertain at this moment. I call upon all website owners and website developers to try to understand that this is a major problematic issue and to test your own sites for this and support this cause, it might be the only way to get yoast and or wordpress core to fix it without theme and plugin developers doing massive amounts of function filtering on a theme by theme basis.

How can we reproduce this behavior?

Fresh WP install, add a few pictures to 2017 theme media library, place shortcode [gallery ids=""] (id of the images) into the post or page editor. Executes fine on front end, but look at source code in the head section for the og:image. Will not register.
Research and testing and other thoughts have been produced here by me. Exhaustive testing and research done to no avail.

https://wordpress.stackexchange.com/questions/306973/property-ogimage-doesnt-register-with-including-a-php-file-as-a-shortcode-in

https://core.trac.wordpress.org/ticket/44470#ticket

https://github.com/Yoast/wordpress-seo/issues/6110

https://github.com/Yoast/wordpress-seo/issues/9827

https://kb.yoast.com/kb/can-i-add-data-to-the-page-analysis/

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Technical info

WordPress version: Version 4.9.6
Yoast SEO version: Newest Version 7.7.1
Relevant plugins in case of a bug:
Tested with theme: Twentyseventeen

[gallery] shortcode produces <meta name="twitter:image" including the correct img src of only the first image in the gallery only with no alt or title anything though. No regular og:image or facebook og protocols are available or other content attributes are available when executing content and media via shortcode in the post or page editors. Plus even though one twitter image meta might work its important to note that there should be multiple og:image metas if using a gallery probably or if multiple images are in the_content

Hello,

Thanks for sharing your issue. I'm afraid I don't think I completely understand what the problem is, so allow me to ask a question to get started in exploring...

You say that images contained within / executed by shortcodes can't be hooked/filtered (e.g., via wpseo_opengraph_image), and therefore added into the open graph tags. I'm not clear where/why this is the case - from my understanding, it should be relatively straightforward (depending on how the shortcode has been developed) to parse the_content, read the results of any parsed shortcodes, and take appropriate actions based on if images are discovered. Which part of this process isn't working for you?

Now, some more general points:

This isn't a WP Core issue, as core doesn't do anything with/to Open Graph tags (as much as I personally agree that core should output OG tags).
Before we can classify this as a bug or a feature request, I need a better understanding of the problem - I'm still not really grasping the specific issue you're having. Perhaps you could try and explain the specific technical issue in more detail, with code examples, screenshots, and URLs of live examples?
Even if we resolve the technical issue (if there is one), I don't have any good answers to the issues I raised here, around how we should infer preference/priority based on discovered images. I'd appreciate your thoughts.

Thank jono-alderson and I really honestly appreciate your attention and help on this matter too. So Thank you. So I didn't see any research or filter attempts with wpseo_opengraph_image at all anywhere on the internet that allows a WP site to execute a [shortcode] in the post-editor that will parse the the_content output of the [shortcode] like the <img> including the attributes and image source like this <img src="https://www.example.com/page-1/wp-content/uploads/file.jpg" alt="example" width="500px" height="300px"> into the <head>

Meaning what happens when you use a shortcode by default of any kind when all installations are fresh and out-box using a 2017 theme is as follows

<head>
<meta property="og:locale" content="en_US" />
<meta property="og:type" content="article" />
<meta property="og:title" content="Same as SEO Title" />
<meta property="og:url" content="https://www.example.com/page-1/" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Same as SEO Title" />
<meta name="twitter:image" content="https://www.example.com/page-1/wp-content/uploads/file.jpg" />
</head>

No og:images, except for twitter image but certainly no other attributes even if the twitter image is picked up.

So would'nt you have to agree that it certainly doesn't do this by default when placing a [shotcode] into a wordpress post page if that shortcode is supposed to display an image?

If you take a stock wordpress [gallery ids="1, 2, 3,"] (replace the id's with the ids of your images) in the media library and insert that gallery short code in the post-editor. The <head> example I showed above is exactly what happens.

Ok Now if you manually insert images into the post-editor the traditional old fashioned way like many users do all day, then every thing works fine, it shows and registers like this.

<head>
<meta property="og:locale" content="en_US" />
<meta property="og:type" content="article" />
<meta property="og:title" content="Same as SEO Title" />
<meta property="og:url" content="https://www.example.com/page-1/" />
<meta property="og:image" content="https://www.example.com/page-1/wp-content/uploads/file.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/page-1/wp-content/uploads/file.jpg" />
<meta property="og:image:width" content="500" />
<meta property="og:image:height" content="300" />
<meta property="og:image:alt" content="example" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://www.example.com/page-1/wp-content/uploads/file.jpg" />
</head>

We know that works, and that Im showing this example, above, to identify a minuscule issue ... notice how you have property="og:image" and property="og:image:secure_url" maybe I think if you have a proper SSL cert, which everyone should do these days probably, maybe yoast might want to code some more automatic intelligence to add one or the other and not both depending on whether you have an http or https site.

Everything above, I am also referring to a regular page in the example it is /page-1/ (with and without shortcodes)

Sort of a next separate issue

What is the default behavior for a static front-page when it concerns an og:image ??

it is as follows with and without a shortcode, using the normal post-editor behavior of inserting media images.

<head>
<meta property="og:locale" content="en_US" />
<meta property="og:type" content="website" />
<meta property="og:title" content="Home - Same as SEO title" />
<meta property="og:url" content="https://www.devsiteviewer.com/site-4/" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Home - Same as SEO title" />
<meta name="twitter:image" content="https://www.example.com/wp-content/uploads/file.jpg" />
</head>

Why aren't the og:image metas showing up by default on a static front-page? This was also tested with other og plugins and SEO plugins still exact same issue. I think its because Yoast actually wants you to go set a default image for the static front page in the yoast settings which is essentially the only way to get the og:image in there now by default. Problem is, you can only use 1 image right? When you set it manually for the front page, meaning it doesn't in my opinion have good default behavior. (again the twitter image shows up and works on the static front page but no image attributes are registered)

I am suggesting always good default behavior first with og:images, and then build upon the functionality of the yoast plugin to allow users to customize the og:images if they want to, and then per post or per page, allow a user whether its your premium version or not to allow a user to add multiple images only if they want to manually override the default behavior first.

Ok, why do I think some of this is possibly a Wordpress Core issue? I think its possible that a plugin can do what I am suggesting with [shortcodes], but maybe it cant, but if it can which it probably can, Wordpress core can certainly do some modifications to the post editor too, to allow many many plugins to work better to execute php more intelligently, such as display the contents of the shortcode, by getting the contents after placing the shortcode in the editor and display a visual representation of the shortcode in the editor, sort of the way they do it for the [gallery] shortcode, i think having some work done on the admin-ajax.php file is the way that is produced, certain tweaks with getting the array of images there might alter the [gallery] shortcode results in the og:image (Not 100% certain, but might be a good conjecture). Im not suggesting Wordpress Core needs to integrate OG protocols. So I want to be clear on that point, even though they should. Im suggesting that wordpress core change the behavior of how [shortcodes] are executed in the backend and front end just a tiny bit with ajax loading and filtering and echoing the content of shortcodes better, to remove the obligation for plugin developers to build out filters for this kind of stuff, because guess what, no plugin, or shortcode plugin or php insert to post-editor plugin can override the default behavior of how [shortcodes] are executed on the backend and front-end at least I don't think, but I could be wrong, but I certainly tested every shortcode plugin to see if it would do anything to parse the images so yoast og metas can grab them, and even tested with hard coded functions to generate the og metas to see if any advanced shortcode plugins might get the images while disabling yoast for a test or 2 anyways.

What am I overlooking? What research is there on the internet to allow a developer to build filters to parse the_content of the shortcode to register in the og:image metas? Also, I am requesting it as a bug , but certainly of course exercise as much advanced judgement on that as yall may want, im sure there are many other factors that have to be taken into account, that Im not considering here to require an update from your development teams, but because i believe many many sites are affected by this possibly, and if yoast can update to a new version of the plugin that can do this for everyone without any developers having to build or add filters then yoast will make Facebook, Twitter, Google + and images.google.com all a better place, and many many people might not ever ever understand why things are getting cooler and more visual on the internet so to speak. All websites that have shortcodes that execute images in the post and page editors, going to push out the links, you'd be surprised the functionality facebook and other social networks will grant website by default behavior if you make this possible within your plugin. In order to classify this as a bug, you may have to go under the assumption that too many sites on the internet that use yoast, execute galleries and images in the post-editor via shortcodes, and therefore cannot register by default in the_content those images through the og:image metas. If there is any solid research to help me with building filters for at least a stock gallery shortcode, in the meantume, would be a good place to start. Thank you kindly yoast team. Good day

jono-alderson, I wanted to continue on with this because I found some work around for getting the images that are executed and generated via shortcode.

This filter sorta kinda works.

add_filter( 'wpseo_pre_analysis_post_content', function ( $post_content, $post ) {
    return do_shortcode( $post_content );
}, 10, 2 );

It is essentially able to get the og:image:alt and height and width dimensions for WPSEO Version 7.7.3.

A few more problems are still bugging this down some though. Static Home Front Page, Cannot getting anything other than the twitter image, with no other information. This is a know bug, that I know you are aware of and your forums says it is scheduled to be fixed on the 7.8 release.

Other bugs though, forget about the shortcode filter for only a minute Ill get back to that, but on Version 7.7.3 (Tested thoroughly on clean WP installs and Clean Yoast Version installs) only gets 1 image on regular pages with 1 alt and the height and width dimensions, with that being manually inserted or hardcoded in the TINYMCE Editor for wordpress, and importantly again nothing happens on Static Home Front Page. And I promise you proper SEO default behavior is to list all the images with all the alts and all the height and width attributes. Something got broke in the last couple version releases again. And this is limiting behavior.

Ran tests on Yoast Version 7.3 before the upgrade to 7.4 which broke the Static HomePage. So I have to use 7.3 for websites right now. Nicely working with the Shortcode filter mentioned above but still the problem is when 7.4 was released, I believe it added the capability to get the image alt and height and width and 7.4 works with Shortcode filter just not on static homepage again.

This filter hook wpseo_pre_analysis_post_content Im Certain yoast is going to want to deprecate in future releases, infact I dont even think it works really all that great or well right now on 7.7.3, IDK somehow it works on 1 site but not on fresh clean install when testing it.

Yoast Claims in other research Ive done that the wpseo_pre_analysis_post_content is being undeprecated, but my history with your plugin suggests that it will be again and doesnt always work for some reason.

Asking that new version releases by default filter the content from the page without using a filter of any kind and get the shortcode generated content.

Asking that the new version, inject all images on the page with all the alts and size dimensions.

Asking that the new version, fix the known bug with the Static Home Front Page. You have to use version 7.3 to avoid this bug and as mentioned before 7.3 doesn't get the image alt or size dimensions.

Asking that the new version, utilize either one or the other property="og:image:secure_url" or property="og:image" because I do not think it is proper to have both right? Doesn't it depend on whether your site is https:// ? And to expand on this point a little bit, the intelligence Yoast needs coded is to understand that a particular image is served over https:// and if the image is not served over https:// it should default to property="og:image" which Yoast sorta does currently right now. Problem is if the image is served overhttps:// it injects both the secure url and the regular og:image, with both having the https link. I am open to hearing your thoughts on whether you should show both versions because some research has showed me that it might be good to do so, but my overall opinion after all my research because og protocols are unclear about this issues, leads me to believe that it is not proper to show both versions.

Final Conclusion: The main point is to get all the images from the_content while making Yoast Capable of natively understanding that images are generated via shortcode in millions of websites without the need for a filter and get all the images from the content on the static home front page as well, meaning to fix the known bug there, and while getting multiple images from the_content especially generated via shortcode also get all the alts and size dimensions with even those generated via shortcode as well, and lastly understand if the image is served with a secure_url or not and not have both redundant og:images.

Thanks Jono for all your time and effort on this. And look forward to one day having this all work super well in future Version releases.

I think I follow, but I'm afraid that I'm struggling to keep track of all of the moving parts in here.

Can you split out your bugs/feature requests into specific tickets, each focused on a single issue, and described succinctly and precisely?

It's difficult for me to read/process/understand the issues/requests in this format! :)

ok :)

First Issue

This Filter to get the images that are generated via shortcode

add_filter( 'wpseo_pre_analysis_post_content', function ( $post_content, $post ) {
    return do_shortcode( $post_content );
}, 10, 2 );

Got it to work on all Yoast versions from 7.0 to 7.7.3. It can be buggy and problematic though with the last 3 Yoast Version releases this month in July 2018.

The request is to Release a version of Yoast that does not require this filter or any filter in order to understand that images are being generated via shortcode in the tinymce post editor.

Second Issue

Since Yoast Version 7.4, a known documented bug exists in which Yoast cannot get the images from the Static Home Front Page, when they are placed in the homepage --> post editor or placed via shortcode in the homepage editor even with the filter. Even if you manually insert an image via the Yoast Meta Box through the sharing options of the homepage, by imputing the Facebook title, description and Image URL.

However setting a default image through the plugin settings still might work. That is limiting default behavior, if the only work around is to manually set a default image through the plugin settings page. I believe Yoast is aware of this already, I would just love to see this fixed more than anything as soon as possible :)

Third issue

Is it proper to have both property="og:image" and property="og:image:secure_url" identifying the exact same image source? I think OG protocols are not clear on this issue. If your website is not an https than yoast by default only injects one property="og:image" and that is correct to do

However the tequest is to have yoast release an updated version that will understand automatically if Image is being served over http or https and only inject 1 meta property if the site is serving images over https than it should only inject 1 meta property and that 1 meta property will always use the property="og:image:secure_url" and not have both. Some research aruges that you should use both properties if the site is https, but I just dont think I agree with that though personally, open to hearing other opinions on that.

Fourth Issue

In the last several Yoast Releases, while we understand that on regular pages and posts, everything that is not a static home front page --> Yoast is only natively getting 1 og:image from the content, it expertly does grab the og:alt and size dimensions which is great. But why only 1 image? now?

This is to me is sort of a bug plus a feature request.

If multiple Images are loaded in the content section on all pages including the static home front page, get all the images and get all the alts and all the size dimensions in correct order from top to bottom.

This has not ever been possible to do, because in earlier releases such as 7.3 and earlier it was getting all the images but there is no capability to get the alts and size dimensions back then on the earlier releases.

So now we want to be able to do that and get all the images by default no matter what kind of page you are on and also get all the alts and size dimensions from top to bottom.

Eek, this is still a wall of text, and a whole bunch of mixed issues. I'll try and respond to them here, but in the future, can you create a distinct ticket for each issue, and follow the template provided please? It's very hard and time-consuming to read, digest, and respond to issues in this format.

1) I'm still nervous about this in principle, as shortcodes can cause unexpected issues. With their gradual deprecation as Gutenberg matures, I think we can park this for now. Feel free to keep using that filter to achieve your own desired behaviour, however.

2) I'm looking into this; it looks like we're still seeing some inconsistent behaviour where homepages aren't currently getting/setting the og:image values.

3) I've researched this heavily, and I'm happy keeping both values - there are some cases where it's explicitly required, and there's no harm in having both.

4) Setting multiple images can cause weird behaviour - check my research at https://yoast.com/advanced-technical-seo-social-image-ogimage-tags/. We're limiting it to picking the defined or 'best' image. If you'd prefer, you could use filters/functions to add all of them; but Facebook (and many other platforms) should already give you the option to sort through the images extracted from the page anyway - we're just specifying the 'preferred' image.

I'm going to close this thread, as it's getting a bit unwieldly. If you've any other issues, or you feel like we haven't addressed these properly, feel free to open new issue - but please follow the templates, and only create one (well-documented, well-defined) ticket for each issue :)

Yoast / wordpress-seo