Paramétrer WordPress via wp-config.php

Le fichier de configuration de WordPress, nommé wp-config.php, vous permet de définir la configuration de base de votre site. C’est ici que sont établis les contrôles, les permissions, les fonctionnalités importantes de gestion de votre WordPress, comme par exemple la connexion à la base de données.
Lors de l’installation “en 5 minutes chrono” de WordPress, la seule chose qu’il vous a justement été demandé de configurer dans ce wp-config.php sont vos coordonnées de base de données… et c’est tout !
En effet, la configuration par défaut permet parfaitement à WordPress de fonctionner, mais quelques petites astuces vous permettront d’améliorer les performances, de renforcer la sécurité, et de personnaliser certaines fonctionnalités.

A l’origine…

… malheur, il n’y a aucun fichier “wp-config.php” dans mon installation WordPress !!!
En effet, le fichier inclus situé à la racine du répertoire d’installation est un certain “wp-config-sample.php” que l’on vous demande de renommer en “wp-config.php”.

Protection

La toute première chose à faire est de protéger votre fichier “wp-config.php”.
Un moyen très simple pour cela est de définir les permissions dans le fichier .htaccess devant se trouver dans le même répertoire que votre fichier “wp-config.php”.
Ajouter le code suivant dans votre .htaccess :

<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>

Une fois ceci réalisé, assurez-vous que les permissions d’accès à tous les fichiers sont en 640 (droit en lecture/écriture au propriétaire et lecture au groupe). Ce paramétrage retournera une erreur “403 Forbidden” à toutes les requêtes extérieures.

Configuration principale

Identifiants de base de données

L’unique modification requise lors de l’installation est de saisir vos identifiants de base de données : le nom de la bdd, votre identifiant de connexion, votre mot de passe.

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database_name_here’); << nom de la bdd/** MySQL database username */
define(‘DB_USER’, ‘username_here’);<< identifiant de connexion/** MySQL database password */
define(‘DB_PASSWORD’, ‘password_here’); << mot de passe

/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’); << adresse de serveur

/** Database Charset to use in creating database tables. */
define(‘DB_CHARSET’, ‘utf8’); << jeu de caractères de la bdd

/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’,  »); << type de collation

La plupart des serveurs ne nécessite pas de modifier le hostname mais il est possible que votre hébergeur vous précise par quoi remplacer “localhost”.

Nota Bene  c;Les deux derniers items ne devront être modifiés qu’en cas de besoin et si vous savez ce que vous faîtes.
(collation = l’ordre de tri du jeu de caractères).

Clefs uniques d’authentification et salage

Votre fichier comporte 8 lignes déterminant ces clefs qui n’ont d’intérêt que si elles sont uniques. Vous pouvez les changer régulièrement et utiliser pour cela le service officiel de WordPress.org en vous connectant à https://api.wordpress.org/secret-key/1.1/salt/ qui vous permet de générer des phrases aléatoires.

