从Wordpress迁移到Jekyll
我和WordPress
我第一次开始使用CMS系统是2015年，算下来已经有10年了，当时最出名的方案应该是织梦CMS，后来还有帝国CMS，并且这都是完善的国产CMS系统。在使用上他们非常轻量级，同时由于国内存在大量的主题开发者，所以拥有海量的皮肤资源，加之这些CMS拥有静态化能力所以整个系统运行起来所占用的资源是非常小的，当时在2015年前后，单个1核1G的云服务器上一个CMS系统能运行上白个门户。
但是那个时候我是一个大学生租用一个云服务器就已经不错了，织梦CMS是一个商业软件，当时的价格不是我一个学生能够消费的起的，所以织梦那个时候只是自己玩玩而已，正经建站做博客最后我还是选择了WordPress。话虽然这也说，WordPress其实在使用上一点不输织梦CMS，无论是门户、相册、博客、商城它们其实都是可以完整覆盖的。事实上我在使用WordPress的过程一直以来是非常满意的，作为一个站长角度出发WordPress提供足够稳定与高效的内容管理方式，并且提供极其丰富的自定义选项可以使站长几乎拼凑出任何界面；但是作为开发者的角度来说WordPress就表现的非常糟糕了，主要原因如下：
- WordPress提供了比较全面的自定义方案，但是本质上它依旧是CMS系统，作为开发者如果你可以自行编写html的情况下，基于CMS的编辑方案极大限制了内容的灵活性；
- WordPress运行时本质上就是提供了伪静态页面供用户访问，但是由于其本身是一个完备系统，也就是意味着哪怕99%的时间它仅仅提供静态资源访问，但是它依旧需要数据库与计算环境，形成了资源的浪费；
- WordPress运行还是需要用户自己的服务器提供支持，这样便存在一个靶子供黑客攻击，虽然你可以套CDN，但是实际上相比完善的Severless方案，风险还是很高。
综上所述，对于个人开发者来说WordPress依旧完成了其历史使命，亦或者说CMS依旧完成了其历史使命，我们需要更加适合我们的方案。所以，WordPress再见了。
静态站生成器SSG（Static Site Generator）
SSG从各个方面来讲都非常适合我们这种个人开发者使用，我大概例举一下我能够想到的优点：
- 大部分内容基于
MarkDown编写，然后由SSG生成对应的静态页面进而再进行部署，常规文章编写效率不低于CMS系统； - 特殊复杂类容需要特殊处理的时候，你可以直接编写html，无限的灵活性；
- 无需数据库与计算能力，任何webserver可以直接使用，同时可以使用入Github Pages或者Cloudflare Pages等静态页寄存服务提供服务能力；
- 媒体资源可以交由CDN存储，与文本分开，站点通过纯文本构建内容，意味着整个站点可以使用Git进行版本控制，并且可以交由CI/CD自动化部署到服务，内容编写与开发代码一致；
怎么说呢？其实非常完美，坦白的说我在好几年前就想把整个站点全部使用SSG方案进行重构了，可惜太懒了（又不是不能用）😂😂😂。这里可能会有个选型的问题，这个就比较主观了，坦白说各个SSG框架都有一定的上手门槛，毕竟是开发者使用的框架，和CMS这种面向普通用户使用的系统完全不是一个概念，所以各位自行选择吧，我选择的是老牌框架Jeykll
开始迁移
WordPress文章迁移
文章相对来说比较简单，估计是这种不仅仅是我，大部分人应该都是相同的心路历程，所以网上能够找到大量的开源工具干了这个事情，这里我推荐这个：wordpress-export-to-markdown，这个工具相较于jekyll官方那个要求连接你WordPress数据库的工具来说，可好太多了。使用非常简单：
- 从WordPress导出XML，注意这里最好是包括所有内容的导出；
- 使用
wordpress-export-to-markdown这个工具导出markdown，这里我建议选择一些导出的标题，最好按照jekyll的命名格式导出；
这里还有一个可选项各位可以参考一下，如果你导出了的时候选择图片也导出的话，这个工具会将所有图片下载到一个特定文件夹，我的建议是不要在SSG里面直接使用这些图片，而是应该将这些图片全部扔到CDN上放着，SSG框架代码里面主要保持文章就行了，这样后续在代码仓库进行管理会简单很多的。
WordPress评论迁移Github Discussions
这个地方才是整个文章的重点，这也是每次我有想法迁移SSG就停下来的主要原因（主要就是懒）。因为SSG生成的结果毕竟只是静态页，各位试想一下，静态页如何存储网友的评论和我的讨论呀😂？所以我们需要一个独立的东西可以存储我们的评论数据，一方面是新的产生的评论，另一方面是我老WordPress里面的评论也得进去才行。同时除此之外还有一个核心问题，各位知道为啥我要自建博客，这些内容其实完全可以放什么CSDN、博客园这种平台对吧？没错是可以放，但是我不想这么做，因为这些平台从我这种第一代互联网参与者而言，用他们就像让我吃苍蝇一样。
所以我们需要一个方案可以将长期有效得存储评论，同时还不能是什么商业平台，能够长期提供稳定得存储能力才行，这个时候开始我才找到一个项目：giscus
简单来说giscus提供了一个方案，内部使用Github Discussions存储所有得评论，而giscus本身通过API访问这些评论并且在你的站点上显示（包括新增评论），所以数据本身存储在Github，怎么说呢？Github我还是信得过的。
所以说我们只需要找到一个方案将WordPress的评论迁移到Github Discussions就行了，然后你就会发现事情没有那么简单，是的我找了很多项目没有一个可以正常运行的😭😭😭😭。
于是，我自己写了一个：https://github.com/tan9710630/WordPressCommentToGithubDiscussions
有个我这个项目之后，后面的事情就很简单了，执行步骤如下：
-
创建GITHUB仓库，并且开启Discussions功能，同时获取如下信息：
-
GITHUB账号的TOKEN；
-
创建的仓库ID；
-
Discussions分类的ID；
-
- 导出wordpress的xml（包括评论）
- 安装依赖
1
npm install
- 修改代码配置
1
2
3
4
5
6
7
8
9
// 找到src/index.js文件，修改这些占位符
// 解析WordPress XML
const wpFactory = new WordPressFactory('Wordpress导出的XML');
const posts = await wpFactory.parse();
// 配置GitHub同步
const token = "GITHUB的token"; // 从环境变量获取token
const repoId = 'GITHUB Discussions 所在仓库ID'; // 仓库ID占位符
const categoryId = 'GITHUB Discussions的分类ID'; // 分类ID占位符
- 执行导入
1
node src/index.js
- 特别注意
- 本项目使用的GITHUB的GraphqlAPI创建Discussions，这个API的请求是有限制的（参考文档），而且限制的策略特别复杂，并不是在请求之间停顿一两秒就可以搞定的，所以最好是自行修改代码，分批次执行导出。
总结
我把我的站点迁移到Jekyll方案之后，建立了github到cloudflare pages的自动流水线，后面空了我准备写点Jekyll的文章或者cloudflare云原生开发的文章，但是那都是后话了，本文我的总结只有一句话：从现在开始，我的站点没有后端服务器了！！