Wird diese Lösung für Caches vs Cookies mich in Schwierigkeiten bringen?

23

Ich habe eine vorläufige Lösung für ein nicht ganz alltägliches, aber keineswegs beispielloses Problem bei der Interaktion von gängigen WP-Caching-Lösungen mit Cookies gefunden, in diesem Fall die Standard-WP-Kommentar-Cookies. Meine Lösung betrifft auch die selten klar definierte Ausnahme "bekannter Benutzer" beim Bereitstellen von zwischengespeicherten Dateien. Ob es brauchbar ist oder nicht, ich denke, dass es allgemein lehrreich sein kann, es zu erklären und möglicherweise zu lernen, warum es eine schlechte Idee ist.

Ich habe meine Methode mit WP Super Cache, W3 Total Cache und Comet Cache getestet. Das Problem, das ich mir ausführlich angesehen habe, war WP Super Cache (im Folgenden "WPSC"). Daher verwende ich es als mein Hauptbeispiel.

HINTERGRUND

Wenn ein WP-Standard-Kommentarthread so eingestellt ist, dass Besucher kommentieren können, werden Kommentarkekse für jeden Kommentator gesetzt, der kein registrierter Benutzer ist und angemeldet ist. Die tatsächlichen Kommentarberechtigungen werden weiteren Überprüfungen unterzogen. In der meiner Meinung nach am häufigsten verwendeten Konfiguration muss ein Kommentator nur einen Namen und eine E-Mail-Adresse angeben. Diese werden in der Regel in zwei Browser-Cookies gespeichert comment_author_ . COOKIEHASH, und comment_author_email_ . COOKIEHASH. COOKIEHASHwird gemäß den Benutzeroptionen definiert.

Wenn festgelegt ist, dass frisch generierte Dateien an "bekannte Benutzer" geliefert werden, bestimmt WPSC auf der Grundlage mehrerer Überprüfungen, ob eine zwischengespeicherte Datei bereitgestellt werden soll oder nicht: Angemeldete Benutzer erhalten frische Dateien, und auch Besucher, "die Kommentare abgeben können". Letztere werden hauptsächlich durch das Vorhandensein von comment_author_Cookies in ihren Browsern identifiziert, die für den jeweiligen Benutzer nicht spezifisch oder eindeutig durch die COOKIEHASH(normalerweise, aber nicht immer, MD5-codierte Version des in den Site-Optionen aufgezeichneten "siteurl") identifiziert werden.

Der anscheinend wichtigste Teil des WPSC-Codes aus wp-cache-phase1.php LL371-383 verwendet ein RegEx-Muster, um eine Zeichenfolge abzurufen, mit der die Cookies durchlaufen werden:

$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);
}

Wenn ich nur mit PHP arbeiten würde, könnte ich die WP-Kernfunktionen neu erstellen oder einbinden und die normalen comment_author_ . COOKIEHASHEinstellungen durch die Kommentarvorlage erhalten, aber ich arbeite in jQuery mit dem jQuery-Cookie-Plug-in. Wie Sie jedoch sehen können, wenn Sie sich die RegEx ansehen, kümmert sich die WPSC-Funktion nicht um Folgendes COOKIEHASH: Sie ist zufrieden, wenn sie auf sie trifft comment_author_.

MEINE VORLÄUFIGE LÖSUNG

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

Für diejenigen, die mit jQuery Cookie nicht vertraut sind: Das oben Gesagte setzt ein einfaches Session-Cookie mit key = comment_author_proxyhashund value = proxy_author, das für die gesamte Site geeignet ist. (Außerdem habe ich für diejenigen, die jQuery Cookie und WP verwenden, zusätzlich zum Ersetzen $des WP durch die vertraute jQuery jQuerybereits festgelegt $.cookie.raw = true;.)

Ich habe die Zeile zu meinem jQuery-Skript hinzugefügt, und voila! , WPSC, W3 Total Cache und Comet Cache verhalten sich alle so, wie ich es möchte. Nachdem ich das Skript verwendet und neu geladen habe, erhalte ich neue Seiten. Wenn ich einen echten Kommentar hinterlasse, werden die normalen comment_author_und comment_author_email_Cookies gesetzt, und es scheint kein Problem mit der Koexistenz zu geben.

Möglicherweise besteht ein Fehler darin, dass der "Proxyhash" -Cookie mit dem Benutzer übertragen wird, solange er oder sie die Sitzung offen hält, aber das scheint mir kein großes Problem zu sein - oder sogar eine Warnung wert. Ich habe sicherlich noch nie von jemandem gehört, der sich über so etwas mit einem der normalen Cookies beschwert.

Aber vielleicht fehlt mir etwas, und ich werde noch viel zu meinem Leid herausfinden, wenn auch möglicherweise zu meiner Erbauung. Oder es gibt für mich eine relativ einfache Best-Practice-Methode, um die COOKIEHASHin jQuery zu replizieren und auch alternative Anwendungsfälle abzudecken ... oder den gleichen Endeffekt auf andere Weise zu erzielen - auf andere Weise, um die Caching-Plug-Ins dazu zu bringen, den Besucher zu behandeln als Kommentator ...

Wenn nicht, gibt es einen guten Grund, dieses oder ein ähnliches Element NICHT in einem Plug-In an das Universum weiterzugeben?

