DISALLOW_FILE_MODS : rétablir les mises à jour WordPress selon la politique du site

Reconnaître une interdiction de modifier les fichiers

Le site fonctionne, mais les boutons pour installer ou mettre à jour une extension ont disparu, ou WordPress annonce que les modifications de fichiers ne sont pas autorisées. La constante DISALLOW_FILE_MODS peut expliquer cette situation. Une constante est une valeur de configuration chargée par PHP : elle ne se change pas depuis un bouton du tableau de bord.

L’objectif est de retrouver un circuit de maintenance opérationnel. Selon l’organisation du site, ce sera l’administration WordPress ou un déploiement préparé ailleurs. Faire réapparaître un bouton ne suffit pas si les fichiers sont ensuite remplacés par le système de déploiement, ou si personne ne prend en charge les mises à jour après la remise en état.

L’absence de nouvelles versions dans la liste ne prouve toutefois pas la présence de cette restriction. Commencez par noter ce qui manque exactement : le menu Ajouter, le lien de mise à jour, une notification ou seulement l’éditeur de fichiers. Un téléchargement qui échoue après avoir commencé correspond à un autre stade. Cette distinction évite de modifier une politique de sécurité pour résoudre une panne de connexion sans rapport.

Vérifier le site et le compte avant la configuration

Ce parcours concerne surtout WordPress auto-hébergé lorsque vous avez un accès autorisé à ses fichiers. Sur WordPress.com, les possibilités dépendent aussi de la configuration du service et du site sélectionné. Une limitation de l’offre ou du compte ne se répare pas en cherchant un fichier de configuration auquel vous n’avez pas accès.

Dans un réseau multisite, l’administration d’un sous-site et celle du réseau n’offrent pas les mêmes possibilités. Un administrateur local peut gérer son contenu sans pouvoir installer des extensions pour le réseau. Comparez donc les droits attendus avec ceux du compte réellement connecté avant de conclure à un verrouillage technique. Le fichier de configuration du réseau peut être commun à tous ses sites : une modification n’est pas limitée au sous-site dont l’onglet est ouvert. Faites intervenir l’administrateur du réseau avant d’éditer cette politique partagée.

1. Relevez l’adresse exacte de l’administration et le nom du site affiché dans la barre supérieure.
2. Vérifiez avec le propriétaire que le compte dispose des droits de maintenance attendus. Pour un réseau, demandez la vérification dans l’administration du réseau.
3. Ouvrez Extensions, Apparence puis Tableau de bord > Mises à jour et notez les commandes présentes ou absentes.
4. Conservez le message précis et sa date. Si un autre administrateur autorisé voit les commandes sur le même site, examinez d’abord les droits du compte concerné.

Préparer une modification récupérable

Un fichier wp-config.php contient habituellement des informations de connexion à la base et des secrets de sécurité. Sa sauvegarde doit rester dans un emplacement privé, hors du répertoire servi aux visiteurs. Ne créez pas une copie nommée wp-config.php.bak à côté du fichier public : une mauvaise configuration du serveur pourrait permettre de la télécharger.

Gardez une session d’accès aux fichiers ouverte pendant l’intervention. Si une erreur de syntaxe empêche WordPress de démarrer, cet accès permet de restaurer le fichier sans dépendre du tableau de bord. Préparez également une sauvegarde cohérente des fichiers et de la base avant d’installer ensuite une véritable mise à jour ; sauvegarder seulement la ligne modifiée ne permet pas d’annuler les effets d’une extension mise à niveau.

Sur une copie de travail, neutralisez les courriels, paiements et intégrations susceptibles de produire des effets réels. La vérification de la restriction ne demande ni commande commerciale ni envoi de formulaire. Choisissez un créneau où personne d’autre ne remplace la configuration et consignez la valeur initiale ainsi que la personne responsable de la maintenance.

Trouver la définition réellement utilisée

Ouvrez les fichiers depuis l’accès SFTP ou le gestionnaire de fichiers fourni pour le bon domaine. Le fichier wp-config.php se trouve généralement à la racine des fichiers WordPress ; certaines architectures le placent ailleurs ou lui font charger une configuration supplémentaire. Le dossier contenant les médias ne suffit donc pas à identifier la configuration active.

