Wymyśliłem tymczasowe rozwiązanie nie do końca powszechnego, ale dalekiego od bezprecedensowego problemu z interakcją popularnych rozwiązań buforowania WP z plikami cookie, w tym przypadku standardowych plików cookie z komentarzami WP. Moje rozwiązanie zawiera również rzadko definiowany wyjątek „znanych użytkowników” od udostępniania plików w pamięci podręcznej. Bez względu na to, czy jest użyteczny, czy nie, myślę, że wyjaśnienie go i być może nauczenie się, dlaczego jest to zły pomysł, może być pouczające.
Przetestowałem moją metodę z WP Super Cache, W3 Total Cache i Comet Cache. Tym, który szczegółowo popsułem podczas studiowania tego problemu, była WP Super Cache (dalej „WPSC”), więc wykorzystam to jako mój główny przykład.
TŁO
Po ustawieniu standardowego wątku komentarza WP, aby umożliwić użytkownikom komentowanie, komentarze są ustawiane dla każdego komentatora, który nie jest zarejestrowanym użytkownikiem i jest zalogowany, a rzeczywiste uprawnienia do komentowania podlegają dalszym kontrolom. W moim przekonaniu, że jest to najczęstsza konfiguracja, komentator musi podać tylko nazwę i adres e-mail. Są one zazwyczaj przechowywane w dwóch plikach cookie przeglądarki comment_author_ . COOKIEHASHi comment_author_email_ . COOKIEHASH. COOKIEHASHjest definiowany zgodnie z opcjami użytkownika.
Jeśli skonfigurowano dostarczanie świeżo wygenerowanych plików do „znanych użytkowników”, WPSC ustala, czy podać buforowany plik na podstawie kilku kontroli: Zalogowani użytkownicy otrzymują nowe pliki, a odwiedzający „mogą komentować”. Te ostatnie są głównie identyfikowane przez obecność w ich przeglądarkach comment_author_plików cookie, które nie są specjalnie lub jednoznacznie identyfikowane przez konkretnego użytkownika przez COOKIEHASH(zwykle, ale nie zawsze, wersję „siteurl” zakodowaną w MD5 zapisaną w opcjach witryny).
To, co wydaje się być kluczową częścią kodu WPSC, z wp-cache-phase1.php LL371-383, używa wzorca RegEx, aby uzyskać ciąg, cyklicznie przechodząc przez pliki 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);
}Teraz, gdybym ściśle pracował w PHP, mógłbym odtworzyć lub podłączyć podstawowe funkcje WP i uzyskać normalny comment_author_ . COOKIEHASHzestaw za pomocą szablonu komentarza, ale pracuję w jQuery przy użyciu wtyczki jQuery Cookie. Jednak, jak widać, jeśli spojrzysz na RegEx, funkcja WPSC nie dba o COOKIEHASH: Jest zadowolony, jeśli się pojawi comment_author_.
MOJE TENTATYWNE ROZWIĄZANIE
$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );
Dla osób niezaznajomionych z jQuery Cookie: Powyższe ustawia prosty plik cookie sesji z kluczem = comment_author_proxyhashi wartością = proxy_author, dobrym dla całej witryny. (Również dla tych, którzy używają jQuery Cookie i WP, oprócz wcześniejszego podstawienia znanego jQuery $na WP jQuery, już ustawiłem $.cookie.raw = true;).
Dodałem wiersz do mojego skryptu jQuery i, voila! , WPSC, W3 Total Cache i Comet Cache działają tak, jak tego chcę. Po użyciu skryptu i ponownym załadowaniu otrzymuję nowe strony. Jeśli zdarzy mi się umieścić prawdziwy komentarz, normalne comment_author_i comment_author_email_pliki cookie są ustawione i wydaje się, że nie ma żadnego problemu ze współistnieniem.
Być może jedną wadą byłoby to, że plik cookie „proxyhash” będzie podróżował z użytkownikiem, dopóki on lub ona utrzyma sesję otwartą, ale nie wydaje mi się to poważnym problemem - a nawet wartym ostrzeżenia. Z pewnością nigdy nie słyszałem o tym, żeby ktoś narzekał na coś takiego z powodu zwykłych plików cookie.
Ale może jest coś, za czym tęsknię i zamierzam odkryć wiele dla mojego nieszczęścia, jeśli potencjalnie także dla mojego budowania. A może istnieje względnie prosty, najlepszy, praktyczny sposób na skopiowanie COOKIEHASHw jQuery, obejmujący również alternatywne przypadki użycia ... lub osiągnięcie tego samego efektu końcowego za pomocą innych środków - inne sposoby oszukiwania wtyczek buforujących w traktowaniu odwiedzającego jako komentator ...
Jeśli nie, to czy jest jakiś dobry powód, aby NIE wypychać tego lub czegoś zbliżonego do wszechświata we wtyczce?
wp_localize_scriptskrótu pliku cookie do skryptu JavaScript, aby zamiast „proxy” użyć „natywnego” pliku cookie. W przeciwnym razie jest to bardzo interesujący problem, a twoje rozwiązanie wydaje się solidne, chociaż pliki cookie i pamięć podręczna są zawsze tak złożone, że trudno powiedzieć, czy jest to „właściwe” rozwiązanie, czy też coś jest pomijane. Świetne badania!