為什麼 MODX 使用者應該在 2026 年遷移到 Next.js：誠實的看法
我自從 Evolution 時代以來就一直在 MODX 上構建網站。我編寫過自訂片段，與 TV（模板變數，不是電視機）搏鬥，並在無數 CMS 辯論中為 MODX 辯護。所以當我說這不是攻擊文章時，請相信我。這是來自曾經真正熱愛這個平台的人的警告。
但問題是：網頁開發世界已經向前發展，而 MODX 並未跟上。社群正在萎縮，發佈週期已經放緩到極其緩慢，人才庫正在消耗得比七月的水窪還快。如果你仍在 2026 年的 MODX 上運行生產網站，你需要認真考慮你的退出策略。對於大多數團隊來說，這個退出通向 Next.js。
讓我告訴你為什麼——誠實地，沒有炒作。
目錄
- 2026 年 MODX 的現狀
- MODX 做對的地方（仍然做對）
- 你再也不能忽視的問題
- 為什麼 Next.js 是自然的遷移目標
- 遷移路徑：MODX 到 Next.js
- 選擇無頭 CMS 來替代 MODX
- 實際性能提升：遷移前後
- 你會錯過什麼（以及你不會）
- 成本比較：運行 MODX vs 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]] 這樣的塊，你已經在元件中思考。你只是沒有 props。
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 等價物 |
|---|---|
| 模板 | 版面配置元件 |
| 塊 | React 元件 |
| 片段 | 伺服器動作 / API 路由 |
| 模板變數 | CMS 欄位 |
| 資源 | 頁面 / 內容條目 |
[[*field]] 標籤 |
Props / 資料擷取 |
| 外掛程式（事件鉤子） | 中介軟體 |
[[!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/user/mo | 否（僅雲） |
| Strapi | 低 | 不錯（基於 UI） | 免費（自行託管），雲從 $29/mo | 是 |
| Contentful | 中等 | 不錯 | 免費層，然後 $300/mo | 否 |
| Payload CMS | 低 | 優秀（代碼定義的結構） | 免費（自行託管），雲從 $50/mo | 是 |
| Directus | 低 | 靈活 | 免費（自行託管），雲從 $99/mo | 是 |
如果你喜歡 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% |
| 核心網頁生命力通過 | 部分 | 完整通過 | ✅ |
| 建置/部署時間 | 手動 FTP | 42s 自動部署 | 白天和黑夜 |
| 月度託管成本 | $45/mo（VPS） | $0（Vercel 免費層） | -100% |
僅 TTFB 改進就令人震驚。MODX 必須啟動 PHP、連接到 MySQL、執行片段、組裝塊並提供回應——即使使用快取。靜態產生的 Next.js 頁面在毫秒內從 CDN 邊緣節點提供。
你會錯過什麼（以及你不會）
你會錯過
- 管理員 UI：MODX 的管理面板對內容編輯器來說確實很直觀。大多數無頭 CMS 管理面板都有學習曲線。
- 脈絡內編輯：在看到它呈現的地方編輯內容。大多數無頭設定需要在 CMS 和預覽之間切換。（Sanity 的演示工具和 Payload 的實況預覽正在縮小這一差距。）
- 簡單性：一台伺服器、一個資料庫、一個程式碼庫。這有其美妙之處。無頭堆疊有更多活動部分。
- 社群氛圍：MODX 社群雖然很小，但非常親密和充滿幫助。
你不會錯過
- 清除快取：無盡的清除快取刷新週期。
- TV 管理：為每個欄位通過 UI 建立和管理模板變數。
- 資料庫焦慮：當你的 MySQL 連接在流量尖峰時達到上限時的那種沉沒感。
- FTP 部署：或任何你用來推送更改的手動過程。
- 外掛程式事件除錯：試圖找出哪個外掛程式何時、以什麼順序發動。
成本比較：運行 MODX vs 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 週內看到排名改進，這歸因於更好的核心網頁生命力分數。
MODX 網站帶有 FormIt 表單和複雜的工作流程怎麼樣？
表單是遷移中較棘手的部分之一。FormIt 在一個軟體包中處理驗證、電子郵件發送、鉤子和垃圾郵件防護。在 Next.js 中，你通常會組合伺服器動作以進行處理、Zod 以進行驗證，以及像 Resend 或 SendGrid 這樣的服務以進行電子郵件傳遞。它更明確，但也更可測試和可靠。
對於簡單的宣傳冊網站，Next.js 是不是過度設計了？
可能是。如果你的 MODX 網站實際上是 10 個靜態頁面和一個聯絡表單，Astro 可能是更好的選擇——它默認不發送 JavaScript，設定更簡單。但如果你以後有任何需要動態功能、身份驗證或複雜資料擷取的可能性，從 Next.js 開始可以防止你進行另一次遷移。
我的 MODX 擴充和自訂片段會發生什麼？
他們需要被重建。沒有自動轉換。自訂片段在 Next.js 中成為 API 路由或伺服器動作。像 Gallery、Articles 或 MIGX 這樣的擴充被你的無頭 CMS 的本地功能（通常更好）替代。像 Foxy 或 SimpleCart 這樣的電子商務擴充將被 Shopify 的店面 API、Snipcart 或 Medusa 替代。在你的遷移時間表中明確計劃這項工作。
我如何說服我的非技術性利益相關者批准這次遷移？
專注於他們關心的三件事：風險、成本和結果。風險：MODX 不斷萎縮的社群意味著在緊急情況下尋找開發人員變得每年都更難。成本：伺服器維護和安全修補並非免費的，即使 CMS 許可證是。結果：向他們展示核心網頁生命力比較，並解釋 Google 如何使用頁面速度作為排名因素。如果他們的競爭對手以不到一秒的速度加載，而他們則是 3 秒，那就是一個商業問題。
我可以逐步遷移還是必須一次性完成？
使用反向代理設定可以進行增量遷移——你將提供新頁面來自 Next.js，並將舊頁面路由到你的 MODX 伺服器。我們已經使用 nginx 配置完成了這種操作，其中特定路徑被代理到舊伺服器，而其他所有內容都進入新 Next.js 部署。它增加了複雜性，但對於有數百頁的網站，它讓你在數週或數月內分階段遷移，而不是進行有風險的大爆炸式切換。
如果你正在運行 MODX 網站並感受到我描述的痛點，最好的開始規劃時機是現在。不是因為天空要塌下來，而是因為在壓力下進行的遷移——在安全漏洞之後、在你的開發人員離職之後、在 PHP 版本達到生命週期終點之後——總是比計劃的更昂貴和更有壓力。如果你想討論你的特定情況，請與我們聯絡。我們已經經歷過足夠多次，知道地雷在哪裡。