从 Halo 搬到 WordPress：这几天整理 godsun.pro 的踩坑记录

👁 520

这几天我把 godsun.pro 这套站从 Halo 那边慢慢整理到 WordPress，原本想法很简单：文章搬过去，主题调一下，能正常访问就行。

真动手以后才发现，迁移博客这件事最麻烦的不是“会不会安装 WordPress”，而是那些很碎、很恶心、很容易被忽略的小坑：导入文件格式、容器名字、主题读取字段、Cloudflare 缓存、后台入口、阅读量插件……每一个单独看都不大，连起来就能把人磨半天。

这篇就当一个实战记录。不是标准官方教程，也不是照着文档抄一遍，而是把我这几天从 Halo 搬到 WordPress 的过程、踩坑点和最后整理出来的流程写下来。以后再折腾别的站，至少不用从零再踩一遍。

为什么要从 Halo 整理到 WordPress

Halo 其实挺适合个人博客，界面清爽，写文章也舒服。之前 godsun.pro 那套内容，很多就是 Halo 时代慢慢攒下来的：路由器、OpenWrt、eMMC、盒子、NAS、Docker、各种矿渣折腾记录。

但内容越来越多以后，我发现 WordPress 在几个地方还是更顺手：

• 主题和插件生态更丰富，想改列表、侧边栏、阅读量、SEO 都比较容易找到现成方案。
• 老文章多了以后，分类、标签、搜索、相关文章、热门文章这些东西更好折腾。
• 后面如果要接 AdSense、Search Console、统计、站内链接优化，WordPress 的成熟方案更多。
• 我这边本来就有 Podman 容器环境，WordPress + MariaDB + Nginx 跑起来也不复杂。

所以这次不是因为 Halo 不能用，而是想把老内容整理到一个后面更方便长期维护的环境里。

整体流程：先迁移，再修站，不要一口吃成胖子

这次整理下来，我觉得比较稳的顺序是：

1. 先把 WordPress 容器跑起来，确认本地源站能访问。
2. 导入 Halo 迁移出来的文章内容，先保证文章能进库。
3. 修正固定链接和 Cloudflare Tunnel，让公网能打开。
4. 换主题或调主题，把首页、列表页、文章页先做成能看的状态。
5. 再处理侧边栏、热门文章、阅读量、评论、后台入口这些细节。
6. 最后才是缓存、SEO、导航、分类标签这种长期整理工作。

一开始千万别想着“导入完马上完美”。迁移站点最怕的就是边导入、边改主题、边改插件、边改反代，最后哪里坏了都不知道是哪一步引起的。

踩坑一：WXR 文件开头不能有乱七八糟的东西

WordPress 导入老内容时，最常见的是 WXR/XML 文件。这个东西有个很烦的坑：文件必须从 <?xml 开始。

如果前面混进去 PHP 标签、空行、注释，或者导出文件被某些工具包了一层奇怪内容，WordPress importer 就会报类似“这不是一个有效的 WXR 文件”。

这个坑一开始很像“插件坏了”或者“WordPress 版本不兼容”，但其实就是文件头不干净。我的处理方式很简单：导入前先清理，确保 XML 声明在第一行。

sed -n '/^<?xml/,$p' old.xml > clean.xml

这类问题不高级，但特别浪费时间。迁移前先检查文件头，比在后台反复点导入靠谱。

踩坑二：容器名字和端口别靠记忆

这次 godsun.pro 是跑在本地 ARM64 机器上的，不是在 VPS 上。容器名也不是以前文档里那些旧名字，而是现在这套：

• wp-fpm：WordPress PHP-FPM
• wp-nginx：前端 Nginx，宿主机端口 8088
• wp-mariadb：数据库

这个坑很实际：如果凭记忆去 SSH VPS，或者拿旧的 wp-halo-test-fpm 容器名执行命令，肯定会改错地方。

所以我后面固定先跑一遍：

podman ps

再用 Host 头测试本地源站：

curl -H "Host: godsun.pro" http://localhost:8088/

这一步很重要。公网打不开时，先看本地源站。如果本地源站是好的，再看 Cloudflare、Tunnel、缓存；如果本地都坏了，就别先怪 Cloudflare。

踩坑三：主题不是装上就完事，Blogsy 还要调很多细节

这次最后用的是 Blogsy 主题。它本身是一个偏杂志/博客风格的主题，适合文章列表、右侧栏、卡片布局，整体比从零写主题省事。

但第三方主题也有第三方主题的问题：默认效果不一定符合自己的站。比如菜单位置、侧边栏是否显示、首页几列、文章页 meta 信息、颜色风格，都要慢慢调。

这里有几个实际坑：

• Blogsy 的菜单位置是 primary_menu，不是很多主题常见的 primary。
• 侧边栏不是设置成 right 就一定显示，sidebar-1 里没小工具时它可能直接隐藏。
• 自定义 CSS 走 WordPress 原生 Additional CSS 更稳，不要乱猜主题自己的 option key。
• 菜单标题不能太长，不然导航栏会变双排，看起来很乱。

这种地方如果靠后台一点点试也能搞定，但我更喜欢直接用 WP-CLI 和本地 curl 验证。改完马上看 HTML 里有没有对应元素，比肉眼刷新靠谱。

