WordPress après migration : corriger « open_basedir restriction in effect »

Reconnaître le refus de chemin après un changement de serveur

Après une migration, le site ou une fonction affiche « open_basedir restriction in effect ». Le message nomme un fichier demandé et les chemins dans lesquels PHP est autorisé à travailler. Le fichier peut être parfaitement lisible par le système, mais rester en dehors de ce périmètre. Modifier ses permissions ne corrige donc pas nécessairement le refus.

Le résultat recherché est un accès au bon fichier dans le contexte du nouveau site. La première approche corrige un ancien chemin que le transfert a laissé dans un réglage ou un fichier généré. La seconde ajuste une autorisation légitime du domaine lorsque la ressource doit réellement se trouver ailleurs. Ajouter l’ancien compte d’hébergement aux chemins autorisés sans vérifier sa provenance peut masquer une mauvaise migration.

Les contrôles demandent un journal privé, l’accès aux fichiers ou au panneau de l’hébergement et une copie pour les essais. Sur WordPress.com, php.ini n’est pas modifiable par l’utilisateur ; le support doit vérifier le besoin et une solution compatible avec la plateforme. Sur une offre gérée, l’accès dépend du contrat. En multisite auto-hébergé, une même configuration PHP peut concerner plusieurs sous-sites : vérifiez leur portée avant une modification. Le guide ne remplace pas le parcours propre à un dossier temporaire absent lors d’un téléversement.

Lire séparément le fichier demandé, la liste autorisée et l’appelant

Un avertissement contient souvent trois informations différentes : le chemin que PHP tente de lire, la liste des chemins permis, puis le fichier de code et la ligne qui ont provoqué la demande. Conservez ces éléments ensemble avec l’heure. Le dernier fichier mentionné n’est pas automatiquement celui dont les permissions seraient mauvaises ; il peut simplement appeler un ancien emplacement.

Exemple fictif : le code s’exécute sous /var/www/vhosts/exemple.test/, mais demande encore /home/anciencompte/public_html/ressource.php. La priorité est de comprendre pourquoi l’ancien chemin est construit. S’il n’existe plus et ne correspond à aucune ressource prévue, élargir la restriction ne récupérera pas le fichier absent.

Dans Plesk, ouvrez Domains > le domaine > Logs pour retrouver l’entrée. Avec un autre hébergement, utilisez le journal PHP privé fourni pour ce site et sa période d’erreur. Si le journal est vide, faites confirmer sa destination par le responsable plutôt que d’exposer les erreurs au public. Lors du partage, masquez les noms de comptes et les secrets tout en conservant la structure utile des chemins.

1. Relevez le chemin exact demandé, sans publier les noms de comptes privés.
2. Copiez séparément la liste des chemins autorisés affichée dans le message.
3. Notez le fichier appelant, sa ligne et le composant qui le possède.
4. Comparez ces informations avec la racine actuelle du site dans le panneau.
5. Gardez un seul exemple daté pour comparer le résultat après correction.

Préserver la configuration avant de modifier un chemin

Conservez une copie privée du fichier concerné et la valeur actuelle du réglage PHP. Préparez une sauvegarde des données si le chemin est enregistré dans un composant. Une restauration de fichiers ne remplace pas la récupération d’un réglage stocké en base. Utilisez une copie récente dont les envois et les intégrations sensibles sont neutralisés pour reproduire le cas.

Gardez un accès au panneau ou à SFTP indépendant de l’administration WordPress. Un fichier chargé tôt peut empêcher le tableau de bord de démarrer après une faute de syntaxe. Préparez donc le moyen de remettre immédiatement la version précédente. Ne déplacez pas wp-config.php vers un répertoire public pour contourner l’erreur.

Le témoin doit montrer la fonction concernée sans lancer une opération importante. Une simple page ou une consultation de réglages peut suffire. Arrêtez les relances si le message vient d’un traitement déjà commencé : une erreur visible ne prouve pas l’absence d’écritures partielles. Notez ce qui a changé pendant la migration, notamment le chemin du compte, la racine documentaire et le moteur PHP utilisé.

Vérifier le PHP du domaine plutôt que celui d’un terminal

Dans le panneau de l’hébergement, identifiez la version et le gestionnaire PHP associés au domaine. Le site peut employer PHP-FPM avec une configuration différente de la commande PHP disponible en SSH. Un relevé effectué sur un autre domaine ou une ancienne copie ne décrit pas nécessairement la requête qui échoue.

