[wp-trac] [WordPress Trac] #14759: Improve the way oEmbed deals with caching

[WordPress Trac]

#14759: Improve the way oEmbed deals with caching
------------------------------+---------------------
 Reporter:  Viper007Bond      |       Owner:  helen
     Type:  enhancement       |      Status:  closed
 Priority:  normal            |   Milestone:  4.0
Component:  Embeds            |     Version:  3.0.1
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch commit  |     Focuses:
------------------------------+---------------------
Changes (by helen):

 * owner:   => helen
 * status:  new => closed
 * resolution:   => fixed


Comment:

 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/14759#comment:53>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform