营销型 CMS
模块、模板、表单组件和SEO面板——足够一个团队在没有开发人员的情况下发布活动页面。
- Plugin Basic Blocks免费
- Templates Manager¥280.80
- Plugin Forms免费
- Grapesjs A11Y Seo — Accessibility auditor + SEO for GrapesJS免费
上面的屏幕是排列的模型,用 CSS 绘制,因此页面成本不高。背后的编辑器引擎是真实且公开的:打开官方 GrapesJS 演示,拖动一个部分到画布上,你看到的内容团队在你自己的 CMS 上会拥有的画布、组件树和样式控制。
演示版运行在 grapesjs.com 浏览器存储上。里面的内容不会被影响。
无头 CMS 为您的应用提供了以 API 为先的内容基础。但它并不总是能让写内容的人在构建页面时看到页面。
结构化字段非常适合文章、产品记录或设置文档。但对于意义在于布局的页面——比如活动页面、专题巡演、价格比较——它们并不适合。对于这些,负责工作的人通常会要求相同的简短清单:
编辑们的需求
GrapesJS 提供那个可视化编辑层,而不必强制你更换 CMS。
无头架构将内容与呈现分开,这正是它为何会留下编辑空白:CMS知道字段,前端知道渲染,中间任何页面都不了解。添加可视化编辑层可以弥合这个空白,而不会拆除任一侧。
传统无头 CMS
缺失
无头 CMS + GrapesJS
添加可视化编辑,同时不放弃无头架构。
因为这三层各自擅长其他两个没有的,而可视化编辑层是唯一没人帮你发布的。编辑到位后,谁拥有什么。
你的无头CMS
你已经运行的内容基础设施。
GrapesJS
你添加的就是可视化编辑图层。
你的前端
没有改变。它保留了之前拥有的一切。
保留架构。升级编辑体验。
可视化编辑体验:画布、组件树、块、样式控制、设备宽度。
通过REST、GraphQL或你自己的API实现持久化。存储适配器有两个功能——一个加载,一个保存。
你现有的内容基础设施。它保留了架构、媒体库、用户和发布规则。
你的前端已经读取了 API 的交付。添加编辑器是增加一个写手,而不是第二个内容来源。
任何消耗你CMS API的前端。
一个内容来源。多个前端。
看看编辑器如何嵌入应用程序编辑层通过你前端调用的同一个API连接。无论你运行的是Strapi、Contentful、Sanity、Directus、Hygraph、Prismic、Payload,还是你团队自己编写的CMS,集成点都是两个端点加载并保存一个文档。
这些平台都可以通过各自的 API 集成,具体实现取决于该 CMS 的内容模型和 API。GJS.Market 并未为其中大多数平台发布官方集成,本页面也不会暗示相反的情况。
保留你的CMS。保留你的前端。添加一个更好的可视化编辑器。
下面的卡片描述了每个平台提供的集成表面,而不是支持声明。其中一个平台在 GJS.Market 目录中有一个社区存储插件;其余的都是你或实现合作伙伴基于其发布的 API 构建的集成。
REST ·GraphQL
自托管,内容类型由你定义。编辑文档通常会成为页面集合类型的 JSON 字段。
REST ·GraphQL
分开交付和管理的APIs。编辑器通过管理的API写入;前端继续读取交付的。
GROQ ·GraphQL
Portable Text 和文档存储。编辑器文档会与你已有的字段并存,而不是替换它们。
REST ·GraphQL
这是本列表中唯一已经在GJS.Market上发布社区存储插件的平台。
查看插件GraphQL
GraphQL优先,所以适配器是一个查询和一个变异,而不是两个URL。
REST
基于切片的内容。当你保持块集与切片对齐时,编辑器块会干净利落地映射到切片上。
REST ·GraphQL
代码定义的集合,因此编辑器写入的字段声明在同一个仓库中。
REST ·GraphQL ·定制
任何能响应加载请求并接受保存请求的设备。两个端点就是整个合同。
目录中唯一一个以CMS命名的适配器
Directus Storage 是一个免费、由社区发布的 GrapesJS 存储插件,源自 Silex 项目。它确实是一个非常有用的参考资料,说明适配器的形状——认证命令、加载、保存——但其自身列表指出它主要针对较旧的 Directus SDK,因此应将其视为阅读起点,而非支持的产品。
Directus Storage可视化编辑器只有在无头系统中生成的内容仍然符合你设计的模式时才有用。在 GrapesJS 中,自定义组件类型声明了它自己的可编辑 traits——而这些 traits 就是你的 CMS 字段名称所在。
实例演练
hero-section
editor.DomComponents.addType('hero-section', {
model: {
defaults: {
// Traits become the fields your CMS entry already has.
traits: [
{ name: 'title', label: 'Title' },
{ name: 'subtitle', label: 'Subtitle' },
{ name: 'image', type: 'image' },
{ name: 'ctaHref', label: 'Button link' },
],
},
},
});可视化编辑器应该适应你的内容模型——而不是强迫你的CMS适应编辑器。
同一个编辑器会有两个表示,它们回答不同的问题。一个可以重新打开进行编辑;另一个可以渲染。大多数制作设备会将两者分别放在不同的列,这更多是设计决策而非规则。
editor.getProjectData()组件树、样式、页面和资源作为结构化数据。这是编辑器重建会话原貌所需的,这是唯一能在第二轮编辑中完整保存的表示。
在以下情况下使用: 有人会在编辑器里再次打开这个页面。
editor.getHtml() + editor.getCss()标记和样式表都从同一树生成。这就是预览版 iframe、静态导出或发布流程所消耗的,且无法可靠地重新导入为编辑会话。
在以下情况下使用: 下游必须有渲染,不需要编辑器。
存储编辑器再次打开时需要的那种表示,再生成前端或发布流程需要的输出。
同一个编辑层,指向产品的不同部分。每个编辑层在GJS.Market上都有自己的页面,因为每个图层在编辑器之后都会提出不同的问题。
让内容团队可视化创建页面,条目仍然存在你已经运行的CMS中。
深入了解可视化编辑让营销团队在没有开发人员参与每次布局变更的情况下启动活动。
着陆页构建器在所有内容保留在CMS和前端的URL中,视觉化地创建页面。
拖放构建器在你的产品中,在内容API之上,给你的客户提供一个可视化编辑器。
SaaS 页面构建器在你的产品中,给每个组织都配备自己的页面、资源和模板,支持一个编辑器。
多租户编辑器围绕品牌定制编辑体验,让编辑能作为产品的一部分阅读。
白标构建器创建使用相同组件模型和邮件安全块集的可重复使用的电子邮件模板。
电子邮件模板构建器编写结构化的可视化文档页面,这些页面仍通过你的API内容发布。
页面预设引擎自带什么,插件添加了什么,以及什么仍是你应用的任务。当你在界定工作范围,而不是单纯看功能列表时,这种区别才是关键。
GrapesJS不发布CMS、主机、用户账户和权限模型。这些都留在你的CMS和你的应用里。
这不是整个产品一次性做出的决定。这是根据内容类型做的决定,大多数团队最终会同时运行两者。
你的CMS本身基于表单的编辑,由模式驱动。
最适合
画布,布置即内容。
最适合
在结构重要的地方使用结构化字段。在布局和构图重要时使用可视化编辑。
编辑和发布是两个独立的事件,无头设置使得执行这一点变得容易:草稿文档和发布文档是不同的行,由不同的标记读取。
该条目已存在于你的CMS中,且处于草稿状态。
有人在画布上构图。
前端会在每个设备宽度处渲染草图。
第二个人会阅读页面,访客会看到。
批准会由你的应用记录,而不是编辑。
你的CMS负责推广草图,前端则重新验证。
人工审核
评审应该能够在不同范围内切换
编辑和发布分开。
这就是你选择无头 CMS 时已经获得的优势,添加可视化编辑器不会消耗这个优势——只要编辑器写的内容保留在内容 API 中,而不是模板中。
无头CMS
一个内容 API,所有频道都能读取
网站
Next.js
移动端
React Native
应用
Nuxt
无头架构允许相同的内容基础设施服务不同的前端。
如果编辑器是产品的一部分,而非内部工具,每个客户组织都需要自己的页面、资源和模板——而且绝不能看到别人的。
你的应用
这种分拆是在服务器上强制执行的
组织A
组织B
组织 C
GrapesJS 本身不支持多租户。租户隔离、每租户品牌和发布规则都是你的应用负责,每次存储调用都必须在服务器端进行范围限制。
如果你的客户使用编辑器,它应该看起来像是你产品的一部分。面板、图标集、块库和模板都可以配置,周围的应用程序提供了编辑器没有的功能。
角色和权限之所以在列表中,是因为品牌编辑器需要它们——而不是因为编辑器提供。它们是由你的后台执行的。
引擎只是整体层面的一个层级。下面是整个阶梯,每个层级都有真实的标签:哪些内容在GrapesJS中发布,哪些可以在GrapesJS上购买或下载,哪些仍属于你自己的作品。
有两个梯级被故意标记为你自己的作品。CMS集成是针对你内容模型的,目录没有权限或审计日志插件——实现合作伙伴可以同时构建两者,但这里没有产品支持。
下面的每个商品都经过实时目录的核对,并发布并可购买。价格是在制作时从市场读取的,所以你看到的就是今天商品所显示的内容。
一个免费、由社区发布的 Directus 存储插件——目录中唯一以 CMS 命名的适配器,同时也是一个可读的模型,方便你自己编写。
当项目文档应该放在托管文档数据库而不是你的CMS时,它就是Cloud Firestore的存储封装器。
浏览器端持久化,作为离线缓冲区或演示,必须运行后才会有任何 API 存在。
自动保存和崩溃恢复。没有它,未保存会话在标签关闭时就消失了,你的编辑会被责怪。
五个起始套装,均来自相同的经过验证的商品列表。它们都不是一键购买的捆绑包——而是针对每种产品不断出现的组合。
模块、模板、表单组件和SEO面板——足够一个团队在没有开发人员的情况下发布活动页面。
多页项目、托管存储、autosave 和可重复使用的符号——这些集合在编辑器中有客户时才重要。
包括读取适配器、崩溃恢复、无障碍和SEO审计,以及存储文档的服务器端渲染。审批和审计轨迹仍为定制工作。
模板、媒体管道、导出和部署命令——用于最终作为网站而非CMS条目的页面。
拖放构建器MJML 组件、托管图片和导出,内容团队将发送模板而非发布。
电子邮件模板构建器价格来自制作时的实时目录。免费列表会被标记。
上面梯子上的每个能力都是可以构建的。问题是,当已有维护的扩展时,哪些能力值得你的团队投入时间。
| 全部自建 | 用插件扩展 |
|---|---|
| 更多发展 | 更快的实现 |
| 更多的维护 | 可重复使用扩展 |
| 构建每一个功能 | 只添加你需要的部分 |
| 内部工具 | 现成解决方案 |
从可视化编辑器开始。随着产品增长,逐步添加功能。
这不是供应商比较——而是范围比较。每一行都是可视化编辑器需要的子系统,唯一的问题是你的团队是否编写它。
| 能力 | 从零开始 | GrapesJS |
|---|---|---|
| 画布 | 自己写 | 内置 |
| 拖拽 | 自己写 | 内置 |
| 组件 | 自己写 | 内置 |
| 区块 | 自己写 | 可扩展 |
| 样式 | 自己写 | 内置 |
| 响应式编辑 | 自己写 | 内置 |
| 图层 | 自己写 | 内置 |
| 素材 | 自己写 | 可扩展 |
| 模板 | 自己写 | 可扩展 |
| 存储 | 自己写 | 可扩展 |
| 导出 | 自己写 | 可扩展 |
“可扩展”意味着子系统存在且有扩展点——块集、模板库、素材后端、存储目标和导出格式均由您提供,无论是从目录还是您自己的代码中。目录声明已验证 2026-09-03。
构建你的CMS产品。不要重建可视化编辑器引擎。
通常你应该这样做。内置编辑器已经集成、已获得权限且熟悉,对于结构化内容通常是正确的解决方案。当你需要内置编辑器不负责的事情时,专门的可视化编辑层就更有用:
这并不是说内置编辑器较差。而是认为编辑界面和内容基础设施是可以分离的决定。
保留你的CMS。选择你自己的编辑体验。
最小的编辑器,能与内容 API 通信。两个端点,一个 autosave 策略,以及两个调用分别代表每个内容。
npm install grapesjsimport grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
const editor = grapesjs.init({
container: '#editor',
height: '100vh',
// Load and save the project through your CMS API. Both endpoints are
// yours: GrapesJS only decides when to call them.
storageManager: {
type: 'remote',
autosave: true,
stepsBeforeSave: 10,
options: {
remote: {
urlLoad: '/api/cms/pages/home',
urlStore: '/api/cms/pages/home',
// Send the session the CMS already issued — never a CMS admin token
// that reached the browser.
fetchOptions: (opts) => ({ ...opts, credentials: 'include' }),
},
},
},
});
// The two representations, whenever you need them.
const project = editor.getProjectData(); // re-openable source
const output = { html: editor.getHtml(), css: editor.getCss() };请沿用 CMS 已经签发的会话。任何抵达浏览器的 CMS 管理员令牌,等于把它交给了所有访客。
GrapesJS 不在乎另一端是 REST、GraphQL 还是你们团队发明的东西。存储适配器既是加载函数,也是存储功能,以下内容都是你在其中做出的选择。
适配器能覆盖的内容
获取一页存储的文档,启动时交给编辑。
最好是写回去,最好是对草稿的更新,而不是更新已发表的条目。
节省变更次数或定时器,让端点能容忍频繁被调用。
通过你的媒体管道上传,并返回素材管理应该显示的URL。
把草稿信息放在前端,用代币形式公开,别对其他人。
一个独立的授权终端。永远不会和存档判定一致。
// A storage adapter is just two functions, so GraphQL needs no extra plugin.
editor.Storage.add('cms', {
async load() {
const res = await gql(`query Page($id: ID!) { page(id: $id) { project } }`);
return res.page.project;
},
async store(data) {
await gql(`mutation Save($id: ID!, $project: JSON!) {
updatePage(id: $id, data: { project: $project }) { id }
}`, { project: data });
},
});GJS.Market 上没有发布任何 GraphQL 适配包——上面的片段是整个集成,因此不需要任何集成。
两个函数,就是可视化编辑器与内容 API 之间的全部契约。
团队在工作原型和客户触摸的物品之间进行的清单。这里没有任何特别的东西;所有这些至少都会被跳过一次。
可视化编辑器是写入你内容基础设施的路径,因此它继承了该路径已有的所有规则——并在表面添加文件上传和任意标记。
每次加载、保存、上传和发布都会针对服务器上的会话进行该特定页面的检查。
数据库查询中按租户划分的范围。读取后应用的过滤器不是隔离。
编辑器使用你的 CMS 发出的会话。浏览器代码中不应包含任何管理或管理员令牌。
检查服务器端的类型、大小和目标,尽可能从不同的来源提供用户媒体。
编辑者可以放置自定义代码。有意识地决定谁可以使用,并对呈现给访客的内容进行净化。
一个独立的端点,有自己的权限检查,所以能编辑不等于能发布。
切勿仅依赖客户端权限。隐藏面板是用户界面的决定,而非安全控制。
编辑器运行时是开发者工具,仅属于编辑路径。该架构中几乎所有性能问题都源于让数据泄漏到访客加载页面。
通过编辑路线导入。面向访客的页面不需要编辑包。
媒体库可以无限增长。分页并在服务器端搜索,而不是整张加载。
每个插件在启动时注册组件、命令和面板。未使用的插件每次打开都会消耗时间。
发布的输出应该是前端渲染的标记和样式,不要附带编辑器代码。
交付的API可以硬缓存;预览后面的草稿读取通常不能。将它们分开处理。
这里没有引用任何时间,因为本页尚未测量过任何时间。用你自己的区块集来衡量你自己的编辑器——区块库和素材数量主导了数字。
五个反复出现的形状。它们会提出同一建筑的不同问题,每个结构都有一页回答自己的内容。
服务
需要把 GrapesJS 接入 Strapi、Contentful、Sanity、Directus、Payload 或自研 CMS?我们可以协助编辑器集成、自定义组件、存储适配、插件配置和上线工作流。
保留你现有的CMS、内容模型和前端架构。添加GrapesJS作为可视化编辑层,然后随着产品增长用GJS.Market插件扩展。
你的 CMS。你的前端。你的编辑器。