踩坑四：阅读量“看起来没变”，其实是主题读错地方

这是这次最典型的坑。

WordPress 里装了 Post Views Counter 插件以后，真实阅读量是存在插件自己的数据结构里，并且可以通过 pvc_get_post_views() 读取。

但 Blogsy 主题自带的阅读量函数，原来读的是旧的 post_views meta 字段。结果就出现一种很迷惑的情况：后台或者插件里真实阅读量已经改了，文章页前端却还是显示旧数字。

最后处理方式是改 Blogsy 的 blogsy_get_post_views()，让它优先读取 PVC 插件的真实总阅读量：

if ( function_exists( 'pvc_get_post_views' ) ) {
    $count = intval( pvc_get_post_views( $post_ID, 'total' ) );
} else {
    $count = intval( get_post_meta( $post_ID, 'post_views', true ) );
}

这样主题显示、侧边栏热门文章、插件统计就能尽量统一到同一个数据源。

踩坑五：那个“0”不是阅读量，是评论数

阅读量刚修好以后，我又碰到一个更搞笑的误会：文章标题下面还是有个 0。

第一眼看过去，很容易以为“阅读量还是没变”。但抓页面源码以后发现，那个 0 是评论数，链接指向 #respond，也就是评论框。

真正的阅读量其实已经在页面里显示了，只是另一个位置还是英文 Post Views:，不够直观。

所以我后面做了两件事：

• 单篇文章页头部关掉容易误解的评论数，打开真实阅读量。
• 用一个 MU 插件把 PVC 前端文案改成中文“阅读：”，并继续读取真实 PVC 总数。

这个坑给我的提醒是：前端看到数字不对，不要先猜，先看源码。链接到 #respond 的，多半是评论；class 里带 post-views 的，才是阅读量。

踩坑六：后台入口要隐藏，但不能把自己绕晕

WordPress 老站最容易被扫的就是 /wp-login.php 和 /wp-admin/。这次我用了 WPS Hide Login，把后台入口改成了：

https://godsun.pro/xoxo-hhhvxzfg 

我随便写的你自己改的记得就好

默认登录入口隐藏以后，机器人扫描会少很多。但这里也要记住：以后自己进后台不要再习惯性输 /wp-admin/，否则就像站坏了一样。

不过日常发文和维护，我其实不太需要后台密码。大部分操作都可以直接在本机用 wp-cli、容器命令或者 REST API 做。后台更多是偶尔看一眼页面效果。

踩坑七：缓存问题不要靠感觉判断

WordPress + Nginx + Cloudflare 这一套，只要改主题、改固定链接、改阅读量显示，就可能遇到缓存问题。

我现在比较习惯的验证方式是：

• 先本地源站 curl，加 Host 头。
• 再公网 curl，加随机参数。
• 最后才打开浏览器看。

比如：

curl -H "Host: godsun.pro" http://localhost:8088/CPE-FM350-GL/?v=123
curl https://godsun.pro/CPE-FM350-GL/?v=123

如果本地是新的，公网是旧的，大概率是 Cloudflare 或浏览器缓存。如果本地也是旧的，那就是 WordPress/主题/插件本身没改对。

这个判断顺序能省很多时间。

我最后整理出来的迁移流程图

下面这张图就是这次迁移后的简化版流程。真实过程肯定比图里乱，但核心顺序差不多：先保证内容和容器稳定，再慢慢修主题和体验。

这次迁移后我会保留的几个习惯

第一，任何站点操作先确认机器和容器。godsun.pro 在本地，不在 VPS；ai.godsun.pro 和 gwrt.uk 又是另外的环境。这个边界一定要清楚。

第二，主题文件能少改就少改。能用 MU 插件解决的东西，就不要直接改插件核心。比如 PVC 阅读量文案，我最后就是用 MU 插件处理，后面插件升级也不容易被覆盖。

第三，前端显示异常时先看源码，不要只凭截图猜。截图里的一个 0 可能是评论数，也可能是阅读量，也可能是某个 JS 占位。

第四，改完必须验证。本地源站、公开域名、文章页、首页、缓存参数，至少跑一轮。不然看着像好了，过一会儿又被缓存打回原形。

结尾：迁移博客不是搬家，是重新整理仓库

这次从 Halo 整理到 WordPress，最大的感受是：博客迁移不是简单“把文章搬过去”。更像是把一个堆了很久的仓库重新整理一遍。

文章能打开只是第一步。真正花时间的是：分类是否还合理，主题是否适合老内容，阅读量是否可信，热门文章是否能反映真实访问，后台入口是否安全，Cloudflare 和容器链路是否稳定。

折腾完以后，godsun.pro 这套站就更像一个能长期维护的内容库了。老文章继续保留，新文章继续写，后面路由器、OpenWrt、盒子、NAS、Agent 这些内容也能更顺手地串起来。

如果你也准备从 Halo、Typecho、Hexo 或其它博客搬到 WordPress，我的建议就一句：别急着美化，先把迁移链路跑稳；别急着装一堆插件，先把数据源搞清楚。

剩下的，慢慢磨。

by 数码罗记 · godsun.pro