如何解決小網站內容管理問題

文章篇幅較長，慎入

隨着網絡應用的豐富和發展，網站每每不能迅速跟進大量信息衍生及業務模式變革的腳步，經常須要花費許多時間、人力和物力來處理信息更新和維護工做。 ——引自「百科」

小公司、小網站因人員、技術問題，在內容管理處理上處於「食之無味棄之惋惜」的一種狀況：內容維護會常常打亂開發人員節奏，可是又沒有精力去思考投入統一去解決相似問題。

有哪些運營內容須要維護

開始以前，咱們先看下小網站通常會存在哪些內容須要維護配置：

• 頁面靜態內容，通常用於導流或者介紹：如輪播圖，特點、功能、產品介紹等；
• 全站統一內容：如導航、友情連接等；
• 站點新聞公告：包含列表、詳情；
• 其餘相似的靜態文檔，用來展現或者介紹公司相關：如幫助、關於咱們等；
• 其他無業務功能邏輯，須要人工維護的內容

現狀

遇到這些內容維護，好的小公司可能會一開始就同步創建一個配置發佈管理功能，其餘的可能由於工期趕就代碼寫死，經過發佈解決，發佈頻繁了纔去作配置發佈管理功能。

• 頁面代碼寫死，調整即發佈 抓狂
• 每類內容都配套「配置發佈管理功能」，須要處理如下內容
  • 抽象數據，建立表
  • 前端開發相關管理頁面，包含「列表」、「新增編輯」、「表單」功能
• 由於是後臺管理頁面，通常狀況這個配置頁面都比較簡單，甚至缺乏校驗，只能人肉在線查看效果來決定是否配置正確

---

做爲一個有追求的攻城獅，這樣的重複性工做應該主動拒絕，經過工具或者流程去改善生活

CMS是什麼

在很早之前，內容管理就成爲一個重要的應用領域，而且伴隨着時間、技術的推移，CMS的功能也變得愈來愈強大。

CMS簡單來講就是內容管理系統（Content Management System），主要解決用戶網站建設與信息發佈中常見的問題和需求，運營同窗能夠經過它進行網站內容新增、修改、審覈發佈，提升信息發佈效率和準確性；其技術核心思想是分離內容的管理和設計。

業界CMS系統

篇幅緣由，這裏並不想去對比和介紹業界相關的系統，只是想大概介紹下相關類型

• 傳統CMS系統
  • 簡單的小至相似上面提到的「配置發佈管理功能」，如公告發布模塊
• 可視化建站，如
  • 雲鳳蝶：能夠基於組件可視化搭建頁面，站點託管在雲鳳蝶提供的服務。
  • 阿里內部CMS系統：也是基於組件可視化搭建頁面，天貓、淘寶成千上萬的活動頁面都是基於此運營本身選擇相關組件搭建並投放的；不對外

從小公司的訴求和運營的專業水平來看，相似雲鳳蝶這樣的基於組件化搭建頁面的CMS平臺，其操做成本高，另外組件開發、維護成本也很高，小公司也很難有業務發展需求，能夠沉澱出本身的組件模塊。因此除非一開始就不打算投入網站服務建設，只是簡單得搭個網站門面，纔會使用相似可視化建站服務。

下面的篇幅咱們仍是以實現「傳統CMS系統」爲目標，去考慮如何作得更好

訴求

那麼小網站對內容管理又有哪些訴求呢？

• 有一套通用解決方案能夠爲任意運營內容快速生成「配置發佈管理頁面」
• 表單頁面強化校驗，增長體驗
• 儘量保證內容填寫的正確性，避免線上出現問題
• 統一的數據獲取API，避免重複開發

• 上篇文章提到的jsonschema-form-vue - 自動生成表單庫，就能快速生成體驗一致的表單；
• 經過抽象將內容表設計成一套統一結構，一方面避免每種配置都建表，另外一方面也容易提供統一API；
• 關於正確性保障，能夠經過 預覽 -> 審覈發佈流程 提早保障；

