[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:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Embeds        |     Version:  3.0.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+-----------------------------

Comment (by Denis-de-Bernardy):

 Replying to [comment:34 sanchothefat]:
 > Rather than leaving it with no optimal solution would it not at least
 make sense to use transients in so far as it's better than no caching at
 all?

 > The only other thing I can think of is that you could register a hidden
 post type, create a single post in it and use that as the fallback post ID
 to cache anything coming from a direct `wp_oembed_get()` call. It seems
 completely crazy but might be the least disruptive.

 The current solution is the most sane we have at the moment imo. The only
 issue is expiring it periodically.

 The benefit of post_meta is that it adds no extra queries: post_meta gets
 queried automatically by the API when a post is loaded by WP (because it's
 in the loop or because you're fetching any of its meta key/value pairs).
 This makes it a very sane place to store anything that relates to a
 specific post.

 In contrast, a transient in wp_options yields an extra DB hit for each
 oembed on a page — whether it's cached or not — on sites with no
 persistent in-memory storage. Likewise, a custom post type would allow to
 keep the cache in sync if two or more posts embed the same resource, but
 this would be at the cost of extra DB queries to actually fetch them. Tbh,
 I'm suspicious that either approach would be a win in the end.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/14759#comment:35>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software