Avec Plesk, ouvrez Domains > votre domaine > Dashboard > PHP, ou PHP Settings dans l’autre présentation. Relevez open_basedir dans les réglages courants et le gestionnaire PHP. Si disponible dans cet écran authentifié, View the phpinfo() page permet de comparer Local Value, Master Value et le fichier chargé. Cette vue contient des informations privées : ne la publiez pas et ne créez pas un fichier phpinfo accessible aux visiteurs.

Une valeur affichée dans un fichier ne prouve pas qu’elle est chargée par ce domaine. Si le message cite une autre liste, faites vérifier le contexte par le responsable PHP, y compris une directive imposée au niveau du service. Gardez la preuve avant toute édition. Une multiplication de fichiers .user.ini et de réglages de panneau rendrait plus difficile l’identification de la valeur réellement appliquée.

Corriger d’abord un ancien chemin dans les réglages du composant

Cette première approche convient lorsque le chemin demandé appartient clairement à l’ancien hébergement. Retrouvez le composant appelant depuis le journal et consultez son écran de configuration sur la copie. Il peut conserver un dossier d’export, une ressource locale ou un chemin calculé au moment de son installation. Utilisez son parcours de migration ou de changement de chemin lorsqu’il en propose un.

Vérifiez que la ressource attendue existe réellement dans le nouvel environnement. Ne remplacez pas mécaniquement chaque occurrence de /home/ par un nouveau préfixe : les différents services n’ont pas forcément été déplacés de la même manière. Un réglage peut aussi attendre un dossier privé, et non la racine publique du site. Si la valeur provient d’un fichier de configuration, ouvrez sa copie privée dans l’éditeur du gestionnaire de fichiers ou votre éditeur local et recherchez le chemin exact du journal. Examinez les seules occurrences du composant identifié ; évitez un remplacement global de la base ou de tous les fichiers.

1. Conservez le réglage initial du composant et son chemin d’origine.
2. Choisissez le nouvel emplacement confirmé pour cette ressource sur la copie.
3. Enregistrez par l’écran ou le mécanisme documenté du composant.
4. Reprenez le témoin et vérifiez le chemin cité dans le nouveau journal.
5. Si la correction est inutile ou vise la mauvaise ressource, restaurez le réglage initial avant une autre comparaison.

Faire régénérer les fichiers de démarrage par leur propriétaire

Un composant peut générer un fichier de démarrage contenant un chemin absolu. La copie de ce fichier sur le nouveau serveur conserve alors une référence devenue obsolète. Il peut être chargé avant les extensions ordinaires, par exemple par une configuration PHP ou un mécanisme de plateforme. Désactiver une extension depuis WordPress ne garantit pas que ce chargement précoce a cessé. Un auto_prepend_file hérité dans la configuration PHP peut notamment charger un fichier avant le cœur WordPress. Relevez la directive et son origine, sans la supprimer automatiquement.

Retrouvez le propriétaire du fichier et son parcours officiel de migration ou de réinstallation de cette intégration. Conservez le fichier et la configuration qui le charge avant de demander sa régénération. Ne retirez pas au hasard une ligne de démarrage qui assure une protection ou une fonction nécessaire. L’opération doit produire un nouveau chemin cohérent avec le domaine actuel.

Pour du code personnel, le mainteneur peut corriger la seule définition erronée dans sa copie contrôlée, avec vérification de syntaxe et possibilité de restauration. N’éditez pas un fichier généré si le prochain déploiement doit l’écraser. Le résultat attendu est une référence durable au bon emplacement, pas la disparition temporaire du message après suppression d’un fichier encore requis.

Confirmer qu’un chemin extérieur est réellement nécessaire

Si le chemin demandé appartient bien au nouveau serveur, vérifiez sa fonction et son propriétaire. Une ressource privée partagée peut légitimement rester en dehors de la racine publique. À l’inverse, un accès vers un autre compte ou un ancien répertoire de copie n’est pas nécessaire simplement parce qu’un script le tente.

Choisissez entre rapprocher la ressource du périmètre prévu et autoriser son emplacement exact. Le déplacement doit conserver les propriétés attendues : un fichier privé ne doit pas devenir téléchargeable depuis le web. Les autres applications qui utilisent cette ressource peuvent aussi dépendre de son chemin ; ne déplacez pas un dossier partagé sans vérifier leurs usages.