Recherchez le texte exact DISALLOW_FILE_MODS dans le fichier et dans les fichiers de configuration qu’il inclut explicitement. Relevez aussi les commentaires voisins : ils peuvent signaler une valeur générée par l’hébergement ou un processus de déploiement. Une ligne présente uniquement dans une documentation, un commentaire ou une ancienne sauvegarde ne définit rien pour le site courant.

1. Confirmez le chemin du domaine dans le panneau d’hébergement, puis ouvrez sa configuration en lecture.
2. Cherchez le nom exact de la constante, sans copier le reste du fichier dans un message public.
3. Notez si la valeur est le booléen true, le booléen false ou une expression provenant d’un environnement.
4. Identifiez le responsable du fichier. S’il est généré, trouvez le réglage ou le fichier source qui le produit avant toute modification.

Corriger une constante ajoutée dans votre propre fichier

Cette approche convient si vous êtes responsable de la configuration, si le site doit être maintenu depuis WordPress et si vous avez identifié une définition locale ajoutée volontairement ou par erreur. Elle ne convient pas à un hébergement imposant un circuit de déploiement distinct. Confirmez ce point avant de modifier la valeur.

Dans le wp-config.php actif, remplacez uniquement la définition existante par l’exemple ci-dessous. Il s’agit d’une ligne à corriger, pas d’un fichier complet à coller. Utilisez les booléens PHP sans guillemets. N’ajoutez pas une deuxième définition plus bas : une constante déjà définie ne devient pas modifiable parce qu’une autre ligne répète son nom.

Avant de lever la restriction, vérifiez deux effets plus larges. Elle bloque aussi les éditeurs de fichiers de thèmes et d’extensions : si ces éditeurs doivent rester interdits, conservez ou faites définir séparément DISALLOW_FILE_EDIT à true dans la source autorisée, sans doublon. Vérifiez également la politique des mises à jour automatiques avant le changement, car leur mécanisme peut devenir de nouveau admissible.

Le mot false entre guillemets n’est pas le booléen attendu : PHP traite cette chaîne non vide comme vraie. Si la valeur vient d’une variable d’environnement ou d’une expression, faites corriger sa conversion dans la source gérée. Ne remplacez pas toute cette logique par une valeur fixe sans connaître les autres environnements qu’elle configure.

1. Téléchargez la version courante vers l’emplacement privé préparé et conservez ses permissions.
2. Remplacez true par false dans l’unique définition concernée, avant le chargement de wp-settings.php.
3. Enregistrez le fichier comme texte PHP, avec son nom et son encodage conservés, puis transférez-le si nécessaire.
4. Rechargez une page publique et l’administration. Si une erreur PHP apparaît, restaurez immédiatement la copie initiale par le même accès aux fichiers.

define( 'DISALLOW_FILE_MODS', false );

Vérifier ce que le changement a réellement permis

Le premier résultat attendu est le retour des commandes autorisées pour le compte utilisé. Leur présence indique que cette restriction ne les masque plus ; elle ne garantit ni la compatibilité de la prochaine version ni l’écriture effective sur le disque. Ne lancez pas la mise à jour de toutes les extensions pour mesurer ce résultat.

Ce réglage s’applique à l’installation, pas seulement à l’onglet ouvert ou à votre session. Après modification, confirmez que les mises à jour automatiques et les éditeurs de fichiers restent conformes à la politique définie auparavant. Le retour des commandes manuelles ne doit pas être le seul contrôle.

1. Rouvrez Extensions et Tableau de bord > Mises à jour avec le compte de maintenance identifié.
2. Comparez les commandes avec votre relevé initial et consignez la différence.
3. Examinez les choix de mises à jour automatiques des composants concernés et la restriction des éditeurs de fichiers, sans ouvrir ces derniers pour modifier du code.
4. Préparez séparément une mise à jour compatible sur une copie, avec sauvegarde et retour arrière.
5. Si rien ne change, ne multipliez pas les définitions : vérifiez le fichier actif et poursuivez vers la politique gérée ou le filtre.

Conserver la restriction lorsqu’un déploiement gère le site

Sur un site géré par une agence, un hébergeur ou un dépôt de code, l’absence de commandes peut être intentionnelle. Les fichiers livrés en production doivent alors rester identiques à une version préparée et validée. Modifier une extension directement dans WordPress créerait une différence qui pourrait disparaître au prochain déploiement.

