web-dev-qa-db-ja.com

キャッシュ対クッキーのためのこの解決策は私を困惑させようとしているのでしょうか？

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

私は自分の方法をWP Super Cache、W3 Total Cache、そしてComet Cacheでテストしました。この問題を研究している間に私が詳細に説明したのはWP Super Cache（以下「WPSC」）なので、私はそれを私の主な例として使います。

バックグラウンド

訪問者がコメントできるようにWP標準コメントスレッドが設定されている場合、登録ユーザーではなく、ログインしているすべてのコメント投稿者にコメントCookieが設定され、実際のコメント権限はさらにチェックされます。私が信じているのは、最も一般的な設定です。コメント投稿者は、名前と電子メールアドレスだけを入力すればよいのです。これらは2つのブラウザクッキー、通常はcomment_author_ . COOKIEHASHとcomment_author_email_ . COOKIEHASHに格納されています。 COOKIEHASHは、ユーザーオプションに従って定義されます。

新しく生成されたファイルを「既知のユーザー」に配信するように設定されている場合、WPSCはいくつかのチェックに基づいてキャッシュされたファイルを提供するかどうかを決定します。後者はCOOKIEHASHによって特定のユーザーのために特にまたは一意に識別されていないcomment_author_ cookieがブラウザ内に存在することによって主に識別されます（通常はサイトオプションに記録された「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プラグを使用して作業しています。 -に。しかし、RegExを見ればわかるように、WPSC関数はCOOKIEHASHを気にすることはありません。comment_author_に遭遇すれば満足です。

私の暫定的な解決策

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

JQuery Cookieに慣れていない人のために：上記はkey = comment_author_proxyhashとvalue = proxy_authorの単純なセッションCookieを設定します。これはサイト全体に適しています。 （また、jQuery CookieとWPを使用している人のために、WP jQueryの代わりにおなじみのjQuery $を代用することに加えて、私はすでに$.cookie.raw = true;も設定しました。）

私のjQueryスクリプトにその行を追加したところ、voila！、WPSC、W3 Total Cache、およびComet Cacheは、すべて私が望んでいたとおりに動作しています。スクリプトを使用してリロードすると、新しいページが表示されます。私が本当のコメントをしたとしたら、通常のcomment_author_とcomment_author_email_のクッキーが設定され、共存に問題はないようです。

おそらく、1つの欠点は、セッションを開いたままにしている限り「proxyhash」Cookieがユーザーと一緒に移動することですが、それが私に大きな問題となることはない、または警告に値することすらありません。私は、誰かがそのようなことが通常のクッキーで起こっていることについて不平を言うのを決して聞いたことがありません。

しかし、もしかしたら私が行方不明になっている可能性があり、もしかしたら私の啓示のためにも、私の悲しみに多くを発見しようとしているのかもしれません。あるいは、jQueryでCOOKIEHASHを複製し、他の使用例もカバーする比較的単純なベストプラクティスの方法があるかもしれません。または他の方法で同じ最終結果を達成する方法もあります。コメンターとしての訪問者...

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

jquerycachecookiesplugin-w3-total-cacheplugin-wp-supercache
23
CK MacLeod

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

ここでの問題は、ページキャッシング機能がWebサイトに本当に必要なものであり、裸のWordPressのパフォーマンスが十分でなくピーク時にサーバーをクラッシュさせることさえ可能であるという理由でページキャッシングが設定されることが多い。 Webサイトのコンテンツの性質によって異なりますが、サイトの所有者はPHP/WPコードを介してすべてを処理するために必要なハードウェアの代金を支払えないことがあります。言い換えれば、可能な限り多くのトラフィックをページキャッシュから処理する必要があります。実際には、キャッシュ例外をするプラグインを識別して無効にしなければならないことがよくあります。

もちろんそれは常に可能というわけではありませんが、可能な限りキャッシュされたページを扱うようにしてください。例えば、divタグをjavascriptやajax-ify全体のコメントブロックで無視したいコメントで隠すことができます。

いずれにせよ、訪問者をコメンターとしてマークする必要はありませんが、カスタムロジックの理由でキャッシュを停止します。それで、それはユニークなクッキーを使い、それをキャッシュ例外シグナルにするほうが良いです。 W3 Total Cacheにはそのための "Reject cookies"オプションがありますが、あなたのリストにある他のプラグインはそうではないのであなたが提案したようなハックが必要になるでしょう。

1
WowPress.host