Ist diese Lösung für Caches vs Cookies in Schwierigkeiten geraten?

Ich habe eine vorläufige Lösung für ein nicht ganz normales, aber beispielloses Problem mit der Interaktion beliebter WP-Caching-Lösungen mit Cookies, in diesem Fall den Standard-WP-Kommentar-Cookies, gefunden. Meine Lösung bezieht sich auch auf die selten definierte “bekannte Benutzer” -Ausnahme, um zwischengespeicherte Dateien zu bedienen. Ob es nützlich ist oder nicht, ich denke, dass es allgemein lehrreich sein kann, es zu erklären und zu lernen, warum es eine schlechte Idee ist.

Ich habe meine Methode mit WP Super Cache, W3 Total Cache und Comet Cache getestet. Der, den ich während der Untersuchung dieses Problems im Detail für mich selbst kaputt machte, war WP Super Cache (“WPSC” im Folgenden), also werde ich es als mein Hauptbeispiel verwenden.

HINTERGRUND

Wenn ein WP-Standard-Kommentarthread so eingerichtet ist, dass Besucher Kommentare abgeben können, werden Kommentarkookien für jeden Kommentator festgelegt, der kein registrierter Benutzer ist und sich angemeldet hat. Aktuelle Kommentarprivilegien werden weiteren Prüfungen unterzogen. In der meiner Meinung nach häufigsten Konfiguration muss ein Kommentator nur einen Namen und eine E-Mail-Adresse angeben. Diese werden in zwei Browser-Cookies gespeichert, normalerweise comment_author_ . COOKIEHASH comment_author_ . COOKIEHASH und comment_author_email_ . COOKIEHASH comment_author_email_ . COOKIEHASH . COOKIEHASH ist nach Benutzeroptionen definiert.

Wenn sie so eingestellt ist, dass sie frisch erzeugte Dateien an “bekannte Benutzer” liefert, stellt WPSC fest, ob eine zwischengespeicherte Datei auf der Basis mehrerer Überprüfungen bereitgestellt werden soll: Eingeloggte Benutzer erhalten neue Dateien, ebenso Besucher “die Kommentare abgeben können”. Letztere werden hauptsächlich durch das Vorhandensein von Cookies vom comment_author_ in ihren Browsern comment_author_ die nicht speziell oder eindeutig für den bestimmten Benutzer von COOKIEHASH (normalerweise, aber nicht immer eine MD5-codierte Version des in Site-Optionen aufgezeichneten “siteurl”).

Was wie der Schlüssel des WPSC-Codes aus wp-cache-phase1.php LL371-383 aussieht, verwendet ein RegEx-Muster, um eine Zeichenfolge zu erhalten, die durch die Cookies läuft:

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

Nun, wenn ich streng in PHP arbeiten würde, könnte ich WP-corefunktionen neu erstellen oder comment_author_ . COOKIEHASH und den normalen comment_author_ . COOKIEHASH comment_author_ . COOKIEHASH von der Kommentarvorlage festgelegt, 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-function nicht um den COOKIEHASH : Er ist zufrieden, wenn er auf comment_author_ stößt.

MEINE TENTIVE LÖSUNG

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

Für diejenigen, die mit jQuery Cookie nicht vertraut sind: Das obige setzt ein einfaches Session Cookie mit key = comment_author_proxyhash und value = proxy_author , was gut für die gesamte Site ist. (Auch für diejenigen, die jQuery-Cookie und WP verwenden, zusätzlich zum $.cookie.raw = true; des bekannten jQuery $ für die WP jQuery , habe ich auch bereits $.cookie.raw = true; )

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

Vielleicht ist ein Defekt, dass der “Proxyshash” -Cookie mit dem Benutzer reist, solange er oder sie die Sitzung offen hält, aber das erscheint mir nicht so wahrscheinlich als ein Hauptproblem – oder sogar eine Warnung wert. Ich habe sicherlich noch nie von jemandem gehört, der sich darüber beschwert, dass so etwas mit einem der normalen cookies passiert.

Aber vielleicht gibt es etwas, das mir fehlt, und ich werde viel zu meinem Wehe entdecken, wenn auch zu meiner Erbauung. Oder vielleicht gibt es eine relativ einfache Best-Practice-Möglichkeit für mich, das COOKIEHASH in jQuery zu replizieren, auch alternative Anwendungsfälle COOKIEHASH … oder den gleichen End-Effekt mit anderen Mitteln zu erreichen – andere Wege, die Caching-Plug-Ins in die Behandlung der Besucher als Kommentator …

Wenn nicht, gibt es irgendeinen guten Grund, dies oder etwas in einem Plug-In NICHT ins Universum zu schieben?

Solutions Collecting From Web of "Ist diese Lösung für Caches vs Cookies in Schwierigkeiten geraten?"

Ihre Lösung mit comment_author_proxyhash cookie wird natürlich technisch funktionieren – alle Caching-Plugins, die ich kenne, analysieren den Hash-Wert nicht und stoppen nur die Lieferung von zwischengespeicherten Inhalten basierend auf comment_author_ * cookie presense.

Das Problem hierbei ist, dass Seiten-Caching-functionen von Websites wirklich benötigt werden und häufig das Seiten-Caching genau konfiguriert wird, weil die nackte WordPress-performance nicht ausreicht und sogar in Spitzenzeiten Server zum Absturz bringen kann. Das hängt von der Art der Website-Inhalte ab, aber Websitebesitzer sind manchmal nicht in der Lage, für Hardware zu bezahlen, die benötigt wird, um alles über PHP / WP-Code zu verarbeiten. Mit anderen Worten, so viel wie möglich muss der Verkehr aus dem Seitencache bedient werden, wann immer dies möglich ist. Aus der Praxis kann ich sagen, dass wir Plugins, die Cache-Ausnahmen machen, oft identifizieren und deaktivieren müssen.

Natürlich ist es nicht immer möglich, aber versuchen Sie, mit der zwischengespeicherten Seite zu arbeiten, wann immer es möglich ist. Zum Beispiel können Sie div Tags mit Kommentaren verbergen, die Sie über Javascript ignorieren möchten, oder Ajax-ify ganze Kommentare blockieren.

In jedem Fall müssen Sie den Besucher nicht als Kommentator markieren, sondern die Zwischenspeicherung aufgrund von benutzerdefinierten Logikgründen einstellen. Es ist also besser, ein eindeutiges Cookie zu verwenden und es zu einem Cache-Ausnahmesignal zu machen. W3 Total Cache hat hierfür die Option “Cookies ablehnen”, aber keine anderen Plugins aus Ihrer Liste, so dass Sie einen Hack benötigen, wie Sie ihn vorgeschlagen haben.