Optistream 将 12 个自定义 WordPress 插件合并到了单一代码库中，且未损失其 1000 个公开页面的任何 SEO 效果。
为什么合并至关重要
一个典型的 WordPress 网站最终会安装一些插件；而规模较大的网站则看起来像是一个布满电线的车间，每个插件都在运行，但却都难以拆卸。Optistream 的网站运行着 12 个定制插件，分别处理主播资料、电竞战队和游戏数据。这些插件生成了 1000 个可索引页面。保持这些 URL 的完整性是不可逾越的底线——任何变动都会导致迁移失败。
旧架构是什么样的
这 12 个插件各自位于独立的文件夹中，注册各自的自定义文章类型 (custom post type)，并在 WordPress 的不同钩子 (hook) 点进行挂载。问题接踵而至：
- 钩子 (Hooks) 和资源文件分布零散，难以预测代码的执行时机。
- 路由逻辑分布在许多独立文件中，导致单个 URL 可能会受到多个插件的影响。
- CSS 文件加载顺序不可预测，导致样式冲突。
- 调试时需要打开 12 个不同的目录，这对任何开发者来说都是极大的时间消耗。
目标并不是为了减少文件数量，而是为了让整个系统拥有统一的生命周期和统一的依赖管理入口。
迁移是如何规划的
团队将公共接口（URL、模板和元数据）视为不可逾越的契约。前端发生的任何变化都将被视为失败。基于这一原则，他们制定了一份在每一步操作后都要执行的检查清单。
1. 列出公共契约
记录下每个 URL 路径及其对应的文章类型、重写别名 (rewrite slug)、模板文件以及所依赖的元键 (meta keys)。这张电子表格成为了规则手册：如果模块迁移后 URL 发生了变化，则必须回滚迁移。
2. 构建一个简单的加载器
创建了一个微小的引导文件 (bootstrap file)。每个原有的插件现在都通过一个可预测的函数名来注册一个单一的“内容域 (content domain)”。这个加载器并不复杂——它只需在需要时将正确的模块拉入 WordPress 即可。简单化让故障变得显而易见。
3. 保护数据
重命名元键会将代码变更演变为数据迁移，从而增加不必要的风险。旧的键保持不变；通过新的辅助函数对其进行封装，从而保持数据库模式 (schema) 的稳定。
4. 解决 CSS 归属问题
通过以下三种措施解决了样式冲突：
- 模块 CSS 文件以高优先级进行入队 (enqueue)，确保它们最后加载。
- 所有选择器都作用于每个模块唯一的包装类 (wrapper class)。
- 在入队时使用
filemtime()，以便在样式表更改时强制刷新浏览器缓存。
5. 使用安全循环
迁移按模块逐一进行。在移动一个模块后，团队会在处理下一个模块之前验证文章类型的注册、路由和移动端布局。原有的插件保持安装但处于禁用状态，从而提供了即时的回滚路径。
上线检查清单
在每次模块替换后，团队都会验证：
- 每个内容类型的 URL 都返回 200 HTTP 状态码。
- 规范 URL (canonical URL) 请求头与原始 URL 一致。
- 页面标题和元描述保持不变。
- 所有图片加载正常，无失效链接。
- 移动端屏幕上没有出现水平溢出。
- 浏览器控制台显示零 JavaScript 或 CSS 错误。
只有在检查清单全部通过后，团队才会永久停用旧插件。
新插件带来的价值
最终生成的单一插件并没有缩小代码库；它只是让边界变得清晰可见。所有 12 个功能区域现在共享同一个生命周期、一组钩子 (hooks) 和一个统一的依赖管理入口。新插件并没有让系统变小，它只是让边界变得可见。事实证明，这比单纯减少插件数量更有用。
风险与反论
Optistream 的案例表明，严谨的“契约优先”方法和逐步部署可以有效控制风险。
后续注意事项
如果你正在考虑进行类似的整合，请从以下两个支柱开始：
- URL 稳定性 – 在编写任何代码之前，先映射每一个公开路径。
- 数据稳定性 – 除非你已准备好进行完整的数据迁移，否则请避免重命名数据库字段。
在此基础上，构建一个微小的加载器，保持 CSS 作用域隔离，并逐个移动模块，同时执行严格的上线检查清单。