Ответы:
Попробуйте добавить код в wp-config.php:
define('FS_METHOD', 'direct');
FS_METHOD
это сокращение от FILESYSTEM_METHOD
. Когда вы определяете direct
изменение файлов - иначе говоря, без использования FTP, тогда вы заставляете WordPress пытаться напрямую изменять файлы на сайте.
Если вы используете Ubuntu.
sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
www-data
см. Здесь: codex.wordpress.org/Harpting_WordPress или здесь: stackoverflow.com/questions/18352682/…
«Каждый раз, когда вы используете панель управления WordPress для автоматической установки, обновления или удаления плагинов, WordPress должен вносить изменения в файлы в файловой системе.
Прежде чем вносить какие-либо изменения, WordPress сначала проверяет, есть ли у него доступ для прямого управления файловой системой.
Если WordPress не имеет необходимых разрешений для прямого изменения файловой системы, вам будет предложено ввести учетные данные FTP, чтобы WordPress мог попытаться сделать то, что ему нужно, через FTP ».
Решение: чтобы узнать, от имени какого пользователя работает ваш экземпляр apache, создайте тестовый сценарий со следующим содержимым:
<?php echo(exec("whoami")); ?>
Для меня это был демон, а не www-данные. Затем исправьте разрешение:
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 и перезапустил apache.
sudo chown -R www-data:www-data <folderpath>
Оно работало завораживающе!
С первого обращения в Google :
WordPress запрашивает ваши учетные данные FTP, когда не может получить доступ к файлам напрямую. Обычно это вызвано тем, что PHP работает от имени пользователя apache (mod_php или CGI), а не пользователя, которому принадлежат ваши файлы WordPress.
Это довольно нормально для большинства сред виртуального хостинга - файлы хранятся от имени пользователя, а Apache запускается от имени пользователя apache
или httpd
. На самом деле это хорошая мера безопасности, поэтому эксплойты и взломы не могут изменять размещенные файлы. Вы можете обойти это, установив для всех файлов WP значение безопасности 777, но это означает отсутствие безопасности, поэтому я настоятельно рекомендую этого не делать . Просто используйте FTP, это автоматический обходной путь, на который есть веские причины.
Если во время установки плагина 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
Сначала перейдите в папку установки (например)
cd /Applications/XAMPP/xamppfiles/
Теперь мы собираемся изменить ваш каталог htdocs:
sudo chown -R daemon htdocs
При появлении запроса введите пароль root, а затем завершите его вызовом chmod:
sudo chmod -R g+w htdocs
Я произвел локальную установку WordPress на Ubuntu 14.04, выполнив описанные здесь шаги, и просто запустил:
sudo chown -R www-data:www-data {path_to_your_project_directory}
решил мою проблему с загрузкой плагинов. Единственная причина, по которой я оставляю этот пост здесь, состоит в том, что когда я поискал в Google свою проблему, это был один из первых результатов, и он привел меня к решению моей проблемы.
Надеюсь, это поможет кому угодно!
У нас была та же проблема как часть более крупной проблемы. Предлагаемое решение
define('FS_METHOD', 'direct');
скрывает это окно, но тогда у нас все еще были проблемы с загрузкой тем, обновлений и т. д. Это связано с разрешениями, однако в нашем случае мы исправили проблему, перейдя от php OS vendor mod_php к более безопасному приложению FastCGI поставщика php OS .
Самый простой способ решить эту проблему - добавить следующую информацию 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-content установки WordPress. FTP_PLUGIN_DIR - это полный путь к папке плагинов в установке WordPress.
Как упоминал Нильс, это происходит потому, что пользователь серверного процесса не может писать в папку Wordpress.
Но вот что не объясняют многие статьи. Это владелец процесса php, а не процесса nginx. Если вы попытаетесь сменить владельца nginx, это не решит.
Чтобы решить эту проблему, попробуйте запустить, ps aux
чтобы узнать, какой пользователь владеет процессом php-fpm. Затем убедитесь, что пользователь является тем же пользователем, что и владелец папки wordpress, или, по крайней мере, может писать в нее. Если пользователь не может писать в нее, вам необходимо изменить права доступа и / или владельца папки; или объедините двух пользователей (владельца сервера и владельца папки wordpress) в общую группу, которая может писать в папку; или измените свойство php.ini "user" на пользователя, который может писать в папку.
На этот вопрос есть много похожих ответов, но ни один из них полностью не затрагивает первопричину. Комментарий Себастьяна Шмида к исходному посту затрагивает его, но не полностью. Вот мое мнение по состоянию на 06.11.2018:
Основная причина
Когда вы пытаетесь загрузить плагин через интерфейс администратора 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. Если они не совпадают, вы получите запрос учетных данных FTP.
Исправления
Убедитесь, что идентификатор, на котором запущен ваш php-процесс, является владельцем файла для:
а) Все файлы приложений WordPress или ...
б) По крайней мере, файл /wp-admin/includes/file.php
Заключительные комментарии
Я не особо заинтересован в применении права собственности на файл к file.php, чтобы обойти эту проблему (это, по меньшей мере, кажется хакерским!). На данный момент мне кажется, что кодовая база WordPress склоняется к тому, чтобы мы выполняли процесс PHP под тем же пользователем, что и владелец файла для файлов приложения WordPress. Я хотел бы получить комментарии от сообщества по этому поводу.