Questa soluzione per cache e cookie sta per mettermi nei guai?

Ho trovato una soluzione provvisoria per un problema non esattamente comune, ma tutt'altro che senza precedenti con l'interazione delle popolari soluzioni di cache WP con i cookie, in questo caso i cookie di commento WP standard. La mia soluzione riguarda anche l'eccezione raramente ben definita degli "utenti noti" alla pubblicazione di file memorizzati nella cache. Che sia utilizzabile o meno, immagino che spiegarlo e possibilmente imparare perché sia ​​una cattiva idea potrebbe essere generalmente istruttivo.

Ho testato il mio metodo con WP Super Cache, W3 Total Cache e Comet Cache. Quello che ho analizzato nel dettaglio mentre studiavo questo problema era WP Super Cache (di seguito "WPSC"), quindi lo userò come esempio principale.

SFONDO

Quando viene impostato un thread di commenti standard WP per consentire ai visitatori di commentare, i cookie di commenti vengono impostati per qualsiasi commentatore che non sia un utente registrato e abbia effettuato l'accesso, con i privilegi di commento effettivi soggetti a ulteriori controlli. In quella che credo sia la configurazione più comune, un commentatore deve fornire solo un nome e un indirizzo e-mail. Questi sono memorizzati all'interno di due cookie del browser, di solito comment_author_ . COOKIEHASHe comment_author_email_ . COOKIEHASH. COOKIEHASHè definito in base alle opzioni dell'utente.

Se impostato per recapitare i file appena generati a "utenti noti", il WPSC determina se pubblicare o meno un file memorizzato nella cache sulla base di numerosi controlli: gli utenti registrati ottengono nuovi file e così i visitatori "possono commentare". Questi ultimi sono principalmente identificati dalla presenza nei loro browser di comment_author_cookie che non sono identificati in modo specifico o univoco per il particolare utente dal COOKIEHASH(di solito ma non sempre una versione codificata MD5 del "siteurl" registrato nelle opzioni del sito).

Quella che sembra essere la parte chiave del codice WPSC, da wp-cache-phase1.php LL371-383, utilizza un modello RegEx per ottenere una stringa, scorrendo ciclicamente i cookie:

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

Ora, se lavorassi rigorosamente in PHP, potrei ri-produrre o agganciare le funzioni principali di WP e ottenere il normale comment_author_ . COOKIEHASHset dal modello di commento, ma sto lavorando in jQuery usando il plug-in jQuery Cookie. Tuttavia, come puoi vedere se guardi il RegEx, la funzione WPSC non si preoccupa di COOKIEHASH: È soddisfatta se incontra comment_author_.

LA MIA SOLUZIONE TENTATIVA

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

Per chi non ha familiarità con jQuery Cookie: quanto sopra imposta un semplice cookie di sessione con key = comment_author_proxyhashe value = proxy_author, buono per l'intero sito. (Inoltre, per coloro che utilizzano jQuery Cookie e WP, oltre a sostituire il familiare jQuery $per WP jQuery, ho già impostato $.cookie.raw = true;.)

Ho aggiunto la riga al mio script jQuery e, voilà! , WPSC, W3 Total Cache e Comet Cache agiscono tutti come voglio io. Dopo aver usato lo script e ricaricato, ricevo nuove pagine. Se mi capita di inserire un commento reale, vengono impostati i normali comment_author_e i comment_author_email_cookie e non sembra esserci alcun problema con la coesistenza.

Forse un difetto sarebbe che il cookie "proxyhash" viaggerà con l'utente fintanto che mantiene aperta la sessione, ma ciò non mi sembra probabile un grosso problema o addirittura merita un avvertimento. Di certo non ho mai sentito parlare di qualcuno che si lamenta di una cosa del genere con uno dei normali biscotti.

Ma forse c'è qualcosa che mi manca e che sto per scoprire molto per il mio dolore, anche se potenzialmente per la mia edificazione. O forse c'è un modo relativamente semplice per la mia pratica di replicare COOKIEHASHin jQuery, coprendo anche casi d'uso alternativi ... o per ottenere lo stesso effetto finale con altri mezzi - altri modi per ingannare i plug-in di cache nel trattare il visitatore come commentatore ...

In caso contrario, c'è qualche buona ragione per NON spingere questo o qualcosa di simile all'universo in un plug-in?

Ovviamente la tua soluzione con cookie comment_author_proxyhash funzionerà tecnicamente: tutti i plug-in di cache che conosco non analizzano il valore di hash e interromperanno semplicemente la consegna del contenuto memorizzato nella cache in base alla presenza di cookie comment_author_ *.

Il problema qui è che la funzionalità di memorizzazione nella cache delle pagine è qualcosa di cui i siti Web hanno davvero bisogno e spesso la memorizzazione nella cache delle pagine è configurata esattamente perché le prestazioni di WordPress non sono sufficienti e sono in grado di arrestare il server nelle ore di punta. Dipende dalla natura del contenuto del sito Web, ma a volte i proprietari dei siti non sono in grado di pagare per l'hardware necessario per gestire tutto tramite codice PHP / WP. In altre parole, il più possibile traffico deve essere offerto dalla cache della pagina ogni volta che è possibile. Dalla pratica, posso dire che spesso dobbiamo identificare e disabilitare i plug-in che fanno eccezioni alla cache.

Ovviamente non è sempre possibile, ma cerca di lavorare con la pagina memorizzata nella cache ogni volta che è possibile. Ad esempio, è possibile nascondere divtag con commenti che si desidera ignorare tramite javascript o blocco di commenti interi ajax-ify.

In ogni caso non è necessario contrassegnare il visitatore come commentatore, ma interrompere la memorizzazione nella cache a causa dei motivi logici personalizzati. Quindi è meglio usare un cookie unico e renderlo un segnale di eccezione della cache. W3 Total Cache ha l'opzione "Rifiuta i cookie", ma non altri plug-in dal tuo elenco, quindi avrai bisogno di un hack come quello che hai suggerito.