WordPress demande des identifiants FTP : retrouver la bonne méthode d’accès

Identifier pourquoi ce formulaire apparaît maintenant

Vous lancez une mise à jour ou une installation et WordPress affiche « Informations de connexion » avec un hôte, un utilisateur et un mot de passe FTP. Cette demande concerne l’accès aux fichiers de l’hébergement. Elle ne signifie pas que votre compte administrateur WordPress est devenu incorrect. Le but est de retrouver la méthode prévue pour modifier ces fichiers, puis de terminer l’opération autorisée.

Sur un site qui écrivait directement jusqu’ici, cherchez le changement récent : migration, restauration, déploiement, modification de PHP ou ajout d’une constante de configuration. Sur une nouvelle installation, cette demande peut correspondre au fonctionnement normal choisi par le prestataire. Sa seule présence ne prouve ni une intrusion ni une permission particulière à appliquer.

Ce guide concerne WordPress autohébergé. Dans un multisite, les installations et mises à jour se préparent au niveau du réseau avec les droits correspondants. Pour un hébergement géré qui impose son outil de déploiement, suivez cette politique. Ne cherchez pas à rendre le code modifiable depuis WordPress si cette interdiction fait partie du fonctionnement prévu.

Sur WordPress.com, l’accès SFTP éventuel est fourni par la plateforme selon l’offre ; ce n’est pas un compte FTP à inventer pour cette fenêtre. Si elle apparaît sur votre site géré, transmettez au support la capture sans secrets et l’action qui l’a déclenchée. Les corrections de propriétaire et les parcours cPanel ci-dessous concernent l’environnement autohébergé dont vous administrez réellement les fichiers.

Distinguer le compte WordPress, l’accès aux fichiers et la base

Le compte administrateur WordPress sert à ouvrir le tableau de bord. L’accès FTP, FTPS ou SFTP concerne des fichiers sur un serveur et provient du prestataire ou du responsable de l’hébergement. L’utilisateur MySQL ou MariaDB sert à la base de données. Ces trois fonctions sont différentes, même si une même personne gère le site.

Ne saisissez donc pas votre mot de passe WordPress ni le secret de la base dans le formulaire FTP pour essayer. Retrouvez d’abord les références du compte de fichiers autorisé et son protocole. L’adresse du serveur de fichiers peut différer du domaine public. Un compte limité à un dossier doit couvrir l’emplacement nécessaire à l’opération, sans donner accès aux autres clients du serveur.

Si vous n’avez aucun accès aux fichiers ou au panneau, le diagnostic natif reste possible, mais une correction de propriétaire demandera le responsable technique. Transmettez-lui l’opération exacte et le changement récent. Il n’a pas besoin de recevoir un mot de passe dans un ticket pour commencer à examiner la situation.

Préparer une intervention limitée et son annulation

Avant de modifier la configuration ou les permissions, conservez les valeurs initiales et une copie privée de wp-config.php. Ce fichier contient des secrets : gardez sa copie hors de tout répertoire servi sur le Web. Pour une véritable mise à jour, préparez aussi une sauvegarde restaurable des fichiers et de la base, avec une date et un périmètre connus.

Le premier parcours recherche un choix de transport forcé par erreur ; il convient après un ajout documenté dans la configuration. Le second examine le chemin et ses droits, puis corrige un élément dont l’état incorrect a été confirmé. Une observation dans Santé du site aide à choisir ; elle n’autorise pas à modifier toute l’installation.

Faites les essais sur une copie lorsque vous le pouvez, avec ses propres fichiers et sa propre base, en neutralisant ses envois et opérations externes. Un second domaine pointant vers les mêmes fichiers ne constitue pas cette copie. Préparez une fenêtre adaptée pour le site réel et vérifiez qu’un autre outil ne met pas déjà les mêmes fichiers à jour. Le retour d’une ligne de configuration est simple ; annuler une mise à jour ayant transformé les données demande une restauration coordonnée.

Lire ce que WordPress peut écrire dans Santé du site

Ouvrez Outils, Santé du site, puis l’onglet Informations. La rubrique Permissions du système de fichiers indique si WordPress estime plusieurs répertoires accessibles en écriture : dossier principal, contenu, extensions, thèmes ou médias selon l’installation. Les libellés et rubriques disponibles varient avec la version et les composants.

