¿Esta solución para cachés frente a cookies me va a meter en problemas?

23

Se me ocurrió una solución provisional para un problema no exactamente común, pero lejos de ser inédito con la interacción de las soluciones populares de almacenamiento en caché de WP con cookies, en este caso las cookies de comentarios estándar de WP. Mi solución también tiene que ver con la excepción rara vez bien definida de "usuarios conocidos" para servir archivos en caché. Ya sea que se pueda usar o no, creo que explicarlo y posiblemente aprender por qué es una mala idea puede ser generalmente instructivo.

He probado mi método con WP Super Cache, W3 Total Cache y Comet Cache. El que analicé en detalle mientras estudiaba este problema fue WP Super Cache ("WPSC" en adelante), así que lo usaré como mi ejemplo principal.

FONDO

Cuando se establece un hilo de comentarios estándar de WP para permitir que los visitantes comenten, las cookies de comentarios se configuran para cualquier comentarista que no sea un usuario registrado y que haya iniciado sesión, con privilegios de comentarios reales sujetos a verificaciones adicionales. En lo que creo que es la configuración más común, un comentarista debe proporcionar solo un nombre y una dirección de correo electrónico. Estos se almacenan en dos cookies del navegador, generalmente comment_author_ . COOKIEHASH, y comment_author_email_ . COOKIEHASH. COOKIEHASHse define de acuerdo con las opciones del usuario.

Si está configurado para entregar archivos recién generados a "usuarios conocidos", WPSC determina si se debe servir o no un archivo en caché sobre la base de varias comprobaciones: los usuarios conectados obtienen archivos nuevos, y también los visitantes "que pueden comentar". Estos últimos se identifican principalmente por la presencia en sus navegadores de comment_author_cookies que no están identificadas específica o exclusivamente para el usuario en particular por el COOKIEHASH(generalmente, pero no siempre, una versión codificada en MD5 del "siteurl" registrada en las opciones del sitio).

Lo que parece ser la parte clave del código WPSC, de wp-cache-phase1.php LL371-383, utiliza un patrón RegEx para obtener una cadena, recorriendo las 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);
}

Ahora, si estuviera trabajando estrictamente en PHP, podría volver a producir o conectarme a las funciones principales de WP, y obtener el comment_author_ . COOKIEHASHconjunto normal de la plantilla de comentarios, pero estoy trabajando en jQuery usando el complemento jQuery Cookie. Sin embargo, como puede ver si observa el RegEx, la función WPSC no se preocupa por COOKIEHASH: se satisface si se encuentra comment_author_.

Mi solución tentativa

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

Para aquellos que no están familiarizados con jQuery Cookie: lo anterior establece una cookie de sesión simple con clave = comment_author_proxyhashy valor = proxy_author, buena para todo el sitio. (Además, para aquellos que usan jQuery Cookie y WP, además de sustituir previamente el familiar jQuery $por el WP jQuery, también lo he configurado $.cookie.raw = true;).

Agregué la línea a mi script jQuery y ¡listo! , WPSC, W3 Total Cache y Comet Cache están actuando como yo quiero que lo hagan. Después de usar el script y volver a cargar, obtengo páginas nuevas. Si sucede que hago un comentario real, se establecen las cookies normales comment_author_y las normales comment_author_email_, y no parece haber ningún problema con la coexistencia.

Quizás un defecto sería que la cookie "proxyhash" viajará con el usuario siempre que mantenga la sesión abierta, pero eso no me parece un problema importante, o incluso vale la pena una advertencia. Ciertamente, nunca escuché que alguien se quejara de que tal cosa sucediera con una de las cookies normales.

Pero tal vez hay algo que me falta, y que estoy a punto de descubrir mucho para mi desgracia, si es que también para mi edificación. O tal vez hay una forma relativamente simple de mejores prácticas para mí para replicar COOKIEHASHen jQuery, que también cubre casos de uso alternativos ... o para lograr el mismo efecto final por otros medios: otras formas de engañar a los complementos de almacenamiento en caché para tratar al visitante como comentarista ...

Si no, ¿hay alguna buena razón para NO enviar esto o algo cercano al universo en un complemento?

