Php Wordpress网站发布管理策略

我正在更新一个现有wordpress站点对主题和站点结构进行重大修改，并更新插件，插件将数据存储到mysql数据库中

据我所知，这里有2（3？）种可能的策略：

将MySQL数据库从DEV“转储并加载”到LIVE，并用最新更新替换wp content文件夹

通过WP导入器导入更改，并用最新更新替换WP内容文件夹

通过WP admin界面手动更改数据库，并用最新更新替换WP content文件夹（这仅适用于较小的更改）

虽然我在自己的独立环境中开发，但这是针对一个现有网站的，该网站目前处于活动状态，并将继续收到来自公众的更新，如评论和联系人表单条目，因此我希望数据库现在与我发布更改时有所不同

鉴于此，上述选项会带来以下问题

1。卸载和装载

“转储和加载”策略似乎是不可能的，因为我的数据正在幕后更新（这是我的首选方法，因为它很容易回滚）

结果：发布后需要同步数据库以获取最新更新，太复杂了

2。使用进口商

使用页面和帖子ID将得到更新，破坏依赖帖子ID激活的样式。这反过来又造成了一个我希望避免的CSS噩梦，在发布后必须通过CSS用数据库创建的ID更新新的页面/帖子ID

结果：过于挑剔、不太专业的方法导致了漫长而复杂的发布过程

3。手动更新数据库

此选项适用于较小的更改，但对于更复杂的版本，PROD界面上要遵循的步骤列表变得冗长且难以遵循，因此很容易出错

结果：太容易搞砸，只是万不得已

现有网站是否有标准的WORDPRESS发布策略？

所以基本上，我的问题是：其他wordpress开发人员在更新现有网站时遵循什么发布过程？是否有一个我在下面没有列出的选项可以在发布过程中最大限度地减少麻烦并减少时间和复杂性

我已经使用GIT为站点设置了源代码控制，并且我习惯于通过ANT或类似的发布脚本实现自动化，这对于当前项目来说可能有些过分，但至少应该知道一种简单的方法来更新wordpress站点，并尽可能减少出错的机会

---

谢谢

我不认为这是WordPress所特有的，这与任何自定义站点的情况类似。我个人喜欢在生产环境中重放在dev上所做的SQL更改。棘手的是，您必须知道所做的SQL更改。例如，当您安装某个插件时，它可能会进行一些模式更改—您需要知道它们是什么。您可以在安装插件之前将数据库导出为SQL，然后在安装插件之后进行另一次导出，并对文件进行差异化处理

既然您说您正在进行修改，那么我可以假设您知道您将要进行哪些SQL更改？只需确保对数据库所做的所有更改都是SQL脚本文件的形式，而不仅仅是使用GUI进行编辑（您可以使用GUI帮助编写查询，而是保存实际的SQL）。在完成所有更改之后，您应该拥有一组在开发过程中运行的SQL脚本—您可以按顺序重新运行它们，而不会遇到错误

然后，当需要投入生产时，创建一个生产的暂存版本（即对生产进行相当当前的DB备份）。在上面运行更新脚本并测试一切是否正常。如果是，则可以运行生产

在对产品进行任何更改之前，一定要对其进行备份

• WordFence背后的人正在开发一个名为 .
• 有一个新的叫做
• 讨论过，但Capistrano不是WP的专用产品
• 启动了一项名为

---

不用说，你还有其他选择。如果手动更改数据库，请确保有效地使用序列化数据。我建议使用。WordPress还有一个很好的小技巧。

我想您已经在测试环境中运行了所有东西。我会：

• 在实时环境中创建新数据库
• 将其与新站点的所有内容和配置一起预加载
• 在测试环境中，将config.php配置为指向新数据库
• 将所有文件上载到live server。最后上传config.php

---

这将最大限度地减少停机时间。

我不喜欢Wordpress的另一个原因我敢肯定我已经不止一次地讨论过这一点。想不到，最近他们甚至为Wordpress进行了堆栈交换。这似乎是您的数据在幕后更新的问题。很好的建议，谢谢，如果通过上面的选项3（手动数据库更改）+1对WP_HOME/WP_SITEURL变量进行手动更新，并使用搜索+替换数据库脚本修复序列化数据，将最大限度地减少停机时间。我知道这是一个2012年的答案，但对于搜索和替换任务，很值得查看相对较新的WP cli命令，它非常简单。这方面的一个示例wp cli命令是：

wp search replacehttp://somesite.com https://somesite.com --干运行

——在测试并检查输出后，请删除--dry run。更改前后DEV数据库上的DIFF为+1。好主意。