[wp-trac] [WordPress Trac] #14759: Improve the way oEmbed deals with caching
WordPress Trac
noreply at wordpress.org
Thu Nov 28 14:02:16 UTC 2013
#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 sanchothefat):
Replying to [comment:33 Denis-de-Bernardy]:
> Replying to [comment:32 Viper007Bond]:
> > Correct, the ideal solution would be a caching system not related to
posts but rather the call itself.
> >
> > Caching to the file system will not work or scale. Many filesystems
are not local and reading and writing to filesystems heavily will be slow
and not good. Look back at what happened when WordPress tried to store
`WP_Cache` results to the filesystem back around WordPress 2.0 if you
don't believe me.
I believe you :)
> > Sadly there isn't really a good solution here, at least one that I've
thought of. Post meta was the best I could come up with.
>
> Methinks it'll remain the best option until we ever mimic what we did
with options by creating some kind of post_transient API (and while we're
at it, user_transient, comment_transient, etc.).
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 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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/14759#comment:34>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list