1
这种针对缓存和Cookie的解决方案会给我带来麻烦吗？
我已经提出了一个临时解决方案，该解决方案不是很常见，但与流行的WP缓存解决方案与cookie（在这种情况下为标准WP注释cookie）的交互作用相比，还没有出现前所未有的问题。我的解决方案还涉及在提供缓存文件方面很少定义的“已知用户”例外。无论它是否可用，我都认为对它进行解释并可能了解为什么它不是一个好主意通常具有指导意义。 我已经使用WP Super Cache，W3 Total Cache和Comet Cache测试了我的方法。在研究此问题时，我为自己详细介绍的一个就是WP Super Cache（以下简称“ WPSC”），因此我将其作为主要示例。 背景 如果将WP标准评论线程设置为允许访问者发表评论，则将为非注册用户并登录的任何评论者设置评论cookie，并使用实际的评论特权进行进一步检查。在我认为是最常见的配置中，评论者只需提供姓名和电子邮件地址。它们存储在两个浏览器Cookie中，通常是comment_author_ . COOKIEHASH和comment_author_email_ . COOKIEHASH。COOKIEHASH是根据用户选项定义的。 如果设置为将新生成的文件传递给“已知用户”，则WPSC会基于以下检查来确定是否提供缓存文件：登录的用户会获得新文件，访问者“可以发表评论”也是如此。后者主要由comment_author_cookie 在浏览器中的存在来标识，这些cookie不是由特定用户COOKIEHASH（通常但并非总是记录在站点选项中的“ siteurl”的MD5编码版本）为特定用户而唯一或唯一标识的。 来自wp-cache-phase1.php LL371-383的WPSC代码的关键部分似乎使用RegEx模式来获取字符串，并在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)) …