Thanks, although I already have that tab open, and I’ve read through and confirmed none of those steps are the issue, except maybe the third step.
Still hoping to hear from somebody — I already read the support docs on the developer’s site, that’s why I came here.
If you can see in the debugger (or source code) that the og:image tag is correct, then All in One SEO Pack is doing its job. We have no control over anything once it’s sent to Facebook.
I am having the same problem. If you specify the image under “Custom Image” by pasting in the URL of the image, it does not work. If you select an image under “image” (where it gives you the radio buttons for options) then it DOES work.
Have been using AIO for a long time and have always used the “custom image” option without issue. Tried multiple times this time and using the image picker was the only way I could get it to work. Definitely something going on.
p.s. in the image debugger the “og:image” tag is NOT correct when using “custom image”
-
This reply was modified 8 years, 9 months ago by
Matt.
-
This reply was modified 8 years, 9 months ago by Matt.
I cannot reproduce this on an new site or any existing site.
Please check the source code of your post or page and see if the og:image meta tag in the All in One SEO Pack section is the correct URL. Make sure you don’t have any other og:image tags in the source code.
If you need further support then please provide the URL for your post and the URL for the custom image you set on that post.
I went back and found an old post because I didn’t want to mess up the one I just fixed. This post: http://www.abington.k12.pa.us/news/abington-senior-high-school-sculptureceramics-and-national-art-honor-society-students-create-fund-raising-bowls-for-annual-event/
Previously had this image set as a custom image (and it worked fine at that time): http://www.abington.k12.pa.us/media/posts/2015/12/2015-Empty-Bowl-Taylor-520×245.jpg
I just went in and changed the custom image to this: http://www.abington.k12.pa.us/media/posts/2015/12/2015-Empty-Bowl-Taylor-720×340.jpg
Now when I re-scrape it in the facebook debugger it warns me at the top:
Provided og:image, http://www.abington.k12.pa.us/media/posts/2015/12/2015-Empty-Bowl-Taylor.jpg could not be downloaded because it exceeded the maximum allowed sized of 8Mb or your server was too slow to respond.
(which is not the correct image)
I’ve confirmed that the generated OG:image tag from AIO is the correct URL.
There are no duplicate tags, and nothing else generating OG meta information.
When I run the post through the facebook debugger, the ‘raw tags’ section has the correct og:image tag. The preview, however, still uses the incorrect image, despite the raw tags reflecting the correct image path.
However, when I re-scrape the post (again, it’s almost always twice), the meta information is updated to the correct preview image.
In order to temporarily resolve the incorrect posts (that have already been published to facebook), I’m isolating each post on the client’s feed (by clicking on the timestamp associated with the post), and choosing the ‘refresh share attachment’ option on the screen that follows.
One possible source of this issue might be the auto-caching that Facebook does. Our client uses a WordPress plugin called NextScripts to auto-post to their social media accounts — we were seeing repeated issues when the auto-poster was set to publish immediately; I set a delay on the posting to Facebook and that seemed to help slightly…
Just hard to narrow down which of the three entities the issue is coming from. I’ll have to wait for another broken post to be able to provide relevant evidence — as I mentioned, since I set the auto-posting delay, each of the 6(?) facebook shared posts made since then have translated successfully.
@syntax53 I have confirmed that there is a bug with directly pasting an image URL into the Custom Image field. I have opened an issue for this in Github here – https://github.com/semperfiwebdesign/all-in-one-seo-pack/issues/1074 and we’ll fix this in the next release.
@emmettn This is the usual Facebook caching issue and not something we can help with but thank you for the information.
