WordPress permet, par défaut, d’installer ou de supprimer des extensions ou des thèmes, et de mettre à jour le cœur ou les plugins de WordPress directement depuis l’administration. Ces actions sont possibles pour les utilisateurs avec le rôle administrateur ou avec des droits comparables (ce sont les capabilities) et potentiellement depuis le serveur de production ou pré-production/recette.
C’est bien entendu très pratique pour une très large typologie d’utilisation, mais ça peut-être problématique dans certains cas. Imaginons que vous ayez en charge – en tant que prestataire – la maintenance d’un site et que vous garantissiez son bon état de fonctionnement. Si un utilisateur de votre équipe ou le client final décide de mettre à jour quelque chose ou d’ajouter, voire de supprimer un plugin directement sur la prod (instance du site accessible au public), vous prenez le risque que ce dernier plante à cause d’une erreur quelconque. Résultat, vous n’avez pas honoré votre contrat de maintenance. Dans d’autres cas, hors contrat, c’est tout simplement préjudiciable d’avoir un site hors service en production, et je ne parle pas du repository GIT pas à jour, etc.
Bref, vous l’avez compris, il est important de prévenir certaines actions en production pour éviter les régressions ou les plantages. Et c’est d’autant plus important si vous êtes prestataires et que votre client compte sur vous pour gérer son site et donc son image.
Wp-config.php
WordPress y a bien entendu pensé et vous permet de désactiver purement et simplement ces fonctionnalités d’ajout/suppression de thèmes et plugins et toutes les mises à jour depuis le back-office. Pour ce faire, il suffit de déclarer la constante suivante dans votre fichier wp-config.php
define( 'DISALLOW_FILE_MODS', true );
Vous pourrez donc facilement ajouter cette ligne au fichier wp-config.php sur votre serveur de production, continuer a faire vos mises à jour en local, tester, versionner puis déployer.
Constante conditionnelle
Pour aller plus loin, il peut-être pratique de créer un plugin drop-in (ou mu-plugin) qui va définir « automatiquement » cette constante uniquement sur l’instance de production et donc de ne PAS la définir sur les instances de développement ou de préproduction.
Dans l’exemple ci-dessous – qu’il faudra sans doute adapter à votre manière de travailler et à vos besoins – j’exclus les sites avec un domaine en .local (ma dev) et ceux avec un sous-domaine en .preprod, sur les autres (donc en fait uniquement la production) je déclare bien ma constante.
function bweb_disallow_file_modifications(){
$currentSite = get_site_url();
if( ( strpos( $currentSite, '.local' ) !== false )
&& ( strpos( $currentSite, 'preprod.' ) !== false )
&& !defined( 'DISALLOW_FILE_MODS' ) ){
define( 'DISALLOW_FILE_MODS', true );
}
}
add_filter( 'init', 'bweb_disallow_file_modifications' );
Le gros avantage de cette méthode pour moi, c’est qu’en procédant de la sorte, mon code est versionné (ce qui n’est pas le cas pour mon wp-config.php), je ne m’en occupe plus et je ne prends pas le risque d’avoir un wp-config non conforme à mes attentes.