**#@+
* Clefs uniques d’authentification et salage.
*
* Remplacez les valeurs par défaut par des phrases uniques !
* Vous pouvez générer des phrases aléatoires en utilisant
* https://api.wordpress.org/secret-key/1.1/salt/ le service de clefs secrètes de WordPress.org.
* Vous pouvez modifier ces phrases à n’importe quel moment, afin d’invalider tous les cookies existants.
* Cela forcera également tous les utilisateurs à se reconnecter.
*
* @since 2.6.0
*/
define(‘AUTH_KEY’, ‘e%>Na&U8jKPGK9[O,_i7()Uw{1.[lP-|j|:v/{oxZ$*,1h8w*@Sz 7h_dxJ0`fTO’);
define(‘SECURE_AUTH_KEY’, ‘~EYI# >jnulOPoaD#>9tofi(7CNhTtAwHe!@XI)Yk78I5+KS8dE$2YIEbs|q#x4T’);
define(‘LOGGED_IN_KEY’, ‘ens%|Mdg3/vh&j_P[Z-l0BbAUx5&kJ7d_1A^U6tMj[dcsodc5a~`CZI+cm;H13A0’);
define(‘NONCE_KEY’, ‘tfcV ~q8xI2Q,;5GL|Cf^5>EbQ~c>|)Wm-R_6&u!;K/`_y.kZcsWz@dStH&(#$h/’);
define(‘AUTH_SALT’, ‘n<l3Agl|ithGvksi/8P-Jm6G,_[?=k!eX7mO T;S-n73h@`L+qbnQW( T8s#3ca1’); define(‘SECURE_AUTH_SALT’, ‘/TLuD^DP2U6+2ZD)+gB(xBl[-(p,REkc=HjL.>.9-7XM}yQ3_cd4l6]&qMcF-B+V’);
define(‘LOGGED_IN_SALT’, ‘]%}R*(V+*XOzScy!l)7`XvP+%?y4$$1jb]oa|+!f|a+w WF)zv:8M)YU{uzc@J V’);
define(‘NONCE_SALT’, ‘>#4;XuCKDYuuU`mnjAmU k%}(Nv{60mMp#4PD_|_Zs@pB;G[6$Wkk4[T@Zc3a>tn’);
/**#@-*/

Le seul petit inconvénient de modifier ces clefs est que les utilisateurs connectés à ce moment là devront se reconnecter.

Préfixe des tables

WordPress est une cible privilégiée pour tout ce qui est hacks, spams ou autres scripts malicieux.
Un des moyens les plus simples pour sécuriser votre base de données est tout bonnement de modifier le préfixe imposé par défaut à chaque nom de table : “wp_”:

/**
* Préfixe de base de données pour les tables de WordPress.
*
* Vous pouvez installer plusieurs WordPress sur une seule base de données
* si vous leur donnez chacune un préfixe unique.
* N’utilisez que des chiffres, des lettres non-accentuées, et des caractères soulignés!
*/
$table_prefix = ‘wp_’;

Cette valeur par défaut étant forcément commune à chaque installation de WordPress, elle est une cible facile pour les robots de piratage et les scripts malicieux, qui comptent sur le fait qu’un certains nombre d’utilisateurs n’iront pas modifier cette valeur.
Le faire revient donc à éviter toute attaque dirigée contre toute donnée préfixée en wp_. Evidemment, plus votre préfixe sera unique et bizarroïde, mieux cela sera, dans le même esprit que pour un mot de passe. Laissez courir votre imagination car un étrange “Bzh1Ik9KM%” sera moins courant qu’un “wp1_”, non?

Nota BeneRemplacer l’underscore (‘_’) par un autre signe facilement identifiable par vous est possible et vous permettra de garder une bonne lisibilité du nom de vos tables.

Trucs et astuces

Voici quelques trucs et astuces pour vous rendre la vie plus agréable.

Configuration du système de révision

Les dernières versions de WordPress fournissent un système de révisions d’articles autorisant l’utilisateur à sauvegarder plusieurs versions d’un même article et à republier une version antérieure en cas de besoin. Par défaut, le nombre de sauvegardes est plutôt important (20) ce qui n’est pas forcément utile.

define(‘WP_POST_REVISIONS’, 3); // Limiter le nombre de sauvegarde par article
define(‘WP_POST_REVISIONS’, false); // Désactivation de ce système

Intervalle de sauvegarde automatique

Dans le même esprit de sauvegarde du travail utilisateur que le système précédent, WordPress effectue une sauvegarde automatique toutes les 60 secondes. Vous pouvez à l’envie modifier cette valeur (mais ne vous tirez pas une balle dans le pied!), si votre serveur a un peu de mal à suivre.

define(‘AUTOSAVE_INTERVAL’, 160);

Corbeille automatique

Depuis la version WordPress 2.9, nous disposons de la fonctionnalité “Corbeille” pour prévenir toute mésaventure de perte malencontreuse d’articles ou de pages. Plutôt que de détruire directement un travail, il est placé dans cette corbeille, où il reste récupérable en cas de besoin, dans une limite de 30 jours.
Cette valeur par défaut, au delà de laquelle WordPress supprime définitivement le contenu de la corbeille, est paramétrable par ajout d’une petite ligne de code dans le fichier wp-config.php:

define(‘EMPTY_TRASH_DAYS’, 14); // toutes les 2 semaines

Pour les grands joueurs et les gros prétentieux*:

define(‘EMPTY_TRASH_DAYS’, 0); // désactivation

Evidemment, désactiver cette sécurité, c’est revenir des années en arrière dans le confort d’utilisation de WordPress!
Signalons que WordPress ne demande pas de confirmation à l’utilisateur s’il effectue une “suppression définitive”.
* it is a joke

Blocage de requêtes extérieures

Par défaut, votre WordPress est autorisé à communiquer avec l’extérieur: interrogation de flux rss, avertissement des outils de création/mise à jour d’un article sur votre site, etc…
Il est possible de réduire cette porte vers l’extérieur en définissant la liste des adresses ayant une autorisation.
Tout d’abord, il faut fermer la porte pour tout le monde :

define(‘WP_HTTP_BLOCK_EXTERNAL’, true);

Ensuite, vous devez créer la “liste blanche” des heureux élus :

define(‘WP_ACCESSIBLE_HOSTS’, ‘rpc.pingomatic.com’);
define(‘WP_ACCESSIBLE_HOSTS’, ‘api.wordpress.org’);

Adresses de WordPress et du site

Ces deux adresses sont paramétrables via l’interface d’administration, sous l’onglet Réglages / Général.
En les ajoutant dans le fichier wp-config.php, où elles ne sont pas présentes par défaut, les valeurs ainsi paramétrées viendront surchargées celles stockées en base.

define(‘WP_HOME’, ‘http://bourdrez.com/blog’);
define(‘WP_SITEURL’, ‘http://bourdrez.com/blog/version2’);

Une fois ajoutée dans le fichier wp-config.php, elles seront grisées dans le panneau d’administration.

Débogage

Par défaut, le rapport d’erreur est désactivé dans WordPress. Pour pouvoir effectuer un débogage, il faut l’activer via le paramétrage suivant:

define(‘WP_DEBUG’, true);

Ceci indique à WordPress d’afficher avertissements et messages d’erreurs de vos pages web.
Cette fonctionnalité s’adresse bien sûr aux développeurs WordPress.

Nota Bene La valeur ‘true’ correspond à l’activation et donc ‘false’ à la désactivation de la fonctionnalité.

Configuration du rapport d’erreur

WordPress permet très facilement de générer un rapport d’erreur automatiquement. Ceci est très utile pour vérifier régulièrement si tout se passe correctement sur votre site.
Ceci se fait en 3 étapes :
– créer un fichier où viendront s’écrire les traces des erreurs (par exemple : php_error.log,) et le placer à votre convenance dans votre arborescence,
– autoriser l’écriture dans ce fichier,
– paramétrer le fichier de configuration en spécifiant le chemin vers votre fichier d’erreur.

@ini_set(‘log_errors’,’On’);
@ini_set(‘display_errors’,’Off’);
@ini_set(‘error_log’,’/home/le_chemin_vers_mon _fichier/php_error.log’);

Le premier paramètre active (‘On’) ou désactive (‘Off’) le journal d’erreurs.
Le second paramètre active (‘On’) ou désactive (‘Off’) l’affichage public des erreurs.
Le troisième paramètre spécifie le chemin vers le journal d’erreurs.

Ce journal d’erreur vous permettra de réagir rapidement à un éventuel problème.
Le site DigIntoWorPress vous en dira plus dans cet article.

Augmentation de la mémoire PHP

Si jamais vous recevez des messages d’erreurs vous prévenant que la place allouée à la mémoire est atteinte (“Allowed memory size of xxx bytes exhausted”), vous avez la possibilité d’augmenter la taille demandée par WordPress à votre serveur, qui est de 32MB par défaut .

define(‘WP_MEMORY_LIMIT’, ’64M’);
define(‘WP_MEMORY_LIMIT’, ’96M’);
define(‘WP_MEMORY_LIMIT’, ‘128M’);

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *