Is this Solution for Caches vs Cookies Going to Get Me in Trouble?

Question

I've come up with a provisional solution for a not exactly common, but far from unprecedented problem with the interaction of popular WP caching solutions with cookies, in this case the standard WP comment cookies. My solution also bears on the rarely well-defined "known users" exception to serving cached files. Whether it's usable or not, I figure that explaining it and possibly learning why it's a bad idea might be generally instructive.

I've tested my method with WP Super Cache, W3 Total Cache, and Comet Cache. The one that I broke down for myself in detail while studying this problem was WP Super Cache ("WPSC" hereafter), so I'll use it as my main example.

BACKGROUND

When a WP standard comment thread is set to allow visitors to comment, comments cookies are set for any commenter who is not a registered user and logged in, with actual commenting privileges subjected to further checks. In what I believe is the most common configuration, a commenter needs to supply only a name and an email address. These are stored within two browser cookies, usually comment_author_ . COOKIEHASH, and comment_author_email_ . COOKIEHASH. COOKIEHASH is defined according to user options.

If set to deliver freshly generated files to "known users," WPSC determines whether or not to serve a cached file on the basis of several checks: Logged-in users get fresh files, and so do visitors "who can comment." The latter are chiefly identified by the presence in their browsers of comment_author_ cookies which are not specifically or uniquely identified for the particular user by the COOKIEHASH (usually but not always an MD5-encoded version of the "siteurl" recorded in site options).

What appears to be the key part of the WPSC code, from wp-cache-phase1.php LL371-383, uses a RegEx pattern to get a string, cycling through the cookies:

$regex = "/^wp-postpass|^comment_author_";
if ( defined( 'LOGGED_IN_COOKIE' ) )
    $regex .= "|^" . preg_quote( constant( 'LOGGED_IN_COOKIE' ) );
else
    $regex .= "|^wordpress_logged_in_";
$regex .= "/";
while ($key = key($_COOKIE)) {
    if ( preg_match( $regex, $key ) ) {
        wp_cache_debug( "wp_cache_get_cookies_values: $regex Cookie detected: $key", 5 );
        $string .= $_COOKIE[ $key ] . ",";
    }
    next($_COOKIE);
}

Now, if I were working strictly in PHP, I could re-produce or hook into WP core functions, and get the normal comment_author_ . COOKIEHASH set by the comment template, but I am working in jQuery using the jQuery Cookie plug-in. However, as you can see if you look at the RegEx, the WPSC function doesn't care about the COOKIEHASH: It's satisfied if it encounters comment_author_.

MY TENTATIVE SOLUTION

$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );

For those unfamiliar with jQuery Cookie: The above sets a simple session cookie with key = comment_author_proxyhash and value = proxy_author, good for the entire site. (Also, for those who use jQuery Cookie and WP, in addition to pre-substituting the familiar jQuery $ for the WP jQuery, I've also already set $.cookie.raw = true;.)

I added the line to my jQuery script, and, voila!, WPSC, W3 Total Cache, and Comet Cache are all acting like I want them to. After I use the script, and reload, I get fresh pages. If I happen to place a real comment, the normal comment_author_ and comment_author_email_ cookies are set, and there doesn't seem to be any problem with co-existence.

Perhaps one defect would be that the "proxyhash" cookie will travel with the user as long as he or she keeps the session open, but that doesn't strike me as likely a major problem - or even worth a warning. I've certainly never heard of someone complaining about such a thing happening with one of the regular cookies.

But maybe there's something I'm missing, and about to discover much to my woe, if potentially to my edification as well. Or maybe there's a relatively simple best-practicey way for me to replicate the COOKIEHASH in jQuery, also covering alternative use cases... or to achieve the same end effect by other means - other ways of tricking the caching plug-ins into treating the visitor as a commenter...

If not, is there any good reason NOT to push this or something close to it out to the universe in a plug-in?

Answer 1

Your solution with comment_author_proxyhash cookie will of course technically work - all caching plugins I know doesn't analyze hash value and will just stop delivery of cached content based on comment_author_* cookie presense.

Problem here is that page caching functionality is something websites really need and often page caching is configured exactly because naked WordPress performance is not enough and able to even crash server at peak times. It depends on website content nature, but site owners sometimes just not able to pay for hardware required to handle everything via PHP/WP code. In other words as much as possible traffic has to be served from page cache whenever possible. From practice I may tell that we often have to identify and disable plugins doing cache exceptions.

Of course it's not always possible, but try to work with cached page whenever possible. For example you may hide div tags with comments you want to ignore via javascript, or ajax-ify whole comments block.

In any case you don't need to mark visitor as a commenter, but stop caching because of your custom logic reasons. So it's better to use unique cookie and make it a cache exception signal. W3 Total Cache has "Reject cookies" option for that, but not other plugins from your list so you'll need a hack like one you have suggested.