Alleycat: 重新制作了博客的CMS

大家好，我是无能。
我尝试重新制作了博客的CMS。
GitHub - haturatu/alleycat: cms & frontend · GitHub

话说回来，如果最终要做到这种程度，那用WordPress不也挺好吗？虽然有这样的想法。

为什么制作它

我的博客最初在2020年左右从WordPress迁移到了LumeCMS，最初的迁移意图如下：

大致如上所述。

因此，必要的需求如下：

CMS本身可以按端口分离
支持图片复制粘贴上传，并生成链接
即使在手机上也能轻松编辑的设计
CSS尽可能保持最小化，以便于理解
- 最终不可避免地会增加，这是没办法的事
- 外部依赖的CSS越多，就越难以理解，所以尽可能避免
即使没有JS也能在前端查看
- 从性能角度来看，静态构建是必须的，而且我还想让它对像我这样偶尔使用w3m的用户友好
TOC（目录）是必须的
- 有了它，可读性会大不相同
- 不过，之前Lume的TOC是从h2开始的，这是为什么呢？虽然觉得标题不包含在TOC中可能有点道理？
- 但不知为何，Lume只支持到h3左右的范围
  - 可能是为了避免设计崩溃吧？
编辑器有富文本编辑器和 md 会很方便
- 用于手机编辑
现在才意识到数据库的宝贵

我个人觉得 Pocketbase 非常好用，所以采用了它。数据备份也无需特意实现，可以直接从标准的Web UI保存备份的 zip 文件。

敏感信息的处理， Pocketbase 也很好地实现了，非常方便。数据库似乎是 SQLite。

此外，我还想实现多语言支持，但由于门槛较高一直未能实现，现在通过注册 Gemini API 来实现了多语言支持。

即使使用Google翻译，也需要特意移动到浏览器上方点击翻译按钮，查看了各种文档页面后，我仍然觉得有内置翻译会更好。不过，这仅限于文章页面。

如果改变太多，博客网站的性质就会改变吗？或者说，我关心博客作者是从哪个国家的视角来写作的，所以日本人还是希望以日本人的身份来呈现“关于”页面，并且在其他页面上没有感受到这种必要性。

SSG也面临类似问题，构建后文件数量增加时，磁盘I/O会频繁扫描。好吧，先不提“文章不会多到耗尽 inode”这种吐槽，我不想增加不必要的磁盘读写。

关于这一点，实际上构建后的公共数据并不需要那么高的持久性。因此，

$ rg tmp
backend/ssr/config.go
13:     staticExportDir  = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")

通过这种方式，默认在 /tmp 目录下输出，将静态构建后的文件放置在RAM上进行分发。

我希望能够直接从Web编辑器复制粘贴上传图片，并且尽可能让导出本身更容易保持文章和图片集的一致性，因此决定将二进制文件直接存储到 Pocketbase 中。

虽然这可能有点争议，但我从未特意查看图片存储的文件夹，这样做是为了消除复杂性。而且，在 Pocketbase 上查看也更方便，所以我选择了这种方式。

感觉效果还不错。

进行构建时会像上图所示，但作为待机资源大约就是这些。大致会收敛到150MiB以下。

能够以这些资源实现包括CMS在内的功能，我感到很高兴。同时，我也想亲自尝试一下 Codex 在前端设计方面能做到什么程度，所以这次也是一个很好的尝试。

那么，下次再见。请多关照。