我最近遇到一个问题，因为我没有“手动安装”或“一键安装”选项，所以无法安装WP Smush Pro插件。
我碰到了这篇文章，建议调整中的设置wp-config.php。我添加了建议的设置，但是似乎最重要的设置是：
define('FS_METHOD', 'direct');
我想知道什么是真正的问题应我身边有设置FS_METHOD到direct？安装插件还有其他选择吗？
这是官方文档必须说的：
FS_METHOD强制使用文件系统方法。它只能是“ direct”，“ ssh2”，“ ftpext”或“ ftpsockets”。通常，只有在遇到更新问题时才应更改此设置。如果您更改了它但无济于事，请将其更改回/删除。在大多数情况下，如果自动选择的方法无效，则将其设置为“ ftpsockets”即可。
（主要首选项）“直接”强制它使用PHP内部的直接文件I / O请求，这会给配置不良的主机带来安全性问题，这在适当时会自动选择。
Answers:
这就是我如何理解WordPress File API的想法。如果不对，请投下反对票:)
好的。如果您上传文件，则该文件具有所有者。如果使用FTP上传文件，则登录后，该文件将归FTP用户所有。由于您具有凭据，因此可以通过FTP更改这些文件。所有者通常可以执行，删除，更改等文件。当然，您可以通过更改文件权限来更改此权限。
如果使用PHP上传文件，则执行PHP的Linux用户将拥有该文件。现在，该用户可以编辑，删除，执行等文件。只要您是在系统上执行PHP的用户，就可以。
假设您位于“配置不佳”的共享主机上。很多人在此系统上运行他们的PHP网站。可以说只有一个Linux用户正在为所有这些人执行PHP。此共享主机上的一位网站站长有恶意。他看到您的页面，并且找出了您的WordPress安装路径。例如，将WP_DEBUG设置为true，并且出现错误消息，例如
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1“哈！” 这个坏男孩说。让我们看看，如果这个人已经设置FS_METHOD为，direct并且他编写了一个脚本，例如
<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>因为只有一个用户正在运行PHP，并且这个坏男孩也使用了该用户，所以如果您已通过PHP上传了文件，并且该用户附加了所有者，则他可以更改/删除/执行系统上的文件。
您的网站已被黑。
或者，如法典中所述：
许多托管系统使Web服务器以与WordPress文件所有者不同的用户身份运行。在这种情况下，从网络服务器用户写入文件的过程将使结果文件归网络服务器用户帐户所有，而不是实际用户帐户所有。在多个主机共享同一网站服务器以用于不同站点的共享主机情况下，这可能导致安全问题。
在配置不佳的共享主机上，每个客户的PHP将以同一用户身份执行（让我们apache讨论）。这种设置非常常见。
如果您在这样的主机上，并且使用WordPress通过直接文件访问来安装插件，则所有插件文件都将属于apache。同一服务器上的合法用户可以通过编写PHP脚本向您的插件文件注入恶意代码，从而攻击您。他们将脚本上传到自己的网站并请求其URL。您的代码已成功泄露，因为它们的脚本运行为apache，即拥有您的插件文件的脚本。
FS_METHOD 'direct'有什么关系呢？当WordPress需要安装文件（例如插件）时，它使用get_filesystem_method（）函数来确定如何访问文件系统。如果未定义FS_METHOD，它将为您选择一个默认值，否则，只要合理就将使用您的选择。
默认行为将尝试检测您是否处于上述危险环境中，如果它认为您安全，则将使用该'direct'方法。在这种情况下，WordPress将直接通过PHP创建文件，从而使它们属于apache用户（在此示例中）。否则，它将退回到一种更安全的方法，例如提示您输入SFTP凭据并在您创建文件时创建文件。
FS_METHOD = 'direct'要求WordPress绕过该风险检测，并始终使用该'direct'方法创建文件。
FS_METHOD = 'direct'呢？不幸的是，WordPress用于检测高风险环境的逻辑存在缺陷，并且会产生假阳性和假阴性。哎呀 该测试包括创建一个文件，并确保该文件与其所在目录属于同一所有者。假设是，如果用户相同，则PHP将作为您自己的帐户运行，并且可以安全地将插件安装为该帐户。如果它们不同，则WordPress会假定PHP以共享帐户运行，因此不安全地以该帐户安装插件。不幸的是，这两个假设都是有根据的猜测，通常是错误的。
您将define('FS_METHOD', 'direct' );在这种错误肯定的情况下使用这种情况：您是一个受信任的团队的成员，该团队的成员都通过自己的帐户上传文件。PHP以其自己的独立用户身份运行。WordPress将假定这是一个有风险的环境，并且不会默认为'direct'mode。实际上，它仅与您信任的用户共享，因此这种'direct'模式是安全的。在这种情况下，您应该使用define('FS_METHOD', 'direct' );强制WordPress直接写入文件的方法。
在“配置合理”的情况下，“直接”将导致问题。
还可以与非共享的PHP执行用户配置共享的WP托管，与文件/目录所有权用户不同。因此，您最终得到了user1拥有的文件，并且PHP代码以php-user1的身份执行。
在这种情况下，被黑的插件或核心代码（a）无法写入（甚至根据权限从其读取）其他用户的目录；（b）无法写入此用户的文件，因此无法将木马代码添加到核心代码或插件代码中。
因此，如果像这样设置主机，则必须使用FTP进行更新，而“直接”将不起作用。
如果您在wp-config.php中设置“ direct”并且PHP执行用户没有写许可权，那么您将收到Update Failed消息，并且没有弹出窗口询问FTP凭据。