Відповіді:
Спробуйте додати код у wp-config.php:
define('FS_METHOD', 'direct');
FS_METHODце короткий FILESYSTEM_METHOD. Коли ви визначаєте direct-ly змінити файли - він же не використовує FTP, ви змушуєте WordPress спробувати безпосередньо змінити файли на сайті.
Якщо ви використовуєте Ubuntu.
sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
www-dataпобачити тут: codex.wordpress.org/Hardening_WordPress або тут: stackoverflow.com/questions/18352682 / ...
"Кожного разу, коли ви використовуєте панель управління WordPress для автоматичного встановлення, оновлення або видалення плагінів, WordPress повинен вносити зміни до файлів у файловій системі.
Перш ніж вносити будь-які зміни, WordPress спочатку перевіряє, чи має він доступ до прямого маніпулювання файловою системою чи ні.
Якщо WordPress не має необхідних дозволів безпосередньо змінювати файлову систему, вам буде запропоновано FTP-дані, щоб WordPress намагався робити все, що потрібно через FTP. "
Рішення. Для того, щоб дізнатися, яким користувачем працює ваш екземпляр apache, створіть тестовий сценарій із наступним вмістом:
<?php echo(exec("whoami")); ?>
Для мене це був демон, а не www-data. Потім виправте дозвіл:
sudo chown -R daemon /path/to/your/local/www/folder
<?php echo(exec("id")); ?>яке навіть надасть вам групові дані за межами ідентифікатора користувача:uid=5018(web27) gid=5012(client7) groups=5012(client7),5002(sshusers)
whoamisudo chown -R `whoami` /path/to/your/local/www/folder
На OSX я використовував наступне, і він працював:
sudo chown -R _www:_www {path to wordpress folder}
_www - це користувач, під яким працює PHP на Mac.
(Можливо, вам також знадобиться chmod деякі папки. Я зробив це спочатку, і це не виправити. Це було, поки я не виконав команду chown, що вона спрацювала, тому я не впевнений, чи це команда chown поодинці або поєднанням chmod і chown.)
Я змінив право власності на папку wordpress на www-data рекурсивно та перезапустив апаш.
sudo chown -R www-data:www-data <folderpath>
Це спрацювало як шарм!
Від першого звернення в Google :
WordPress запитує ваші облікові дані FTP, коли він не може отримати доступ до файлів безпосередньо. Зазвичай це викликано PHP, що працює як користувач apache (mod_php або CGI), а не користувач, який володіє вашими файлами WordPress.
Це досить нормально в більшості спільних хостинг-середовищ - файли зберігаються як користувач, а Apache працює як користувач apacheабо httpd. Це насправді хороша запобіжна безпека, тому експлуатація та хаки не можуть змінювати розміщені файли. Ви можете це обійти, встановивши всі файли WP на безпеку 777, але це означає відсутність безпеки, тому я б дуже радив цього. Просто використовуйте FTP, це автоматично радиться рішення з вагомих причин.
Спочатку перейдіть у вашу інсталяційну папку (наприклад)
cd /Applications/XAMPP/xamppfiles/
Тепер ми будемо змінювати ваш каталог htdocs:
sudo chown -R daemon htdocs
Коли з’явиться запит, введіть свій кореневий пароль, а потім закінчіть його chmod call:
sudo chmod -R g+w htdocs
Я зробив локальну установку WordPress на Ubuntu 14.04, дотримуючись наведених тут кроків та просто запустивши:
sudo chown -R www-data:www-data {path_to_your_project_directory}
вирішив мою проблему із завантаженням плагінів. Єдиною причиною, коли я залишаю цю посаду тут, є те, що коли я переглянув свою проблему, це був один із перших результатів, і це призвело до вирішення моєї проблеми.
Сподіваюся, що цей допомагає комусь!
У нас була така ж проблема, як частина більшої проблеми. Пропоноване рішення
define('FS_METHOD', 'direct');
приховує це вікно, але тоді у нас все ще виникли проблеми з завантаженням тем та оновленнями тощо. Це пов'язано з дозволами, проте в нашому випадку ми вирішили цю проблему, перейшовши від постачальника php OS mod_php до більш безпечного додатка FastCGI постачальника php .
Якщо під час встановлення плагіна Wordpress запитує ваше ім’я хоста або FTP. Потім виконайте наступні дії:
Увійдіть на свій сервер і перейдіть до / var / www / html / wordpress / . Відкрийте wp-config.php і додайте цей рядок після визначення ("DB_COLLATE")
define('FS_METHOD', 'direct');
Якщо ви отримаєте помилку "Не вдалося створити каталог". Дайте дозволи на запис в каталог Wordpress в рекурсивному вигляді
chmod -R go+w wordpress
ПРИМІТКА. Для безпеки скасуйте ці дозволи після встановлення плагіна як
chmod -R go-w wordpress
Найпростіший спосіб вирішити цю проблему - додати в свою інформацію наступну інформацію про FTP 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 - це повний шлях до папки "базовий" (ABSPATH) інсталяції WordPress FTP_CONTENT_DIR - це повний шлях до папки wp-вмісту установки WordPress. FTP_PLUGIN_DIR - це повний шлях до папки плагінів установки WordPress.
Як зазначає Niels, це відбувається тому, що користувач серверного процесу не може записатись у папку Wordpress.
Але ось багато статей не пояснюють. Це власник процесу php, а не процес nginx. Якщо ви спробуєте змінити власника nginx, це не вирішить.
Щоб вирішити це, спробуйте запустити, ps auxщоб побачити, якому користувачеві належить процес php-fpm. Потім перевірте, чи користувач той самий користувач, як власник папки wordpress, чи може принаймні написати до нього. Якщо користувач не може записати на нього, вам потрібно буде змінити дозволи та / або право власності на папку; або розмістити двох користувачів (власника сервера та власника папки Wordpress) у загальній групі, яка може записувати у папку; або змінити властивість php.ini "user" на користувача, який може записати в папку.
На це питання є багато подібних відповідей, але жодна з них повністю не торкається першопричини. Коментар Себастьяна Шміда до оригінальної публікації стосується цього, але не повністю. Ось мій підсумок станом на 2018-11-06:
Першопричина
Коли ви намагаєтеся завантажити плагін через адміністраторський інтерфейс WordPress, WordPress здійснить виклик до функції під назвою "get_filesystem_method ()" (ref: /wp-admin/includes/file.php:1549 ). Ця програма буде намагатися записати файл у відповідне місце (у цьому випадку каталог плагінів). Звичайно, тут може негайно вийти з ладу, якщо дозволи файлів не налаштовані правильно, щоб дозволити користувачеві WordPress (думаю, що ідентифікатор користувача, що виконує php), записати файл у вказане місце.
Якщо файл можна створити, ця функція визначає власника файлу тимчасового файлу разом із власником поточного файлу функції (ref: /wp-admin/includes/file.php:1572 ) і порівнює два. Якщо вони відповідають, то, за словами WordPress, "WordPress створює файли того самого власника, що і файли WordPress, це означає, що безпечно змінювати та створювати нові файли через PHP", і ваш плагін успішно завантажується без запиту FTP Credentials. Якщо вони не збігаються, ви отримуєте підказку FTP Credentials.
Виправлення
Переконайтеся, що особа, яка виконує ваш процес php, є власником файлу:
a) Усі файли програм WordPress або ...
b) принаймні файл /wp-admin/includes/file.php
Заключні коментарі
Я не надто зацікавлений у тому, щоб спеціально застосувати право власності на файл до file.php, щоб обійти цю проблему (це, мабуть, сказати тад-хакі!). На даний момент мені здається, що база коду WordPress схиляється до того, щоб ми виконували процес PHP під тим же принципом користувача, що і власник файлів для файлів додатків WordPress. Я вітаю деякі коментарі з цього приводу громади.