La solution consiste à utiliser le parcours de maintenance prévu. Ce n’est pas renoncer à la mise à jour : celle-ci est effectuée au bon endroit, puis livrée au site. Il n’existe pas de menu universel pour ce processus ; utilisez le projet et le panneau effectivement associés à votre installation. Une commande trouvée pour une autre plateforme ne constitue pas une procédure valable pour la vôtre.

1. Relevez la version installée et la version visée du composant, ainsi que le motif de mise à jour.
2. Ouvrez le projet de maintenance identifié dans votre contrat ou votre procédure interne et créez une demande pour ce composant précis.
3. Faites préparer la nouvelle version sur l’environnement de validation prévu, avec les données sensibles et les effets externes maîtrisés.
4. Contrôlez les fonctions concernées puis utilisez le déploiement documenté pour la production.
5. Vérifiez la version livrée dans WordPress. Conservez la restriction si elle fait partie de cette organisation et documentez le moyen de revenir à la livraison précédente.

Lire une seule valeur avec WP-CLI quand le contexte est maîtrisé

Si vous disposez déjà d’un accès au terminal de l’hébergement et de WP-CLI, une lecture ciblée peut compléter l’examen du fichier. Cette voie reste facultative : il n’est pas nécessaire d’installer un nouvel outil sur le serveur pour corriger une ligne identifiée. Utilisez le compte technique et le chemin de l’installation validés par le responsable.

La commande ci-dessous demande seulement la valeur de cette constante. Elle s’exécute avant le chargement normal de WordPress, mais évalue le PHP de la configuration : ce n’est pas une simple recherche de texte. Réservez-la à une configuration connue et de confiance. Si son contenu est suspect ou son chargement personnalisé inconnu, préférez l’examen privé du fichier avec le mainteneur.

Remplacez le chemin entre guillemets par celui des fichiers WordPress ; les guillemets conservent un éventuel espace dans le chemin. Le format JSON distingue le booléen false du texte "false". Le premier ne bloque pas les modifications par cette constante ; le second est une chaîne interprétée comme vraie. Une réponse true confirme une valeur vraie dans ce contexte terminal, pas encore la cause unique de tous les menus absents.

Le terminal peut recevoir des variables d’environnement différentes du processus web. Les fichiers inclus et les conditions de configuration doivent donc être compris avant de généraliser son résultat au tableau de bord. Un résultat absent ou une erreur ne prouve pas que tout est autorisé. Conservez le message expurgé et revenez à la lecture ciblée ; ne lancez ni commande d’écriture ni liste complète des constantes, qui exposerait des secrets inutiles.

wp config get DISALLOW_FILE_MODS --type=constant --format=json --path='/chemin/vers/wordpress'

Examiner un filtre si la constante n’explique pas le blocage

WordPress ne consulte pas seulement la constante. La fonction wp_is_file_mod_allowed() transmet aussi sa décision au filtre file_mod_allowed. Un filtre est un point où une extension ou du code personnalisé peut ajuster un comportement. Une valeur false dans votre fichier n’impose donc pas à tous les composants d’accepter les modifications.

L’examen doit viser le code responsable, sans retirer au hasard les protections du site. Si l’administration est accessible, regardez dans Extensions les éléments actifs et, lorsqu’elle existe, la catégorie des extensions indispensables. Les composants gérés par l’hébergement peuvent ne pas offrir de bouton de désactivation ordinaire. Leur présence seule ne démontre pas qu’ils causent le refus.

Demandez au mainteneur de rechercher l’enregistrement du filtre file_mod_allowed dans les fichiers effectivement chargés et d’identifier sa condition : environnement de production, utilisateur ou opération. Le cœur fournit notamment capability_update_core pour les capacités d’installation et de mise à jour, et automatic_updater pour le mécanisme automatique. Le nom du premier contexte ne signifie donc pas qu’il protège seulement le cœur. Une politique peut agir différemment selon le parcours. Corrigez son réglage source, puis vérifiez l’action concernée ; un filtre forçant toujours l’autorisation masquerait la décision d’origine.

Ne pas confondre les autres constantes avec cette interdiction

DISALLOW_FILE_MODS couvre aussi les éditeurs de fichiers. À l’inverse, DISALLOW_FILE_EDIT vise ces éditeurs sans interdire à elle seule les installations et mises à jour. Si seuls les éditeurs manquent, il n’est pas nécessaire de les rétablir pour maintenir normalement les composants. Garder cette interdiction séparée permet de conserver la protection souhaitée.

