Opened 6 years ago
Last modified 6 years ago
#44470 reopened defect (bug)
meta property=“og:image” doesn't register if an image is executed via a shortcode in WP Post and Pages
| Reported by: |
nlstm
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | critical | Version: | 4.9.6 |
| Component: | Editor | Keywords: | dev-feedback needs-patch |
| Focuses: | Cc: |
Description
I want to try and explain a WordPress core issue and bug, in which I dont feel there is an available solution, at least I dont think after exhaustive research. I ran many many tests on fresh WP installations and twenty17 themes. And some may suggest this is a 3rd party plugin issue, while I am suggesting that it is both a Core and 3rd Party Plugin issue with the most widely used plugin in the world perhaps WPSEO. Applying shortcodes to WP post and Pages, of course it renders fine in the front-end, the output code that is. However, many recent updates to social media platforms Open Graph Protocols. The WPSEO plugin cannot understand that an image <img src="file.jpg"> is being executed via php through a shortcode, unless the image is hard-coded directly into the WP page editor then it works fine. Problem is, no image executed from literally any 3rd party plugin shortcode contained within a wordpress post or page will execute the meta property="og:image" in the <head> .... In short WordPress Core does not support opengraph functions or plugins when shortcodes are being used.
one of the last tests to try to continue to prove this is a WP core issue from their last several updates, that I am certainly of course trying to gain some attention on, that even an out of the box wordpress stock short codes like [gallery ids="21"] to display images, cool enough that it displays visually in the post editor, still impossible to hook into the main property=og:image meta. Of course the other primary issue, no rhyme or reason either that a static front page cannot display the meta in the <head> either by any know third party plugin or hard coded functions in the theme directory. Being that exhaustive testing has been done, without the modification of stock wordpress core files, continues to lead me to believe that this is a core issue again.
And after a lot of I intelligent research I believe wordpress next core update should fix this. Please read some other additional testing I have done on this issue as well. I am certainly trying to gain some attention to this issue because developers need to be able to execute php via shortcodes into wp post editors therefore execute images in a dynamic way via short codes and still be in compliance with al know third party plugins like yoasts og: settings and the social media platform og protocols. https://wordpress.stackexchange.com/questions/306973/property-ogimage-doesnt-register-with-including-a-php-file-as-a-shortcode-in
Change History (8)
#2
@
6 years ago
I agree in principle that open graph tags should be supported in core. They're a basic universal standard, and it's a little embarrassing that WP doesn't handle basic representation of content on third party networks without a plugin.
However...
I'm not convinced that we should be trying to intelligently sniff for images in shortcodes, for a number of reasons.
- We'd have to execute those shortcodes in the process of evaluating the_content, which is a bit performance heavy, and messy in multiple regards (we have no idea what they'll do / output).
- We'd then need to parse the resultant HTML to detect any if any images exist, and then, try and extract and parse them. This is riddled with issues, performance considerations, etc.
- There are no hints in those images as to whether they're the preferred OG image(s), or what their additional attributes (like the alt or dimensions etc) should be, which requires a lot of inference + guestimation, and another (albeit minor) performance hit
Lastly, Open Graph support from the platforms (Facebook, WhatsApp, Twitter, etc) is erratic at best (see my research at https://yoast.com/advanced-technical-seo-social-image-ogimage-tags/), so I'm nervous about 'fudging in' extra images, there are already frameworks for registering and hooking them in.
Having said that... At Yoast, we actually parse the shortcodes, and look for images already, if I'm not mistaken.
So... I think that your best course of action is probably to identify the use-cases where you'd want an open currently only accessible in a shortcode reside, and patch the problem for your own requirements, or collaborate on an addition/enhancement to the Yoast SEO plugin via our GitHub (https://github.com/Yoast/wordpress-seo) - I'd love to see some use-cases!
#3
@
6 years ago
- Keywords needs-patch added
- Resolution invalid deleted
- Status changed from closed to reopened
I'm going to always continue to respond and move forward on this issue, until I can either solve it, or a lot of research has been produced, I am moving forward with trying to gain continued attention to this matter and or prove it unworkable with Wordpress Core, because Open Graph Functionality is a primary focus of marketing work being done on websites. Firstly, Yoast CANNOT parse any shortcodes that execute images, to register the image source in the <head> metas, show me a filter or an example that can and I will admit defeat. From what I can tell that issue was first defined on the internet in November 2016 found here --> https://github.com/Yoast/wordpress-seo/issues/6110
I did also infact test older versions of yoast 2.5.3 and --> v3.0.4 and I think was updated on November 25th 2015 which deprecated a lot of yoast add filter settings, I mention that because something in my continued research pointed me to trying to use that version to avoid the shortcode execution problem I was having. I guess I dont know how to explain my thought process on that at this point, I just know it didnt work, maybe because I thought it did before November 2015, but that was also a way earlier version of wordpress core as well too. Regardless though.
To respond to @webdados I respectfully disagree with your humble opinion. Your plugin by default as well as yoast and every other single plugin for Open Graphs, and every single piece of functional code for open graphs all in which accomplish the same task, by default picks up the image src if they are hard coded in the post or manually inserted into page editor.
og:Image size metas and og:alt metas are removed from the head in the known plugins if the developers remove the html attributes for them anyways by default, so it doesnt matter on that point either, plus the social media platforms with their OG protocols are intelligent enough to know the size of the image without attributes as well as know if an alt or title is present or not. The Image Size and image alt and title metas are important to use through for SEO and to basically crop the image for facebook manually and detail better information for the fb protocols so they don’t do it manually for you.
@webdados Your comment is asking developers to perform tedious work and tasks in which we should have automated in which your plugin does so as well as yoast does it too right but again only if manually placed in the post editor?? But now youre saying if a shortcode placed in the page or post editor that we have to manually set the image through both of your heavily loaded post-editor meta boxes, that I like to disable portions of anyways by theme default. And but, as far as I can tell, both yoast and every other plugin that allows us to set the image which is fairly nice to be able to do for less skilled developers, you can only set 1 image, Which destroys an ability to create sliding image carousels on facebook and other more intelligent features you can do, that essentially can be automated, because you can only by default set 1 image per post with all these OG plugins. Having multiple OG image metas is important to have in the head section, because when you push the link out to facebook or other social platforms including google and bing, you can adjust there very quickly on their platforms if you want them removed before you click the share and post button, which means 99% of the work is done for you.
Again, so if you have to manually set an image because your plugins wont parse shortcodes that contain hardcoded images, and the shortcode is inserted into the post-editor, then the only workable alternative is to hardcode and write content the old fashioned way, again meaning no php functionality executed within the post editor will work with OG metas on your plugins.
Adding multiple images manually the old fashioned traditional Wordpress way through the post editor, it's tedious work and not worth it. If I have to manually set the images that I want on 300 page websites, I mean thatd be a complete trip to hell maybe ya know.
This is the suggestion I am trying to make, is there anything that a plugin developer can do within your theme functions to make this work with OG plugins or to create your own og plugin or functions to make this work WITHOUT modifying any wordpress core files? If it is impossible to do so then it is a wordpress CORE issue or an issue with the most widely used plugin in the world Yoast.
You have to have the ability to USE SHORTCODES in the post editor and still get the same functionality. Again Even with STOCK WORDPRESS SHORTCODE FOR THEIR OWN IMAGE GALLERY SHORTCODE [gallery ids=”1, 2, 3,”] will not automatically parse on any know OG plugin.
Lastly, a Marketing tip and GOOD Practice to always follow, if you intend on sharing post and page links to facebook or other social networks, like many many do, then you want to organize your images, on your post from top to bottom structuring in an intelligent and ordered way, (which is the default way yoast and other og plugins parse the content anyways) also good for SEO on search engines as well, to understand that the first image inserted is your featured image, then your 2nd image inserted is you second featured image and so on, and in that way you automate the OG protocols on facebook, as mentioned earlier before you hit the post button on facebook or other Social Post-Pushing plugins like JETPACK, you can remove certain pictures, instead of trying to find the ones you want to use and manually insert them the way @webdados suggested or yoast allows too. The only reason yoast and og plugins have that feature is to override the images contained in the content if you want to.
And as far as what @jonoaldersonwp suggested about some of cumbersome problems associated with what I want to get accomplished here, hes not necessarily wrong that it is infact cumbersome for a plugin developer to do and get streamlined, so I push it to WORDPRESS CORE to adjust the way it interprets shortcodes in the post-editor to be able to pull the array of images from the content and their attributes the same way It does for the [gallery ids=”1,2,”] shortcode and grant the ability to editor to understand that is code first before it is outputed and executed I think maybe. Which logically if I think about this all correctly is leading me again to believing this to be a wordpress core issue because it cannot interpret an array of images in the content if it is a shortcode not even for their own gallery shortcodes. I HATE this that theirs no known good solution you have to use shortcodes in wordpress if youre ever going to place well crafted and dynamic code in the post-editor.
Wordpress core might have to ability to make some changes to the tinymce post editor and grant the ability for the Post-Page Visual Editor to understand very intelligently the content being inserted via a SHORTCODE, because I think if that can be accomplished by Wordpress CORE default then no filters or modifications ever have to be made by theme and plugin developers, which is suggesting that wordpress core should and ought to consider caring because a primary focus of wordpress is to push content to the search engines and social networks, which also means wordpress core doesnt have to enable OG protocols they just have to more intelligently understand what the contents of a shortcode are within the wordpress admin post editor before it is executed on the front-end, I THINK maybe. Thanks for reading and caring. This is the worst issue Ive ever faced with wordpress. I’m probably going to continue to light of the internet on this, until someone cares as much as I do about it or can prove their is a known solution to at least the [gallery] shortcode as a simple test. If a filter can be added to fix this with the og: plugins ill cave, plus im sure developers will be interested in knowing about this issue and want patches and fixes for the future, if wordpress core cant do it. And again I strongly disagree with what @webdados, because the best practice is to by default get the images from the content section of the site only per post or page, having to manually add filters to a website on a per post and per page is what I think you were suggesting is a bad practice, and only good for maybe small websites 10 or 20 pages. Developers want good default behavior first then specific customization after.
#4
@
6 years ago
I still think the open graph image should be set explicitly, either by using the post featured image, a custom field, or a WordPress filter. Getting it from the post content is the last resort and Facebook already does that on the final HTML, no shortcodes hassle whatsoever. (And yes, I also do that on my plugin, but I do not parse shortcodes. God knows what each and every shortcode does each time he's parsed and I don't think I want to mess with that.)
I strongly disagree with this: "the best practice is to by default get the images from the content section of the site".
Maybe Open Graph tags will be supported in core sometime in the future but with Gutenberg around the corner, I seriously doubt "parsing shortcodes to find images for Open Graph" will ever be something implemented in core. WordPress is moving towards making shortcodes deprecated.
This ticket was mentioned in Slack in #core by nlstm. View the logs.
6 years ago
#6
@
6 years ago
I don't disagree with your strategy necessarily. A client would love that ability of course. A developer doesnt. You're strategy requires extra work for a developer, my entire point is a default behavior first which sets the priority to the_content images, if a client wants to change and override that priority then that's fine.
But as a developer, I would never care to manually find an image and put that URL in a field, it's extra steps. Why wouldnt I just put the images in the_content section post-editor, appropriately according to a priority the developer chooses and human behavior is to always show your best images first when writing in the post-editor, because then I will know without thinking at all that a specific image will show first and it's always going to be the first image in the content then the second one and so on.
I would want this as an automatic feature, if someone wants to override it by all means great to have that ability.
What I am also trying to accomplish too by this is get some of the top OG plugin developers like you, some extra insight on a topic that I care a lot a lot about. I personally dont want to have to build functions or plugins for open graphs, if I can get some of the top ones to build out extra functionality.
I am willing to continue on with the research and help in anyways, and if I figure out any filters or solutions I will post them, but I have a lot of other projects I need to do instead of building filters this month, and the filters I sometimes find often get deprecated after a few updated versions of a plugin.
Main goal right now above anything is figure out how to get shortcodes within the content to register in open graph metas in the head, like I said no advanced shortcode plugins, php insert or any og plugins right now can accomplish this, Im worried about that being a wp core issue because of the post editor limitations when executing a shortcode.
I appreciate your thoughts, and I agree that you are right in principle, but your principle requires thought processes in real time by real people to accomplish it. My principle is automation. Just two different strategies in which both are right.
Lastly Facebook does a few things with images even if no og: protocols are there at all, but facebook does not do it well, caching bugs, constant refreshing is the problem currently when suggesting facebook does a few things natively, and takes a good amount of time to get facebook to do something natively without og: protocols. But agreed their native practices for Facebook, Andriod, and IOS are the_content if no og protocols exist. Keep in mind, facebook is not the only network I am considering, either, images.google.com indexing is important for og:protocols and other social networks that have bad native behavior for website images or no behavior at all, which is why you want a default behavior. And you want more than one og:image meta more often than not, looks nice on the social networks and provides more options there if you want them. A user can override the og:images with their own custom pick or simply turn off the default behavior right? Dont forget [shortcodes] are the main problem in the_content for registering og:images automatically is what this is about nothing more. Thanks @webdados I dont disagree that your strategies are actually best here, it just requires more time and work, when I want it automated by default first like how yoast does, they just cant parse shortcodes that execute images either right now.
#7
@
6 years ago
If Open Graph ever comes into core (which I doubt will happen anytime soon, <title> support is quite recent for example), I predict that:
- The OG image will default to the featured image and not to the images on the post content. That’s what most people expect (even if you disagree). Major plugins do this for a reason.
- You’ll still be able to change it using filters / actions.
- Shortcodes will not be processed to scan images just for open graph. It’s just too much hassle. And also, Gutenberg.
I understand your needs but I wouldn’t have much faith this will ever going to happen. It’s just not that important for the future of WordPress. Also, most people would say this is plugin territory. (And I agree)
#8
@
6 years ago
We are spending all this time debating about open graph protocols. This is 100% NOT the point Im trying to make for Wordpress Core!
The Only Point is, to execute [Shortcodes] in a better way. Tweaks to how the post-editors can get the_content, buffer the_content, and display the_content using ajax within the post-editor and then echo properly on the front end applying the same standard filtering and buffering it does the same as if it is manually placed or hard-coded in the post-editor. That could solve many many issues for many many plugins that have to hook into the wp_head and wp_footer as things are right now without having to manually hard code tons of filtering on a theme by theme basis in the function files, is my best guess and conjecture right now. Because all shortcode plugins, php insert plugins are all having plenty of problems doing just that and requires a ton of time to build out filters and buffering to make it work. Im mentioning this because Wordpress Core is getting real close to being able to do this with their own standard shortcodes such as the [gallery] one, they are almost there with it. Im just mentioning OG hooks into the head as an example, that I am just dismayed about right now.
This is NOT a WordPress Core issue. WordPress does NOT output OG tags.
This is related to SEO and Open Graph plugins that, IMHO, shouldn't mess around with themes shortcodes.
If the themes use shortcodes to display so simple thins as images, and they want that image to be the open graph image for that post, they should hook into the available SEO / Open Graph filters and set the correct image.