0
Under review

Facebook refuses to pull child images

Nick 8 years ago in BLOX CMS updated by Christine Masters 8 years ago 23

I've been fooling with this all morning. I'll paste a link in and it gives me either our logo(which is set as the og_image on our site). I deleted that from the back-end because I never want that to show. Then it gives me the second child image. I want the first. So I set the second to "Do not publish" just to test it. THEN it shows the first child image. For crying out loud, why is this? And I'm not talking about an image the size of a fav icon. These images are in the range of 1296x864+. I know Facebook is particular about the size of the images. So it seems like for whatever reason Facebook only sees one image.


Here's one of the pages that refuses to display an image for Facebook: http://www.coastalillustrated.com/columns/community_notes/article_1f806700-eab3-11e5-b9ad-1b2a31f86771.html


Absolutely nothing comes up on Facebook for that one. Is it some way BLOX is displaying the images that prevents Facebook from seeing them? Are we doing something wrong?


I've read the BLOX documentation page and all it lists are the custom properties. These are URL custom properties but am I supposed to set it for ALL urls? Do I give the property og_image a value? The documentation says nothing about giving it a value. But all of the custom properties I know in BLOX have some sort of value.

Under review

Hi Nick!


Can you please put this in as a Customer Service ticket for this?


You shouldn't have to put in any URL properties, we fill that out for you on story pages.


If you look at the code on that page, you can see we are passing it the correct image as og_image:


http://www.coastalillustrated.com/columns/community_notes/article_1f806700-eab3-11e5-b9ad-1b2a31f86771.html


And, using the Facebook debugger, it does recognize that it sees that image.


That being said, there could be another error or something that our CS and developers should look at, so a ticket would be ideal. :)

It's really weird because I put it in Facebook and it loads our logo image. Then I go to the debugger and it loads the same. I rescrape it and it shows the image. Then I try to post the link again in Facebook and it works. It's the weirdest thing.

We've had a lot of issues with Facebook lately, too. Images, headlines and summaries may or may not be pulled in accurately. To get everything to show up correctly, we're running stories through debugger 2 to 5 times.

Nick, on your site I am getting an error in the Facebook debugger that your App ID is invalid. Is that an ID that you created? If not, you may want to recreate on specific to your site and then add that to your site settings.


Erica, I put a few of your stories through and I didn't see any errors. Do you see an error the first few times you put it in debugger or is it just not coming through.


Usually if we see issues with a vendor on both of our platforms (Zen AND Flex) it may be an issue with the vendor. We'll keep looking at it though!

I have been having this issue as well.

I had previously had it and put in a ticket. I didn't get any answers on why it was happening from the customer service person and it resolved after about a week, so I closed the ticket. She didn't seem to understand what I was trying to communicate to her, imo.

I have been Facebook debugging and I have the problem most often when using HootSuite. I've noticed that if I slow down and let my page fully load that I have it less often. I did a survey of other papers in our group and the majority of them said that they have this issue frequently.



I had the same problems with Town News' customer service. After reporting problems for more than a month, a Town News rep finally said on Minday that yes, there is a problem. (Although they say it's Facebook's problem, not theirs, and there's no ETA on when it might be fixed.)

I was told

Facebook will only update their cached image every 30 days. By submitting this to Facebook and telling them to rescrape the story, you're cutting out the default caching time.

But we're not talking about old stories. Unless Facebook scrapes it as soon as we post it but before we attach a child asset I don't know why it's cached the story without the correct image.

I just don't know why it's SO inconsistent.

Hi Maunette / Nick / Erica


Just wanted to give you guys an update on this.

As Christine mentioned above, this is an issue that folks are seeing on both Flex and Zen. Since nothing has changed on our end, this usually points to the vendor making a change of some sort. Our developers are currently looking at this and working with Facebook to try and determine if this is a bug on Facebook's end, or if this is a change that they've made which we now need to adapt to.


