1 Blog Cacher: caching plugin per WordPress

Cercando di dare una mano ad un mio gentile lettore, alle prese con problemi nell’installazione del famigerato WP-Cache, mi sono definitivamente reso conto di quanto questo plugin – da molti mesi del resto non più supportato né sviluppato – riesca a disseminare di dubbi ed incertezze l’esistenza dei suoi pur numerosi utilizzatori. Installare e configurare correttamente WP-Cache non è infatti sempre sufficiente a vederlo mettersi al lavoro, vista la sua tendenza ad “indispettirsi” e scioperare, sensibile com’è ad una serie di variabili, il più delle volte imprevedibili e ad ogni logica tetragone.

L’umorale WP-Cache può rifiutare di lasciarsi correttamente installare o smettere di funzionare per mille motivi, che comprendono il semplice aggiornamento di WordPress, l’uso nemmeno troppo disinvolto di queries al database all’interno di un template, l’ordine con cui viene attivato rispetto agli altri plugin, il passaggio della Luna in Saturno, il posizionamento non feng-shui del vostro server. Essendomi in buona sostanza rotto le balle di dover continuamente assecondare le lune (non riesco a definirle altrimenti) di un plugin senescente, mi sono messo alla ricerca di qualcosa di meglio. Trovandolo.

La quadratura del cerchio è l’ancora semisconosciuto (a confronto con “nonno“ WP-Cache) 1 Blog Cacher 2.0, dello spagnolo Javier García. Fa quel che deve fare ed anche bene, lasciandosi installare senza complicazioni, funzionando sia in safe_mode che non, restituendo header HTTP corretti, col pieno supporto della compressione di tipo Gzip. Il tutto piuttosto velocemente.

Una panoramica delle caratteristiche di 1 Blog Cacher 2.0

• Compatibile con WordPress 1.5 o più recente (testato al momento fino alla versione 2.3.1)

• Facile e veloce da installare e configurare

• Portabile: le sue impostazioni sono indipendenti dal percorso di installazione di WordPress e da quelle del database.

• I file della cache sono salvati in formato HTML ed organizzati in cartelle che riproducono la struttura degli URL, per una loro più facile gestione (si pensi ad esempio al dover rintracciare le copie cache di una determinata pagina, di un’intera categoria, dei post di un determinato periodo)

• Il plugin funziona anche con safe_mode attivato, pur senza la possibilità di organizzare i file della cache in sottocartelle.

• Possibilità di cancellare tutti i file della cache (o solo quelli scaduti) direttamente dal pannello di controllo di WordPress.

• Possibilità di impostare la durata dei file della cache.

• Possibilità di impostare filtri per abilitare o disabilitare il caching di determinate pagine (o di gruppi, ad esempio: il filtro wp-admin disabilita il caching dell’interfaccia di amministrazione di WordPress).

• Gestione degli User Agents per evitare il caching di massa da parte dei motori di ricerca e per mostrare loro i contenuti più aggiornati.

• I file della cache vengono aggiornati ogni volta che post e commenti vengono pubblicati, modificati o cancellati.

• Possibilità di restituire un header di tipo “Expires” in modo da far uso della cache del browser, riducendo i tempi di risposta ed il numero delle richieste.

• Vengono memorizzate nella cache solo pagine generate da richieste di tipo GET

• Il cosiddetto “Browser super-reload“ (Ctrl+F5) viene riconosciuto e restituisce la versione aggiornata della pagina richiesta.

• Supporto della compressione di tipo Gzip.

Novità della versione 2.0

• Utilizzo del file di WordPress advanced-cache.php. Il plugin viene eseguito prima del completo caricamento di WordPress, riducendo i tempi di esecuzione e (soprattutto) l’occupazione di memoria.

• Efficiente gestione degli header HTTP, salvati separatamente in formato .txt per poter essere opportunamente modificati, ed opportunamente restituiti.

• Supporto all’utilizzo di codice dinamico (inseribile tramite i commenti mfunc e mclude), come già in Staticize Reloaded (e successivamente in WP-Cache).

  • Nel caso in cui sia attivata la compressione di tipo Gzip, le pagine vengono salvate già compresse in formato .gz, in modo che la compressione avvenga una volta sola, risparmiando tempo e risorse di sistema. L’eventuale codice dinamico viene eseguito senza problemi: la copia compressa verrà aggiornata solamente se il codice dinamico dovesse generare un contenuto differente da quello già memorizzato.

  • La compressione di tipo Gzip è attivata, ma non si fa uso di codice dinamico? È possibile non effettuare alcun controllo sui contenuti dinamici, impostando a false la costante OBC_LOOK_FOR_DYNAMIC_CODE.

• Quando opportuno, viene restituito un header HTTP di tipo 304 (not modified), per un’ancora maggiore velocità di caricamento delle pagine.

  • Prima di restituire la stessa copia cache allo stesso utente, il plugin aggiunge un header di tipo 304 (not modified).

  • L’header di tipo 304 viene aggiunto anche nel caso in cui al medesimo utente stia per venire restituita una nuova copia cache dal medesimo contenuto di quella precedente (il confronto avviene per mezzo di un header di tipo Etag con hash).

