Wordpress demandant mes identifiants FTP pour installer des plugins
J'ai installé un blog Wordpress sur mon système local. Mais lorsque j'essaie d'ajouter des plugins à partir de l'administrateur, il demande un accès FTP. Que dois-je configurer pour que Wordpress puisse télécharger sans FTP?
Essayez d'ajouter le code dans wp-config.php:
define('FS_METHOD', 'direct');
Si vous utilisez Ubuntu.
Sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
"Chaque fois que vous utilisez le panneau de configuration de WordPress pour installer, mettre à niveau ou supprimer automatiquement des plug-ins, WordPress doit modifier les fichiers du système de fichiers.
Avant d’apporter des modifications, WordPress vérifie d’abord s’il a ou non le droit de manipuler directement le système de fichiers.
Si WordPress ne dispose pas des autorisations nécessaires pour modifier directement le système de fichiers, des informations d'identification FTP vous seront demandées afin que WordPress puisse essayer de faire ce qu'il faut via FTP. "
Solution: Pour savoir quel utilisateur votre instance d’Apache est en cours d’exécution, créez un script de test avec le contenu suivant:
<?php echo(exec("whoami")); ?>
Pour moi, c'était un démon et non www-data. Ensuite, corrigez la permission en:
Sudo chown -R daemon /path/to/your/local/www/folder
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 PHP sous Mac.
(Vous aurez peut-être aussi besoin de modifier certains dossiers. Je l'avais déjà fait et cela n'a pas été résolu. Ce n'est que lorsque j'ai exécuté la commande chown que cela a fonctionné. seul, ou une combinaison de chmod et chown.)
J'ai changé la propriété du dossier wordpress en www-data récursivement et j'ai redémarré Apache.
Sudo chown -R www-data:www-data <folderpath>
Ça a marché comme sur des roulettes!
Dès le premier coup sur Google :
WordPress demande vos informations d'identification FTP lorsqu'il ne peut pas accéder aux fichiers directement. Cela est généralement dû à l'exécution de PHP en tant qu'utilisateur Apache (mod_php ou CGI) plutôt que l'utilisateur qui possède vos fichiers WordPress.
Ceci est plutôt normal dans la plupart des environnements d'hébergement partagé - les fichiers sont stockés en tant qu'utilisateur et Apache est exécuté en tant qu'utilisateur Apache ou httpd. C’est en fait une bonne mesure de sécurité pour empêcher les exploits et les hacks de modifier les fichiers hébergés. Vous pouvez contourner ce problème en définissant tous les fichiers WP sur la sécurité 777, mais cela signifie une sécurité no; Il suffit d’utiliser FTP, c’est la solution de contournement automatiquement recommandée avec une bonne raison.
D'abord, déplacez-vous dans 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 avec un appel chmod:
Sudo chmod -R g+w htdocs
J'ai fait une installation locale de WordPress sur Ubuntu 14.04 en suivant les étapes décrites ici et tout simplement en cours d'exécution:
Sudo chown -R www-data:www-data {path_to_your_project_directory}
résolu mon problème avec le téléchargement de plugins. La seule raison pour laquelle je laisse ce post ici, c'est parce que lorsque j'ai cherché mon numéro sur Google, c'était l'un des premiers résultats et cela m'a amené à la solution de mon problème.
J'espère que celui-ci aide n'importe qui!
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 avions toujours des problèmes de chargement de thèmes et de mises à niveau, etc. Cela est lié aux autorisations, mais dans notre cas, nous avons résolu le problème en passant de fournisseur du système d’exploitation php mod_php au fournisseur plus sécurisé php du système d’exploitation FastCGI. application .
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 du dossier "base" (ABSPATH) de l'installation WordPress FTP_CONTENT_DIR est le chemin complet du dossier wp-content de l'installation WordPress . FTP_PLUGIN_DIR est le chemin d'accès complet au dossier des plugins de l'installation WordPress.
Comme mentionné par Niels, cela se produit car l'utilisateur du processus serveur ne peut pas écrire dans le dossier Wordpress.
Mais voici la chose que beaucoup d'articles n'expliquent pas. C'est le propriétaire du processus php, pas le 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 aux pour voir quel utilisateur est propriétaire du processus php-fpm. Vérifiez ensuite que cet utilisateur est le même que le propriétaire du dossier wordpress, ou 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 placez les deux utilisateurs (propriétaire du serveur et propriétaire du dossier wordpress) dans un groupe commun pouvant écrire dans le dossier; ou changez la propriété php.ini "utilisateur" en un utilisateur pouvant écrire dans le dossier.
Il y a beaucoup de réponses similaires à cette question, mais aucune d'entre elles ne traite vraiment de la cause fondamentale. Sebastian Schmid / commentaire sur le message original touche mais pas complètement. Voici mon point de vue du 2018-11-06:
Cause première
Lorsque vous essayez de charger un plugin via l'interface d'administration de WordPress, WordPress appelle la fonction "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). Cela peut bien sûr échouer ici immédiatement si les autorisations de fichier ne sont pas configurées correctement pour permettre à l'utilisateur WordPress (pensez à l'identité de l'utilisateur exécutant 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 (ref: /wp-admin/includes/file.php:1572 ) et compare les deux. S'ils correspondent, comme le dit WordPress, "WordPress crée des fichiers ayant le même propriétaire que les fichiers WordPress, cela signifie que vous pouvez modifier et créer de nouveaux fichiers via PHP en toute sécurité" et que votre plug-in est chargé avec succès sans l'invite d'informations d'identification FTP. S'ils ne correspondent pas, vous obtenez l'invite d'informations d'identification FTP.
Corrections
- Assurez-vous que le répertoire du plugin est accessible en écriture par l'identité exécutant votre processus php.
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) À tout le moins, le fichier /wp-admin/includes/file.php
Commentaires finaux
Je ne suis pas très enthousiaste à l'idée d'appliquer spécifiquement la propriété de fichier à file.php pour résoudre ce problème (c'est un peu hacky, c'est le moins qu'on puisse dire!). Il me semble à ce stade que la base de code WordPress tend à nous faire exécuter le processus PHP sous le même principe d'utilisateur que le propriétaire du fichier pour les fichiers de l'application WordPress. Je souhaiterais recevoir des commentaires de la communauté à ce sujet.
Je faisais face au même problème! J'ai ajouté le code ci-dessous dans le fichier wp-config.php (quelle que soit la ligne) et tout fonctionne maintenant!
define('FS_METHOD', 'direct');