WordPress 要求我的 FTP 证书来安装插件

我在本地系统中安装了一个 WordPress 博客。但是当我试图从管理员添加插件时,它会要求 FTP 访问。我需要为 WordPress 配置什么才能在没有 FTP 的情况下上传?

149349 次浏览

尝试在 wp-config. php 中添加代码:

define('FS_METHOD', 'direct');

在 OSX 上,我使用了以下方法,而且很有效:

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

_ www 是 PHP 在 Mac 上运行的用户。

(您可能还需要 chmod 一些文件夹。我一开始就这么做了,但是没有解决问题。直到我执行 chown 命令,它才开始工作,所以我不确定这是 chown 命令本身,还是 chmod 和 chown 的组合。)

正如 Niels 提到的,这是因为服务器进程用户无法写入 Wordpress 文件夹。

但有件事很多文章都没有解释清楚。它是 php 进程的所有者,而不是 nginx 进程。如果您尝试更改 nginx 所有者,它不会解决这个问题。

要解决这个问题,请尝试运行 ps aux来查看哪个用户拥有 php-fpm 进程。然后检查用户是否与 wordpress 文件夹的所有者是同一个用户,或者至少可以写入该文件夹。如果用户无法写入,你需要更改权限和/或文件夹的所有权; 或者将两个用户(服务器所有者和 wordpress 文件夹所有者)放在一个可以写入文件夹的公共组中; 或者将 php.ini“ user”属性更改为一个可以写入文件夹的用户。

如果你正在使用 Ubuntu。

sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER

”每当您使用 WordPress 控制面板自动安装、升级或删除插件时,WordPress 必须对文件系统中的文件进行更改。

在进行任何更改之前,WordPress 首先检查是否可以直接操作文件系统。

如果 WordPress 没有直接修改文件系统的必要权限,你将被要求提供 FTP 凭证,这样 WordPress 就可以尝试通过 FTP 做它需要做的事情。”

解决方案: 为了找出 apache 实例的运行用户,创建一个测试脚本,其内容如下:

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

对我来说,它是 daemon 而不是 www-data:

sudo chown -R daemon /path/to/your/local/www/folder

首先移动到安装文件夹(例如)

cd /Applications/XAMPP/xamppfiles/

现在我们要修改 htdocs 目录:

sudo chown -R daemon htdocs

在提示时输入 root 密码,然后通过 chmod 调用完成输入:

sudo chmod -R g+w htdocs

我递归地将 wordpress 文件夹的所有权更改为 www-data 并重新启动 apache。

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

真是太有效了!

解决此问题的最简单方法是将以下 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 是 WordPress 安装的“ base”(ABSPATH)文件夹的完整路径 FTP _ CONTENT _ DIR 是 WordPress 安装的 wp-content 文件夹的完整路径。 FTP _ PLUGIN _ DIR 是 WordPress 安装插件文件夹的完整路径。

我们有同样的问题,作为一个更大的问题的一部分

define('FS_METHOD', 'direct');

隐藏了那个窗口,但是我们在加载主题和升级等方面仍然存在问题。它与权限有关,但是在我们的案例中,我们通过从 操作系统供应商 mod _ php移动到更安全的 操作系统供应商 FastCGI 应用程序来解决这个问题。

我在 Ubuntu 14.04上本地安装了 WordPress,按照 给你的步骤简单运行:

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

解决了我下载插件的问题。我离开这个帖子的唯一原因是因为当我在谷歌上搜索我的问题时,这是最初的结果之一,它引导我找到了解决问题的方法。

希望这个能对大家有所帮助!

对于这个问题有很多类似的回答,但是没有一个完全触及根本原因。塞巴斯蒂安 · 施密德的对原帖的评论涉及到了这一点,但并非完全如此。以下是我对2018-11-06年度的看法:

根本原因

当你试图通过 WordPress 管理界面上传插件时,WordPress 会调用一个名为“ get _ filessystem _ method ()”的函数(参考文献: /wp-admin/include/file.php: 1549)。这个例程将尝试将一个文件写入有问题的位置(在本例中是插件目录)。当然,如果没有正确设置文件权限,允许 WordPress 用户(想想正在执行 php 的用户身份)将文件写入相关位置,那么这里就会立即失败。

如果可以创建文件,那么该函数将检测临时文件的文件所有者,以及该函数当前文件的文件所有者(参考文献: /wp-admin/include/file.php: 1572) ,并对两者进行比较。如果它们匹配,用 WordPress 的话说,“ WordPress 创建的文件与 WordPress 文件的所有者相同,这意味着通过 PHP 修改和创建新文件是安全的”,你的插件在没有 FTP 凭证提示的情况下成功上传。如果它们不匹配,您将获得 FTP 凭据提示。

解决问题

  1. 确保运行 php 进程的标识可以写入插件目录。
  2. 确保运行 php 进程的标识是以下两种情况的文件所有者:

    A)所有 WordPress 应用程序文件,或者..。
    B)至少/wp-admin/include/file.php 文件

最终评论

我并不是特别热衷于将文件所有权应用到 file.php 来解决这个问题(至少可以说,这样做感觉有点怪怪的!).在我看来,WordPress 的代码基础倾向于让我们在与 WordPress 应用程序文件的文件所有者相同的用户主体下执行 PHP 进程。我欢迎社会各界就此提出意见。

我也面临着同样的问题! 我已经将下面的代码添加到 wp-config.php 文件中(在任何行中) ,现在它正在工作!

define('FS_METHOD', 'direct');

如果在安装插件时,Wordpress 询问你的主机名或 FTP 详细信息。 然后按照以下步骤:

登录到服务器并导航到 /var/www/html/wordpress/。 打开 wp-config.php 并在 Definition (‘ DB _ COLLATE’)后添加这一行

define('FS_METHOD', 'direct');

如果你得到“无法创建目录”错误。递归给你的 wordpress 目录写权限为

chmod -R go+w wordpress

注意: 为了安全起见,安装插件时应撤销这些权限

chmod -R go-w wordpress
define('FS_METHOD', 'direct');

将其添加到 wp-config. php

如果问题仍然存在,您可以尝试将插件文件夹的权限设置为755 或者在 linux 中,您可以通过这个命令来设置它

Chmod -R 755

对我来说,能够在我的本地主机上使用 Ubuntu 的解决方案是: (当然你必须用你的用户代替 myUser,如果你不知道的话,whoami会为你显示出来)

  • 包括我自己在 www-data 组(能够访问和编辑没有 sudo 的文件) :

    sudo usermod -aG www-data myUser
    
  • 把我自己和这个小组设置为文件所有者:

    sudo chown -R myUser:www-data /var/www/html
    
  • 为组设置一个主要权限(组也必须写入) :

    sudo find . -type f -exec chmod 664 {} \;
    sudo find . -type d -exec chmod 775 {} \;
    
  • 然后在 config.php 上添加这一行

    define('FS_METHOD', 'direct');
    

改变文件的所有权只有在我退出我的 wordpress 网站并再次登录后 但是才起作用。我还重新启动了 Apache 服务器,但这可能没有必要。