Cette solution pour les caches contre les cookies va-t-elle me poser problème?

23

J'ai mis au point une solution provisoire pour un problème peu commun, mais loin d'être sans précédent, de l'interaction de solutions de mise en cache WP populaires avec des cookies, en l'occurrence les cookies de commentaire WP standard. Ma solution porte également sur l'exception "utilisateurs connus", rarement définie, de la fourniture de fichiers en cache. Que ce soit utilisable ou non, je pense que l'expliquer et éventuellement comprendre pourquoi c'est une mauvaise idée pourrait être généralement instructif.

J'ai testé ma méthode avec WP Super Cache, W3 Total Cache et Comet Cache. WP Super Cache (ci-après "WPSC") est un exemple de ce que j’ai décomposé en détail lors de l’examen de ce problème. C’est pourquoi je l’utiliserai comme principal exemple.

CONTEXTE

Lorsqu'un fil de commentaires standard WP est défini pour permettre aux visiteurs de commenter, les cookies de commentaires sont configurés pour tout commentateur qui n'est pas un utilisateur enregistré et connecté. Ses privilèges de commentaire sont soumis à des vérifications supplémentaires. Dans ce que je crois être la configuration la plus courante, un intervenant doit uniquement fournir un nom et une adresse électronique. Ceux-ci sont stockés dans deux cookies de navigateur, généralement comment_author_ . COOKIEHASH et comment_author_email_ . COOKIEHASH . COOKIEHASH est défini en fonction des options de l'utilisateur.

S'il est configuré pour fournir des fichiers nouvellement générés à des "utilisateurs connus", WPSC détermine si un fichier mis en cache doit être ou non archivé sur la base de plusieurs vérifications: les utilisateurs connectés obtiennent de nouveaux fichiers, ainsi que les visiteurs "qui peuvent commenter. " Ces derniers sont principalement identifiés par la présence dans leurs navigateurs de comment_author_ de cookies qui ne sont pas spécifiquement ou spécifiquement identifiés pour l'utilisateur concerné par COOKIEHASH (généralement, mais pas toujours, une version codée en MD5 du "siteurl" enregistrée dans le site). options).

Ce qui semble être la partie clé du code WPSC, à partir de wp-cache-phase1.php LL371-383, utilise un modèle RegEx pour obtenir une chaîne, en passant en revue les cookies:

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

Maintenant, si je travaillais strictement en PHP, je pourrais reproduire ou intégrer des fonctions de base de WP et obtenir le comment_author_ . COOKIEHASH normal défini par le modèle de commentaire, mais je travaille dans jQuery à l'aide du plugin jQuery Cookie. dans. Cependant, comme vous pouvez le voir si vous consultez RegEx, la fonction WPSC ne se soucie pas de COOKIEHASH : elle est satisfaite si elle rencontre comment_author_ .

Ma solution provisoire

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

Pour ceux qui ne sont pas familiers avec le cookie jQuery: La procédure ci-dessus définit un cookie de session simple avec la clé = comment_author_proxyhash et la valeur = proxy_author , bon pour l’ensemble du site. (En outre, pour ceux qui utilisent jQuery Cookie et WP, en plus de pré-substituer le familier jQuery $ au WP jQuery , j’ai déjà défini $.cookie.raw = true; .)

J'ai ajouté la ligne à mon script jQuery et, voila! , WPSC, W3 Total Cache et Comet Cache agissent tous comme je le souhaite. Après avoir utilisé le script et rechargé, je reçois de nouvelles pages. Si je mets un vrai commentaire, les cookies normaux comment_author_ et comment_author_email_ sont définis et il ne semble pas y avoir de problème de coexistence.

Peut-être un défaut serait-il que le cookie "proxyhash" voyagera avec l'utilisateur tant qu'il laissera la session ouverte, mais cela ne me semble pas être un problème majeur - ni même un avertissement. Je n'ai certainement jamais entendu parler de quelqu'un se plaindre d'une telle chose avec l'un des cookies habituels.

Mais peut-être qu'il me manque quelque chose et sur le point de découvrir beaucoup de choses à mon chagrin, si potentiellement à mon édification aussi. Ou peut-être existe-t-il un moyen relativement simple, conforme aux meilleures pratiques, de reproduire le COOKIEHASH dans jQuery, en couvrant également d'autres cas d'utilisation ... ou d'obtenir le même effet final par d'autres moyens - d'autres moyens de transformer les plug-ins de mise en cache en traiter le visiteur comme un commentateur ...

Si non, y a-t-il une bonne raison de NE PAS pousser ceci ou quelque chose de proche vers l'univers dans un plug-in?

    
posée CK MacLeod 30.11.2016 - 01:15
la source

1 réponse

0

Votre solution avec le cookie comment_author_proxyhash fonctionnera évidemment sur le plan technique - tous les plugins de mise en cache que je connais n’analysent pas la valeur de hachage et arrêtent simplement la diffusion du contenu mis en cache sur la base de la présentation de cookie.

Le problème ici est que la fonctionnalité de mise en cache des pages est un élément indispensable des sites Web. Souvent, la mise en cache des pages est configurée avec précision, car les performances WordPress nues ne suffisent pas et peuvent même faire planter le serveur aux heures de pointe. Cela dépend de la nature du contenu du site Web, mais les propriétaires de site ne sont parfois tout simplement pas en mesure de payer le matériel nécessaire pour tout gérer via le code PHP / WP. Autrement dit, autant que possible, le trafic doit être servi à partir du cache de pages. De pratique, je peux dire que nous devons souvent identifier et désactiver les plugins faisant des exceptions de cache.

Bien sûr, ce n’est pas toujours possible, mais essayez autant que possible de travailler avec une page en cache. Par exemple, vous pouvez masquer les balises div avec les commentaires que vous souhaitez ignorer via javascript ou le blocage de commentaires entiers ajax-ify.

Dans tous les cas, vous n'avez pas besoin de marquer le visiteur comme commentateur, mais d'arrêter la mise en cache pour des raisons de logique personnalisée. Il est donc préférable d'utiliser un cookie unique et d'en faire un signal d'exception de cache. W3 Total Cache a l'option "Refuser les cookies" pour cela, mais pas les autres plugins de votre liste, vous aurez donc besoin d'un hack similaire à celui que vous avez suggéré.

    
réponse donnée WowPress.host 25.01.2018 - 19:18
la source

Lire d'autres questions sur les étiquettes