I'll make sure that this thread gets updated as more information becomes available. Apologies for the confusion.

We've also seen this problem (second child image instead of first) in the past, but doesn't sound like it has happened to us as frequently as you guys.

Hi guys! I just wanted to give you a quick update on this... We've identified some things that we think will improve this process. We haven’t changed anything with our Facebook sharing in a few years, but there appears to have been some updates with Facebook that are causing issues. It is possible Facebook may address these things on their side, but until then, we have some ideas and improvements that we think will help:


Firstly, it appears that even though we pass an og_image, Facebook is refusing to accept anything smaller than 200px by 200px. Again, we've been doing the same thing for years, but we think FB has changed something about this.


For now, we're going to NOT pass through the image if it is less than 200x200 px. We'll fall back to the og_image default (defined in site settings or URL properties). This will be in our next update for both Zen and Flex (in a week or so).


In the future, we're going to look at using our image proxy technology to create a special image for Facebook that takes the small child image and sizes it up. It will only be used for the Facebook og_image, however. We are looking into how this will need to happen, and several aspects of our system will need to be updated to support this, so it is likely a few months away.


In addition, we have found some new information about Facebook pre-catching. Basically, Facebook says that the first time someone shares the page, they may not see the image because of asynchronous loading (this may happen more frequently to newsrooms where they are often posting the content themselves and looking right away to make sure it worked). Facebook now provides some new image tags that will allow us to send this information to Facebook and it will more likely work the first time. This will also be added to both Zen and Flex in a few weeks.


And lastly, while troubleshooting all of this, I’ve found a few best practices to share with you:


1. Ensure you’ve got an appropriate backup og_image (documentation for Zen, Flex). This is usually the site logo, but you can create a section-specific one per section because they can be applied at the URL level on both Zen and Flex platforms. Make sure this image is larger than 200px in both height and width.


2. Instruct the newsroom to upload images that are larger than 200px in both height and width. Some of the steps we are taking (above) will reduce the need for this eventually of course, but even if BLOX is automatically sizing up images, it may be better for the newsroom to do this themselves. This will ensure there is optimum image quality (or if you don’t want to size it up you can letterbox it instead). We know that this isn’t possible for all newsrooms, so we’re working to automate this as best we can (as explained above).


3. Do not share from a non-live or preview page. We are going to take steps to further prevent this from happening, but if Facebook attempts to try to scrape your page before it is ready, you’ll get an error. This error will appear as an item with very minimal information on Facebook (no photo, title or description). To fix this error, you can use the Facebook debugger to re-scrape the page.


4. The Facebook debugger is a great tool for your newsrooms to know, in case there are errors or fixes that need to be made on the Facebook shares. For example, when an image or headline needs to be fixed after it has been shared (maybe a typo in the headline), even if you fix it in BLOX it will not update on Facebook until the page is re-scraped.


I hope this helps! Also, please let me know if you have any other best practices or ideas on our to improve this process. Thanks! =)

Basically, Facebook says that the first time someone shares the page, they may not see the image because of asynchronous loading (this may happen more frequently to newsrooms where they are often posting the content themselves and looking right away to make sure it worked).

This is likely the culprit, at least in our case, because it explains exactly what's happening with having to rescrape the page.

It's not just the first time, though. We're unable to successfully post stories to Facebook that we've already pushed through Debugger hours or days before. It happened this morning on a story that was posted via TCMS and shared on Facebook on Friday night. It could not be shared again on Facebook (at least, not with an image, headline and summary) without running it through debugger several times.

I'm curious - has this image issue happened to anyone pushing content via the Broadcast tool? Or only via posting links manually?

Hi Lindy,


We've seen issues from media organizations posting with a variety of mechanisms: manual, broadcast and third-party tools (i.e. Hootsuite). Also, we've seen some issues with third-party sites, such as Wordpress or other platform vendors.



We've now made improvements to Facebook og tags to both Zen and Flex based on new Facebook rules. Has this been working better for you?