Відповіді:
Спробуйте додати код у 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)
whoami
sudo 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. Я вітаю деякі коментарі з цього приводу громади.