Show HN：Pages CMS – 面向 GitHub 的 CMS
一个新的开源项目 Pages CMS 提供了一个基于 GitHub 的内容管理系统，它建立在 Jekyll、Hugo、Eleventy、Astro 和 Next.js 等现有静态站点生成器之上，目标是在不把用户锁定到特定托管服务商的前提下，重现类似 WordPress 的编辑体验。评论者称赞它比 Decap/Netlify CMS 和 TinaCMS 等工具拥有更简单的 UX，喜欢它可以轻松自托管到 Cloudflare Pages 等服务，并强调了多仓库支持、可配置内容类型和富文本编辑等功能。当前的关键挑战和路线图项目包括：通过自动生成配置改善上手体验、增强 MDX 和 HTML 集合支持、提供媒体存储选项（S3/R2），以及扩大除 GitHub 之外的 Git 提供商兼容性。
总体反响与适用场景
- 许多评论者都很兴奋，尤其是那些怀念 Forestry，或者对 Decap/Netlify CMS 和 Tina 不满意的人。
- 常见用途包括使用 Hugo、Jekyll、Eleventy、Astro、Next.js 以及其他 SSG 构建的博客和文档站点，让非技术用户更容易在 Git 仓库中编辑内容。
- 一些人认为这正是他们一直想要的“位于 GitHub 之上的轻量 CMS 层”。
安装、配置与 UX
- 人们称赞其 UI/UX，并表示在 Cloudflare 上几分钟内就能跑起来。
- 也有人指出，上手过程还没有完全做到“点一点就完成”；弄清页面配置和内容 schema 仍然需要一些精力。
- 有几位用户希望有一个配置向导，能根据现有文件夹和 front matter 推断内容类型和字段；作者表示这在计划中。
内容格式与 SSG 集成
- 与常见 SSG 的 Markdown front matter 配合良好。
- 当前限制：MDX 支持是部分可用的（通过“code”模式处理单文件没问题；集合和富文本编辑器还不够稳定）。
- 一些 Jekyll 用户不清楚当
body只是 front matter 之后的隐式内容时，它是如何映射的。 - 目前对 HTML 和 MDX 集合、Jekyll 的按文件名取日期，以及使用扁平 YAML“collections”而不是“一条条记录对应一个文件”的支持都有需求。
认证、托管与 Git 提供商
- 目前只支持 GitHub；代码可以托管在任何地方（例如 Cloudflare Pages），CMS 本身纯粹是前端加上一些较小的认证函数。
- GitHub OAuth 需要较宽泛的仓库访问权限；评论者对此有些不安，但细粒度个人访问令牌和自托管可以缓解这一点。
- 有些人强烈希望支持 GitLab、Bitbucket、Gitea 或通用 Git API；通用 Git 目前不在范围内。
媒体处理与存储
- 当未配置
media时，富文本编辑器一开始会出问题；补丁很快就发布了。 - 用户请求 S3/R2 和第三方上传服务；S3/R2 支持正在积极推进。
- 可以通过为文件扩展名配置过滤器，把媒体与文章放在同一位置。
对比、定价与理念
- 经常被拿来与 Decap、Static CMS、Keystatic、Tina、Statamic、Lektor、Publii 和 CloudCannon 做比较。
- 讨论的主要区别点包括：比 Decap 的 UX 更简单；不像 Keystatic 的桌面模式那样依赖本地运行；也不要求使用特定服务商托管。
- 该项目采用 MIT 许可且可自托管；文中还提到未来可能会有一个面向高级功能的 “Pro” 等级，这也让一些人对其长期免费状态表示怀疑。