不過雖然保證了內容配置管理，可是文章一開始提到的「新聞公共」、「幫助」、「關於咱們」這些內容類似、字段一致的頁面，難道每次都要建立相似的配置管理，而後在web應用建立相關頁面，再發布應用嗎？

• 須要提供一套頁面模板機制，經過複製頁面模板，快速複製同類型頁面以及跟它關聯的內容配置；經過這種關聯關係，應用只要經過路由pageId去查詢頁面相關的內容，便可避免發佈

目標

基於訴求，先明確解決小網站內容管理須要完成的目標

• 內容管理：減小內容運營成本
  • 減小內容的維護成本
  • 減小應用發佈成本
• 經過配置化自動生成「配置表單」，減小開發投入成本
  • jsonschema-form-vue
  • 可基於頁面模板快速複製、新增頁面
• 保證發佈質量、體驗
  • 支持預覽、審覈發佈、回滾
  • 支持可視化編輯
• 成本小
  • 能容易和現有系統結合
  • 考慮投入產出比

分層關係和表設計

經過內容，對數據模型進行抽象，主要分紅如下三層：

組件

最底層組件，它包含了基於 jsonschema-form-vue的表單相關配置，可使用版本管理，讓配置升級更安全。

{
    id: Schema.Types.ObjectId,
    name: String, // 配置名稱
    version: String, // 版本號
    jsonSchema: String, // JSONSchema
    definition: String, // Form Definition
    histories: Array, // 歷史記錄
    author: String, // 用戶
    createdAt: Date, // 建立時間
    modifiedAt: Date // 修改時間
}
複製代碼

模塊

模塊是運營內容編輯單元，基於組件表單配置去生成表單，能夠保存草稿和發佈數據，用於預覽和線上內容

{
    id: Schema.Types.ObjectId,
    name: String, // 模塊名稱
    title: String, // 模塊標題
    siteId: Schema.Types.ObjectId, // 所屬站點ID
    pageId: Schema.Types.ObjectId, // 頁面ID
    componentId: Schema.Types.ObjectId, // 組件ID
    componentVersion: String, // 組件版本號
    model: {}, // 配置數據
    draft: {}, // 配置草稿
    status: Number, // 狀態 0: 配置更新, 1: 內容更新, 2: 發佈審覈
    online: Boolean,
    histories: Array, // 歷史記錄
    author: String, // 用戶
    createdAt: Date, // 建立時間
    modifiedAt: Date // 修改時間
}
複製代碼

爲何不把表單配置直接放模塊，而是增長組件這一層？ 這主要是由於模塊和組件是「多對一」的關係，一個表單配置可能會被用到多個模塊；另外上面提到的類似頁面，會複製出類似模塊，若是將表單配置放在模塊表中，會存在重複數據，後續也很難同步配置升級

頁面

頁面就是瀏覽器中看到頁面，主要用來保存模塊的關聯關係，一個頁面可能存在多個獨立模塊

{
    id: Schema.Types.ObjectId,
    name: String, // 頁面名稱
    url: String, // 頁面url
    realUrl: String, // 頁面實際url
    useRoute: Boolean, // 是否啓用路由規則
    router: String, // 路由規則
    siteId: Schema.Types.ObjectId, // 所屬站點ID
    modules: String, // 模塊
    owner: String, // 用戶
    createdAt: Date, // 建立時間
    modifiedAt: Date // 修改時間
}
複製代碼

爲何有url又有實際url？這主要考慮後面的「可視化編輯」功能，須要去請求真實頁面，因此在頁面複製發佈時，須要基於「頁面路由」生成實際url

由於數據模型的核心是配置和內容，因此選用了文檔型數據庫MongoDB

總體設計

抽象了數據模型，先經過設計看下CMS須要提供哪些功能

設計上，CMS遵循如下幾點原則：

• 對現有web應用侵入性、影響最小，方便接入
• 操做簡單，儘可能設計簡單，功能明確
• CMS只提供數據服務，不容許用戶流量直接進入，致使須要跟web應用同步擴容

因此：

