对于流行的WP缓存解决方案与Cookie的交互问题，我提出了一个临时解决方案，这个问题并不常见，但远不是前所未有的，在本例中是标准的WP注释Cookie。我的解决方案还涉及很少明确定义的“已知用户”例外，即为缓存文件提供服务。无论它是否可用，我认为解释它并可能了解它为什么是一个坏主意通常都是有益的。

我已经用WP Super Cache、W3 Total Cache和Comet Cache测试了我的方法。在研究这个问题时，我为自己详细分析了WP超级缓存（“WPSC”），因此我将使用它作为我的主要示例。

背景

当WP标准评论线程设置为允许访问者发表评论时，将为任何非注册用户且已登录的评论者设置评论cookie，实际评论权限将接受进一步检查。在我认为最常见的配置中，评论者只需提供姓名和电子邮件地址。它们通常存储在两个浏览器cookie中comment_author_ . COOKIEHASH, 和comment_author_email_ . COOKIEHASH. COOKIEHASH 根据用户选项定义。

如果设置为将新生成的文件交付给“已知用户”，WPSC将根据几项检查确定是否提供缓存文件：登录用户获得新文件，访问者“可以发表评论”也获得新文件后者主要通过浏览器中的comment_author_ 未由特定用户专门或唯一标识的CookieCOOKIEHASH （通常但不总是站点选项中记录的“siteurl”的MD5编码版本）。

来自wp-cache-phase1的WPSC代码的关键部分。php LL371-383，使用正则表达式模式获取字符串，在cookie中循环：

$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);
}

现在，如果我严格使用PHP，我可以重新生成或钩住WP核心函数，并获得正常的comment_author_ . COOKIEHASH 由注释模板设置，但我正在使用jQuery Cookie插件处理jQuery。然而，如果查看RegEx，您可以看到，WPSC函数并不关心COOKIEHASH: 如果遇到comment_author_.

我的暂定解决方案

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

对于那些不熟悉jQuery Cookie的人：上面设置了一个简单的会话Cookie，其键=comment_author_proxyhash 和值=proxy_author, 对整个网站都有好处。（另外，对于使用jQuery Cookie和WP的用户，除了预先替换熟悉的jQuery之外$ 对于WPjQuery, 我也已经准备好了$.cookie.raw = true;.)

我在jQuery脚本中添加了这一行，然后，瞧、WPSC、W3 Total Cache和Comet Cache都像我希望的那样。使用脚本并重新加载后，我会得到新的页面。如果我碰巧发表了真正的评论comment_author_ 和comment_author_email_ Cookie已经设置好了，而且共存似乎没有任何问题。

也许有一个缺陷是，只要用户保持会话打开，“proxyhash”cookie就会随用户一起移动，但我觉得这不太可能是一个大问题，甚至不值得一提。我当然从没听说过有人抱怨这样的事情发生在一个普通的饼干上。

但也许我遗漏了一些东西，即将发现我的悲哀，如果可能也会对我有所启迪的话。或者，也许有一种相对简单的最佳实践方法可以让我复制COOKIEHASH 在jQuery中，还包括其他用例。。。或者通过其他方式实现相同的最终效果-其他方式诱使缓存插件将访问者视为评论者。。。

如果没有，有什么好的理由不把这个或接近它的东西用插件推向宇宙吗？