Opened 9 years ago
Closed 6 years ago
#33970 closed defect (bug) (worksforme)
Huge inflation of post_meta for oEmbed caches
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | Embeds | Keywords: | reporter-feedback close |
| Focuses: | Cc: |
Description
This is a follow-up to #17210.
@tollmanz and I are seeing a huge inflation on post_meta as a result of oEmbed caches. It seems like the caching only comes from saving posts, so maybe stampedes aren't totally at fault, but might be an issue. Any ideas here? Going to dig in on this.
Change History (10)
#2
follow-up:
↓ 5
@
9 years ago
- Version trunk deleted
@whyisjake Can you log the HTTP requests for these? You'll probably have to hook in somewhere that gets the $url and $attr so you can determine the key (oembed_result maybe), I'm not recalling anything that receives the key as context. If there are hooks or more context for hooks that we could use in core to better enable this, we can look at that too.
Still want to know what's going on, but maybe we could delete all the {{unknown}} responses on post save at least. I'll try to remember if there was a reason we didn't go that route when we made those changes in 4.0.
#3
follow-up:
↓ 4
@
9 years ago
Are you attempting to use the oEmbed functionality in a custom location, such as a sidebar widget? I wouldn't be surprised if this was a result of post ID pollution.
#4
in reply to:
↑ 3
@
9 years ago
Replying to Viper007Bond:
Are you attempting to use the oEmbed functionality in a custom location, such as a sidebar widget? I wouldn't be surprised if this was a result of post ID pollution.
No, these are all in post content.
#5
in reply to:
↑ 2
@
9 years ago
Replying to helen:
@whyisjake Can you log the HTTP requests for these? You'll probably have to hook in somewhere that gets the
$urland$attrso you can determine the key (oembed_resultmaybe), I'm not recalling anything that receives the key as context. If there are hooks or more context for hooks that we could use in core to better enable this, we can look at that too.
Yeah, I can setup some logging. What is so strange to me is that the keys seem to be totally random. They don't match the results at all.
Still want to know what's going on, but maybe we could delete all the
{{unknown}}responses on post save at least. I'll try to remember if there was a reason we didn't go that route when we made those changes in 4.0.
Yeah, it seems like it would be easy to hook into the delete cache method when saving a good response. I'll whip up .diff.
#6
@
9 years ago
It looks like @nacin set it up to delete the cache on pre_post_update here: #22190 but this code was seem to be removed. Any ideas why that was changed? I'm looking for the change.
What @markjaquith [notes here](https://core.trac.wordpress.org/ticket/14759#comment:49) is that What this doesn't address: that if you never update the post, the cache stays indefinitely. Which is definitely the case that we are seeing. The problem tho, is that we see the post has a bunch of seemingly unrelated {{unknown}} cached oembeds.