Un dossier signalé accessible n’établit pas que chaque fichier contenu peut être remplacé. Le répertoire d’une extension particulière peut avoir un autre propriétaire ou des droits différents. Inversement, un code volontairement non inscriptible peut correspondre à une politique de déploiement. Reliez donc ce constat à l’action précise, plutôt que vouloir rendre tous les voyants favorables.

1. Dépliez Permissions du système de fichiers et relevez seulement les lignes pertinentes pour l’opération bloquée.
2. Notez également la version de PHP et les chemins utiles présentés dans les informations, sans publier tout l’export technique.
3. Comparez avec le dossier nommé par le message d’échec, s’il en contient un. Gardez les deux constats séparés.
4. Après une correction, revenez dans cet écran et comparez. Cette lecture seule ne demande aucun changement à annuler.

Comprendre le choix de transport avant de le forcer

WordPress dispose de plusieurs transports pour lire et modifier les fichiers. La méthode direct passe par PHP ; d’autres utilisent FTP ou SSH2 selon les capacités disponibles. Pour choisir automatiquement l’accès direct, WordPress peut créer un fichier temporaire de contrôle et comparer son propriétaire à celui de ses propres fichiers. Le dossier testé dépend du contexte de l’opération.

Pouvoir déposer un fichier depuis le gestionnaire de l’hébergement ne prouve pas que PHP agit avec la même identité. De même, un compte SSH qui peut écrire dans le dossier ne prouve pas que le processus Web le peut. Cette différence explique qu’un changement d’hébergement ou de mode d’exécution PHP puisse faire apparaître le formulaire.

Une définition FS_METHOD dans wp-config.php ou un filtre logiciel peut imposer une autre méthode. Cela explique aussi pourquoi modifier des permissions ne supprime pas toujours la demande. Avant toute correction, faites distinguer un transport imposé, une différence de propriétaire et un vrai refus d’écriture. Le diagnostic ne consiste pas à essayer successivement toutes les méthodes jusqu’à masquer le formulaire.

Approche 1 : retirer un forçage FTP ajouté par erreur

Ce cas est précis : une définition FS_METHOD a été ajoutée récemment, son auteur confirme qu’elle est inutile et l’environnement est censé choisir automatiquement sa méthode. Il faut un accès privé à la configuration, par SFTP ou gestionnaire autorisé. Si l’hébergeur impose ce transport, ne retirez pas son réglage.

L’exemple montre comment commenter une ancienne ligne fictive qui forçait ftpext. Il ne faut pas ajouter ce commentaire à côté d’une définition encore active : modifiez la ligne identifiée elle-même. Si une variable ou un autre fichier fournit la valeur, faites corriger sa source. Ne remplacez pas le fichier entier par cet extrait.

1. Copiez wp-config.php vers votre stockage privé et recherchez FS_METHOD dans le fichier complet.
2. Commentez uniquement l’ajout erroné confirmé, comme dans l’exemple, puis enregistrez sans changer les autres paramètres.
3. Revenez à l’opération prévue après préparation de sa sauvegarde. WordPress doit pouvoir refaire son choix ; l’accès direct n’est pas garanti.
4. Si le problème persiste ou si ce réglage était nécessaire, restaurez la ligne initiale. Une erreur PHP demande de rétablir immédiatement la copie privée.

// define( 'FS_METHOD', 'ftpext' );

Éviter de confondre accès direct et réparation des droits

Ajouter FS_METHOD avec la valeur direct impose le transport PHP, mais ne crée aucun droit système supplémentaire. Le formulaire peut disparaître alors que le remplacement des fichiers échoue plus loin. Cette disparition ne prouve pas que le propriétaire est correct ni que l’isolation entre sites est préservée.

Un réglage direct peut être légitime dans un environnement spécifiquement préparé. Il demande que le responsable ait vérifié l’identité PHP, les droits nécessaires et la politique d’isolation. Dans ce cas, appliquez sa configuration précise avec sauvegarde et retour arrière. Ce guide ne propose pas cette ligne comme remède général à toute demande FTP.

Si vous l’avez déjà ajoutée pour cet incident et que l’erreur s’est déplacée vers un dossier non inscriptible, relevez le nouveau message. Revenez à la configuration initiale si le changement n’était pas justifié, puis examinez ce dossier. N’augmentez pas les permissions pour faire fonctionner un transport forcé dont la pertinence n’a jamais été établie.

Approche 2 : retrouver le chemin et l’élément réellement refusés

