Czy to rozwiązanie dla pamięci podręcznych kontra pliki cookie wpędzi mnie w kłopoty?

23

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?

CK MacLeod
źródło
3
Rekwizyty do dobrze zbadanego i udokumentowanego pytania. Wydaje mi się jednak, że charakter pytania może otworzyć go na większą dyskusję, a nie na ostateczną odpowiedź (nie na temat: przede wszystkim na podstawie opinii). FWIW moim zdaniem nie widzę tu nic złego - ostatecznie ustawiasz tylko jeden ogólny plik cookie bez danych osobowych.
TheDeadMedic
Wielkie dzięki za wkład. Byłbym wdzięczny za taką dyskusję i jako takie zaznaczyłem jako dobre odpowiedzi, że a) wskazał problem z tą metodą „ogólnego pliku cookie”, b) zapewnił alternatywne sposoby osiągnięcia tego samego efektu lub c) podał użyteczne wgląd w podstawowe pytania techniczne dotyczące „znanych użytkowników”.
CK MacLeod
Uwaga: możesz użyć 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!
phatskat
Interesujące pytanie - nie mogę wymyślić nic, co mogłoby wpędzić cię w kłopoty, ale czy mogę zapytać, dlaczego chcesz w ten sposób ominąć pamięć podręczną? Danie użytkownikom tej umiejętności w pewnym sensie pokonuje cel polegający na tym, aby mieć pełną pamięć podręczną stron. Ponadto dodatkowy plik cookie zwiększa wielkość żądania (choć minimalnie), gdy ten sam wynik można osiągnąć przy użyciu typowych konfiguracji pamięci podręcznej, po prostu dodając dowolne parametry zapytania do adresu URL, np. Mysite.com?a. Tylko moje 0,02 $ ...
ssnepenthe
ssnepenthe: Może powinienem był wyjaśnić: Wtyczka, którą opracowywałem, gdy pisałem pytanie - wordpress.org/plugins/commenter-ignore-button - używa jQuery, aby umożliwić odwiedzającym umieszczanie wybranych komentatorów „na ignorowaniu”. Początkowa czynność stosuje formatowanie CSS do wątku komentarza, a następnie polega na pliku cookie do przechowywania oznaczenia i jego obecności w celu powielenia efektu (za pośrednictwem PHP) podczas kolejnych odświeżeń aż do wygaśnięcia pliku cookie. W wersji strony z pamięci podręcznej efekt nie zostałby zarejestrowany. Tak, tak, jest to forma celowego zlokalizowanego pomijania pamięci podręcznej.
CK MacLeod

Odpowiedzi:

1

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ć divtagi 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ś.

WowPress.host
źródło
Dzięki! Podnosisz szereg ważnych problemów, ale powiem, że to, co robi ten kod, zasadniczo traktuje każdego gościa, który bierze udział w wątkach komentarzy na tyle, aby kogoś „zignorować” lub „wyciszyć” jak „znanego użytkownika / komentator ”. Jeśli strona nie jest w stanie poradzić sobie z takim udziałem, prawdopodobnie również nie może obsłużyć standardowego szablonu komentarzy WordPress (i społeczności komentujących)!
CK MacLeod
Myślisz, że jesteś tutaj, choć oczywiście nie wiesz na pewno, w jaki sposób użytkownicy go używają. Btw wiele stron o dużym ruchu wyładowuje swoje komentarze do oddzielnych żądań lub nawet usług stron trzecich właśnie w celu szybkiego wyświetlania treści artykułów, a później leniwe ładowanie dynamicznych komentarzy. Weź to za nietypowy pomysł na kolejne wersje wtyczki :)
WowPress.host