Configuration avançée de WordPress

Installer un WordPress ce n’est pas très compliqué. C’est d’ailleurs l’une des raisons du succès de ce CMS. Tout ou presque se passe dans le fichier wp-config.php. Une fois l’ensemble des fichiers de WordPress envoyés sur le serveur, c’est dans ce fichier (à la racine de votre serveur) que vous renseignez le serveur de base de données, le nom de la base de données, l’utilisateur et le mot de passe pour accéder à la base de données. Une fois ceci fait, votre WordPress est prêt à tourner. Pourtant, le fichier wp-config.php peut faire beaucoup plus que ça.

Définition de la langue

Vous pouvez spécifier la langue utilisée par défaut par WordPress ce qui vous permettra d’avoir l’interface de WordPress dans la langue de votre choix. Cela facilite également l’affichage des dates sur le site (juillet au lieu de july par exemple). Précision : en plus de cette ligne dans le fichier wp-config.php, il vous faut créer un répertoire languages dans ‘wp-content’ et y télécharger les fichiers de traduction fr_FR.mo par exemple.

define ('WPLANG', 'fr_FR');

Vous pouvez également changer l’emplacement du dossier contenant les fichiers de traduction :

define('WP_LANG_DIR', $_SERVER['DOCUMENT_ROOT'].'wordpress/languages');

Optimisation des performances

Par défaut, WordPress demande au serveur 32  MB de mémoire au serveur. Vous pouvez augmenter cette part de mémoire simplement :

// more memory
define('WP_MEMORY_LIMIT', '64M');
// even more memory
define('WP_MEMORY_LIMIT', '96M');
// a good deal more memory ;-)
define('WP_MEMORY_LIMIT', '128M');

Utile si vous voyez passer ce genre de message : Allowed memory size of xxx bytes exhausted.

Pour alléger les appels à votre base de données, vous pouvez mettre en constante l’adresse de votre site et l’adresse de WordPress, deux valeurs configurées habituellement via les settings dans la page « Général » mais que vous pouvez directement configurer dans wp-config.php :

// Override Database values - better performances
define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST'].'/nomdurepertoirewordpresssiceluicinestpasalaracine');

Mise à jour : d’après des tests effectués par Emmanuel, le gain en performance est semble quand même être minime.

Pratiques

Depuis la version 2.6, WordPress s’est vu doté d’une fonctionnalité intéressante mais un peu polluante : les posts revision. Lorsque vous écrivez un article, WordPress sauvegarde automatiquement x versions de votre article. Cela vous permet de revenir en arrière très facilement. Problème, le nombre de sauvegardes d’article doit être limité à plus d’une vingtaine par défaut. Moi, ça m’énerve. Si vous êtes dans le même cas que moi, voici comment diminuer le nombre de révisions par défaut :

define('WP_POST_REVISIONS', 3);

Autre fonctionnalité bien pratique : la poubelle. Lorsque vous supprimez un article, celui-ci ne disparaît pas. Il va dans une poubelle, exactement comme la poubelle de votre Windows 98 – pour ceux qui travaillent dans une banque – ou de votre Mac Book Air à 3000 € et que pour ce prix là t’as même pas de prise ethernet – pour ceux qui travaillent dans une agence de créa. Problème : par défaut, la poubelle ne se vide jamais. Pour la vider automatiquement tous les 7 jours, ajoutez ceci :

define('EMPTY_TRASH_DAYS', 7); // empty weekly

Debug et dev

Là, c’est la partie un peu plus velue, réservée plutôt aux créateurs de thèmes et de plugins (qui en même temps doivent certainement déjà connaître ces options mais comme je suis un professionnel je continue par souci d’exhaustivité et d’ailleurs je fais bien ce que je veux).

Pour passer WordPress en mode debug et lui permettre d’afficher tous les messages d’erreurs habituellement masqués :

define('WP_DEBUG', true); // debugging mode: 'true' = enable; 'false' = disable

Très utile pour la chasse au bug, notamment pour trouver l’origine des fameux headers already sent. Ca va sans dire, mais ça va mieux en le disant, n’utilisez pas cette option en production.

Autre debug mode très utile pour résoudre les problèmes de performances :

define('SAVEQUERIES', true);

Cette constante vous permet d’afficher toutes les requêtes avec leur temps d’exécution. Une fois cette ligne rajouté dans votre wp)-config.php, il faut afficher le résultat. Pour ce faire, ajoutez dans le footer :

if (current_user_can('administrator')){
global $wpdb;
echo "<pre>";
print_r($wpdb->queries);
echo "</pre>";
}

Beaucoup plus précis que que le classique :


echo get_num_queries();
echo "requêtes";
timer_stop(1);


que l’on trouve dans le footer.

Sécurité

Depuis sa version 2.6, WordPress utilise des clefs d’authentification. Ce sont des phrases uniques servant à générer des cookies uniques permettant d’identifier si un utilisateur est bien connecté et si celui-ci a bel et bien lancé telle ou telle action dans l’administration. Je ne m’étends pas plus mais si vous souhaitez en savoir un peu plus sachez que ces clefs sont utilisées dans le système de nonces de WordPress entre autres.

define('AUTH_KEY', 'ma chaîne unique de caractère');
define('SECURE_AUTH_KEY', 'ma chaîne unique de caractère');
define('LOGGED_IN_KEY', 'ma chaîne unique de caractère');
define('NONCE_KEY', 'ma chaîne unique de caractère');

Si vous êtes paranoïaques – ou si vous pensez que votre site sera la cible d’éventuelles attaques – sachez qu’il existe d’autres options de sécurisation que l’on peut mettre en œuvre via wp-config.php :

WordPress effectue des requêtes externes chaque fois que celui-ci va interroger des flux rss. Cela arrive au chargement du tableau de bord lorsque wordpress vous affiche les dernières news de différents blogs, cela arrive également lors de la publication de chaque billet lorsque WordPress ping les différents services de mise à jour, cela peut arriver sur les fichiers du thème si vous utiliser un plugin lecteur de flux, etc. Si vous souhaitez pour une raison ou une autre bloquer les requêtes externes, voici comment faire

define('WP_HTTP_BLOCK_EXTERNAL', true);

Vous pouvez une fois cette ligne insérée dans wp-config.php définir avec quels hôtes WordPress a le droit de communiquer :
define('WP_ACCESSIBLE_HOSTS', 'rpc.pingomatic.com');

Personnellement je ne vois pas trop d’utilité à cette option de configuration, mais on sait jamais, si vous travaillez dans une banque et que vous avez un DSI flippé au-dessus de vous, voire, juste derrière votre épaule, éventuellement, ça peut servir. En même temps, si vous travaillez dans une banque, je vous plains ; vous faites partie de la population la plus détestée de France.

Autre option de sécurisation pour nos amis paranoïaques, un peu plus utile celle-là : forcer l’authentification en mode SSL.

define('FORCE_SSL_ADMIN', true);

Une fois cette ligne ajoutée, l’interface d’administration de votre site sera accessible à l’adresse https://monsitewordpress/wp-admin. À utiliser sur un serveur qui vous permet d’obtenir votre propre certificat d’autentification, sinon vous aurez toujours un avertissement de sécurité lors de l’authentification. Pas grave mais gênant.

Pour aller plus loin

Toutes les options décrites ci-dessus sont celles que j’utilise sur la plupart des sites WordPress sur lesquels je travaille. Il existe de nombreuses autres options, un peu plus exotiques. Pour en avoir une liste exhaustive, je vous invite à consulter Pimp your wp-config.php et bien évidemment le codex WordPress.