CMS的登台环境架构

Question

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

我现在谈的是内容，而不是开发软件的开发/测试/舞台/制作环境

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

1. 使用版本控制：版本x在生产时运行，y在生产阶段;
2. 使用草稿/发布标记：所有草稿内容远离实际网站;
3. 使用两个数据库：一个用于登台环境，一个用于实时。

所有这些都有问题：

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

还有其他选择吗？您希望在用户控制杆上执行此操作，因此用户A可以开始大修，用户B仍然可以发布新内容。但也许现在这太难了，我们现在必须解决第一个问题。

PS。它是一个带有MySQL后端的php，ZF应用程序，但这对我认为的架构无关紧要。

Answer 1

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

这是SDL Tridion使用的架构，我从自己的经验中知道它非常有效。我确信还有其他WCMS系统可以像这样工作，尽管唯一让人想到的就是Bricolage。

Answer 2

执行此操作的方法是使用相对链接或根据站点配置文件中的值为链接添加前缀。

Answer 3

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

内容本身通过版本控制进行管理，其中版本控制表包含所有版本，实体表包含生产版本。版本控制（用于分段）因此在生产版本之前的一些步骤。这样我们也可以为文本blob实现自动保存（它只是另一个版本）。