AUTOMATIC_UPDATER_DISABLED concerne le mécanisme automatique. Il ne faut pas l’effacer simplement parce qu’une opération manuelle ne fonctionne pas. De même, le réglage des mises à jour automatiques du cœur ne remplace pas la vérification de l’autorisation générale de modifier les fichiers. Identifiez l’opération réellement attendue avant de toucher à ces valeurs.

Enfin, WP_HTTP_BLOCK_EXTERNAL contrôle les requêtes sortantes. Un refus de connexion à WordPress.org relève d’un autre diagnostic que la disparition d’un bouton. Ne le remplacez pas par une autorisation générale de communication sans examiner la restriction existante. Lorsque plusieurs constantes sont présentes, notez séparément leur fonction et leur propriétaire. Changer quatre valeurs à la fois empêche de savoir laquelle était utile et peut ouvrir des possibilités que personne n’avait demandées.

Traiter séparément une demande FTP ou une erreur d’écriture

Après correction de la politique, WordPress peut demander des identifiants FTP ou signaler qu’un dossier ne peut pas être créé. Ce nouveau message ne signifie pas que la constante a été mal corrigée. L’application est passée à une autre étape : elle essaie désormais d’accéder aux fichiers et rencontre une question de transport, de propriétaire ou de droits.

Conservez le message exact et le chemin du dossier cité. Vérifiez qu’il appartient au site courant et recherchez la procédure propre à cet échec. N’ajoutez pas automatiquement FS_METHOD pour imposer l’écriture directe et n’accordez pas les permissions 777. Une permission très large ne corrige ni une politique WordPress ni une mauvaise propriété des fichiers.

L’installation d’une extension de dépannage n’est pas pertinente pour lever ce verrou. Si les installations sont interdites, l’outil peut lui-même être impossible à ajouter ; et un outil ordinaire ne rend pas modifiable une constante déjà chargée. Le parcours sans nouvelle extension est ici le plus direct. Si un composant de gestion déjà installé pilote la politique, son réglage documenté peut être utile, mais seulement après identification de son rôle exact.

Revenir en arrière sans annuler les autres interventions

Si le fichier modifié provoque une panne immédiate, remettez sa copie privée initiale avec l’accès aux fichiers resté ouvert. Vérifiez ensuite l’accueil puis la connexion à l’administration. Ne restaurez pas tout le site pour une simple erreur de caractère si aucune autre modification n’a eu lieu depuis la sauvegarde.

Si le site fonctionne mais que la politique choisie doit être rétablie, remettez uniquement la définition précédente dans la source effectivement utilisée. Tenez compte d’éventuelles modifications intervenues entre-temps : remplacer un ancien fichier complet pourrait effacer une nouvelle configuration légitime. Contrôlez les différences avant tout transfert.

1. Consignez le motif du retour arrière et l’heure de la dernière modification.
2. Rétablissez la ligne ou le fichier approprié selon l’étendue réelle du changement.
3. Rechargez les écrans observés au départ et comparez les commandes disponibles.
4. Si une mise à jour a déjà été exécutée, traitez son retour arrière séparément : rétablir la constante ne remet pas les anciens fichiers ni l’ancienne base.
5. Rangez la preuve du résultat avec la procédure de maintenance, puis retirez toute copie de travail qui aurait été laissée dans un emplacement public.

Garder une politique de maintenance explicite

Après résolution, documentez le chemin de configuration, la valeur retenue, la personne qui la gère et le circuit des prochaines mises à jour. Un commentaire court dans la procédure interne est plus utile qu’une constante dont personne ne connaît l’origine. Sur une configuration générée, indiquez surtout le réglage source : une correction manuelle du fichier produit risquerait de disparaître.

Prévoyez aussi qui vérifie les nouvelles versions et comment une mise à jour urgente sera livrée. Une interdiction d’écriture peut être cohérente avec une maintenance organisée ; elle devient problématique si elle laisse le site durablement sans responsable. À l’inverse, autoriser les modifications ne remplace ni la sauvegarde ni la validation de compatibilité.

Pour transmettre un problème non résolu, fournissez l’adresse de l’administration, les commandes absentes, le rôle du compte, la définition expurgée et son emplacement. Ajoutez le résultat de lecture ciblée si vous l’avez effectué, ainsi que l’existence éventuelle d’un déploiement géré. Ces éléments permettent au mainteneur de distinguer une restriction voulue d’un filtre inattendu sans demander votre fichier de configuration complet ni vos secrets.