Wordpress-seo: Default Facebook share image not displaying

Created on 20 May 2016  Â·  12Comments  Â·  Source: Yoast/wordpress-seo

What did you expect to happen?

I set a default image in the Yoast SEO settings underneath Social -> Facebook -> Default Settings. I then created a post with no featured image, published it, and the default image that I set was not used.

What happened instead?

I checked the source code and it looks like every image in the post was added under the og:image meta tag. I disabled all other plugins but this problem still persisted.

yoastseo_og_image

However when I set the Facebook Image explicitly in the WordPress post editor, it worked properly.

How can we reproduce this behavior?

  1. Set a default image for Facebook in the Yoast SEO settings
  2. Create a new post with no featured image, but multiple images in the post editor
  3. Publish the post
  4. Check the source code or the Facebook debugger and see what image meta image is being used
    Can you provide a link to a page which shows this issue?

Unfortunately we don't have any posts published with this issue as our marketing team wants control over the share images for every post. I'm hoping you can replicate. I was able to replicate on my local instance of WordPress as well as WP Engine (our host).

Technical info

  • WordPress version: 4.5.2
  • Yoast SEO version: 3.2.5

I also saw this issue which might be related, but didn't mention the exact same problems that I was noticing: https://github.com/Yoast/wordpress-seo/issues/4404

social question

Most helpful comment

This is a bad design though. It should have the option to not pickup the images by default form the post content! Facebook Social Debugger is showing not the right image otherwise...

All 12 comments

I think you are missing a nuance in what the settings are:

  • Facebook image in social settings of _individual post_ is _priority_ image, it will be used _over_ any other;
  • Facebook image in social settings of the _plugin_ is a _fallback_ image, it will be use in case there _aren't any other_ images to use.

It says as much in plugin settings:

This image is used if the post/page being shared does not contain any images.

So behavior you observe is by design as of right now. If you want more custom logic you would likely need to customize it with hooks. Or just make sure every post does have image assigned explicitly, which seems to be the degree of control necessary anyway.

Does this makes sense?

@Rarst Excellent, thank you for elaborating on that, that make sense to me. It looks like I'll have to write a custom hook to accomplish what I'm looking for. I appreciate the feedback!

This is a bad design though. It should have the option to not pickup the images by default form the post content! Facebook Social Debugger is showing not the right image otherwise...

@benmarten please consider opening new issue with specifics of your problem. There are a lot of possible places for images to come from, it's impractically complicated to attempt to cover every possible configuration and provide controls for it.

@Rarst I do agree with @benmarten that this design is a bit confusing (granted it does say "This image is used if the post/page being shared does not contain any images." in the options panel). I don't see many different configurations for how this process could work. The plugin currently works as such (left being the first option that would be chosen by the plugin with options to the right overriding that):

Post with no images:

  • Default image in options -> Specific image defined in post editor

Post with images:

  • First image in the post -> Specific image defined in post editor

I would propose a process that allows for more flexibility for posts that have images in them. I think a flow like this might be desirable (and helpful) for people using your plugin:

Post with no images:

  • Default image in options -> Specific image defined in post editor

Post with images:

  • First image in the post -> Default image in options -> Specific image defined in post editor

By allowing users to specify a default image that overrides the first image in the post, you make it easier for people writing posts. Instead of manually uploading an image in the post editor to override the first image in the post, you can have an option that allows you to specify a default image. By adding an extra setting, you reduce the number of users that need to repeatedly upload or select the same image because they do not want the first image of the post to be used.

What do you think?

The current implementation works from most specific (to the post) towards least specific to the post. I get that you have different use case, but it re-arranges that logic into something different.

I will reopen and mark needs decision for consideration, but my own opinion is that this is behind the line where one should use filters to implement custom requirements.

I'm curious in what manner it rearranges the logic? I think the logic should be the same (most specific to the post to least specific) but we add one more point of specificity. I'd be curious to see what other people think though.

  1. Specific image defined in post editor (most specific)
  2. First image in the post (less specific)
  3. Default image in options (least specific)

vs

  1. Specific image defined in post editor (most specific)
  2. Default image in options (least specific)
  3. First image in the post (more specific)

Okay, I see what you're saying when you mention rearranging the logic and I could understand an argument for both sides.

What are your thoughts on a solution that could provide both options? What I mean by this is having a switch in the Yoast options that when turned on, flips the preference for first image in the post in favor of a default image in the options. This would allow both flows of logic based on the user's preference.

See above — my personal opinion is that this is not worth complicating UI for. It should very well be possible with hooks for cases that need it.

The core of my business and experience is with Facebook. From users using plugins for this functionality, most people actually want the best of both worlds.

There are big pros and cons to either switch of that logic. While I agree with you that cluttering up an interface is bad... there really is a big difference available here that does lend itself to a toggle.

Personally, I most often want the behavior we use today, but there are sites where having the other would certainly be advantageous.

The problem with setting the logic for the default image to trump images "in the article but not specified" is that it is the behavior that is LEAST like Facebook's behavior when our plugin is not present. When our plugin is not in use, Facebook looks at what images are available that are big enough. Sure, these are "implied" but they still functionally work. If we move the default image logic in front of that logic, we move away from approximating Facebook's default handling, which, if done, I think does call for either a toggle or hook.

The general use-case is to have the most specific image for a post. So we are not going to do this.

Was this page helpful?
0 / 5 - 0 ratings