前言

本站从20年开始一直就使用wordpress，由于从nas到国外vps再到cloudflare的链路实在过长，加上wp插件多，加载速度慢，影响用户体验和 SEO。于是乎，有了更换blog的想法。

最开始看到有些博主使用astro，确实有跟风使用的想法，一番研究后还是放弃了。

astro有react和vue等用在同一个项目内的优势，却无法在岛(island)之间共享状态，虽然astro 有Nano Stores用于跨岛共享状态，但是很多react组件都是和react的context强绑定的，不能使用context共享状态。

相比astro，nextjs就做的好很多，虽然nextjs有服务端组件和客户端组件，但是在根layout放置一个Provide的客户端组件去共享上下文，虽然中间隔着不少服务端组件，但是还是能把context传递下去，而astro根本不行。

当然，nextjs还有其他优势，比如服务端渲染 (SSR)，现代前端技术栈，不需要遵循wp和主题的掣肘，没有wp主题的手搓jq的烦恼。

对于后端这部分，虽然确实是可以重写一个新的blog后端，但是某种程度上，成本确实有点高，虽然blog基本算大学生毕设一样就是纯curd的系统。但是有现成的headless wordpress，为什么要重复造轮子呢？

并且，使用wordpress + nextjs的混合架构，一方面，既能保留wordpress成熟的内容管理生态，又能享受React生态的前沿技术红利。并且，当你哪一天不想使用nextjs时，还可以无缝fallback回到wordpress，没有任何迁移成本。

大致过程与困难

使用GraphQL与查询默认架构不存在的字段

在wp安装WPGraphQL并且在nextjs端安装Apollo Client，基本按照官方文档很顺利就安装上了。 这里碰到第一个问题我需要查询wp默认不存在的数据库gql字段

原因是我安装了wp-editer.md插件，我的大部分历史文章都是使用这个编写的，没有使用古腾堡编辑器，而wp官方默认数据库存储文章的内容是html，html在nextjs那边渲染会很费劲，必须尽量搞成markdown的格式，刚好wp-editer.md在数据库存了原始的markdown数据，但是WPGraphQL定义的结构没有这个字段

经过一番研究，找到了扩充WPGraphQL自定义字段的方法，使用注册字段：

绕过wp的xss过滤器

在开发博文评论接口的时候，碰到神奇的问题，提交到wp评论，成功后的<img/> 标签总会消失不见，研究半天，发现原来是wp默认评论会过滤img标签。使用如下action 可以绕过wp的富文本过滤

另一个蛋疼的问题就是Sakurairo这个主题有检测评论是否为markdown的action，并且居然主题设置没有关闭的开关，只能注释主题相关php代码解决。

结尾

换nextjs之后，性能比wp老古董强，而且react技术栈相比wp主题能玩的花活很多，当然前提得是个前端哈哈，还有一些需要后续优化，慢慢迭代咯