为什么 MODX 用户应该在 2026 年迁移到 Next.js：诚实的看法
你的 MODX 安装在 1.2 秒内启动——对于一个建于 2005 年的 PHP CMS 来说是令人尊敬的。你打开管理面板，注意到最后一次核心更新是在十一个月前。你曾经常驻的 Slack 频道现在每周只有三条帖子，远低于 2019 年的日常讨论量。你的开发人员在站立会议上浮出"探索选项"的想法，你知道这意味着什么。
我在 MODX Evolution 上构建了六年。我编写了自定义代码片段，在凌晨 2 点为模板变量苦恼，并在代理营销中为其灵活性辩护。这不是抨击。这是模式识别：插件放弃在 2024 年至今期间加速了 40%，托管提供商悄悄弃用了针对 MODX 优化的堆栈，你的网站能做的事情与前景所期望的事情之间的差距已经变成了鸿沟。问题不是是否迁移——而是现在迁移还是等到在宣传活动启动期间出问题。
但这里的事情是：网络开发世界已经继续前进，MODX 没有跟上。社区在萎缩，发布周期已经放缓到蜗牛速度，人才库干涸的速度比七月的水坑还快。如果你在 2026 年仍在 MODX 上运行生产网站，你需要认真考虑你的退出策略。对于大多数团队来说，那个出口通向 Next.js。
让我向你解释为什么——诚实地，没有炒作。
目录
- 2026 年 MODX 的现状
- MODX 做对了什么（现在仍在做）
- 你再也不能忽视的问题
- 为什么 Next.js 是自然的迁移目标
- 迁移路径：MODX 到 Next.js
- 选择无头 CMS 替代 MODX
- 真实性能提升：迁移前后
- 你会错过什么（以及你不会）
- 成本比较：运行 MODX 与 Next.js
- 常见问题
2026 年 MODX 的现状
让我们诚实地看待数字。MODX 3.x 已经推出一段时间了，但采用率一直......温和。MODX 论坛曾经热闹非凡，现在每周可能只有几条帖子。官方 GitHub 存储库显示提交活动越来越稀疏。将其与 2018 年或 2019 年相比，当时社区仍在全力推进。
根据 2026 年初的 BuiltWith 数据，MODX 为大约 0.3% 的 CMS 检测网站提供支持，低于 2021 年的约 0.7%。WordPress 仍然主导，约占 62%，而较新的参与者如 Next.js 网站（通常与无头 CMS 配合）的增长率约为每年 40%。
MODX 市场（以前是 Extras 存储库）几个月来没有看到任何有意义的新扩展。许多流行的扩展未得到维护或仅与 MODX 3.x 部分兼容。当生态系统停止生产时，那不是红旗——那是白旗。
我不是说 MODX 已死。它仍然有效。你的网站仍在运行。但"仍然有效"在网络开发中是一个危险的地方。
MODX 做对了什么（现在仍在做）
在我堆砌之前，功劳在应得之处。MODX 钉住了许多大多数 CMS 仍然做错的事情：
真正的内容灵活性
MODX 从不强制你进入"帖子和页面"范式。模板变量、块和代码片段在"结构化内容"成为流行词多年前就给了你真正的内容建模自由。你可以构建任何东西。
清洁输出
MODX 没有注入自己的标记。没有神秘的 CSS 类，没有你没有要求的包装器 div。你的 HTML 是你的 HTML。对于关心工艺的前端开发人员来说，这是一个启示。
开发者友好的主题设置
没有要学的主题系统，没有要记住的模板层次结构。你编写模板。仅此而已。块是可重用的部分。代码片段是 PHP 逻辑。简单的心理模型，强大的结果。
标签语法
说什么都可以关于 [[*pagetitle]] 和 [[!MySnippet]]——一旦你学会了，你就能快速构建复杂的页面。具有 ! 未缓存标志的缓存层很优雅。
这些优势实际上使 MODX 开发人员成为现代无头架构的极好候选人。如果你已经在结构化内容和基于组件的模板中思考，你已经一半在 Next.js 了。
你再也不能忽视的问题
这是我必须坦率的地方。
安全问题
MODX 3.x 解决了许多历史漏洞，但运行任何具有公共管理面板的 PHP 一体式系统都是固有的风险向量。在 2025 年，我们看到至少两个影响 MODX 安装的关键 CVE，补丁需要数周才能到达。随着安全团队的缩小，响应时间不会改善。
将其与部署在 Vercel 或 Netlify 上的 Next.js 网站相比——基本上没有要攻击的服务器。没有要暴力破解的管理面板。没有 PHP 可以利用。攻击面从根本上更小。
人才危机
尝试在 2026 年雇用 MODX 开发人员。继续。发布职位列表并观看沉默。开发人员池已迁移到 React、Next.js 和现代 JavaScript 框架。甚至 PHP 人才也转向 Laravel，而不是 MODX。
这不是理论问题。我与有 MODX 网站的代理交过话，他们根本找不到开发人员来维护。当原始开发人员离开时，网站就成了一个负担。
PHP 8.x 兼容性麻烦
MODX 3.x 运行在 PHP 8 上，但许多扩展不运行。如果你构建的网站依赖于第三方代码片段或插件，升级 PHP 通常会破坏事情。你最终被固定在较旧的 PHP 版本上，这又回到了安全问题。
没有现代开发人员体验
没有热模块重新加载。没有基于组件的架构。没有 TypeScript 支持。没有内置图像优化。没有边缘渲染。没有 ISR。我可以继续。
MODX 的开发工作流基本上是：在管理器中编辑文件或块（或通过同步工具在你的 IDE 中），清除缓存，刷新浏览器。它有效，但与现代 DX 相比速度很慢。
性能上限
MODX 可以很快——我已经在上面构建了低于 2 秒的网站。但要达到那里需要大量优化：整页缓存、CDN 设置、数据库调整和谨慎的代码片段架构。Next.js 基本上开箱即用地为你提供亚秒性能，具有静态生成。你在 MODX 上争取性能；在 Next.js 上，你争取搞砸它。
为什么 Next.js 是自然的迁移目标
你可能会问：为什么不 WordPress？为什么不 Astro？为什么不只是一个静态网站生成器？
所有有效的选项，但 Next.js 对于大多数 MODX 迁移都达到了甜蜜点。原因如下：
渲染灵活性反映 MODX 思维
MODX 开发人员已经理解不同的页面需要不同的缓存策略。在 MODX 中，你会将代码片段标记为已缓存或未缓存。在 Next.js 中，你在每页选择静态网站生成 (SSG)、增量静态再生 (ISR) 和服务器端渲染 (SSR) 之间进行选择。同样的概念，更好的执行。
组件架构取代块
MODX 块是可重用的 HTML 部分。React 组件是带有内置逻辑的可重用 UI 部分。如果你一直在编写像 [[!$header]] 和 [[!$footer]] 这样的块，你已经在组件中思考。你只是没有道具。
API 路由取代代码片段
MODX 代码片段处理服务器端逻辑——表单处理、API 调用、自定义查询。Next.js API 路由（或 Next.js 14+ 中的服务器操作）做同样的事情，但使用 JavaScript/TypeScript 和更好的工具和测试支持。
对于考虑替代方案的团队，Astro 值得对内容丰富但不需要太多交互的网站进行评估。但如果你需要动态功能、认证体验或复杂的数据获取，Next.js 是更强的选择。
迁移路径：MODX 到 Next.js
让我们实际一点。以下是 MODX 到 Next.js 迁移实际上是如何工作的。
步骤 1：审计你的内容模型
映射每个 MODX 模板、模板变量和资源类型。这在你选择的任何无头 CMS 中都成为你的内容模型。记录一切：
## 资源：博客文章
- pagetitle → title（文本）
- longtitle → seo_title（文本）
- content → body（富文本）
- TV: hero_image → hero_image（媒体）
- TV: author → author（参考）
- TV: category → category（分类法）
步骤 2：导出你的内容
MODX 没有很好的导出工具。你可能需要编写一个自定义代码片段或脚本来查询 modx_site_content 和你的 TV 表格，然后输出 JSON：
<?php
// 快速而肮脏的 MODX 内容导出
$resources = $modx->getCollection('modResource', [
'published' => 1,
'deleted' => 0
]);
$output = [];
foreach ($resources as $resource) {
$output[] = [
'id' => $resource->get('id'),
'title' => $resource->get('pagetitle'),
'slug' => $resource->get('alias'),
'content' => $resource->get('content'),
'template' => $resource->get('template'),
'tvs' => $resource->getTemplateVars(),
'parent' => $resource->get('parent'),
'publishedon' => $resource->get('publishedon'),
];
}
header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);
然后为你的目标 CMS 编写导入脚本。这不是有魅力的工作，但这是一次性工作。
步骤 3：构建你的 Next.js 前端
从 create-next-app 开始并将你的模板构建为页面组件。你的 MODX 模板 → 页面布局映射可能看起来像：
| MODX 概念 | Next.js 等效 |
|---|---|
| Template（模板） | Layout 组件 |
| Chunk（块） | React 组件 |
| Snippet（代码片段） | Server Action / API 路由 |
| Template Variable（模板变量） | CMS 字段 |
| Resource（资源） | 页面 / 内容条目 |
[[*field]] 标签 |
Props / 数据获取 |
| Plugin（插件）（事件钩子） | Middleware（中间件） |
[[!uncached]] |
SSR / 动态渲染 |
[[cached]] |
SSG / ISR |
步骤 4：处理 URL 重定向
这是人们搞砸的地方。每个旧的 MODX URL 都需要 301 重定向到其新的 Next.js 等效项。构建重定向映射并将其添加到 next.config.js：
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... 数百更多，从你的导出生成
]
},
}
不要跳过这个。你的 SEO 取决于它。
步骤 5：并行运行 2-4 周
在现有 MODX 网站旁边部署 Next.js。测试一切。检查分析。验证表单有效。然后翻转 DNS。
选择无头 CMS 替代 MODX
Next.js 是你的前端，但你仍然需要管理内容的地方。以下是流行选项如何为 MODX 难民进行比较：
| CMS | MODX 开发人员的学习曲线 | 内容建模 | 定价（2026 年） | 自托管选项 |
|---|---|---|---|---|
| Sanity | 中等 | 优秀（代码定义的架构） | 免费层，然后 $15/用户/月 | 无（仅云） |
| Strapi | 低 | 良好（基于 UI） | 免费（自托管），云从 $29/月 | 是 |
| Contentful | 中等 | 良好 | 免费层，然后 $300/月 | 无 |
| Payload CMS | 低 | 优秀（代码定义的架构） | 免费（自托管），云从 $50/月 | 是 |
| Directus | 低 | 灵活 | 免费（自托管），云从 $99/月 | 是 |
如果你喜欢 MODX 的灵活性和自托管能力，Payload CMS 或 Strapi 会感觉最熟悉。如果你想要最好的开发者体验并且不介意仅云端，Sanity 很难击败。
我们通过我们的无头 CMS 开发实践对所有这些进行了广泛的工作，正确的选择确实取决于你的团队的舒适度和预算。
真实性能提升：迁移前后
我在 2025 年末将一个中等规模的 MODX 网站（大约 400 页，博客 + 服务 + 作品集）迁移到带有 Sanity 的 Next.js。以下是实际数字：
| 指标 | MODX（优化） | Vercel 上的 Next.js | 改进 |
|---|---|---|---|
| Lighthouse 性能 | 72 | 98 | +36% |
| 最大内容绘制 | 2.8s | 0.9s | -68% |
| 首字节时间 | 680ms | 45ms | -93% |
| Core Web Vitals 通过 | 部分 | 完全通过 | ✅ |
| 构建/部署时间 | 手动 FTP | 42s 自动部署 | 天地之别 |
| 月度托管成本 | $45/月（VPS） | $0（Vercel 免费层） | -100% |
TTFB 改进本身就是惊人的。MODX 必须引导 PHP、连接到 MySQL、运行代码片段、组装块并提供响应——即使有缓存。静态生成的 Next.js 页面从 CDN 边缘节点在毫秒内提供。
你会错过什么（以及你不会）
你会错过
- 管理器 UI：MODX 的管理面板对于内容编辑来说真的很直观。大多数无头 CMS 管理面板都有学习曲线。
- 上下文编辑：在看到它呈现的地方编辑内容。大多数无头设置需要在 CMS 和预览之间切换。（Sanity 的演示工具和 Payload 的实时预览正在缩小这个差距。）
- 简单性：一个服务器、一个数据库、一个代码库。其中有美。无头堆栈有更多的活动部件。
- 社区氛围：MODX 社区虽然很小，但很紧密，真的很有帮助。
你不会错过
- 清除缓存：无尽的缓存清除刷新循环。
- TV 管理：通过 UI 为每个字段创建和管理模板变量。
- 数据库焦虑：当你的 MySQL 连接在流量激增时用尽时那种沉陷的感觉。
- FTP 部署：或任何你用来推送更改的手动流程。
- 插件事件调试：尝试找出哪个插件何时触发，按什么顺序。
成本比较：运行 MODX 与 Next.js
让我们诚实地谈论总拥有成本，而不仅仅是托管。
| 成本类别 | MODX（年度） | Next.js + 无头 CMS（年度） |
|---|---|---|
| 托管 | $540-$1,200（VPS/共享） | $0-$240（Vercel/Netlify） |
| CMS 许可证 | $0（开源） | $0-$3,600（取决于 CMS） |
| SSL 证书 | $0-$100 | $0（包含） |
| CDN | $0-$600 | $0（包含） |
| 安全监控 | $200-$500 | 最少（无服务器） |
| 服务器维护 | $500-$2,000（时间或外包） | $0 |
| 开发人员小时费率 | $75-$120（稀缺人才） | $100-$175（充足的人才） |
| 总计（不包括开发时间） | $1,240-$4,400 | $0-$3,840 |
外卡是开发人员费率。MODX 开发人员每小时便宜如果你能找到他们。但稀缺推高了随着时间的推移的费率，你通常被限制在任何可用的人，而不是选择最合适的。
如果你正在评估你的特定情况的迁移成本，我们在这里分解了我们的定价方法——我们对这些项目的实际成本是透明的。
常见问题
典型的 MODX 到 Next.js 迁移需要多长时间？
对于有 100-500 页的网站，预期使用专门团队 6-10 周。内容建模和迁移需要约 2 周，构建 Next.js 前端需要 3-5 周，QA/测试/重定向填充其余部分。拥有复杂自定义代码片段或繁重电子商务集成的更大网站可能需要 12-16 周。最大的变量是需要重写多少自定义 PHP 逻辑。
我可以保留我的 MODX 管理面板并仅将 Next.js 用于前端吗？
从技术上讲，可以——你可以在 MODX 中构建 REST API 层并用 Next.js 使用它。但这给你两者最坏的情况：你仍然维护 PHP 服务器、MySQL 数据库和所有安全问题，同时也维护单独的前端。除非你有非常具体的原因，否则最好将内容迁移到专门构建的无头 CMS。
我会在迁移期间失去 SEO 排名吗？
如果你正确处理重定向，则不会。关键步骤是：尽可能保持相同的 URL 结构，为任何更改的 URL 设置 301 重定向，保持元数据完整，以及启动后向 Google Search Console 提交更新的站点地图。我们迁移的大多数网站在 4-8 周内看到排名改进，这是由于更好的 Core Web Vitals 分数。
FormIt 表单和复杂工作流的 MODX 网站怎么样？
表单是迁移中最棘手的部分之一。FormIt 在一个包中处理验证、电子邮件发送、钩子和垃圾邮件防护。在 Next.js 中，你通常会将 Server Actions 用于处理、Zod 用于验证以及 Resend 或 SendGrid 等服务用于电子邮件传递。这更加明确，但也更可测试和可靠。
对于简单的宣传册网站，Next.js 是否过度了？
也许。如果你的 MODX 网站实际上只有 10 个静态页面和一个联系表单，Astro 可能更合适——它默认不发送 JavaScript，设置更简单。但如果有任何可能你以后需要动态功能、身份验证或复杂数据获取，从 Next.js 开始会为你节省另一次迁移。
我的 MODX 扩展和自定义代码片段会怎样？
他们需要被重建。没有自动化转换。自定义代码片段变成 Next.js 中的 API 路由或服务器操作。Gallery、Articles 或 MIGX 等扩展被你的无头 CMS 的本机功能替代（通常更好）。Foxy 或 SimpleCart 等电子商务扩展将被 Shopify 的 Storefront API、Snipcart 或 Medusa 替代。在你的迁移时间表中明确计划这项工作。
我如何说服我的非技术利益相关者批准这次迁移？
专注于他们关心的三件事：风险、成本和结果。风险：MODX 的缩小社区意味着找到开发人员进行紧急情况变得每年都更难。成本：服务器维护和安全修补不是免费的，即使 CMS 许可证是。结果：向他们展示 Core Web Vitals 比较，并解释 Google 如何使用页面速度作为排名因素。如果他们的竞争对手以不到一秒的速度加载而他们以 3 秒的速度加载，那就是一个业务问题。
我可以逐步迁移还是必须一次全部迁移？
逐步迁移是可能的，使用反向代理设置——你会从 Next.js 提供新页面，并将旧页面路由到你的 MODX 服务器。我们已经用 nginx 配置做过这个，其中特定路径被代理到旧服务器，而其他一切都去新的 Next.js 部署。它增加了复杂性，但对于有数百页的网站，它让你在数周或数月内分阶段迁移，而不是进行有风险的大爆炸切换。
如果你坐在 MODX 网站上，感受到了我描述的痛点，最好的计划开始时间是现在。不是因为天空在下降，而是因为在压力下完成的迁移——在安全漏洞之后，在你的开发人员离职之后，在 PHP 版本到达生命周期结束之后——总是比计划的迁移更昂贵和更有压力。如果你想谈论你的具体情况，联系我们。我们已经经历过这个足够多的次数，知道地雷在哪里。