单向DB迁移工作流

Question

我喜欢下面所示的建议的WordPress工作流。然而，由于我是WordPress新手，我想知道它有多现实。

数据库向下移动，代码向上移动

这个想法在WPEngine支持WordPress文章和另一篇名为“不再有牛仔编码”的文章中都有介绍。这样的想法是，像"WP迁移DB“这样的工具用于将生产数据库拉到开发环境中，但事实并非如此。

问题？

我关心的是我在开发环境中添加的插件，这些插件可能会对DB结构进行更改。事实上，WPEngine还有另一篇文章指出：

有时，您对开发实例所做的更改涉及代码和数据库更改。在这些特定的情况下，您仍然可以部署代码更改“up”。但是，您还需要下载希望使用特定表格的导出导入到生产环境中的phpMyAdmin。最常见的情况是，您希望具体地导出wp_options表以及特定于您在开发中所做的更改的任何其他表。您添加了添加数据库表的插件吗？

我想了解一个第三方安装/激活的插件通常会产生(结构性) DB变化吗？如果有50%的插件有这种行为，那么这个工作流几乎是无用的。如果只有1%的插件有这种行为，那么我并不担心。

有人有这种感觉吗？

再一次，我试图评估这个工作流有多现实。我也想知道其他人是如何处理(罕见的？)当插件确实修改数据库的时候。

为了澄清，我不期望我将开发任何我自己的插件或主题。我只希望在我的本地开发环境中集成第三方插件和主题，然后我会将其推向阶段或直接投入生产。

Answer 1

我想了解一个第三方安装/激活的插件通常会产生(结构性) DB变化吗？

无时无刻不在修复非bug版本。无论插件做什么，很少有特性不需要一些设置。

解决这个问题的一种方法是尽量减少插件的使用。另一种方法是“拦截”插件的请求，从DB获取配置并在代码中覆盖它。如果对于示例插件将相关值存储在一个选项中，则可以使用pre_option_{option_name}过滤器。

您可能需要添加一些插件版本检查，以在生产和开发之间返回不同版本的数据。

澄清一下，我不希望开发我自己的插件或主题。

嗯，打电话给第三方并不是不能完全控制它所做的事情的借口，因为最终你将需要解决在你的网站上发生的任何错误。只使用提供足够钩子的插件，这样您就不必与它们一起运行到DB同步问题。