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_ . COOKIEHASH
i comment_author_email_ . COOKIEHASH
. COOKIEHASH
jest 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_ . COOKIEHASH
zestaw 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_proxyhash
i 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 COOKIEHASH
w 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_script
skró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!Odpowiedzi:
Twoje rozwiązanie z plikiem cookie comment_author_proxyhash będzie oczywiście technicznie działało - wszystkie wtyczki buforujące, które znam, nie analizują wartości skrótu i po prostu zatrzymają dostarczanie zawartości pamięci podręcznej na podstawie obecności pliku cookie comment_author_ *.
Problem polega na tym, że funkcja buforowania stron jest czymś, czego naprawdę potrzebują strony internetowe i często buforowanie stron jest skonfigurowane dokładnie dlatego, że wydajność samego WordPressa nie jest wystarczająca i może nawet zawiesić serwer w godzinach szczytu. Zależy to od charakteru treści witryny, ale właściciele witryn czasami po prostu nie są w stanie zapłacić za sprzęt wymagany do obsługi wszystkiego za pośrednictwem kodu PHP / WP. Innymi słowy, w miarę możliwości ruch z pamięci podręcznej strony musi być obsługiwany jak najwięcej. Z praktyki mogę powiedzieć, że często musimy identyfikować i wyłączać wtyczki robiące wyjątki pamięci podręcznej.
Oczywiście nie zawsze jest to możliwe, ale w miarę możliwości staraj się pracować ze stroną z pamięci podręcznej. Na przykład możesz ukryć
div
tagi z komentarzami, które chcesz zignorować za pomocą javascript, lub cały blok komentarzy ajax-ify.W każdym razie nie musisz oznaczać gościa jako komentującego, ale przestań buforować z przyczyn niestandardowych. Lepiej więc użyć unikalnego pliku cookie i uczynić go sygnałem wyjątku pamięci podręcznej. W3 Total Cache ma do tego opcję „Odrzuć pliki cookie”, ale nie ma innych wtyczek z listy, więc będziesz potrzebować włamania takiego jak ten, który zasugerowałeś.
źródło