Faites confirmer le chemin réel du fichier et la portée de l’autorisation souhaitée. Les liens symboliques sont résolus par PHP : un lien placé dans un dossier autorisé ne rend pas automatiquement sa cible extérieure admissible. Si aucune nécessité n’est établie, corrigez la demande du composant. Si la nécessité est confirmée, préparez une adaptation limitée au domaine et au dossier utile, avec l’état initial conservé. La liste autorise une arborescence de répertoire, pas n’importe quel nom commençant par le même préfixe. Elle ne remplace pas l’isolation des comptes et les permissions du système.

Comparer un composant après démarrage avec une aide facultative

Sur une copie qui démarre encore, vous pouvez comparer le composant suspect sans nouvel outil depuis Extensions, Extensions installées. Désactivez uniquement ce composant si la fonction témoin reste significative, puis remettez-le après le relevé. Si l’erreur apparaît avant WordPress ou provient d’un fichier imposé au démarrage, cette comparaison peut être insuffisante.

Troubleshooting, de Marius L. J., constitue une aide facultative pour une comparaison dans votre session. La version relevée est 1.0.2, avec WordPress 5.8 et PHP 7.1 au minimum, testé jusqu’à WordPress 7.1.4. Elle ne crée pas une base séparée et ne modifie pas la restriction PHP. Utilisez une copie pour les opérations qui écrivent. Ces minima ne conseillent pas d’installer une ancienne branche PHP. Le mode peut lui-même échouer si le fichier nécessaire ne peut pas être créé dans mu-plugins : n’élargissez pas les permissions ou open_basedir uniquement pour forcer cet outil facultatif.

1. Sur la copie, ouvrez Extensions > Ajouter une extension, recherchez Troubleshooting de Marius L. J., puis Installer maintenant et Activer si vos droits le permettent.
2. Ouvrez Outils > Santé du site > Troubleshooting, puis Enable Troubleshooting Mode. Le thème et les extensions ordinaires changent pour votre session ; la base n’est pas isolée par cet outil.
3. Depuis le menu Troubleshooting Mode de la barre d’administration, réactivez les composants nécessaires un par un et observez le même témoin.
4. Conservez les journaux correspondants. Les MU-plugins et certains chargements précoces restent actifs ; leur présence limite la conclusion.
5. Terminez avec Disable Troubleshooting Mode depuis ce menu et contrôlez le fonctionnement normal de la copie.

Adapter la liste autorisée dans Plesk pour le seul domaine

Cette seconde approche convient si le dossier extérieur est nécessaire et si le compte peut modifier le PHP du domaine. Dans Plesk, ouvrez Domains > le domaine > Dashboard > PHP, ou PHP Settings. Conservez la valeur entière de open_basedir, y compris les variables de panneau. Cliquez dans son champ pour saisir une valeur personnalisée. Si le réglage est absent ou verrouillé, faites appliquer le besoin documenté par l’hébergeur ; ne modifiez pas le plan de service de tous les domaines.

Dans le champ open_basedir, préservez les chemins nécessaires et ajoutez seulement le dossier confirmé. L’exemple Linux ci-dessous montre la forme attendue, pas un remplacement automatique de votre liste existante. Les variables sont propres à Plesk ; ne collez pas cette ligne dans Additional configuration directives, un fichier INI ou une console. Windows utilise le point-virgule entre répertoires et sa syntaxe de chemin : faites adapter la valeur, sans transposer cette ligne Linux.

1. Vérifiez le domaine et copiez sa valeur initiale en privé.
2. Ajoutez le seul répertoire nécessaire selon le mécanisme du panneau.
3. Appliquez avec OK ou le bouton de validation de cet écran.
4. Relevez la valeur effective et testez le même cas.
5. Pour annuler, remettez exactement la valeur initiale dans ce champ et contrôlez son application.

{WEBSPACEROOT}{/}{:}{TMP}{/}{:}/chemin/prive/autorise

Faire adapter la configuration effective dans les autres environnements

Sans Plesk, le responsable PHP doit identifier le fichier ou le réglage qui impose la valeur au domaine : panneau de l’offre, configuration du service ou réglage par répertoire compatible. Ne créez pas plusieurs fichiers de configuration pour voir lequel semble agir. Conservez la définition initiale et sa portée avant un changement.

Une modification à l’exécution peut resserrer open_basedir, mais elle n’est pas un moyen général d’élargir une restriction déjà appliquée. Ajouter ini_set dans le thème ou un extrait ne constitue donc pas le bon parcours pour autoriser un ancien dossier refusé. Une valeur imposée par le service doit être traitée à ce niveau par son responsable.

