Keystone 6 中的內容版本控制

Question

在之前的 Keystone 4 項目中，我能夠使用內容版本控制。 也就是說，如果我要更新內容實體（例如 BlogPost），我將有可能在博文的前一版本和當前版本之間切換。

我在 Keystone 6 的文檔中看不到這方面的任何選項，而且我也發現很難在網上找到關於這個主題的任何資源。 有人對此有任何見解嗎？ 如果不可能開箱即用 - 您對如何手動完成它有什么建議嗎？

提前致謝

Answer 1

內容版本控制是 Keystone 團隊在內部討論過很多的東西，但這是一個相當復雜的領域。 有很多不同的方法來解決這個問題，即使是在單個項目中進行版本控制時也是如此。 如果您將關系引入其中並跨多個項目進行版本控制，問題空間會迅速擴大。

如果確實構建了第一方解決方案，它可能會構建在 Keystone“之上”——類似於@keystone-6/auth package——即，一個單獨的、可配置的 package，它使用記錄的 Keystone API 來添加功能。 無論如何，就目前而言，版本控制和發布工作流程是您需要自己設計和構建的。

我的建議是首先明確您需要版本化的內容和不需要的版本。 需要考慮的事項：

• 您需要對整個項目進行版本控制還是只需要對幾個字段進行版本控制？
• 您是否需要更改歷史記錄，或者擁有一個“已發布”版本和一個可選的可編輯“草稿”版本就足夠了嗎？
• 您需要“還原”更改，還是“僅更新”model 就足夠了？
• 你關心相關項目嗎？ （例如，假設您的博客帖子與Tags列表相關，編輯標簽是否構成帖子的新“版本”，或者是版本化部分的“外部”？）
• 合作呢？ 會有多人同時嘗試編輯一篇文章/草稿嗎？
• 你可以有多個草稿版本還是只有一個？
• 您是否需要考慮預覽更改或（更糟糕的）更改集？
• 您是否需要某種集成的批准工作流程，或者任何創建內容的人都可以發布/恢復它嗎？

spring 記住的一些基本方法：

草稿/發布字段

對於諸如博客文章之類的相對簡單的內容，您也許能夠在字段級別的項目中實施草稿/發布工作流。 是這樣的：

  Post: list({
    fields: {
      slug: text({ validation: { isRequired: true }, isIndexed: 'unique' }),
      publishedTitle: text({ validation: { isRequired: true } }),
      publishedBody: document({ /* ... */ }),
      draftTitle: text({ validation: { isRequired: true } }),
      draftBody: document({ /* ... */ }),
    },
    // access, hooks, etc.
  }),

您的前端僅顯示已published...字段，但您將后端限制為僅允許編輯draft...字段（您甚至可以從管理 UI 隱藏已發布的字段）。 可以添加掛鈎或自定義突變以通過在字段之間復制來“促進”草稿內容發布。 通過正確的訪問控制，您甚至可以設置前端以使用神奇的 URL 參數或其他東西預覽草稿內容。

它非常基本，但易於設置和使用。

每個版本的項目

一個更強大的替代方案是用單獨的項目表示版本，並使用一個字段來跟蹤哪個版本是當前發布的內容：

  Post: list({
    fields: {
      slug: text({ validation: { isRequired: true }, isIndexed: true }),
      title: text({ validation: { isRequired: true } }),
      body: document({ /* ... */ }),
      isPublished: checkbox(),
    },
    // access, hooks, etc.
  }),

在這種情況下， slug字段在列表中不是唯一的——每個帖子可以有多個項目，代表即將到來的草稿或歷史版本。 發布帖子的一個版本時（通過將isPublished設置為 true），掛鈎確保具有相同 slug 的任何項目都將isPublished標志設置為 false。 前端簡單地通過isPublished過濾以獲取當前版本（如果需要，通過訪問控制強制執行）。 這使您既可以發布更新又可以回滾到任何以前的版本。 它還在某種程度上解決了關系——例如。 如果您有一個相關的Tags列表，與Posts多對多鏈接，則對帖子標簽的更新與內容一起進行版本控制。

為了使工作流程順暢，擁有一個復制現有帖子的自定義突變可能會很有用，這樣您就可以輕松地對現有內容進行更改。 也許還有一個自定義的管理 UI 頁面，以幫助可視化帖子歷史記錄和管理恢復操作等。

---

這些只是兩個例子，但還有許多其他方法可以解決這個問題。 只要清楚你的要求，然后做最簡單的事情：:)