Make WordPress Core

Opened 9 years ago

Closed 3 years ago

#32553 closed defect (bug) (invalid)

Corrupted embeds

Reported by: pavelevap's profile pavelevap Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1.5
Component: Embeds Keywords:
Focuses: Cc:

Description

I noticed that all of my embedded tweets are not displayed correctly. It worked when I inserted them into posts, but now there is only URL address displayed.

oembed_time_c2514d9c02607e0bc7216e614d9c37c8 - 1432677756
_oembed_c2514d9c02607e0bc7216e614d9c37c8 - {{unknown}}

It was 4.1.x website, it seems to me that it can be related to automattic update to 4.1.5 or some changes on webhoster side. I updated to 4.2.2, but there is still only URL address. I can add new URL into post without problems, but current URL embed does not work anymore...

Any idea how could it happen? I know that I can delete wrong postmeta records in database (= clear oembed cache), but it should not happen anyway...

Change History (12)

#1 @helen
9 years ago

  • Keywords reporter-feedback added

{{unknown}} responses indicate something went wrong when retrieving the oEmbed, like a tweet that has been deleted or hitting a rate limit (not clear on whether Twitter specifically still has one). oEmbed caching only re-requests embeds a day past the time in the oembed_time key (unless the oembed_ttl value has been filtered), and does not replace stored values with {{unknown}}. Do you have a plugin or other code that could be affecting oEmbeds or even post meta? We do not clear them en masse in any situation in core as of 4.0, and even then, it was only for a given post on post save, not globally on upgrades.

#2 @pavelevap
9 years ago

Strange...

I published post on 05/21/2015 with this embedded tweet: https://twitter.com/ellaiseulde/status/591980282447843329

Everything was fine, but I checked this post several days later and there was only URL address with {{unknown}} value in database and timestamp 1432677756 linked to 05/26/2015.

There are some plugins, for example bbPress, Jetpack, but nothing special. And nothing was changed during several weeks... So I am not sure what should I check?

I also found that only some embedded tweets are corrupted, many older posts are OK. I tried to resave affected post, but tweet is still not embedded, I thought that embeds are updated when resaving post? I will try to search for any other clues, but now I am out of ideas...

#3 @helen
9 years ago

You could try a plugin that logs external HTTP calls to see what it's getting back - Cron Control does it (have to turn on a module or two), I'm sure there are others as well. Perhaps try deleting the oEmbed caches for that post, re-saving, checking what's in the DB, and seeing what got logged.

#4 @johnbillion
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

No feedback in 4 months and no other reports of this issue. If this is still a problem, please re-open with some more details, particularly your HTTP logs as Helen mentioned above.

#5 @kranzoky
8 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I am experiencing the same issue as @pavelevap.

When inserting in Tweet URLs into a post, all the URLs will work initially and be automatically converted to the Embed.

However, after the post is edited and saved a few times, I notice that some of the URLs in the post just stay URLs and don't get converted.

I did notice that when I click on the URLs that don't end up working in the editor that they are wrapped in paragraph tags.

I also noticed that when I even try to grab those URLs that don't work and insert the Tweet using the "Insert from URL" in the insert media dialogue box that even that method does not work. I will paste in the Tweet URL and nothing happens. It doesn't get converted to an embed.

I was able to get the embeds working by using a plugin called "Oembed Cache". Using that plugin, I deleted the Oembed Cache for the post and then tried embedding the tweets again and it worked. Why would some oEmbeds in my post be getting corrupted?

Last edited 8 years ago by kranzoky (previous) (diff)

#6 @swissspidy
8 years ago

  • Milestone set to Awaiting Review

#7 @kranzoky
8 years ago

Also, just a note that after the oEmbed Cache was cleared on that post, the URLs that stopped working did not just automatically start working again.

I had to delete the URL from the editor and re-paste it in.

I also noticed that if I copied all the content from a post that had some URLs that were not being converted to an embed correctly and pasted that content into a new post that they ended up working fine (again, because there was no corrupt oembed cache it was pulling from).

Last edited 8 years ago by kranzoky (previous) (diff)

#8 @swissspidy
8 years ago

@kranzoky Thanks for your feedback!

It's hard to tell why exactly the embeds didn't work. Previously on this ticket there were some plugin recommendations that would help you (and us) to debug the issue.

Why would some oEmbeds in my post be getting corrupted?

It could have simply been because of twitter not responding for a brief moment

It makes sense that it only worked after a couple of tries, because errors are cached too. There's a ticket about improving caching: #30720.

I think it makes sense to pursue that ticket and close this one here. Any objections?

#9 @kranzoky
8 years ago

Sounds good.

#10 @swissspidy
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

#11 follow-up: @rfischmann
4 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sorry for reopening such an old ticket, but I've faced this issue for years and I believe it's the exact same behavior reported by @pavelevap.

I simply gave up a couple of years ago and have been mostly using Twitter's (and also Instagram's) manual iFrame embeds, as they of course always work, but try to go back to the simpler/quicker oEmbed feature by pasting the URL to see if any recent WordPress update fixes it for good. Nope.

Both Twitter and Instagram always work fine when I'm writing the post and publishing it for the first time. Then, I don't know why, after a few hours or days, their embeds break and we only see the URL in the post. When I go into the post's meta information on my MySQL database, I can see its embeds are all set to {{unknown}}. If I delete all _oembed lines from the post, the embeds start working again.

Simply hoping into the broken post's editor in WordPress, changing something and re-saving it doesn't clear the oEmbed cache and they stay broken. Also, from inside the editor (Gutenberg), all embeds always show up fine — I believe they're not cached there.

I never have any issues with YouTube's or Vimeo's embeds, only Twitter and Instagram.

It doesn't make any sense at all for WordPress to cache a broken oEmbed request with {{unknown}}. If Twitter doesn't temporarily respond, as @swissspidy suggested, then the oEmbed shouldn't be updated (if it was already correct generated before) or cached at all, if broken. Or maybe the time for the next oEmbed caching clearance — which @helen mentioned above — should be very, very low when the remote's response is broken.

#12 in reply to: ↑ 11 @desrosj
3 years ago

  • Keywords reporter-feedback removed
  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to rfischmann:

Also, from inside the editor (Gutenberg), all embeds always show up fine — I believe they're not cached there.

The block editor actually uses the exact same post meta caching logic as the Classic Editor and reuses a lot of the same underlying code.

It doesn't make any sense at all for WordPress to cache a broken oEmbed request with {{unknown}}.

The idea behind caching {{unknown}} when an embed fails is to prevent repeatedly sending requests to the endpoint, which could potentially happen frequently and may result in the site being mistaken as a bot and blocked. {{unknown}} is cached for 1 hour by default to prevent situations like this.

Because this is not reproducible in the block editor, there are still no identified steps to reproduce reliably, and there have not been any other similar reports, I am going to close this out again.

@rfischmann if you are able to identify where the code is breaking and provide some detailed steps for someone else to reproduce, please feel free to reopen with that information.

Note: See TracTickets for help on using tickets.