Deployment 使用Capistrano部署时如何升级Wordpress和插件？

我希望有人能确认以下场景是否是WordPress站点部署更新的问题，如果是，您是否有解决方案来最好地管理此问题

基本要素：

• 我有一个本地开发WordPress多站点项目 使用GIT和Capistrano部署到远程暂存和生产 服务器
• 除了uploads和blogs.dir目录之外的所有内容（在 wp内容）受版本控制。是的，WordPress核心， 主题、插件等在本地更新、提交、推送和删除 部署。这意味着我必须登录并激活插件 最初-它们只需通过Capistrano deploy安装即可
• 关于开发、分期和生产的数据库各不相同，而且 我不担心尝试同步这些

我关注的是：

许多插件更新和WordPress内核在通过管理员进行自动更新时也会执行数据库更新。我正在我的开发安装中本地更新WordPress核心和插件。这些更新的代码最终被提交、推送和部署。但是，在部署代码时，它只是向临时服务器和生产服务器添加/删除/替换更改的文件。生产和暂存缺少对数据库的任何更新，因为这通常是自动更新过程的一部分-例如，停用、更新、激活（运行对数据库的任何更新）

我的问题是:

我关心的是生产和暂存服务器是否具有 最新代码，但缺少最新版本所需的任何数据库更新 代码准确吗

如果是这样的话，有人对我如何修改Capistrano有什么想法吗 是否部署代码以停用/重新激活插件？变化呢 在WordPress中，例如3.2到3.3

如果Capistrano不是这方面的工具，我需要做得更多 通过登录管理员“手动”-是否存在维护模式 工具/插件，可在一定程度上自动停用/激活 那么激活后是否会触发任何更新

非常感谢,

---

Matt

需要注意的是，在将WordPress core从一个版本升级到另一个版本时，不需要激活和停用插件。不过，根据插件的不同，他们中的一些人可能在升级过程中内置了一个升级过程——即插件的升级，而不是WordPress的升级。尽管如此，我还是会仔细检查你的三个问题，并尽可能直接地回答它们

1。我所担心的生产和暂存服务器是否具有最新代码，但缺少最新代码所需的任何数据库更新？

是的，在更新时，如果数据库模式发生更改，则WordPress将无法正常工作，除非新模式存在。当尝试访问WordPress的管理员端时，如果db版本低于WordPress版本的预期值，它会将您重定向到数据库升级页面

WordPress在文件中设置一个名为

$wp_db_version

的全局文件，并维护每个迁移脚本，以将数据库从以前的每个版本增量升级到下一个版本，直到版本号最新。以下是常见问题解答中的一个简单列表，显示了修订号与版本号之间的关联

2。如果是这样的话，有人对我如何修改Capistrano部署代码以停用/重新激活插件有什么想法吗？

正如我上面所说的，在核心升级之后，你通常不需要激活/停用插件，除非我认为插件特别要求你这样做。如果WordPress中的模式更改破坏了一个插件，那么插件开发人员将需要发布一个新版本。当升级该插件时，它将被关闭并重新启动，开发者有责任确保所有需要发生的事情都是如此

但是，您可能需要在部署的环境（如您的环境）中分别停用/激活，因为实际的升级过程发生在不同的计算机上，因此可能与最终使用它的数据库不同

也许最好的办法是让你的部署脚本在WordPress中点击一个插件的URI，一个你将要编写的用来停用/激活插件的插件，或者一个已经这样做的现有插件

一些现有的插件可能会处理部分您需要的内容，但我认为您问题的关键部分是自动化，避免登录到每个环境并升级每个环境的插件，因此自己开发一个完全满足您需要的插件可能是一条路。如果您使用WordPress已经提供的工具，开发插件是可能的

• （也许）

浏览整个文件，看看有什么有用的。另外，在管理员端签出实际处理插件的代码-只是为了看看它是如何完成的。您可能想停止<代码> DeActuaTyPuxin < /COD>钩子从插件配置中清除插件，然后清除插件，因此在禁用插件时考虑传递<代码> $默默无闻< /代码>为<代码>真< /代码>。 为了让这个过程变得更加流畅，您可能需要抓取

get_选项（“active_plugins”）

来查看哪些插件已经被激活，并且只在这些插件上运行脚本（确保插件将自己从过程中排除）

3。WordPress的变化情况如何，例如3.2到3.3？

从3.2到3.3的更改应该被认为与任何其他更改集没有区别，因此这里所说的一切都适用

4。如果Capistrano不是这方面的工具——我需要更多地“手动”登录到管理员——是否有一个维护模式工具/插件可以自动停用/激活p