L’adaptation doit viser le dossier nécessaire et conserver les autres chemins requis par le fonctionnement du domaine. N’utilisez pas une valeur vide ou un accès à toute la racine comme diagnostic permanent. Après application, faites relire la valeur effective dans le contexte web puis reprenez le témoin. Si elle reste inchangée, vérifiez le gestionnaire et le fichier chargés avant toute nouvelle modification.

Un fichier .user.ini n’est pris en compte que pour les contextes CGI/FastCGI compatibles, pas universellement. PHP recherche ces fichiers dans le chemin du script jusqu’à la racine documentaire ; un réglage voisin peut donc encore intervenir. Leur relecture dépend de user_ini.cache_ttl, dont la valeur par défaut est 300 secondes. Faites vérifier le délai effectif avant de cumuler d’autres modifications. Les directives imposées avec php_admin_value ne peuvent pas être remplacées par ini_set ; faites intervenir le responsable de cette configuration.

Séparer la restriction PHP des permissions du système

Même après autorisation du chemin, le fichier doit exister et être accessible au processus PHP. Si un nouveau message indique une absence de fichier ou un refus de permissions, traitez ce résultat comme une autre étape du diagnostic. Le répertoire autorisé ne crée pas la ressource et n’accorde pas à lui seul les droits de lecture ou d’écriture du système.

Ne passez pas tous les dossiers en 777 pour faire disparaître un avertissement de chemin. Vérifiez le propriétaire, les droits nécessaires et la fonction du fichier. Une permission trop large ne corrige pas une cible extérieure à open_basedir ; elle ajoute seulement un autre changement à l’incident. Gardez les réglages de permissions initiaux si un contrôle ciblé est nécessaire.

Si le bon fichier a été corrigé mais que l’ancien chemin apparaît encore, faites vérifier une copie concurrente, un autre point de connexion ou du code ancien toujours chargé. Utilisez le mécanisme d’invalidation prévu par l’hébergement lorsque cette cause est confirmée. N’installez pas une page publique de réinitialisation de cache PHP pour explorer une hypothèse.

Valider le chemin et le résultat sur une nouvelle requête

Reprenez la consultation exacte qui produisait l’avertissement, après application de la correction. Notez l’heure et examinez le journal correspondant. Le message doit cesser pour le chemin concerné et la fonction doit produire le résultat attendu. Masquer l’affichage public des avertissements ne répare pas un accès refusé : le journal privé et le comportement restent les contrôles utiles.

Si le composant devait lire une ressource, vérifiez son contenu ou son effet attendu. S’il devait écrire un export, vérifiez l’emplacement privé et le fichier final, sans envoyer de vraies données sensibles pour le seul test. Une notification de succès n’établit pas que le bon dossier a été utilisé. Contrôlez aussi une fonction voisine dépendant de chemins conservés dans la liste autorisée.

Confirmez ensuite sur la copie en fonctionnement normal si vous aviez utilisé un mode de dépannage. Une session isolée ne représente pas tous les composants qui démarrent sur le site. Ne retenez pas une correction qui remplace seulement l’ancien avertissement par une erreur d’inclusion ou de permissions. Le parcours est validé lorsque le chemin est cohérent et le résultat complet.

Revenir au réglage initial et préparer la prochaine migration

Si l’essai doit être annulé, restaurez la seule valeur ou le seul fichier modifié par la méthode utilisée. Relevez ensuite le réglage effectif du domaine. Une restauration de configuration PHP ne rétablit pas automatiquement les données qu’un composant aurait écrites pendant le test ; gardez leur récupération séparée et limitée à leur périmètre.

Documentez les chemins privés, la racine du site, le propriétaire des fichiers de démarrage et la manière de les régénérer après transfert. Lors de la prochaine migration, comparez ces références avec la nouvelle architecture avant de réutiliser un fichier généré. Évitez de conserver un ancien chemin simplement pour faire taire un avertissement après un déplacement incomplet.

Pour obtenir une aide précise, transmettez le message expurgé, le fichier appelant, le domaine, le gestionnaire PHP et les valeurs effective et initiale de la restriction. Indiquez quelle ressource existe réellement sur le nouveau serveur et quelle correction a été essayée. Ces informations permettent de choisir entre chemin obsolète et besoin d’autorisation, sans cumuler des modifications de permissions, de cache et de configuration qui masqueraient la cause.