我停止与 WordPress 抗争…于是重新构建了我的使用方式

Source: Dev.to

Introduction

我已经构建了足够多的 WordPress 项目，注意到一个规律。它们一开始都很干净，但随后慢慢出现：

• 插件堆积
• 逻辑渗入模板
• API 四散

“让它能跑起来”成了架构，到了某个时点，你已经不再是在构建系统，而是在管理混乱。

Why WordPress Feels Chaotic

WordPress 试图兼顾所有角色：

• CMS
• 后端
• 前端
• 插件系统
• 模板引擎

于是所有东西都混在一起。路由了解太多信息，数据、行为和执行之间没有明确的边界。这就是问题出现的地方。

A New Perspective: Treat WordPress as a Data Source

我不再把 WordPress 当作应用本身，而是把它当作数据源。这个单一的转变改变了一切。

• WordPress 负责内容管理。
• 我的系统 负责行为逻辑。
• 前端则完全自由。

KiwiPress – An Application Layer on Top of WordPress

KiwiPress 不 替代 WordPress；它只是在组织你使用它的方式。目标很简单：把 WordPress 存储的内容与应用的行为分离。

Responsibility Split

• Seltzer → 处理路由和请求生命周期
• Nectarine → 解析配置和 API 结构
• KiwiPress → 拥有 WordPress‑特定的行为

Services Inside KiwiPress

每个部分只做一件事。没有泄漏。

Delegating Logic Instead of Embedding It

// wpread.js
const wpread = new WPRead();

const route = {
  method: "GET",
  path: "/users/:email",
  handler: () => wpread.getUserByEmail()
};

路由并不知道 WordPress 的内部实现，它只负责请求数据。

Benefits

Clarity

你始终清楚逻辑所在的位置。

Flexibility

前端可以是任何形式：自定义 UI、SPA、静态站点或混合模式。

Portability

即使以后不再使用 WordPress，你的应用也不会崩溃。

Maintainability

不再需要在插件和模板中四处搜寻才能弄清行为。

Conclusion

我并不是要取代 WordPress，而是想在现代系统中正确使用它。WordPress 在内容管理、后台工作流以及生态系统方面依然出色，但应用逻辑不该驻留其中。

KiwiPress 是更大系统的一部分，关注：

• 基于契约的架构
• 模块化应用引擎
• 供应商中立的系统

WordPress 本身并没有坏，只是我们一直让它承担太多职责。把职责拆分开来，一切就会简单得多。