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.
Built from https://develop.svn.wordpress.org/trunk@28972
git-svn-id: http://core.svn.wordpress.org/trunk@28761 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Helen Hou-Sandí
Sergey Biryukov
Andrew Ozz
Scott Taylor
Drew Jaynes
John Blackbourn
Andrew Nacin