為什麼 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 年，當時社群仍在努力推動發展。
BuiltWith 在 2026 年初的數據估計 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 基本上從開箱即用給你低於 1 秒的效能，具有靜態生成。你在 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 週
將 Next.js 與你現有的 MODX 網站一起部署。測試所有東西。檢查分析。驗證表單是否有效。然後切換 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.8 秒 | 0.9 秒 | -68% |
| 首位元組時間 | 680 毫秒 | 45 毫秒 | -93% |
| 核心網路生命力通過 | 部分 | 完全通過 | ✅ |
| 建構/部署時間 | 手動 FTP | 42 秒自動部署 | 天壤之別 |
| 月度託管成本 | $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 週內看到排名改進，這是由於更好的核心網路生命力分數。
FormIt 表單和複雜工作流程的 MODX 網站怎麼樣？
表單是遷移中較棘手的部分之一。FormIt 在一個套件中處理驗證、電子郵件傳送、掛鉤和垃圾郵件防護。在 Next.js 中，你通常會組合伺服器動作進行處理、Zod 進行驗證以及像 Resend 或 SendGrid 這樣的服務進行電子郵件傳遞。它更明確，但也更可測試和可靠。
Next.js 對於簡單的宣傳冊網站來說是否過度設計？
也許。如果你的 MODX 網站從字面上只是 10 個靜態頁面和一個聯繫表單，Astro 可能更適合——預設情況下它不傳送 JavaScript，設定更簡單。但如果有任何機會你以後需要動態功能、身份驗證或複雜的資料提取，從 Next.js 開始可以讓你避免另一次遷移。
我的 MODX extras 和自訂程式碼片段會發生什麼？
它們需要被重建。沒有自動轉換。自訂程式碼片段變成 Next.js 中的 API 路由或伺服器動作。Gallery、Articles 或 MIGX 等 Extras 被你無頭 CMS 的本地功能取代（通常更好）。像 Foxy 或 SimpleCart 這樣的電子商務 extras 將被 Shopify 的 Storefront API、Snipcart 或 Medusa 取代。在你的遷移時間表中明確計劃此工作。
我如何說服非技術利益相關者批准此遷移？
專注於他們關心的三件事：風險、成本和結果。風險：MODX 萎縮的社群意味著在緊急情況下找到開發人員變得每年越來越難。成本：伺服器維護和安全修補不是免費的，即使 CMS 授權也是如此。結果：向他們展示核心網路生命力比較，並解釋 Google 如何將頁面速度用作排名因素。如果他們的競爭對手在一秒以下加載，而他們在 3 秒，那是一個商業問題。
我可以逐步遷移還是必須一次性完成？
增量遷移是可能的，使用反向代理設定——你會從 Next.js 提供新頁面並將舊頁面路由到你的 MODX 伺服器。我們使用 nginx 配置完成過此操作，其中特定路徑被代理到舊伺服器，而其他所有內容都轉到新的 Next.js 部署。它增加了複雜性，但對於有數百頁的網站，它讓你在數週或數月內分階段遷移，而不是執行風險的大爆炸切換。
如果你坐在 MODX 網站上，並感受到我描述的痛點，最好的計劃時間是現在。不是因為天要塌下來，而是因為在壓力下進行的遷移——在安全漏洞之後、在開發人員辭職後、在 PHP 版本達到生命週期末期後——總是比計劃好的遷移更昂貴和更有壓力。與我們聯繫，如果你想談論你的具體情況。我們已經進行了足夠多次以知道地雷在哪裡。