优化页面发布选项-做的和不做的

页面发布是CMS最基本的特性。这就是我们的内容对世界可见的原因。Episerver CMS(现在称为Optimizely Content Cloud)也有这个特性和一些更灵活的构建，以帮助我们的内容作者。有一个常见的页面发布，你点击一个按钮，它就在那里。此外，还可以安排页面发布，使其在未来的特定时间向世界开放，而不需要人工干预。

有点技术，页面发布的工作方式-有一个StartPublish属性。当我们点击Publish时，这是现在设置的日期，当浏览器试图呈现页面时，这是Optimizely内部查看的属性，以查看页面是否已经发布。

在安排要发布的页面时，作者通常选择未来的日期时间，并将其存储在DelayPublishUntil属性的页面内容类型。此时，对于一个全新的页面，StartPublish为空。所以现在我们等待。

”发布延迟内容版本"预定作业

EPiServer有一个内建的计划作业，称为“发布延迟内容版本，默认情况下每小时运行一次。该作业所做的是查看设置了DelayPublishUntil日期的内容，如果有任何内容具有过去的日期且尚未发布，则该作业将发布该内容。在这样做的过程中，它基本上复制了DelayPublishUntil日期到StartPublish属性。由于它是在过去，现在当用户浏览页面时，他们看到的是一个已发布的页面。

这一切都很好，按预期工作。这两种选择都有明确的最终结果。

然而，我最近遇到了一种情况，我发现我们的内容作者实际上一直在玩弄页面上的Published属性，以便将来安排它。一开始，我不明白，但后来我深入研究了一下。Published属性本质上是StartPublish日期。当你调整这个时，你改变了页面的StartPublish日期。如果这是一个全新的页面，我将发布日期设置为未来的某个日期，然后点击发布，它会为未来的发布安排页面。只是这一次，我不需要等待作业来实际发布页面。一旦将来的StartPublish日期到来，它就会出现。

这是一个启示．

我问自己为什么我们不用这个来安排出版?为什么我们需要等待一份工作来做这件事?好吧，我必须找到答案，所以我多做了一些疑难解答。

我选择了一个我刚刚发布的页面，并将其发布日期修改为未来5分钟。当我在CMS数据库下看tblWorkContent对于这个页面，它实际上并没有修改现有页面的StartPublish日期。相反，它创建了页面的新版本，并获得了修改后的StartPublish日期值。从技术上讲，这是正确的行为。每当您编辑现有页面时，它都会创建一个新版本。

现在我继续点击在这个页面上发布，然后在网站上浏览这个页面。你觉得我看到了什么?

我有一个404错误代替。从技术上讲，这意味着我正在尝试浏览的页面不存在或不可用。

但是我的页面已经发布了，到底发生了什么?

当我编辑一个页面并创建新版本并点击发布时，这就是我浏览时获取的版本。如上所述，在尝试渲染时，Optimizely会查看StartPublish日期。但是现在在这个版本中，我的StartPublish日期是未来5分钟。因此，它将其视为未发布的页面，因此出现404。

如果我使用Schedule to Publish选项做同样的事情，并将新版本设置为5分钟后发布，我的页面仍然可以浏览。为什么?因为现在当创建新版本时，它从以前的版本复制了现有的StartPublish日期，并将DelayPublishUntil日期设置为未来5分钟。现在，该作业将在时机成熟时处理发布并更新StartPublish。在此之前，终端用户仍然可以浏览原始版本。

我从这个练习中学到了什么?

不要直接打乱StartPublish日期。它可能会产生意想不到的影响。相反，使用专用的Schedule特性来优雅地处理发布，并且在浏览时不会影响现有页面。

希望这能有所帮助!