WordPress 和 UNIX 权限问题怎么回事?

WordPress 和 UNIX 权限问题怎么回事?

我正在设置几个 wordpress 安装,经常遇到权限问题。我怀疑主要问题是我不是共享托管环境,只是一个普通的 Ubuntu VM,因此 Ubuntu 上的默认设置不是 WP 所期望的。问题示例:

  1. 升级失败,因为 apache 对 wp 安装没有写入权限
  2. 主题和其他上传失败,因为新建的文件夹具有错误的组成员身份或权限
  3. 无法创建目录 wordpress/wp-content/grade

到目前为止,我不得不修改 apache 的默认 umask 以修复 2,修改 setgroupid 位以修复 1,现在我正在研究 3。我猜这不应该这么难。我是否遗漏了一些明显的配置设置?

我设置了一个 wordpress 安装,每个类别都有一个用户,以限制附带损害,同时允许团队合作和修补,因此 chmod 777 和其他鸵鸟政策方法比现状更糟糕。

答案1

对于升级,我将所有文件/目录的权限都移交给运行 Web 服务器的用户,进行升级,然后将其移回 root。升级不再是点击操作,但在我看来,这个价格是值得的。Web 服务器用户可写的 PHP 文件让我感到畏缩。wp-content 下的一些目录可能需要始终由运行 Web 服务器的用户可写。

或者,您可以不进行在线升级,而是让 Ubuntu 更新系统处理升级,假设您最初使用它来安装 WP。

http://codex.wordpress.org/Changing_File_Permissions说:

注意:对于插件/主题的自动升级/安装和 WordPress 升级,无需设置特殊权限。所有 WordPress 文件都应归您的用户帐户所有,您不必将其设置为全球可写 (777)。如果您尝试更改文件的所有权/权限以允许升级程序运行,则很有可能出现与所选权限方案不正确相关的错误/问题。

对于核心 WordPress 文件,所有文件都应该只有您的用户帐户可写入。

那是错的。如果 Web 服务器用户无法写入核心文件,升级如何替换核心文件?如果无法写入目录,如何添加新文件?

答案2

不幸的是,它或多或少应该是这么难。

LAMP 无限灵活性的代价是其无限的排列组合以及随之而来的不可避免的退步和熵。不同的人使用不同的发行版,使用这些发行版中的不同软件包,遵循不同的指南/操作方法/博客文章,使用不同的目录,使用不同的功能和插件。再加上每个组件的版本控制差异,您就会遇到这种情况:实际上几乎没有两个 wordpress 博客的配置是相同的。

您的选择是
- 自己动手,根据具体情况处理每件小事
- 遵守共享主机设置的预配置决定(即使在您自己的 vps 上)
- 支付专业服务费用,例如 wpengine.com
- 支付系统管理员费用来处理所有事情

相关内容