我正在更新现有的wordpress网站，对主题和网站结构进行重大修改，并对插件进行更新，然后插件将数据存储到mysql中数据库中。
据我所知，这里有2（3？）种可能的策略：
虽然我在自己独立的环境中开发，但这是针对现有网站，该网站目前正在进行并将继续接收公众的更新，例如评论和条目到联系表单，因此我希望数据库现在与当我发布我的更改时。
鉴于此，上述选项提供了以下问题。
1。转储和负载
“转储和加载”策略似乎不可能，因为我的数据正在幕后更新（这可能是我首选的方法，因为这很容易回滚）。
结果：要求在发布后同步数据库以获取最新更新，TOO COMPLICATED。
2。使用进口商
使用WP-Importer plugin页面和帖子ID将会更新，搞砸依赖帖子ID的样式来激活。这反过来会产生一个我想避免的CSS噩梦，不得不在发布后通过CSS 来更新数据库创建的新页面/帖子ID。
结果：过于挑剔，不是非常专业的方法导致漫长而复杂的发布过程。
第3。手动更新数据库
此选项适用于较小的更改，但是对于更复杂的版本，PROD界面上要遵循的步骤列表变得冗长且难以遵循，从而容易出错。
结果：太容易搞砸，只是万不得已。
是否存在标准的WORDPRESS发布现有网站的策略？
基本上，我的问题是：在更新现有网站时，其他wordpress开发人员会遵循哪些发布流程？是否有一个我未在下面列出的选项可以最大限度地减少麻烦并减少发布期间的时间和复杂性？
我已经使用GIT设置了网站的源代码控制，我习惯通过ANT或类似的发布脚本自动化这些东西，这可能对当前项目来说太过分了，但至少知道一个简单的方法是理想的更新一个wordpress网站，并尽量减少搞砸它的机会。
谢谢！
答案 0 :(得分：2)
我认为这不是WordPress特有的，它与任何自定义网站的情况类似。我个人赞成重放在dev上生成的SQL更改。棘手的部分是你必须知道做了哪些SQL更改。例如，某个插件在安装时可能会进行一些架构更改 - 您需要知道它们是什么。您可以通过在安装插件之前创建数据库导出为SQL，然后再执行另一次导出并对文件执行差异来实现。
既然你说你正在进行修改，那么我可能会假设你知道你要做什么SQL更改？只需确保您对数据库所做的所有更改都采用SQL脚本文件的形式，而不仅仅是使用GUI进行编辑（您可以使用GUI来帮助编写查询，但保存实际的SQL）。完成所有更改后，您应该在开发过程中运行一堆SQL脚本 - 您可以按顺序重新运行它们而不会遇到错误。
然后，当需要推向生产时，创建一个暂存版本的生产（即生产的相当当前的数据库备份）。在其上运行更新脚本并测试一切正常。如果是，那么你可以继续生产。
在对其进行任何更改之前，一定要备份生产！
答案 1 :(得分：2)
毋庸置疑，您还有其他一些选择。如果您手动进行数据库更改，请确保您正在有效地处理序列化数据。我建议使用Search and Replace DB。对于changing the site url entirely from the wp-config file，WordPress也有一个很棒的小技巧。
答案 2 :(得分：1)
我假设您在测试环境中运行了所有内容。我会：
这样可以最大限度地减少停机时间。