it-swarm.com.de

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 den Standard-WP Kommentar Kekse. 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 im Detail aufgeschlüsselt habe, war WP Super Cache (im Folgenden "WPSC"), daher verwende ich es als mein Hauptbeispiel.

HINTERGRUND

Wenn ein WP Standard-Kommentarthread festgelegt ist, um Besuchern das Kommentieren zu ermöglichen, 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 zwei Browser-Cookies gespeichert, normalerweise comment_author_ . COOKIEHASH und comment_author_email_ . COOKIEHASH. COOKIEHASH wird 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 dadurch identifiziert, dass in ihren Browsern comment_author_-Cookies vorhanden sind, die von der COOKIEHASH nicht spezifisch oder eindeutig für den jeweiligen Benutzer identifiziert werden (normalerweise, aber nicht immer, eine MD5-codierte Version des in den Site-Optionen aufgezeichneten "siteurl").

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 Kernfunktionen von WP neu erstellen oder einbinden und den normalen comment_author_ . COOKIEHASH abrufen, der von der Kommentarvorlage festgelegt wird, aber ich arbeite in jQuery mit dem jQuery-Cookie-Plug -im. Wie Sie jedoch sehen können, wenn Sie sich die RegEx ansehen, kümmert sich die WPSC-Funktion nicht um die COOKIEHASH: Es ist zufrieden, wenn sie auf comment_author_ trifft.

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 legt ein einfaches Sitzungscookie mit key = comment_author_proxyhash und value = proxy_author fest, das für die gesamte Site gültig ist. (Außerdem habe ich für diejenigen, die jQuery Cookie und WP verwenden, zusätzlich zum Ersetzen der WP jQuery durch den bekannten jQuery $ bereits $.cookie.raw = true; festgelegt.)

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 COOKIEHASH in jQuery zu replizieren, die auch alternative Anwendungsfälle abdeckt ... oder den gleichen Endeffekt auf andere Weise zu erzielen - auf andere Weise, um die Caching-Plug-Ins dazu zu bringen, die zu behandeln Besucher als Kommentator ...

Wenn nicht, gibt es einen guten Grund, dieses oder etwas in der Nähe befindliches NICHT in einem Plug-In an das Universum zu senden?

23
CK MacLeod

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 div Tags mit Kommentaren, die Sie ignorieren möchten, über Javascript oder den gesamten Ajax-Ify-Kommentarblock 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.

1
WowPress.host