Trucs et astuces pour wp-config.php

Voici quelques conseils pour optimiser votre fichier wp-config.php dans le cadre d’un environnement WordPress multisite.

La grande partie, tout le mode la connais et sait la remplir. Sinon, lisez la doc !
Pour le reste, voici quelques portions de code typique à utiliser selon vos besoins.

WordPress Multisites

Environnement multisite configuré en sous-domaines : (source : Codex)

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'site-principal.fr');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Si vous souhaitez éviter les erreurs de frappe ou ne pas rediriger vers la page de création d’un nouveau blog, vous pouvez désactiver les « sous-domaines qui n’existent pas » avec

define( 'NOBLOGREDIRECT', 'http://votre-site.fr' );

Depuis la version 3.7 de WordPress, il y a les mises à jours automatiques. C’est super, sauf quand on veut garder le contrôle de son code, ou que le code est versionné. Pour désactiver cela :

// Disabling Core auto-update (3.7)
define( 'WP_AUTO_UPDATE_CORE', true );

// Disable all automatic updates
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Hyper pertinent dans le cadre d’un cadre d’un réseau de sites WordPress infogéré ou versionné, bloquer toute possibilité d’installer sois-même des plugins et des thèmes :

define('DISALLOW_FILE_MODS',true);

Une fonctionnalité dont j’ai encore du mal à comprendre l’utilité : la possibilité d’éditer les fichier php depuis le back-office… En plus d’apporter des risques d’erreur, ce n’est pas top niveau sécurité ! Alors autant le désactiver partout où c’était possible d’y accéder :

define('DISALLOW_FILE_EDIT', true)

Vous utilisez Akismet pour lutter contre les commentaires indésirables mais ne voulez pas configurer l’extension pour chaque blog ? Alors configurez-là une fois pour l’ensemble du réseau :

define('WPCOM_API_KEY','123456789');

Débogage :

Pour déboguez votre site ou votre thème, voici les constantes à connaitre. A vous de jouer entre true et false sur l’une ou l’autre des constantes pour arriver au meilleurs compromis possible sur des sites de développement ou de pré-production.

1. Mes recommandations pour un site en pré-prod (ou si vous déboguez en prod…)
Cette configuration + l’extension Debug bar
Cela vous permet de masquer les erreurs, tout an ayant WP_DEBUG d’activé et donc de pouvoir quand même de les visualiser :

// Enable WP_DEBUG mode
define('WP_DEBUG', true);
// Disable display of errors and warnings
define('WP_DEBUG_DISPLAY', false);

2. Pour un site en prod, tout à off :

// Enable WP_DEBUG mode
 define('WP_DEBUG', false);

3. Pour du développement, vous pouvez tout activer :

// Enable WP_DEBUG mode
 define('WP_DEBUG', true);
 // Enable Debug logging to the /wp-content/debug.log file
 define('WP_DEBUG_LOG', true);
 // Disable display of errors and warnings
 define('WP_DEBUG_DISPLAY', true);
 // Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
 define('SCRIPT_DEBUG', true);

Supprimer ou limiter les révisions

Avec les révisions des articles vous pouvez revenir sur tout l’historique de votre contenu. C’est bien sauf que ça prend vite de la place.

Solution la plus radicale : désactiver complètement les révisions

define('WP_POST_REVISIONS', false);

Sinon, un bon compromis est de n’en conserver qu’un certain nombre :

define( 'WP_POST_REVISIONS', 5 );

Option possibles :

  • true (default), -1: enregitre toutes les révisions
  • false, 0: n’enregistre aucune révision (sauf une sauvegarde automatique)
  • (int) > 0: enregistre autant de révisions (plus une sauvegarde automatique). Les anciennes révisions sont automatiquement supprimée.