如何解决小网站内容管理问题

文章篇幅较长，慎入

随着网络应用的丰富和发展，网站每每不能迅速跟进大量信息衍生及业务模式变革的脚步，经常须要花费许多时间、人力和物力来处理信息更新和维护工做。 ——引自「百科」

小公司、小网站因人员、技术问题，在内容管理处理上处于「食之无味弃之惋惜」的一种状况：内容维护会常常打乱开发人员节奏，可是又没有精力去思考投入统一去解决相似问题。

有哪些运营内容须要维护

开始以前，咱们先看下小网站通常会存在哪些内容须要维护配置：

• 页面静态内容，通常用于导流或者介绍：如轮播图，特点、功能、产品介绍等；
• 全站统一内容：如导航、友情连接等；
• 站点新闻公告：包含列表、详情；
• 其余相似的静态文档，用来展现或者介绍公司相关：如帮助、关于咱们等；
• 其他无业务功能逻辑，须要人工维护的内容

现状

遇到这些内容维护，好的小公司可能会一开始就同步创建一个配置发布管理功能，其余的可能由于工期赶就代码写死，经过发布解决，发布频繁了才去作配置发布管理功能。

• 页面代码写死，调整即发布 抓狂
• 每类内容都配套「配置发布管理功能」，须要处理如下内容
  • 抽象数据，建立表
  • 前端开发相关管理页面，包含「列表」、「新增编辑」、「表单」功能
• 由于是后台管理页面，通常状况这个配置页面都比较简单，甚至缺乏校验，只能人肉在线查看效果来决定是否配置正确

---

做为一个有追求的攻城狮，这样的重复性工做应该主动拒绝，经过工具或者流程去改善生活

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时间戳，从新请求页面，获取新数据

就这样，立刻提供一个档次

到这里，文章就结束了，在工做过程当中，多去发现工做流程中，重复性的、本身不喜欢去处理但又不得不去处理的活儿，去思考如何经过工具、流程化去处理它们；让事情变得简单、可复制；这个思考和实现的过程，不只能提高你的设计和技术能力，同时也能增长公司对你的依赖性，走向升职加薪的路上。