Les secrets du fichier wp-config.php

Avec la version 3.0 de WordPress (téléchargeable ici en français) arrive le multiblog, qui doit impérativement être activé via le fichier wp-config.php, et non par une option du tableau de bord.

Pour les impatients, la ligne à ajouter pour activer le multi-site est :

define('WP_ALLOW_MULTISITE', true);

C’est l’occasion de faire un tour d’horizon des constantes qui peuvent être paramétrées dans le fichier wp-config.php, dont certaines sont moins connues que d’autres.

Les paramétrages indispensables du fichier wp-config.php

Ce sont les paramètres présents par défaut. Ils concernent :

la liaison avec la base de données

avec les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST, qui parlent d’elle mêmes, et donc les valeurs sont fournies par votre hébergeur. (Si c’est déjà du chinois, allez lire la série “WordPress pour les nuls”, et laissez tomber la suite de cet article).
Plus bas se trouve la variable $table_prefix qui va permettre d’avoir plusieurs blogs stockés sur la même base de données. Personnellement, je gère 6 blogs sur la même base sans problème.

le renforcement de la sécurité

avec les quatres clés de sécurités, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et NONCE_KEY qui doivent, dans l’idéal, être des chaines de caractères longues et complexes. Le plus simple est d’utiliser le site indiqué dans le fichier wp-config.php pour générer automatiquement ces clés. Elles peuvent être modifiées sans gêner en quoi que ce soit l’accès au site.

les options de langues du blog

WPLANG permet de définir la langue du blog. La valeur de la constante doit être sous la forme en_UK ou fr_FR.

Il est possible de définir le répertoire où seront stockés les fichiers de langues avec LANGDIR :
define('LANGDIR', 'mylanguagedirectory');, si cette constante n’est pas définie, WordPress recherchera les fichier .mo d’abord dans wp-content/languages puis dans wp-includes/languages.

L’ordre de tri de la base de données est par défaut celui correspondant à la définition du charset de la base de données :
define('DB_COLLATE', );
Si on veut une valeur différente (par exemple avec des blogs dans plusieurs langues sur la même table, il faut renseigner le paramètre, avec le nom utilisé dans mysql, par exemple :
define('DB_COLLATE', 'utf8_general_ci');

L’url du site et les répertoires par défaut

Adresse du site et adresse du blog WordPress

L’url du blog WordPress et l’url du répertoire WordPress, si elle est différente, est normalement modifiée via le dashboard, dans les options générales. Elle est stockées dans la table wp_options.

Le grand classique, c’est le site qu’on déménage, on n’a pas modifié l’adresse du site, et on se retrouve incapable d’accéder à l’admin.

Pour ceux qui ne souhaitent pas faire la modif via phpmyadmin (ou qui n’y ont pas pas accès dans le cas d’installation automatisée sur une base virtuelle, chez OVH ou 1&1 par exemple), il est possible de fixer cette valeur dans le fichier wp-config avec les constantes
WP_SITEURL et WP_HOME (qui ne modifieront pas les valeurs dans la base de données).

Pour ceux qui ont un serveur local qui est la copie de leur serveur de production, il est aussi possible de définir l’adresse à partir de la racine du serveur, avec $_SERVER[‘HTTP_HOST’] ou $_SERVER[‘SERVER_NAME’] define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpressp'); qui permet de ne pas se poser de questions quand on passe le site de local à public.

wp-content et wp-content /plugins

Il est possible de stocker les dossiers de contenu en dehors de l’architecture WordPress classique.
Il suffit de définir leur chemin d’accès, soit par rapport au serveur (wp_content_dir et wp_plugin_dir), soit avec leur adresse complète (wp_content_url, etc…)

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );

ou

define( ‘WP_CONTENT_URL’, ‘http://example/blog/wp-content’);

Il n’y a pas de constante spécifique pour les thèmes. Donc on peut fixer au choix :

• un répertoire pour tout le contenu de wp-content
• un répertoire pour wp-content et un autre répertoire pour wp-plugin -> cela affecte les thèmes (on peut aussi déplacer le dossier de langues, on l’a vu plus haut, et le dossier d’upload se détermine dans les options de l’admin)

Enfin, pour ceux qui intègrent WordPress avec un autre CMS ou avec un site fait maison, il est possible de stocker les templates et/ou les feuilles de styles dans un répertoire différent avec TEMPLATEPATH et STYLESHEETPATH.

Sauvegardes automatiques, versions des posts et corbeille.

Ce sont deux fonctionnalités différentes qui ont pour objectif de nous éviter de perdre nos textes.

La sauvegarde automatique des posts

Comme son nom l’indique, elle enregistre automatiquement à intervalle régulier l’article ou la page que vous êtes en train de rédiger. En bas de l’espace de rédaction, apparaît “Brouillon enregistré à xx ” avec l’heure de la dernière sauvegarde.
C’est un très bon garde fou, notamment contre les plantages d’un navigateur qui feraient disparaître un article presque fini de rédiger, comme par exemple celui-ci.
Il est possible de changer de rythme de sauvegarde (par défaut 60 secondes) avec
define('AUTOSAVE_INTERVAL', 160 );
où 160 représente un nombre de secondes.

La gestion des révisions

La gestion des révisions, c’est WordPress qui stocke chaque état du post, à chaque fois que l’on clique sur sauvegarder. Pour un peu que l’on mette un peu de temps à rédiger un article, ou qu’on le modifie après l’avoir publié, suite à des commentaires, cela peut rapidement faire gonfler le nombre de posts.
Personnellement, je ne pense pas que cette fonctionnalité soit utile si on a un seul rédacteur sur un blog.
On peut donc la désactiver avec
define('WP_POST_REVISIONS', false );
ou au moins limiter le nombre de versions qui seront stockées avec
define('WP_POST_REVISIONS', 3);
(ou 2 ou 5 ou ce que vous voulez).

La corbeille

Depuis la 2.9, les articles ne sont plus supprimés directement, mais mis en stockage intermédiaire dans la corbeille (statut dans wp_posts : trash). Par défaut, WordPress conserve les articles pendant 30 jours avant de les supprimer définitivement.
On peut diminuer ce laps de temps avec
define('EMPTY_TRASH_DAYS', 30 );
où 30 est le nombre de jours.
En mettant 0 on désactive complétement la corbeille. Mais attention, il n’y a plus d’avertissement avant la suppression du post, c’est donc un réglage dangereux.

La performance du blog

Taille mémoire pour php

Un problème récurrent est la taille de la mémoire allouée à php.
Selon les hébergeurs, il est possible de modifier cette valeur via le php.ini (par exemple, chez 1&1, il est possible de créer un fichier php.ini à la racine du site), mais si on n’a pas cette possibilité, le wp-config permet de modifier l’allocation mémoire uniquement pour WordPress avec
define('WP_MEMORY_LIMIT', '96M');

Activer le cache

WordPress dispose d’un script de cache, qui permet d’améliorer la performance en cas de nombre de visites important. On l’active avec la ligne
define('WP_CACHE', true);

Enfin WordPress permet un certain nombre de réglages pour les développeurs, avec le débugage, la concaténation ou pas des javas, etc. Le détail se trouve dans l’article du codex sur le fichier wp-config.