• 提供組件、模塊、頁面管理功能；
• 提供API讓接入方能夠方便獲取數據，可是接入方須要對數據進行緩存，減少對CMS服務的壓力；
• 支持獲取草稿數據，讓web應用支持預覽功能；
• 提供可視化編輯功能，頁面編輯能夠可視化預覽編輯線上頁面，實時查看效果，方面查找模塊；

Web應用接入只要改動如下幾點：

• 若是以前沒有數據、結構分離，要先分離，數據源替換成CMS數據；
• 線上數據要進行緩存，減小CMS服務壓力；在服務啓動時讀取CMS內容數據，進行緩存；
• 提供方法讓Controller能夠獲取CMS數據；
• 可選擇支持預覽功能，如定義url規則?preview=true則實時請求CMS草稿數據；
• 提供緩存更新API，在CMS內容審覈發佈更新時，能更新緩存，不用重啓應用；
• 可選擇接入「可視化編輯腳本」，在使用CMS數據的html模塊進行moduleId標識

流程

經過流程能夠更清楚瞭解CMS的功能

1. 建立組件配置 前端在本地開發完靜態頁面後，先mock內容，完成數據模板分離；而後能夠藉助JSON2JSONSchema工具快速生成JSONSchema結構，根據 jsonschema-form-vue文檔，生成組件配置

2. 建立內容模塊，引用相應的組件配置（內容模塊纔是運營內容維護單元）；若是有初始數據，能夠幫運營填入；複製moduleId到web應用中調用相應方法獲取CMS數據；而後，發佈web應用後，開發的工做就完成了，之後的內容維護都交由運營同窗。

3. 運營同窗維護模塊內容，有兩種方式： 3.1 經過模塊名查找模塊進行編輯 3.2 經過頁面編輯進行可視化編輯，見下面

4. 內容編輯確認無誤後，進行保存預覽

5. 預覽確認沒有問題後，審覈發佈，內容上線

到這裏，CMS最基本的功能已經完成了；不再用由於文案內容改動，須要進行應用發佈重啓了

MORE

接下來的篇幅最後介紹「頁面複製」和「可視化編輯」功能

關於頁面複製

上文提到的新聞公告、關於咱們，或者一些風格相似的活動頁面，須要提供快捷複製建立新頁面，而後修改頁面內容便可。

主要思考以下：

• 模塊纔是內容編輯單元，頁面維護着模塊映射關係，複製頁面的同時複製相應模塊，並更新對應的映射關係便可；
• 提供經過pageId獲取數據接口，這樣相似頁面能夠經過路由規則params或query來獲取對應頁面數據渲染；

可視化編輯

最後必須來點看起來科技感滿滿的功能來個收尾，以提供該CMS系統的檔次，直接跟前沿接軌。

在具有了模塊編輯功能後，可視化編輯就是如何獲取編輯的數據並實時渲染頁面預覽，同時預覽頁面可識別可編輯模塊，並表現出本身能被編輯，引發運營點擊修改的慾望：

• 關於實時預覽 上文咱們已經提到預覽功能，實時預覽問題不攻而破
• 關於可編輯模塊 要想識別模塊並編輯，必須在HTML Template上標識上moduleId，而後經過規則識別在CMS系統中引入「可視化編輯.js」，CMS在編輯時經過iframe引入線上頁面，作如下事情：
  • 識別頁面可編輯模塊，在上面遮上一層編輯DIV，表現出可編輯樣子
  • 點擊編輯DIV時，iframe通訊，告知CMS編輯模塊，彈出模塊配置
  • 編輯保存後，更新iframe時間戳，從新請求頁面，獲取新數據

就這樣，立刻提供一個檔次

到這裏，文章就結束了，在工做過程當中，多去發現工做流程中，重複性的、本身不喜歡去處理但又不得不去處理的活兒，去思考如何經過工具、流程化去處理它們；讓事情變得簡單、可複製；這個思考和實現的過程，不只能提高你的設計和技術能力，同時也能增長公司對你的依賴性，走向升職加薪的路上。