Twitter rendering wrong card image. not caching on full URL key?


#1

Description of issue:
Images showing up on twitter cards aren’t showing the correct image.
Shared URL’s aren’t pulling twitter:image meta tag correctly. Seems to be caching somewhere on the Twitter side?

URL affected (must be public):
See this tweet: https://twitter.com/CarmenCrincoli/status/969642198235955201

It has a link in it that points to a URL that has a different image than what the rendered image is.

Image showing up should be of a black dog.

Troubleshooting steps attempted [note that we will not prioritise posts unless there is evidence of following the troubleshooting guides]:

If you look at this page: https://deadspin.com/video/3479293?utm_medium=sharefromsite&utm_source=Deadspin you’ll see the meta tags are correct but it renders on Twitter.com as a different image.

Seems to be a caching problem on the twitter side. You can see three different posts here: https://twitter.com/coolbusparty all have unique URL’s all with the right twitter card meta tags, they all validate in the Card Validator, but they render the same image


#2

I’m hoping to hear back from someone on this. I certainly could be wrong, but it seems like a caching issue on the twitter side. Thanks in advance for any help.

Any other info I can provide?


#3

I’m curious to know how you did that. Does the code that covers execution to display the tweets fetch the image differently (IP, UA, etc) from the validator? As you say, the 3 images are the same, and while it’s not a black dog it is interesting.

Lee


#4

Hey Lee,

I think the validator might actively fetch the image, but once an image is fetched, I think maybe Twitter is caching it somewhere. So, I’m guessing that the code that displays the tweets might pull from a cache that isn’t indexed properly.

So, this is still a problem. Thanks


#5

Ah, the index may be confused by special characters in the file name. If we can replicate it we can write a client side bot to flood twitter with duplicate images of a white vulture killing a passive red bird, and this would allow anyone else to be responsible for DDOSing them. Difficult to be sure though if twitter’s code dies without error when it fails.

Lee


#6

Ahh special characters. Seems like a likely culprit. Are commas special characters? I don’t see special characters in the URL’s in question (other than commas):

here’s the URL of the Interview With a Good Boy link:


(no special characters as far as I can tell)

Here’s the url of the Good Boy dog image that is in the HTML of the page:

No special characters here either other than commas.

Thanks Lee. Any other ideas? Don’t let the vultures win!


#7

The Andy Piper may be able to answer whether commas are considered special characters by Twitter (but that’s neither here nor there because this is a problem with transparent and uniform execution of their algorithm), that is does their code either have a unique ID for all images OR simply publish the spec and say I guess we lied about requiring zero commas, so don’t use commas.

The good news is that Twitter just announced they are the ones that will continue to maintain this code, so hopefully they’ll be responsible and update half their validator, or at least write a spec in Canadianese that we can all understand.

Kill all vultures! Bury them deep!


#8

Here are two examples of the URL’s from the twitter:image meta tags.

https://i.kinja-img.com/gawker-media/image/upload/s--Q5wjEOL0--/c_fill,fl_progressive,g_center,h_450,q_80,w_800/i6gcw5hqavo4vxapvfai.jpg

https://i.kinja-img.com/gawker-media/image/upload/s--2ZqG4qF0--/c_fill,fl_progressive,g_center,h_450,q_80,w_800/by5pvuftvwq2w2n487sr.jpg

Maybe the commas are the problem? Can anyone confirm? Thanks!


#9

According to RFC3986 the problem isn’t commas. Twitter may disagree.


#10

@andypiper et al any thoughts on this? Thanks!


#11

You can confirm by validating the same URLs without commas and see if there’s 1 pic or 2.


#12

ok good idea, I don’t want to a/b test our entire site if I don’t have to so I created two pages, one that has a comma in the image one that doesn’t but the card validator doesn’t render them… now I can’t get the card validator to work for these two pages, any idea why this doesn’t work in the card validator?

this one has image.jpg in the twitter:image meta tag

this one has image,2.jpg in the twitter:image meta tag

Thanks


#13

You don’t understand. Try the same html and image URL, one with commas, one without commas. Your URLs are different, confirm by doing the same but remove the commas. The choice to use commas may cause the problem, if the twitterites won’t confirm this that’s the only way to know. Both validate for me by the way.


#14

The image URLs in our system are generated dynamically. I’m trying to troubleshoot this without having to make a change to our infrastructure (at least establish some certainty around this being the problem before making a sweeping change). So, I thought trying simple tests that don’t include the original HTML might be a good way to isolate/reproduce the problem.

I have now made two pages with the same HTML as the live site, the only thing I changed was the image in the twitter:image meta tag. One has a path with commas one without.

Has commas in the path of the image:

https://twitter-card-test.now.sh/bar-with-comma.html Rendered to Twitter here: https://twitter.com/coolbusparty/status/984466439485706240

No commas:

https://twitter-card-test.now.sh/bar.html Rendered to Twitter here: https://twitter.com/coolbusparty/status/984466841694326786

Both render the image properly, so the commas themselves don’t seem to be the issue…


#15

Yes, reverse engineering Twitter’s software will be much easier with static code, good to understand. Your test was flawed again because commas aren’t the only difference between the 2 image URLs. It could be you’re trying to take more time than necessary but the concept of testing the unsupported comma hypothesis is simple: you need the same URL but without commas.


#16

Ok thanks, I’ve updated the url to have the only difference between the two be a couple of commas:

https://twitter-card-test.now.sh/images/folder/image.jpg

https://twitter-card-test.now.sh/images/f,older/i,mage.jpg

They both render fine when I post them on twitter here and here. FWIW, our images have more that differentiate them… but they do share the same part of the url string that has comma’s in it: c_fill,fl_progressive,g_center,h_450,q_80,w_800… maybe Twitter fumbles the cache keys on that?

https://i.kinja-img.com/gawker-media/image/upload/s--Q5wjEOL0--/c_fill,fl_progressive,g_center,h_450,q_80,w_800/i6gcw5hqavo4vxapvfai.jpg

versus:

https://i.kinja-img.com/gawker-media/image/upload/s--fUEs31Ga--/c_fill,fl_progressive,g_center,h_450,q_80,w_800/qtwzntb5qusmsni0f3pj.jpg

I really appreciate your help and agree that I wish I hadn’t had to spend this much time on it. I wonder if there’s another place to get support from @twitter?

Thanks again!


#17

To be clear, this is still a problem as shown by the ongoing inconsistency between the URL and the summary card that gets rendered here https://twitter.com/CarmenCrincoli/status/969642198235955201


#18

Any way to get anyone from @twitter to comment on this? Thanks