Cette approche convient lorsque la méthode prévue est connue mais que l’écriture échoue sur un emplacement précis. Il faut un accès au panneau ou aux fichiers du bon abonnement. Retrouvez la racine correspondant au domaine, puis le chemin de l’installation concernée ; public_html n’est pas nécessairement le dossier de tous les sites.

Le message peut viser wp-content/upgrade, le dossier d’une extension ou un fichier de destination. Une mise à jour du cœur et une mise à jour d’extension ne demandent pas exactement les mêmes accès. Notez l’élément cité et le parent dans lequel un fichier doit être créé. Une copie voisine portant le même nom ne doit pas recevoir la correction.

Vérifiez aussi si le chemin est un lien symbolique ou relève d’un déploiement automatisé. Une correction manuelle peut être annulée au prochain déploiement ou viser un autre emplacement que prévu. Lorsque le propriétaire n’est pas celui attendu après une restauration, faites corriger cette appartenance par le prestataire. Votre gestionnaire de fichiers ne permet pas nécessairement cette opération, même s’il affiche un bouton Permissions.

Corriger une permission confirmée dans cPanel

Ce parcours porte sur un seul élément, avec une valeur adaptée à votre hébergement déjà confirmée. Le mode 755 d’un dossier ou 644 d’un fichier est fréquent, mais ne constitue pas une solution universelle. Les besoins du dossier et du fichier diffèrent ; aucun essai ne justifie 777 ou une application récursive à tous les sites.

Dans cPanel, ouvrez Files puis File Manager, appelé Gestionnaire de fichiers dans certaines traductions. Le responsable doit avoir distingué la permission du propriétaire avant cette correction. Si votre compte ne peut pas modifier l’élément, n’élargissez pas les droits d’un parent sans rapport pour contourner ce refus.

1. Ouvrez le chemin confirmé et sélectionnez exactement le fichier ou dossier concerné.
2. Cliquez sur Permissions et notez sa valeur actuelle avec le chemin.
3. Saisissez uniquement la valeur confirmée, vérifiez l’élément sélectionné et validez avec Change Permissions.
4. Reprenez une seule opération prévue et observez son résultat. Le résultat attendu est l’écriture autorisée dans cette zone, pas seulement la disparition du formulaire.
5. Si la correction était injustifiée ou sans effet selon le diagnostic, rétablissez la valeur initiale ; n’augmentez pas progressivement les chiffres.

Lire les propriétaires sous Linux sans modifier les fichiers

Cette variante s’adresse à une personne disposant d’un accès SSH autorisé. La commande suivante affiche les informations des trois chemins indiqués ; elle ne change ni permissions ni propriétaire. Remplacez /CHEMIN/CONFIRME/wordpress par la racine absolue réelle. Adaptez le dernier chemin au dossier effectivement concerné ; son absence doit être relevée, pas masquée par une création improvisée.

L’option -d affiche les dossiers eux-mêmes, et -n les identifiants numériques de propriétaire et de groupe. Relevez aussi le type de l’élément et ses permissions. Un lien symbolique demande d’identifier sa cible réelle avant toute correction. Une information absente ou un refus de lecture est un résultat à transmettre.

Comparez ces identifiants avec le compte attendu selon l’hébergement. Avec PHP-FPM, le responsable retrouve l’identité des processus dans la configuration du pool du site ; ce n’est pas nécessairement le compte de votre session SSH. Ne déduisez pas qu’il faut tout attribuer à www-data, apache ou votre utilisateur personnel. La bonne appartenance dépend du dispositif d’isolation et de déploiement.

ls -ldn '/CHEMIN/CONFIRME/wordpress' '/CHEMIN/CONFIRME/wordpress/wp-content' '/CHEMIN/CONFIRME/wordpress/wp-content/upgrade'

Distinguer propriétaire incorrect, quota et code volontairement protégé

Si des fichiers restaurés appartiennent à un autre compte, transmettez leur chemin et les identifiants relevés. Le prestataire doit comparer avec la politique du site et corriger le périmètre concerné. Une commande globale chown ou chmod sur tout l’abonnement peut toucher des archives privées, d’autres sites et des fichiers dont les protections sont intentionnelles.

