WordPress demande mes informations d'identification FTP pour installer des plugins

118

J'ai installé un blog WordPress dans mon système local. Mais lorsque j'essaie d'ajouter des plugins à l'administrateur, cela demande un accès FTP. Que dois-je configurer pour que WordPress puisse télécharger sans FTP?

sasi kanth
la source

Réponses:

302

Essayez d'ajouter le code dans wp-config.php:

define('FS_METHOD', 'direct');
Nickle
la source
29
Je n'arrête pas de trébucher sur cette réponse tout en googlant, donc je poste une note ici pour moi et les autres: Le code est dans wp-admin / includes / file.php: get_filesystem_method. Wordpress essaie de créer un fichier 'wp-content / temp-write-test -'. Time (). Si cela échoue, cela suppose que vous ne pouvez utiliser que FTP. Mais cela peut ne pas être vrai, si wp-content lui-même n'est pas accessible en écriture, mais par exemple wp-content / plugins l'est. Ensuite, forcer FS_METHOD fonctionne.
Sebastian Schmid
3
cela fonctionne mais le problème est qu'après la décompression du paquet, l'erreur dit: "Impossible de créer le répertoire."
Andrew
3
Cela m'a aidé, mais uniquement parce que cela a révélé plus d'informations sur l'échec. Le problème principal est d'avoir des autorisations d'écriture pour le compte d'utilisateur qui effectue la mise à jour. Pour chaque type de système, cela peut être différent. (notez que certaines réponses ci-dessous vous indiquent de définir les permissions d'écriture pour daemon, ou httpd, ou apache ...) Cela m'a aidé à voir l'extrait de PHP à partir d'un commentaire ci-dessous (<? php echo (exec ("whoami")); ?>) pour que je puisse dire quel utilisateur exécute la mise à jour. Faire le changement suggéré ici semblait simplement supprimer le défi des informations d'identification FTP afin que je puisse voir les messages d'erreur.
agentv
J'utilise nginx et non Apache. Il est tout à fait clair que PHP-FPM n'utilise la bonne combinaison utilisateur / groupe ( en utilisant l'astuce décrite par @Aboozar Rajabi); cependant, pour une raison quelconque, la vérification WP échoue (aucune erreur sur les journaux cependant). L'utilisation de ce paramètre m'a permis de passer à 4.7 parfaitement!
Gwyneth Llewelyn
1
J'ai fait des devops dans d'autres domaines avant WordPress, ma meilleure supposition FS_METHODest courte FILESYSTEM_METHOD. Lorsque vous définissez pour direct-ly modifier les fichiers - c'est-à-dire ne pas utiliser FTP, vous obligez WordPress à essayer de modifier les fichiers directement sur le site.
Dylan Pierce
40

Si vous utilisez Ubuntu.

sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
Nanhe Kumar
la source
7
-1 mauvaise idée pour faire cela, seul le contenu wp devrait appartenir à www-datavoir ici: codex.wordpress.org/Hardening_WordPress ou ici: stackoverflow.com/questions/18352682/…
timhc22
Cette réponse corrige également l'erreur «Échec de l'installation: impossible de localiser le répertoire de contenu WordPress (wp-content)». lorsque vous essayez d'installer un plugin à partir du tableau de bord.
WindChimes
25

«Chaque fois que vous utilisez le panneau de configuration WordPress pour installer, mettre à niveau ou supprimer automatiquement des plugins, WordPress doit apporter des modifications aux fichiers sur le système de fichiers.

Avant d'apporter des modifications, WordPress vérifie d'abord s'il a ou non accès pour manipuler directement le système de fichiers.

Si WordPress ne dispose pas des autorisations nécessaires pour modifier directement le système de fichiers, il vous sera demandé des informations d'identification FTP afin que WordPress puisse essayer de faire ce dont il a besoin via FTP. "

Solution: afin de savoir quel utilisateur votre instance d'Apache s'exécute, créez un script de test avec le contenu suivant:

<?php echo(exec("whoami")); ?>

Pour moi, c'était démon et non www-data. Ensuite, corrigez l'autorisation en:

sudo chown -R daemon /path/to/your/local/www/folder
Aboozar Rajabi
la source
3
N'oubliez pas de désactiver exec () ou des fonctions sensibles similaires. en production.
Arda
2
Mieux encore est d'utiliser <?php echo(exec("id")); ?>ce qui vous fournira même des données de groupe au-delà de l'ID utilisateur:uid=5018(web27) gid=5012(client7) groups=5012(client7),5002(sshusers)
Gwyneth Llewelyn
Si vous pouvez sudo et chown, vous pouvez taper whoamipour voir les mêmes informations:sudo chown -R `whoami` /path/to/your/local/www/folder
Benji
11

Sur OSX, j'ai utilisé ce qui suit et cela a fonctionné:

sudo chown -R _www:_www {path to wordpress folder}

_www est l'utilisateur sous lequel PHP s'exécute sur Mac.

(Vous devrez peut-être également chmod certains dossiers. J'avais fait cela en premier et cela ne l'a pas résolu. Ce n'est que lorsque j'ai exécuté la commande chown que cela a fonctionné, donc je ne suis pas sûr que c'était la commande chown seul, ou une combinaison de chmod et chown.)

Kenny
la source
9

J'ai changé la propriété du dossier wordpress en www-data de manière récursive et redémarré apache.

sudo chown -R www-data:www-data <folderpath>

Ça a marché comme sur des roulettes!

KawaiKx
la source
C'est probablement la bonne réponse pour la plupart des gens. Je pense que c'est la troisième fois que je crée un dossier et que j'oublie de le faire.
MrMysterious2502
7

Dès le premier coup sur Google :

WordPress vous demande vos informations d'identification FTP lorsqu'il ne peut pas accéder directement aux fichiers. Cela est généralement dû au fait que PHP s'exécute en tant qu'utilisateur apache (mod_php ou CGI) plutôt qu'en tant qu'utilisateur propriétaire de vos fichiers WordPress.

C'est plutôt normal dans la plupart des environnements d'hébergement partagé - les fichiers sont stockés en tant qu'utilisateur et Apache s'exécute en tant qu'utilisateur apacheou httpd. C'est en fait une bonne précaution de sécurité, donc les exploits et les hacks ne peuvent pas modifier les fichiers hébergés. Vous pouvez contourner cela en définissant tous les fichiers WP sur la sécurité 777, mais cela signifie aucune sécurité, donc je vous déconseille fortement cela. Utilisez simplement FTP, c'est la solution de contournement automatiquement conseillée avec une bonne raison.

Niels Keurentjes
la source
Merci pour l'explication. Existe-t-il un moyen de configurer le serveur partagé pour exécuter PHP en tant qu'utilisateur correct ou corriger le propriétaire ou une autre solution?
Maxwell sc
5

Si lors de l'installation d'un plugin, Wordpress vous demande votre nom d'hôte ou vos détails FTP. Suivez ensuite ces étapes:

Connectez-vous à votre serveur et accédez à / var / www / html / wordpress / . Ouvrez wp-config.php et ajoutez cette ligne après define ('DB_COLLATE')

define('FS_METHOD', 'direct');

Si vous obtenez l'erreur "Impossible de créer le répertoire". Donnez des autorisations d'écriture à votre répertoire wordpress de manière récursive comme

chmod -R go+w wordpress

REMARQUE. Pour des raisons de sécurité, révoquez ces autorisations une fois que vous avez installé un plugin en tant que

chmod -R go-w wordpress
Abhishek Rathore
la source
4

Accédez d'abord à votre dossier d'installation (par exemple)

cd /Applications/XAMPP/xamppfiles/

Nous allons maintenant modifier votre répertoire htdocs:

sudo chown -R daemon htdocs

Entrez votre mot de passe root lorsque vous y êtes invité, puis terminez-le par un appel chmod:

sudo chmod -R g+w htdocs
Benja Garrido
la source
4

J'ai fait une installation locale de WordPress sur Ubuntu 14.04 en suivant les étapes décrites ici et en exécutant simplement:

sudo chown -R www-data:www-data {path_to_your_project_directory}

a résolu mon problème de téléchargement de plugins. La seule raison pour laquelle je laisse ce message ici est que lorsque j'ai recherché mon problème sur Google, c'était l'un des premiers résultats et cela m'a conduit à la solution de mon problème.

J'espère que celui-ci aide à n'importe qui!

Hiren Gohel
la source
3

Nous avons eu le même problème dans le cadre d'un problème plus important. La solution suggérée de

define('FS_METHOD', 'direct');

cache cette fenêtre, mais nous avons encore eu des problèmes avec le chargement des thèmes et des mises à jour, etc. Il est lié aux autorisations, mais dans notre cas, nous avons résolu le problème en passant du fournisseur de php OS mod_php à l' application FastCGI du fournisseur de système d'exploitation php plus sécurisé .

Malte
la source
2

Le moyen le plus simple de résoudre ce problème consiste à ajouter les informations FTP suivantes à votre wp-config.php

define('FS_METHOD', 'direct');
define('FTP_BASE', '/usr/home/username/public_html/my-site.example.com/wordpress/');
define('FTP_CONTENT_DIR', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/plugins/');

FTP_BASE est le chemin complet vers le dossier "base" (ABSPATH) de l'installation WordPress FTP_CONTENT_DIR est le chemin complet vers le dossier wp-content de l'installation WordPress. FTP_PLUGIN_DIR est le chemin complet du dossier plugins de l'installation WordPress.

Purvik Dhorajiya
la source
FTP n'est pas sécurisé et en tant que tel, nous le désactivons, donc ce n'est pas une solution. Nous utilisons plutôt SFTP.
Laurence Cope
1

Comme mentionné par Niels, cela se produit parce que l'utilisateur du processus serveur ne peut pas écrire dans le dossier Wordpress.

Mais voici ce que beaucoup d'articles n'expliquent pas. C'est le propriétaire du processus php, pas du processus nginx. Si vous essayez de changer le propriétaire de nginx, cela ne résoudra pas le problème.

Pour le résoudre, essayez d'exécuter ps auxpour voir quel utilisateur possède le processus php-fpm. Vérifiez ensuite que l'utilisateur est le même utilisateur que le propriétaire du dossier wordpress, ou qu'il peut au moins y écrire. Si l'utilisateur ne peut pas y écrire, vous devrez modifier les autorisations et / ou la propriété du dossier; ou mettez les deux utilisateurs (propriétaire du serveur et propriétaire du dossier wordpress) dans un groupe commun qui peut écrire dans le dossier; ou remplacez la propriété "user" de php.ini par un utilisateur qui peut écrire dans le dossier.

Mahemoff
la source
1

Il y a beaucoup de réponses similaires à cette question, mais aucune d'entre elles n'aborde complètement la cause profonde. Le commentaire de Sebastian Schmid sur le message original y touche mais pas complètement. Voici ma prise en date du 06/11/2018:

Cause première

Lorsque vous essayez de télécharger un plugin via l'interface d'administration de WordPress, WordPress appellera une fonction appelée "get_filesystem_method ()" (ref: /wp-admin/includes/file.php:1549 ). Cette routine tentera d'écrire un fichier à l'emplacement en question (dans ce cas le répertoire du plugin). Il peut bien sûr échouer ici immédiatement si les autorisations de fichier ne sont pas correctement configurées pour permettre à l'utilisateur WordPress (pensez à l'identité de l'utilisateur exécutant le php) d'écrire le fichier à l'emplacement en question.

Si le fichier peut être créé, cette fonction détecte alors le propriétaire du fichier temporaire, ainsi que le propriétaire du fichier actuel de la fonction (réf: /wp-admin/includes/file.php:1572 ) et compare les deux. S'ils correspondent alors, selon les termes de WordPress, "WordPress crée des fichiers avec le même propriétaire que les fichiers WordPress, cela signifie qu'il est sûr de modifier et de créer de nouveaux fichiers via PHP" et votre plugin est téléchargé avec succès sans l'invite des informations d'identification FTP. S'ils ne correspondent pas, vous obtenez l'invite des informations d'identification FTP.

Corrections

  1. Assurez-vous que le répertoire du plugin est accessible en écriture par l'identité exécutant votre processus php.
  2. Assurez-vous que l'identité qui exécute votre processus php est le propriétaire du fichier pour:

    a) Tous les fichiers d'application WordPress, ou ...
    b) Au minimum le fichier /wp-admin/includes/file.php

Commentaires finaux

Je ne suis pas trop enclin à appliquer spécifiquement la propriété des fichiers au file.php pour contourner ce problème (cela me semble un peu piraté pour dire le moins!). Il me semble à ce stade que la base de code WordPress tend à nous faire exécuter le processus PHP sous le même principal utilisateur que le propriétaire du fichier pour les fichiers d'application WordPress. Je serais heureux de recevoir des commentaires de la communauté à ce sujet.

Matt Woodward
la source
1

J'étais confronté au même problème! J'ai ajouté le code ci-dessous dans le fichier wp-config.php (dans n'importe quelle ligne) et cela fonctionne maintenant!

define('FS_METHOD', 'direct');
erovere
la source