[wp-trac] [WordPress Trac] #17210: Massive duplication of oEmbed postmeta

[WordPress Trac]

#17210: Massive duplication of oEmbed postmeta
--------------------------+---------------------------
 Reporter:  archon810     |       Owner:  Viper007Bond
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  4.0
Component:  Embeds        |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------------

Comment (by helen):

 In [changeset:"28972"]:
 {{{
 #!CommitTicketReference repository="" revision="28972"
 Improve oEmbed caching. Introduces the concept of a TTL for oEmbed caches
 and a filter for `oembed_ttl`.

 We will no longer replace previously valid oEmbed responses with an
 `{{unknown}}` cache value. When this happens due to reaching a rate limit
 or a service going down, it is data loss, and is not acceptable. This
 means that oEmbed caches for a post are no longer deleted indiscriminately
 every time that post is saved.

 oEmbed continues to be cached in post meta, with the addition of a
 separate meta key containing the timestamp of the last retrieval, which is
 used to avoid re-requesting a recently cached oEmbed response. By default,
 we consider a valued cached in the past day to be fresh. This can greatly
 reduce the number of outbound requests, especially in cases where a post
 containing multiple embeds is saved frequently.

 The TTL used to determine whether or not to request a response can be
 filtered using `oembed_ttl`, thus allowing for the possibility of
 respecting the optional oEmbed response parameter `cache_age` or altering
 the period of time a cached value is considered to be fresh.

 Now that oEmbeds are previewed in the visual editor as well as the media
 modal, oEmbed caches are often populated before a post is saved or
 published. By pre-populating and avoiding having to re-request that
 response, we also greatly reduce the chances of a stampede happening when
 a published post is visible before oEmbed caching is complete.

 As it previously stood, a stampede was extremely likely to happen, as the
 AJAX caching was only triggered when `$_GET['message']` was 1. The
 published message is 6. We now trigger the caching every time
 `$_GET['message']` is present on the edit screen, as we are able to avoid
 triggering so many HTTP requests overall.

 props markjaquith. fixes #14759. see #17210.
 }}}

--
Ticket URL: <https://core.trac.wordpress.org/ticket/17210#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform