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

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?

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.