キャッシュとCookieのこのソリューションは問題を引き起こすでしょうか？

まったく一般的ではないが、人気のあるWPキャッシングソリューションとCookie（この場合は標準のWPコメントCookie）との相互作用に関する前例のない問題から、暫定的なソリューションを思い付きました。私のソリューションは、キャッシュファイルの提供に対する、あまり明確に定義されていない「既知のユーザー」例外にも関係しています。それが使用可能かどうかにかかわらず、それを説明し、おそらくそれが悪いアイデアである理由を学ぶことは、一般的に有益であると考えています。

WP Super Cache、W3 Total Cache、Comet Cacheでメソッドをテストしました。この問題の調査中に私が詳細に故障したのはWPスーパーキャッシュ（以下「WPSC」）であったため、これを主な例として使用します。

バックグラウンド

訪問者がコメントできるようにWP標準のコメントスレッドが設定されている場合、登録ユーザーではなくログインしているコメント作成者にはコメントCookieが設定され、実際のコメント権限はさらにチェックされます。私が最も一般的な構成だと思うのは、コメンターが名前とメールアドレスだけを提供する必要があることです。これらは2つのブラウザCookie（通常comment_author_ . COOKIEHASH、および）内に保存されますcomment_author_email_ . COOKIEHASH。COOKIEHASHユーザーオプションに従って定義されます。

新しく生成されたファイルを「既知のユーザー」に配信するように設定されている場合、WPSCはいくつかのチェックに基づいてキャッシュファイルを提供するかどうかを決定します。後者は主comment_author_に、特定のユーザーに対して特定または一意に識別されない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)) {
    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で作業しています。あなたが正規表現を見ればお分かりのようしかし、WPSC機能は気にしませんCOOKIEHASH：それは遭遇した場合には満足していますcomment_author_。

私の暫定的な解決策

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

jQuery Cookieに不慣れな場合：上記は、キー= comment_author_proxyhashと値=を持つ単純なセッションCookieを設定し、proxy_authorサイト全体に適しています。（また、jQuery CookieとWPを使用する人の$ために、WPに馴染みのあるjQueryを事前に置き換えることに加えてjQuery、すでに設定しました$.cookie.raw = true;。）

行をjQueryスクリプトに追加しました。、WPSC、W3 Total Cache、Comet Cacheはすべて、私が望むように動作しています。スクリプトを使用してリロードすると、新しいページが表示されます。たまたま実際のコメントを入れると、通常comment_author_とcomment_author_email_Cookieが設定され、共存に問題はないようです。

おそらく1つの欠陥は、ユーザーがセッションを開いている限り「プロキシハッシュ」Cookieがユーザーと一緒に移動することですが、それは大きな問題ではないと思います-または警告する価値さえありません。確かに、通常のCookieの1つでこのようなことが起こっているという不満を聞いたことはありません。

しかし、おそらく私が欠けているものがあり、潜在的にも私の教養にも、私の悲惨さに多くを発見しようとしています。またはCOOKIEHASH、別のユースケースもカバーするjQueryで複製するための比較的簡単なベストプラクティスの方法があるかもしれません...または他の手段で同じ最終結果を達成するためにコメンターとして...

そうでない場合、これまたはそれに近いものをプラグインでユニバースにプッシュしない理由はありますか？

comment_author_proxyhash cookieを使用したソリューションはもちろん技術的に機能します-私が知っているすべてのキャッシングプラグインはハッシュ値を分析せず、comment_author_ * cookie presenseに基づいてキャッシュされたコンテンツの配信を停止します。

ここでの問題は、ページキャッシュ機能がWebサイトに本当に必要なものであり、多くの場合、裸のWordPressのパフォーマンスが十分ではなく、ピーク時にサーバーをクラッシュさせる可能性があるため、ページキャッシュが正確に構成されていることです。それはウェブサイトのコンテンツの性質に依存しますが、サイトの所有者は、PHP / WPコードを介してすべてを処理するために必要なハードウェアを支払うことができない場合があります。言い換えれば、可能な限りページキャッシュから可能な限りトラフィックを提供する必要があります。練習から、キャッシュ例外を行うプラグインを特定して無効にする必要があることがよくあると思います。

もちろん、常に可能であるとは限りませんが、可能な限りキャッシュされたページで作業してみてください。たとえばdiv、javascriptを使用して無視したいコメントのあるタグを非表示にしたり、コメントブロック全体をajax-ifyしたりできます。

いずれの場合でも、訪問者をコメントとしてマークする必要はありませんが、カスタムロジックの理由によりキャッシュを停止します。そのため、一意のCookieを使用し、キャッシュ例外シグナルにすることをお勧めします。W3 Total Cacheにはそのための「Cookieを拒否する」オプションがありますが、リストの他のプラグインはありませんので、提案したようなハックが必要になります。