CK MacLeod
fuente
3
Apoyos para una pregunta bien investigada y documentada. Sin embargo, creo que la naturaleza de la pregunta podría abrir esto a más debate en lugar de una respuesta definitiva (fuera del tema: principalmente basado en la opinión). FWIW, en mi opinión, no veo nada malo aquí; en última instancia, solo está configurando una única cookie genérica sin datos personales.
TheDeadMedic
Muchas gracias por el aporte. Estaría agradecido por tal discusión, y marcaría como buenas respuestas cualquiera que a) señalara un problema con este método de "cookie genérica", b) proporcionó medios alternativos para lograr el mismo efecto, o c) proporcionó información útil comprensión de las cuestiones técnicas subyacentes relacionadas con los "usuarios conocidos".
CK MacLeod
Solo para tener en cuenta, puede usar wp_localize_scriptpara pasar el hash de cookies a su Javascript para que pueda usar la cookie "nativa" en lugar del proxyhash. De lo contrario, este es un tema muy interesante y su solución parece sólida, aunque las cookies + caché siempre son tan complejas que es difícil decir si es la solución "correcta" o si se está perdiendo algo. ¡Gran investigación!
phatskat
Pregunta interesante: no puedo pensar en nada que pueda meterte en problemas, pero ¿puedo preguntarte por qué quieres evitar el caché de esta manera? Brindar a los usuarios este tipo de habilidad frustra el propósito de tener la caché de página completa para empezar. Además, una cookie adicional se agrega al tamaño de la solicitud (aunque sea mínimamente), cuando se puede lograr el mismo resultado con configuraciones de caché comunes simplemente agregando cualquier parámetro de consulta a la URL, por ejemplo, mysite.com?a. Solo mis $ 0.02 ...
ssnepenthe
ssnepenthe: Tal vez debería haber explicado: un complemento que estaba desarrollando cuando escribí la pregunta - wordpress.org/plugins/commenter-ignore-button - usa jQuery para permitir a los visitantes poner "comentar" a los comentaristas seleccionados. La acción inicial aplica el formato CSS al hilo de comentarios, y luego se basa en una cookie para almacenar la designación y su presencia para duplicar el efecto (a través de PHP) en las actualizaciones posteriores hasta el vencimiento de la cookie. En una versión en caché de la página, el efecto no se registraría. Entonces, sí, es una forma intencional de capturar caché localizada.
CK MacLeod

Respuestas:

1

Su solución con la cookie comment_author_proxyhash funcionará técnicamente, por supuesto, todos los complementos de almacenamiento en caché que conozco no analizan el valor hash y simplemente detendrán la entrega de contenido en caché basado en la presencia de cookies comment_author_ *.

El problema aquí es que la funcionalidad de almacenamiento en caché de la página es algo que los sitios web realmente necesitan y, a menudo, el almacenamiento en caché de la página se configura exactamente porque el rendimiento de WordPress no es suficiente e incluso puede bloquear el servidor en las horas punta. Depende de la naturaleza del contenido del sitio web, pero los propietarios del sitio a veces simplemente no pueden pagar el hardware requerido para manejar todo a través del código PHP / WP. En otras palabras, tanto como sea posible el tráfico debe ser servido desde la caché de la página siempre que sea posible. En la práctica, puedo decir que a menudo tenemos que identificar y deshabilitar los complementos haciendo excepciones de caché.

Por supuesto, no siempre es posible, pero trate de trabajar con la página en caché siempre que sea posible. Por ejemplo, puede ocultar divetiquetas con comentarios que desea ignorar a través de javascript o ajax-ify bloque de comentarios completo.

En cualquier caso, no necesita marcar al visitante como comentador, pero deje de almacenar en caché debido a sus razones lógicas personalizadas. Por lo tanto, es mejor usar cookies únicas y convertirlas en una señal de excepción de caché. W3 Total Cache tiene la opción "Rechazar cookies" para eso, pero no otros complementos de su lista, por lo que necesitará un truco como el que ha sugerido.

WowPress.host
fuente
¡Gracias! Planteas una cantidad de problemas válidos, pero diré que lo que hace este código, esencialmente, es tratar a cualquier visitante que esté participando en los hilos de comentarios lo suficiente como para poner a alguien "ignorado" o "silenciado" como un "usuario conocido / comentarista ". Si un sitio no puede manejar dicha participación, ¡probablemente tampoco pueda manejar una plantilla estándar de comentarios de WordPress (y una comunidad de comentarios)!
CK MacLeod
Cree que está aquí, aunque, por supuesto, no puede saber con certeza cómo lo usan sus usuarios. Por cierto, muchos sitios web de alto tráfico descargan su procesamiento de comentarios a solicitudes separadas o incluso a un servicio de terceros exactamente con el fin de mostrar el contenido del artículo de manera rápida y la carga lenta de contenido de comentarios dinámicos más tarde. Tómelo como una idea fuera de tema para quizás más versiones de su complemento :)
WowPress.host