CK MacLeod
quelle
3
Requisiten für eine gut recherchierte und dokumentierte Frage. Ich bin jedoch der Meinung, dass die Art der Frage eher zu einer Diskussion als zu einer endgültigen Antwort führen könnte (Off-Topic: in erster Linie meinungsbasiert). FWIW meiner Meinung nach sehe ich hier nichts Falsches - letztendlich setzen Sie nur ein einziges generisches Cookie ohne personenbezogene Daten.
TheDeadMedic
Vielen Dank für die Eingabe. Ich wäre für eine solche Diskussion dankbar und würde jede Antwort als gut markieren, die a) auf ein Problem mit dieser "generischen Cookie" -Methode hinwies, b) alternative Mittel zur Erzielung desselben Effekts bereitstellte oder c) nützlich war Einblick in zugrunde liegende technische Fragen in Bezug auf "bekannte Benutzer".
CK MacLeod
Nur zur Erinnerung, Sie können wp_localize_scriptden Cookie-Hash an Ihr Javascript übergeben, damit Sie den "nativen" Cookie anstelle des Proxy-Hash verwenden können. Ansonsten ist dies ein sehr interessantes Problem und Ihre Lösung scheint solide zu sein, obwohl Cookies + Cache immer so komplex sind, dass es schwer zu sagen ist, ob es sich um die "richtige" Lösung handelt oder ob etwas übersehen wird. Großartige Forschung!
Phatskat
Interessante Frage - Mir fällt nichts ein, was Sie in Schwierigkeiten bringen könnte, aber kann ich Sie fragen, warum Sie den Cache auf diese Weise umgehen möchten? Indem Sie den Benutzern diese Möglichkeit geben, verlieren Sie den Zweck, zunächst den vollständigen Seiten-Cache zu haben. Ein zusätzliches Cookie erhöht die Anforderungsgröße (wenn auch nur geringfügig), wenn dasselbe Ergebnis mit allgemeinen Cache-Konfigurationen erzielt werden kann, indem einfach beliebige Abfrageparameter an die URL angehängt werden, z. B. mysite.com?a. Nur meine $ 0,02 ...
Snepenthe
ssnepenthe: Vielleicht hätte ich erklären sollen: Ein Plugin, das ich entwickelt habe, als ich die Frage schrieb - wordpress.org/plugins/commenter-ignore-button - verwendet jQuery, um Besuchern zu ermöglichen, ausgewählte Kommentatoren "zu ignorieren". Bei der ersten Aktion wird die CSS-Formatierung auf den Kommentarthread angewendet. Anschließend werden die Bezeichnung und das Vorhandensein eines Cookies in einem Cookie gespeichert, um den Effekt (über PHP) bei nachfolgenden Aktualisierungen bis zum Ablauf des Cookies zu duplizieren. In einer zwischengespeicherten Version der Seite würde der Effekt nicht registriert. Also, ja, es ist eine Form des absichtlichen lokalisierten Cache-Bustings.
CK MacLeod

Antworten:

1

Ihre Lösung mit dem Cookie comment_author_proxyhash wird natürlich technisch funktionieren - alle Caching-Plugins, die ich kenne, analysieren keinen Hash-Wert und stoppen lediglich die Auslieferung von zwischengespeicherten Inhalten basierend auf dem Cookie comment_author_ *.

Das Problem hierbei ist, dass die Seiten-Caching-Funktionalität etwas ist, das Websites wirklich benötigen. Oft wird das Seiten-Caching genau deshalb konfiguriert, weil die Leistung von nacktem WordPress nicht ausreicht und der Server in Spitzenzeiten sogar abstürzen kann. Dies hängt von der Art des Website-Inhalts ab, aber manchmal können Websitebesitzer einfach nicht für die Hardware bezahlen, die für die Abwicklung aller Aufgaben per PHP / WP-Code erforderlich ist. Mit anderen Worten, so viel Verkehr wie möglich muss aus dem Seiten-Cache bereitgestellt werden, wann immer dies möglich ist. Aus der Praxis kann ich sagen, dass wir oft Plugins identifizieren und deaktivieren müssen, die Cache-Ausnahmen ausführen.

Natürlich ist dies nicht immer möglich, aber versuchen Sie, wann immer möglich mit zwischengespeicherten Seiten zu arbeiten. Beispielsweise können Sie divTags mit Kommentaren, die Sie ignorieren möchten, über Javascript oder den Ajax-Ify-Block für ganze Kommentare ausblenden.

In jedem Fall müssen Sie den Besucher nicht als Kommentator markieren, sondern beenden das Zwischenspeichern aus Gründen Ihrer benutzerdefinierten Logik. Daher ist es besser, ein eindeutiges Cookie zu verwenden und es zu einem Cache-Ausnahmesignal zu machen. W3 Total Cache bietet dafür die Option "Cookies ablehnen", jedoch keine anderen Plugins aus Ihrer Liste, sodass Sie einen Hack wie den von Ihnen vorgeschlagenen benötigen.

WowPress.host
quelle
Vielen Dank! Sie werfen eine Reihe gültiger Probleme auf, aber ich sage, dieser Code behandelt im Wesentlichen jeden Besucher, der an den Kommentarthreads teilnimmt, so weit, dass er jemanden als "bekannten Benutzer" "ignoriert" oder "stummschaltet". Kommentator. " Wenn eine Site mit einer solchen Teilnahme nicht umgehen kann, kann sie wahrscheinlich auch keine Standard-WordPress-Kommentarvorlage (und keine Kommentar-Community) verarbeiten!
CK MacLeod
Denken Sie, Sie sind hier richtig, obwohl Sie natürlich nicht genau wissen, wie Ihre Benutzer es verwenden. Übrigens verlagern viele Websites mit hohem Datenaufkommen ihre Kommentarbearbeitung auf separate Anfragen oder sogar auf Dienste von Drittanbietern, um Artikelinhalte schnell anzuzeigen und dynamische Kommentare später nur schleppend zu laden. Nehmen Sie es als offtopische Idee für vielleicht weitere Versionen Ihres Plugins :)
WowPress.host