Esta solução para Caches vs Cookies vai me trazer problemas?

Eu vim com uma solução provisória para um problema não exatamente comum, mas longe de ser um precedente com a interação de soluções populares de cache do WP com cookies, nesse caso, os cookies de comentário padrão do WP. Minha solução também tem a exceção de "usuários conhecidos" raramente bem definida em servir arquivos em cache. Seja utilizável ou não, acho que explicá-lo e, possivelmente, aprender por que é uma má ideia podem ser geralmente instrutivos.

Testei meu método com WP Super Cache, W3 Total Cache e Comet Cache. O que eu quebrei detalhadamente para mim mesmo enquanto estudava esse problema era o WP Super Cache ("WPSC" a seguir), por isso vou usá-lo como meu exemplo principal.

FUNDO

Quando um segmento de comentário padrão do WP é definido para permitir que os visitantes comentem, os cookies de comentários são definidos para qualquer comentarista que não seja um usuário registrado e logado, com privilégios de comentários reais sujeitos a verificações adicionais. No que eu acredito ser a configuração mais comum, um comentarista precisa fornecer apenas um nome e um endereço de email. Eles são armazenados em dois cookies do navegador, geralmente comment_author_ . COOKIEHASH, e comment_author_email_ . COOKIEHASH. COOKIEHASHé definido de acordo com as opções do usuário.

Se definido para entregar arquivos gerados recentemente a "usuários conhecidos", o WPSC determina se um arquivo armazenado em cache deve ou não ser usado com base em várias verificações: Os usuários conectados obtêm arquivos novos e os visitantes "que podem comentar". Estes últimos são principalmente identificados pela presença em seus navegadores de comment_author_cookies que não são identificados de maneira específica ou exclusiva para o usuário em particular pelo COOKIEHASH(geralmente, mas nem sempre, uma versão codificada em MD5 do "siteurl" registrado nas opções do site).

O que parece ser a parte principal do código WPSC, de wp-cache-phase1.php LL371-383, usa um padrão RegEx para obter uma string, alternando entre os 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);
}

Agora, se eu estivesse trabalhando estritamente no PHP, poderia reproduzir ou conectar-se às funções principais do WP e obter o comment_author_ . COOKIEHASHconjunto normal pelo modelo de comentário, mas estou trabalhando no jQuery usando o plug-in Cookie do jQuery. No entanto, como você pode ver se você olha para o RegEx, a função WPSC não se importa com o COOKIEHASH: Está satisfeito se encontrar comment_author_.

MINHA SOLUÇÃO TENTATIVA

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

Para aqueles que não estão familiarizados com o jQuery Cookie: O item acima define um cookie de sessão simples com a chave = comment_author_proxyhashe o valor = proxy_author, bom para todo o site. (Além disso, para aqueles que usam o jQuery Cookie e o WP, além de pré-substituir o familiar jQuery $pelo WP jQuery, também defini $.cookie.raw = true;.)

Eu adicionei a linha ao meu script jQuery e pronto! , WPSC, W3 Total Cache e Comet Cache estão agindo como eu quero. Depois de usar o script e recarregar, recebo novas páginas. Se eu colocar um comentário real, o normal comment_author_e os comment_author_email_cookies estão definidos, e não parece haver nenhum problema com a coexistência.

Talvez um defeito seja que o cookie "proxyhash" viaje com o usuário enquanto ele mantiver a sessão aberta, mas isso não me parece um grande problema - ou até vale um aviso. Eu certamente nunca ouvi falar de alguém reclamando de tal coisa acontecendo com um dos cookies regulares.

Mas talvez haja algo que esteja faltando, e prestes a descobrir muito para minha aflição, se possível para minha edificação. Ou talvez exista uma maneira relativamente simples de práticas recomendadas para replicar o COOKIEHASHno jQuery, também cobrindo casos de uso alternativos ... ou obter o mesmo efeito final por outros meios - outras maneiras de enganar os plug-ins de cache para tratar o visitante como comentarista ...

Caso contrário, existe alguma boa razão para NÃO enviar isso ou algo próximo ao universo em um plug-in?

É claro que sua solução com o cookie comment_author_proxyhash funcionará tecnicamente - todos os plugins de cache que eu conheço não analisam o valor do hash e apenas interromperão a entrega do conteúdo em cache com base na presença do cookie comment_author_ *.

O problema aqui é que a funcionalidade de cache de página é algo que os sites realmente precisam e, geralmente, o cache de página é configurado exatamente porque o desempenho nu do WordPress não é suficiente e pode até travar o servidor nos horários de pico. Depende da natureza do conteúdo do site, mas os proprietários do site às vezes simplesmente não conseguem pagar pelo hardware necessário para lidar com tudo via código PHP / WP. Em outras palavras, o tráfego possível deve ser atendido a partir do cache da página sempre que possível. Na prática, posso dizer que geralmente precisamos identificar e desativar plugins que fazem exceções de cache.

Claro que nem sempre é possível, mas tente trabalhar com a página em cache sempre que possível. Por exemplo, você pode ocultar divtags com comentários que deseja ignorar via javascript ou bloco inteiro de comentários do ajax-ify.

De qualquer forma, você não precisa marcar o visitante como comentarista, mas pare o cache por causa de seus motivos lógicos personalizados. Portanto, é melhor usar um cookie exclusivo e torná-lo um sinal de exceção de cache. O W3 Total Cache tem a opção "Rejeitar cookies" para isso, mas não outros plugins da sua lista, portanto, você precisará de um hack como o sugerido.