Research cache age of oEmbed response

[reefdog]

WP can cache the oEmbed response; to enable it, we just need to flip WP_DocumentCloud::CACHING_ENABLED to true. But does it obey our cache_age or have its own internal age? Research.

[reefdog]

Gosh, WP oEmbed caching is a mess. After testing and searching the source, here's what I've determined:

• wp_oembed_get() is uncached, so every pageload hits us twice: once for the oEmbed service and then once for the resource data.
  • Unless, presumably, they're using a page cache like W3 Total Cache or WP Super Cache. We can't rely on this since it's non-default.
• The $wp_embed->shortcode() trick suggested by a WP employee here caches the result of the oEmbed call in the postmeta table, ostensibly with a 24-hour cache age. Except…
  • I can't confirm that this cache is ever refreshed. I tried changing this 24-hour cache age to a minute, but wasn't able to trigger a refresh.
  • Our cache_age is completely ignored, despite conversation in that ticket around supporting it.

So, it seems we must decide between:

1. No caching; every load of every embed hits us twice (and, even worse for the user experience, synchronously).
2. Aggressive cache that may never expire.

I vote for #2, partly because I don't believe my own results and have to assume the cache would eventually expire, and partly because stale embed codes are less of a problem than letting WP DDOS us.

[knowtheory]

That sounds... awful?

Remember that this is just for the oembed response... and since our embed codes are normally static anyway... So what i'd say is we should cache as aggressively as possible, and any data changes that are made will be handled through our platform caching & expiry anyway.

[reefdog]

Yup.

[eyeseast]

I think caching the embed code is probably fine. Every raw embed in the wild is essentially the same thing. As long as the underlying document keeps getting fetched, it shouldn't be a problem.

But I concur with Ted: Ick.