不，没有比这更方便的方法了。

问题是，您的第一个示例在最常见的托管系统上是不安全的，因为该目录将由运行Web服务器本身的任何用户“拥有”。因此，任何其他能够在同一Web服务器上执行代码的人都可以访问、写入、更改其中的文件，等等。

必须提供凭据，以确保文件由正确的人拥有，防止同一服务器上的其他人访问这些文件。

其他信息，因为评论似乎需要它：

在“标准”共享托管配置上，甚至在某些VPS托管系统上，Web服务器运行的用户与实际拥有文件的用户不同。因此，我的WordPress安装文件可能属于“otto”，但Web服务器可能在“apache”帐户下运行。

这意味着当WordPress代码运行时，它通常以“apache”用户的身份运行。它创建的任何文件也将归“apache”所有，而不是归“otto”所有。此外，“apache”帐户必然受到限制。它可能根本没有能力在我的web目录中写入文件，也可能没有能力将文件更改为正确的“otto”用户所拥有。这都是出于安全原因，它不应该具有这些能力。

WP\\u文件系统检测到这种情况，然后将向用户显示一个表单，请求FTP凭据。这就是request_filesystem_credentials 调用实际上是这样做的：它执行该测试，然后在必要时为用户生成一个表单。用户输入他们的信息，并在下次提交时使用这些信息request_filesystem_credentials 呼叫可以检查它是否可以通过FTP连接回自身（环回，sorta）。

请看，当我通过FTP创建文件时，我以我的身份连接，因此生成的文件归“otto”所有。使用这种机制，WP\\u文件系统可以以正确的用户身份创建文件，即使它是以“apache”运行的。因此，这些凭据是必要的，是的，您必须向用户索取这些凭据。简单地使用普通PHP方法创建文件和目录可能会导致安全问题，尤其是在共享主机上。

在共享主机上，其他人在同一台计算机上拥有帐户。他们使用相同的Web服务器进程运行代码。该代码也以“apache”的形式运行。因此，如果我有“apache”拥有的目录和文件，那么其他人可以将其代码作为“apache”运行并修改我的文件。这是个问题。文件归我所有而不是“apache”可以防止这种情况的发生。

现在，在一些最常见的共享主机系统上，您会发现request_filesystem_credentials call实际上不会弹出表单。相反，它只返回true，WP\\u文件系统代码继续运行。当主机系统使用称为“setuid”或“suphp”的配置运行时，就会发生这种情况。

在setuid配置中，webserver以“apache”或其他任何形式运行，但它为处理请求而生成的PHP进程将其自己的用户/所有者设置为与最初运行的PHP文件的所有者相同。因此，当php进程运行并加载初始WordPress索引时。php文件（或任何文件），它会看到该文件由“otto”所有，因此它会将自己的用户帐户设置为“otto”，用于特定的运行。

许多共享主机提供商都会进行这种配置，因为在这种情况下，它实际上更安全。如果php进程作为用户帐户运行，那么它就不再是“apache”，无法访问其他人帐户中的文件。它只能访问其应有访问权限的帐户的文件。作为一个很好的副作用，这意味着request_filesystem_credentials 调用执行其测试并发现a）是的，它可以写入文件；b）这些文件将由正确的用户拥有，因为进程的用户现在设置为与文件的所有者相同。在这种情况下，使用“直接”模式，request_filesystem_credentials 返回true，并且不会向用户显示FTP凭据的表单。

请注意，像这样的setuid方法在非共享托管帐户上实际上不太安全。当只有一个web用户时，就不需要使用setuid来保护同一服务器上的其他web用户。因此，在VPS托管和类似的情况下，这种设置并不常见，需要FTP凭据是很常见的。这更安全，因为即使攻击者可以使系统执行代码，他们也可能无法让代码修改任何文件，因为它没有以正确的进程运行。

安全性很复杂。WP\\u文件系统从根本上来说是一个安全问题，如果需要在安装过程中操作文件，应该使用它。是的，有时这意味着您需要显示凭证表单。我建议您应对它，因为其他任何东西都是潜在的安全风险，您不应该仅仅因为它有点令人不快就将其消除。