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?
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!