Recent Posts Widget should include scheme in cache key

[dllh]

Repro:

1. Run WP on a site with SSL enabled but optional and with an object cache.
2. Enable the Recent Posts widget.
3. Create some posts.
4. Visit the site from the non-SSL url.
5. Now visit the site from the SSL url.

Expected: Items linked in the recent posts widget will use the same scheme as the site itself.

Actual: Whatever was last cached is what's used. The result is that if you visited the site via https but someone else cached data from http, you'll get insecure links when your expectation is that you'll continue to browse the site via ssl.

This can be fixed by using the scheme in the cache key so that we're always serving the right links when served from the object cache.

[johnbillion]

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

[dllh]

Replying to johnbillion:

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

I guess you could hash the home_url() or something. That makes it a little less obvious what you're looking at if you happen to be peeking at cache keys, but it's also more resilient to hostname changes.

[westi]

Replying to johnbillion:

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

I think using home_url is probably a little excessive, if we are really worried about cache pollution when home_url changes we can just hook the purging function onto that too.

[westi]

Updated patch to also purge both cache variants.

[obenland]

Refreshed westi's patch. Can anyone see anything wrong with it?

[westonruter]

Replying to obenland:

Refreshed westi's patch. Can anyone see anything wrong with it?

What about the situation where the site can be accessed via multiple domains? For instance, if setting the WP_HOME constant to include $_SERVER['HTTP_HOST'], then the cached values could be wrong.

So what if instead of using is_ssl() ? 'https' : 'http' in the cache key, it instead uses home_url()?

This would necessarily change how the cache deletion is done, since it wouldn't be known all of the possible home URLs that could appear. So the cached value could instead be an array of cached outputs mapped to the home_url that was active for that given cache. In that way, you can still just delete one cache value and it will purge the caches for all variations of the home URL.

[wonderboymusic]

why on earth are we caching the HTML output? The only other place this is done is the 2011 Ephemera widget

[wonderboymusic]

27565.3.diff​ ditches the cache completely. No other widgets, except for Recent Comments, cache like this. This was 7 releases before $split_the_query. Without an object cache, these queries already happen. With an object cache, posts are served from the cache. This will remove any cached scheme weirdness automatically.

[wonderboymusic]

In 34464:

Recent Posts Widget: remove HTML fragment caching. The cache currently doesn't work cross-scheme and causes mixed content issues for links. The widget was written pre-$split_the_query, after which post objects can be served from the cache.

Fixes #27565.