Une écriture peut aussi échouer faute de capacité. Dans cPanel, ouvrez Files, Disk Usage et examinez les indicateurs du compte. Un message disk quota exceeded oriente vers le quota ; des limites de nombre de fichiers peuvent également exister selon le prestataire. Changer le propriétaire ne libère pas d’espace. Une sauvegarde créée sur un compte déjà plein peut elle-même échouer : vérifiez le résultat, pas seulement le lancement.

Enfin, un déploiement géré peut réserver le remplacement du code à son propre outil. Dans ce cas, faites appliquer la version préparée par ce processus, avec contrôle et possibilité de retour. Le maintien d’un code non inscriptible depuis PHP n’est pas automatiquement une panne. Évitez une modification manuelle qui serait écrasée au prochain déploiement.

Si l’hébergement exige réellement un transport de fichiers

Il existe des environnements où un transport distinct est prévu. Avant de saisir un accès, faites confirmer par le prestataire le formulaire attendu, le serveur, le port, le compte limité et le protocole autorisé. FTP, FTPS et SFTP ne sont pas interchangeables. Le HTTPS de votre administration protège le trajet navigateur–site ; il ne décrit pas à lui seul le trajet entre PHP et le serveur de fichiers.

Le formulaire natif peut proposer FTP, FTPS (SSL) ou SSH2 selon les extensions PHP disponibles. Le libellé FTPS ne garantit pas la vérification du certificat : le transport PHP utilisé par WordPress repose sur ftp_ssl_connect, dont la documentation précise cette limite. Faites valider cette voie dans votre contexte, ou employez le processus de transfert sécurisé prévu par l’hébergeur. Ne passez pas à FTP en clair pour faire disparaître une erreur de connexion.

Dans un parcours expressément validé, renseignez l’hôte fourni, éventuellement suivi de :port dans le champ Hôte selon les consignes reçues, l’utilisateur de fichiers et son secret, puis le type réellement correspondant. N’utilisez pas le mot de passe SQL. Le traitement natif évite de sauvegarder le mot de passe dans l’option de connexion ; cela ne garantit pas le comportement d’un formulaire remplacé par une extension. N’ajoutez pas durablement des secrets FTP dans wp-config.php pour éviter de les ressaisir.

Reprendre une seule mise à jour et contrôler le résultat

Après la correction, revenez à l’opération initialement prévue. Pour une extension, utilisez sa ligne dans Extensions installées ; pour le cœur, Tableau de bord puis Mises à jour. Vérifiez le composant et la version cible avant de confirmer. Gardez l’écran ouvert jusqu’au résultat et notez l’heure de ce nouvel essai.

Si la demande d’accès disparaît mais qu’un téléchargement vers WordPress.org échoue, l’incident a changé d’étape : examinez la connexion sortante. Si l’archive est invalide, examinez le paquet. Si un dossier précis reste refusé, le périmètre des accès n’est pas encore corrigé. Ces résultats demandent des actions différentes, pas un nouvel ajout systématique de FS_METHOD.

Contrôlez ensuite la version installée et une fonction représentative du composant. Consultez le site public et l’administration. Sur une copie, utilisez des données de contrôle sans effet réel. Sur le site actif, préparez les essais sensibles avec son responsable. Une connexion FTP réussie ne prouve pas qu’une mise à jour a fini, et une mise à jour finie ne prouve pas que toutes les fonctions du site sont intactes.

Refermer l’intervention avec un retour arrière précis

Conservez le chemin corrigé, la valeur précédente, la nouvelle valeur et le résultat du contrôle. Une modification de permission peut être annulée en remettant la valeur relevée. Une ligne de configuration peut être restaurée depuis sa copie privée. Pour une correction de propriétaire réalisée par le prestataire, demandez le compte initial, le compte attendu et le périmètre effectivement modifié.

Ne confondez pas ces retours avec l’annulation d’une mise à jour. Si le composant a déjà modifié sa base ou ses réglages, restaurer seulement ses anciens fichiers peut laisser un état incohérent. Préservez les nouvelles données et faites appliquer le plan de restauration préparé avant d’écraser une sauvegarde sur le site actif.

Aucune nouvelle extension n’est nécessaire pour cette démarche. Une extension qui masque le formulaire ne peut pas attribuer à PHP des droits système absents ni corriger l’appartenance imposée par le serveur. Pour obtenir une aide ciblée, transmettez le domaine, l’heure, l’action, le message exact, les chemins et les changements récents. Gardez les accès, les clés et les copies de configuration dans votre stockage privé.