architecture - CMS 暂存环境的架构

Question

我的公司开发了一个 cms，但现在我们使用它一段时间后，我们偶然发现了一个问题：所有的变化都与现场环境直接相关。如果您想对站点进行大修，有时您希望先完成所有工作，然后一次将所有更改发布到实时站点。

我现在谈论的是内容，而不是用于开发软件的开发/测试/登台/生产环境

我已经看到了几种解决问题的方法，但没有一个可以完全解决这个问题：

1. 使用版本控制：版本 x 在生产中运行，y 在暂存；
2. 使用草稿/发布标志：所有草稿内容都远离实时站点；
3. 使用两个数据库：一个用于暂存环境，一个用于实时环境。

他们都有问题：

1. 版本控制对于新创建的页面（生产时版本为空？）和页面站点地图的更改（我们为此使用嵌套集）是有问题的；
2. 对于草稿，无法创建已发布页面的第二个版本；
3. 使用第二个数据库，您必须复制/同步您不希望在两个地方之间有所不同的所有数据：用户、用户组、权限等。

还有其他选择吗？最好您想在用户杠杆上执行此操作，以便用户 A 可以开始大修，而用户 B 仍然能够发布新内容。但也许现在这太难了，我们现在只需要解决第一个问题。

PS。它是一个带有 MySQL 后端的 php、ZF 应用程序，但这对于我认为的架构来说并不重要。

Answer 1

还有另一种策略，即拥有一个单独的内容管理存储库，内容从该存储库发布到不同的内容交付环境。（所以 3 个数据库而不是两个。）

这是 SDL Tridion 使用的架构，我根据自己的经验知道它非常有效。我确信还有其他 WCMS 系统可以像这样工作，尽管唯一立即浮现在脑海中的是 Bricolage。

Answer 2

这样做的方法是使用相对链接或根据站点配置文件中的值向链接添加前缀。

Answer 3

已经很长时间了，但我们现在有一个多阶段 CMS，其工作方式如下。生产树和分期树是双重的。在嵌套集设置中，我们可以在一个数据库中存储多棵树。生产中的页面使用 UUID 链接到登台。

内容本身通过版本控制进行管理，其中版本控制表保存所有版本，实体表保存生产版本。版本控制是（用于暂存），因此比生产版本提前了一些步骤。通过这种方式，我们还可以为文本 blob 实现自动保存（这只是另一个版本）。