[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:  Awaiting Review
Component:  Embeds        |     Version:  3.0.1          
 Severity:  normal        |    Keywords:                 
--------------------------+-------------------------------------------------

Comment(by Denis-de-Bernardy):

 Replying to [comment:7 Viper007Bond]:
 > The other issue is when embeds are used outside of posts, in the sidebar
 for example. Where do we cache to? Currently it caches sorta randomly
 (whatever `$post` happens to be set to at the time).

 Don't we have an in_the_loop() function for that? In a sidebar, it would
 make a lot of sense.

 >
 > Replying to [comment:6 Denis-de-Bernardy]:
 > > Alternatively, WP could flush postmeta by key when we know a few that
 are invalid during upgrades. Btw, is it that much of a big deal? I haven't
 tested, but I would assume that Vimeo made sure the old oEmbed code would
 continue to work.
 >
 > We can't flush by service. The meta key is `_oembed_md5-hash-of-url-and-
 args`. On post save, `_oembed_*` are deleted for a post.

 If memory serves, the ticket I had looked into related to implementing
 delete_post_meta_by_key() had code to allow the use of a like statement.

 > Here's some code though that deletes all oEmbed caches:
 http://core.trac.wordpress.org/attachment/ticket/10337/10337.10.patch

 If I may suggest, the huge IN statement could have been replaced by a join
 or a subquery. It would make the query much faster on larger sites.

 > > If you need postmeta to expire, the easy approach is to an expire date
 tied to it in a separate postmeta (much like we do for transients in the
 options table: _$key_expires). Ideally, the stuff key in question gets
 detected and its parent key gets stored accordingly in memcache.
 >
 > That'd require a heavy rewrite of post meta.

 For the store in memcached part, yes. For the rest, it seems like a one-
 liner in get_meta() that checks for a separate key before returning the
 value. Or a similar one liner in the oEmbed code before using the cached
 value, no?

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