Le thème du plugin en question n’a rien d’innovant, le cache, et les concurrents sont multiples dont :

• WP Super Cache : cache HTML en fichiers
• BatCache : cache HTML via Memcached
• HyperCache : cache HTML en fichiers

Sans oublier le mécanisme de cache objet interne à WordPress qui peut se coupler aux différents optimiseurs PHP et logiciels de cache du marché… ( Xcache, APC, Memcached, eAccelerator )

W3 Total Cache se veut résolument comme une solution transversale, il travaille sur les aspects suivants :

• Le cache HTML
• Le cache DB, donc orienté objet
• La compression des fichiers CSS et JS via la compression : Minify.
• L’utilisation de serveurs CDN (via FTP)

Pour le moment, le plugin est compatible avec les logiciels Memcached et APC, mais d’autres interfaces devraient voir le jour (on parle de Xcache assez rapidement).

Autrement dit, tout cela est très prometteur… Malheureusement, ce plugin n’est pas destiné au commun des mortels… En effet, avec des prérequis comme APC ou Xcache, très peu d’hébergeurs mutualisés sont compatibles… ( par exemple OVH et 1and1 ne le sont pas )

Ce plugin est donc destiné aux personnes ayant un serveur dédié ou virtualisé…

Autre inconvénient, et de taille, malgré que le plugin se dise compatible WordPress Mu, il ne l’est pas pour le moment. Mais cela devrait vite être résolu !

Bon caching !

Pour cela, il suffit juste de changer 4 paramètres de PHP et pour y parvenir nous allons créé/édité le fichier .htaccess à la racine de votre FTP. (dans le dossier WWW)

Et on va y insérer les lignes:

SetEnv REGISTER_GLOBALS 0
SetEnv ZEND_OPTIMIZER 1
SetEnv MAGIC_QUOTES 0
SetEnv PHP_VER 5

Autrement dit, on désactive les directives PHP magic quotes, register globals qui n’apportent rien à WordPress.
On passe à PHP5 (qui offre une meilleure comptabilité avec les extensions) et on active le module PHP Zend Optimiser, ainsi le code PHP sera optimisé et les traitements récurrents seront mis en cache.

Tout cela de façon transparente pour WordPress, mais avec une meilleure réactivité à la clef pour l’utilisateur.

Pour plus d’infos sur PHP chez OVH, 2 petits guides à lire:

• http://guide.ovh.com/PhpChezOvh
• http://guide.ovh.com/ConfigPhp

Pour y remédier, une solution simple et peu couteuse à mettre en place consiste à installer le plugin WP Super Cache, de mon ami Donncha. (mainteneur de WPmu au passage)

Malheureusement, il se trouve que le plugin bien que très efficace provoque un bug assez aléatoire.

Pour comprendre la source du bug, petit rappel technique sur le fonctionnement de WP Super Cache.

1. Un visiteur consulte une page X
2. Si la page n’est pas en cache, WP Super Cache créé 2 copies :
   • 1 exemplaire HTML
   • 1 exemplaire compressé Gz
3. Le visiteur suivant, qui consulte la même page X, va vérifier la présence d’une copie.
   • Dans un premier temps, la copie compressée Gz
   • Dans un second temps, la copie HTML
   • Sinon, il charge WordPress pour créer la copie (on revient au point 2)
4. Et ainsi de suite.

Petite précision, mais pas importante ici, les copies HTML et Gz ont une durée de vie. Cette dernière est spécifiée dans les options du plugin. Une fois la durée dépassée, les 2 copies sont supprimées pour obliger une nouvelle création.

Revenons au bug, il est assez simple. Lors de la première consultation, WP Super Cache va créer une copie compressée avec Gzip, malheureusement avec la version actuelle (0.7.0.1), il ne vérifie pas l’intégrité de l’archive.

De ce fait, il lui arrive de créer aléatoirement des archives corrompues. On tombe alors sur des pages comme:

L'art moderne selon WordPress

Pour éviter ce bug, tout en profitant du cache HTML classique de WP Super Cache, rien de plus simple… Il suffit de désactiver la compression GZ dans les options du plugin.

Cependant pour des raisons assez mystérieuses, le bug se reproduit par moment. Pour être sur que le bug ne se reproduit, je vous conseille de désactiver la redirection du fichier .htaccess concernant la compression Gz.

C’est-à-dire les lignes suivantes:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*p=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

En supprimant cette partie, vous pouvez être sûr que les pages avec hiéroglyphes, c’est terminé !

• Page blanche sur le tableau de bord et la page apparence
• Page blanche lors de la publication d'un article et/ou d'un commentaire

Le problème intervient sur les installations WordPress Mu à haute fréquentation uniquement.

Cause possible ?

Créer un fichier info.php à la racine de votre blog, placez-y :

<?php phpinfo(); ?>

Enregistrez le fichier, consultez la page générée et partez à la recherche de l'extension eAccelerator pour PHP.

Si le module est présent; vous êtes simplement victime d'un bug avec les caches OPcode PHP et les fonctions de filtrage HTML Kses de WordPress. Cela provoque une erreur de segmentation PHP, et hop page blanche.

La solution ?

Désinstallez eAccelerator de votre serveur dédié. Installez à la place l'extension pour PHP, j'ai nommé Alternative PHP Cache (APC).

Et n'oubliez pas de filtrer le fichier kses.php de l'optimisation. Pour cela, ajoutez dans votre fichier de configuration de PHP la ligne suivante:

apc.filters = "(kses.php)"

Redémarrez votre serveur Web et hop problème résolu !