• Ogni volta che un post viene creato, modificato o cancellato vengono automaticamente rigenerate sia la sua copia che quella della pagina indice.

• Gestione degli utenti registrati e dei commentatori. È possibile scegliere tra tre opzioni:

  • 0: nessun caching per gli utenti registrati e per i commentatori.

  • 1: imposta una cache comune a tutti gli utenti e commentatori.

  • 2: imposta una cache individuale per ogni singolo utente registrato (o commentatore).

• Ulteriori opzioni di configurazione:

  • Possibilità di memorizzare nella cache le pagine di errore (status 404).

  • Possibilità di memorizzare nella cache i reindirizzamenti (status 301 o 302).

  • Possibilità di rimuovere il trailing slash (/) finale dagli indirizzi, onde evitare il caching di contenuti duplicati (da non usare con WordPress 2.3+ o nel caso si utilizzino plugin per la gestione dei trailing slashes)

  • Possibilità di salvare i file in un’unica cartella.

• Il plugin crea automaticamente un file .htaccess nella cartella /wp-cache/ per prevenirne l’accesso non autorizzato e l’indicizzazione da parte dei motori di ricerca.

• Unico «inconveniente» di questa versione: la cartella della cache deve obbligatoriamente essere /cartella-di-wordpress/wp-cache/ (è ad ogni modo semplicissimo cambiarne il percorso mettendo mano al codice).

Ce n’è abbastanza per decidere di pensionare l’ormai obsoleto WP-Cache. Che aspettate?

1 Blog Cacher e FireStats: una convivenza possibile?

Il codice di 1 Blog Cacher viene eseguito prima di ogni altra funzione nativa di WordPress e di ogni altro plugin: se nella cache esiste una pagina valida, 1 Blog Cacher restituirà questa, bloccando l’esecuzione di ogni altro codice lato server. Ne consegue che FireStats – il noto plugin per la gestione delle statistiche – va utilizzato in modalità standalone anziché come plugin di WordPress, pena il suo mancato funzionamento.

Come fare:

1. Disattivare FireStats nella lista dei plugin di WordPress.

2. Facoltativo: spostare a piacimento la cartella /firestats/ (esempio: vostrosito/firestats/).

3. Impostare i permessi di lettura/scrittura della cartella /firestats/php/ (CHMOD 777), perché FireStats possa crearvi il file fs-config.php.

4. Aprire via browser l’interfaccia di amministrazione di FireStats (si veda il punto 2), impostarvi i dati per la connessione al database e scegliere di accodare il tutto all’installazione preesistente, in modo da non perdere nemmeno un hit.

5. Impostare i dati d’accesso per l’amministratore di FireStats, seguendo la procedura guidata.

6. Cliccare “Amministrazione siti”, selezionare quello che volete riprendere a monitorare, ed alla voce “Tipo” “Sito PHP generico”. Salvare e copiare il codice PHP che a questo punto FireStats vi mostrerà.

7. Reimpostare i permessi di lettura/scrittura della cartella /firestats/php/ a 755, 644 o al valore che più ritenete opportuno.

8. Modificare il file index.php di WordPress

   Che fare del codice appena copiato? Deve essere eseguito prima di quello di 1 Blog Cacher, che viene a sua volta eseguito con precedenza assoluta. Tagliamo la testa al toro ed incolliamolo al sicuro da ogni possibile conflitto: nel file index.php di WordPress.

   <?php
   /* Short and sweet */ 
   define('WP_USE_THEMES', true); 
   require('./wp-blog-header.php'); 
   ?>
   

   Le righe 3 e 4 della versione modificata sottostante includono la versione standalone di FireStats prima dell’esecuzione di 1 Blog Cacher, permettendo di continuare ad utilizzare l’utilissimo sistema di gestione delle statistiche.

   <?php
   /* Standalone FireStats hack */ 
   include('/full-path-to-FireStats/php/db-hit.php'); 
   fs_add_site_hit(1); # 1 è l’ID FireStats del vostro sito 
   /* Short and sweet */ 
   define('WP_USE_THEMES', true); 
   require('./wp-blog-header.php'); 
   ?>
   

9. Facoltativo: avete spostato FireStats al di fuori di /wp-content/plugins/ e non volete che anche le pagine delle vostre statistiche vengano salvate nella cache?
   È necessaria una piccola modifica a /wp-content/advanced-cache.php, che aggiunga la stringa firestats all’array OBC_REJECTED_STRINGS (riga 26):

   define("OBC_REJECTED_STRINGS","wp-, firestats");
   

Testato, funzionante. Va da sé che non mi assumo alcuna responsabilità, doveste perdere dei dati: un bel backup prima di procedere è – come sempre – caldamente raccomandato.

il Gambero Rotto