你的測試環境在凌晨3點完成 Joomla 6 更新。六小時後你打開管理員面板，發現一切都不在原來的位置。你記了八年的擴充功能管理器現在使用卡片式配置，隱藏了操作選項。那個耗時兩個衝刺週期才完成的自訂結帳範本因為框架層級的範本渲染變更而拋出致命錯誤。Joomla 4 強制進行痛苦的遷移。Joomla 5 修復了最嚴重的破損。但 Joomla 6 發佈時進行了深層的變更，導致 40% 的頂級擴充功能在發佈三個月後仍然沒有相容版本。社區論壇充滿了管理員問同樣的問題：現在終於是時候離開了嗎？

我從 Mambo 時代就開始構建和維護 Joomla 網站。我已經為許多客戶進行了每次痛苦的主版本更新遷移。所以當我說 Joomla 6 感覺不同時——並不是好的方式——我不是在誇大其詞。讓我詳細帶你了解到底改變了什麼，為什麼資深管理員很生氣，以及如果你正在考慮跳船，存在哪些現實的替代方案。

Joomla 6 管理員面板 UX 大改造

首先從最明顯的改變開始：管理員面板。Joomla 6 引入了開發團隊所稱的「現代管理體驗」。實際上，這意味著他們撕掉了 Joomla 4 以來 Joomla 管理員一直使用的熟悉左側邊欄導覽，用頂部導覽加上文脈側邊欄方式取代了它。

實際改變了什麼

舊的管理員面板有一個可摺疊的左側邊欄，帶有嵌套菜單項。你最多可以點兩下就進入 CMS 的任何部分。它不夠漂亮，但很實用——最重要的是，它是一致的。

Joomla 6 移到了水平頂部導覽欄，帶有下拉巨型菜單。左側邊欄現在只在文脈上出現，顯示與你目前所在部分相關的選項。文章管理、使用者管理、擴充功能配置——它們現在都有不同的側邊欄配置。

以下是導覽模式的比較：

操作 Joomla 5（點擊次數） Joomla 6（點擊次數） 備註
建立新文章 2 2-3 取決於目前文脈
存取全域配置 2 3 隱藏在「系統」菜單下
管理擴充功能 2 2-4 新的分類檢視增加了步驟
編輯範本檔案 3 4-5 範本編輯器重新定位
檢查系統資訊 2 3 移到子菜單
管理媒體檔案 2 2 基本相同

為什麼管理員厭惡它

核心投訴不是看起來不同。管理員可以適應視覺變化。問題在於肌肉記憶——使日常 CMS 管理可忍受的事物——被完全破壞了。

當你全天管理 15 個以上的 Joomla 網站並在它們之間切換時，你依賴於確切知道事物的位置而無需思考。Joomla 6 強制你重新學習所有東西。而文脈側邊欄意味著導覽在新系統中甚至不一致。根據你所在的位置，側邊欄顯示不同的項目，這使得建立新的肌肉記憶更加困難。

還有無障礙的角度。幾位社區成員報告說巨型菜單下拉列表對螢幕閱讀器的效果不佳，鍵盤導覽不一致。對於一個以無障礙為傲的開源 CMS，這是一個顯著的倒退。

儀表板小部件問題

Joomla 6 還引入了新的儀表板小部件系統，用來取代之前的儀表板模組。舊系統讓你以合理的靈活性新增和排列儀表板模組。新小部件系統在視覺上更吸引人，但配置性明顯較低。

你不再能為每個使用者群組建立自訂儀表板配置——這是許多 Joomla 代理機構用來為客戶建立簡化管理員體驗的功能。取而代之的是單一儀表板配置，具有個別小部件上的基於角色的可見性切換。這是功能退步，用設計進步的外衣打扮起來。

擴充功能管理器：你所知道的一切都錯了

這是真正令人痛苦的地方。Joomla 6 引入了完全重寫的擴充功能管理系統，它破壞了超過十年來擴充功能打包和安裝方式的相容性。

新的擴充功能架構

Joomla 6 移動到基於 Composer 的擴充功能管理系統。從紙面上看，這是個好主意。Composer 是 PHP 依賴管理的標準，使 Joomla 與現代 PHP 實踐保持一致是有意義的。

實際上，這意味著：

  • 擴充功能包現在必須包含 composer.json，具有適當的命名空間宣告
  • 舊的 XML 清單格式已棄用（在 6.0 中仍然有效但拋出警告，計畫在 6.2 中移除）
  • 擴充功能探索和安裝路徑已變更——參考舊路徑的自訂安裝指令碼將中斷
  • 更新伺服器協議已修改——使用舊更新 XML 格式的擴充功能需要遷移到新的基於 JSON 的更新清單
// 新的 Joomla 6 擴充功能清單 (composer.json 摘錄)
{
  "name": "vendor/my-joomla-extension",
  "type": "joomla-plugin",
  "require": {
    "joomla/cms": "^6.0"
  },
  "extra": {
    "joomla": {
      "element": "myextension",
      "group": "content",
      "namespace": "Vendor\\Plugin\\Content\\MyExtension"
    }
  }
}

擴充功能相容性危機

現實世界的影響是：Joomla 擴充功能生態系統的一大部分還沒準備好。根據 2026 年初 Joomla 擴充功能目錄 (JED) 的資料，大約 40% 的列出擴充功能還沒有針對 Joomla 5 相容性進行更新，更不用說 Joomla 6 了。

在 Joomla 5 相容的擴充功能中，早期測試表明大約 60-70% 的擴充功能需要進行非平凡的修改才能與 Joomla 6 的新擴充功能架構相容。我們不是在談論輕微調整。我們在談論重新構建擴充功能的打包和分發方式。

對於 Akeeba Backup、RSForm 和 JCE Editor 等流行擴充功能，開發人員已經宣佈 Joomla 6 相容版本正在開發中。但對於由獨立開發人員或小型團隊維護的數千個較小擴充功能呢？許多這些將簡單地被遺棄。

這對網站所有者意味著什麼

如果你的 Joomla 網站依賴五個或更多第三方擴充功能（大多數網站都這樣做），在考慮升級之前，你需要審查每一個。建立電子試算表。檢查每個擴充功能開發人員網站以了解 Joomla 6 公告。如果沒有提及 Joomla 6 支援，假設它不會運作。

到目前為止，我已經為三個客戶網站進行了這項審查。其中兩個至少有一個沒有 Joomla 6 路線圖的關鍵擴充功能。那是遷移阻礙。

範本渲染破損變更

Joomla 6 中的範本系統變更是讓經驗豐富的開發人員皺眉的那種東西。Joomla 已從其傳統的基於 PHP 的範本覆蓋系統移動到引入新範本化層的混合方法。

新的範本引擎

Joomla 6 引入了 Twig 作為傳統 PHP 覆蓋的可選（但明顯是首選）範本引擎。核心管理範本現在用 Twig 編寫。前端範本可以使用 PHP 或 Twig，但範本覆蓋探索系統已變更。

{# Joomla 6 Twig 範本範例 #}
{% extends "@joomla/base.html.twig" %}

{% block content %}
  <div class="com-content-article">
    <h1>{{ article.title | escape }}</h1>
    <div class="article-body">
      {{ article.introtext | raw }}
      {{ article.fulltext | raw }}
    </div>
  </div>
{% endblock %}

什麼會中斷

覆蓋發現順序已變更。在 Joomla 5 中，範本覆蓋位於 templates/your-template/html/com_content/article/default.php。這在 Joomla 6 中仍然有效，但如果 Twig 版本存在於 templates/your-template/html/com_content/article/default.html.twig，Twig 版本優先。

這意味著如果範本開發人員提供了 PHP 和 Twig 覆蓋（許多人會這樣做以支援過渡），你的自訂 PHP 覆蓋可能會被無聲地忽略。我已經在測試版中看到這傷害人們。

此外，範本參數系統已被重新設計。在 templateDetails.xml 中定義的範本參數現在需要在新的 template.config.php 檔案中有相應的項目。舊參數仍然加載，但實時預覽和視覺範本配置器等新功能只適用於新格式。

對商業範本的影響

JoomlArt、GavickPro 和 Youjoomla 等商業範本提供商處於困難的位置。他們的商業模式依賴於維護跨 Joomla 版本工作的範本框架。Twig 引入和覆蓋優先級變更意味著他們本質上需要重建他們的範本框架。

有些已宣佈他們將完全跳過 Joomla 6 支援，而專注於他們自己的頁面生成器工具或過渡到其他平台。這是範本社區如何看待這些變更的有力信號。

社區反應：論壇、GitHub 和社群媒體

社區反應一直很......激烈。大多數是負面的。

GitHub 問題和拉取請求

Joomla GitHub 儲存庫的問題報告激增，標記為 J6 里程碑。幾位知名社區成員已經開啟了詳細的問題，記錄 UX 倒退。一個特別值得注意的線程，有超過 200 條評論，論證了管理員面板變更是在沒有充分社區諮詢的情況下推行的。

引入新擴充功能管理器架構的拉取請求在審查期間受到重大反對，多位資深貢獻者投票反對合併。儘管如此，它還是被合併了，製作領導團隊引用了現代化程式碼庫的必要性。

論壇情緒

Joomla 社區論壇和非官方 Joomla subreddit 上充滿了來自沮喪管理員的貼文。常見主題包括：

  • 「為什麼要修復沒有壞的東西？」——管理員面板 UX 雖然不完美，但功能實用且熟悉
  • 「擴充功能啟示錄」——擔心基於 Composer 的系統會殺死擴充功能生態系統
  • 「誰要求 Twig？」——範本開發人員感到驚訝
  • 「遷移路徑在哪裡？」——缺乏針對現有網站的清晰、自動化遷移工具

更廣泛的背景

這不是發生在真空中。Joomla 的市場份額一直在穩步下降。根據 2026 年 W3Techs 的資料，Joomla 為大約 1.5% 已知 CMS 的網站提供動力，低於 2022 年的 2.6%。WordPress 超過 62%。每個有爭議的決定都會加速網站遠離該平台的遷移。

社區挫折不僅關於 Joomla 6 本身。這是多年來感覺專案領導層不聽實際日常使用該軟體的人的話的積累。Joomla 6 是催化劑，但怨恨一直在增加。

Joomla 領導層在說什麼

Open Source Matters (OSM) 委員會和 Joomla 製作領導層已經對批評做出回應，儘管許多人認為回應態度很差。

官方立場是這些改變對 Joomla 的長期生存是必要的。基於 Composer 的擴充功能系統使 Joomla 與現代 PHP 開發實踐保持一致。Twig 範本化層使該平台對來自其他框架的開發人員更容易存取。管理員 UX 變更是基於使用者研究的（儘管研究方法和樣本量受到質疑）。

2026 年初的 Joomla 製作部門部落格文章承認了過渡期的痛苦，但論證短期中斷對長期可行性是必要的。該貼文將比較與 Joomla 1.5 到 2.5 的過渡，這也很痛苦，但最終使平台前進。

這個比較是恰當的，但不是他們的本意。1.5 到 2.5 的過渡趕走了社區的大部分。許多使用者再也沒有回來。

你應該遷移還是離開？

這是每個人都在問的問題，老實的答案取決於你的具體情況。

留下如果...

  • 你的網站主要使用核心 Joomla 功能，沒有重度擴充功能依賴
  • 你的範本基於 Cassiopeia 或致力於 Joomla 6 支援的框架
  • 你有可以處理遷移工作的內部 PHP 開發人員
  • 你的組織因政治/機構原因致力於 Joomla

離開如果...

  • 你的網站依賴沒有 Joomla 6 路線圖的擴充功能
  • 你已經對 Joomla 感到沮喪，這是最後一根稻草
  • 你需要一個生態系統增長（不是萎縮）的平台
  • 遷移到另一個 CMS 的成本與升級到 Joomla 6 的成本相當

成本現實

這是人們不夠談論的東西：從 Joomla 5 遷移到 Joomla 6 可能花費幾乎與完全遷移到不同 CMS 一樣多。如果你需要重建範本、更新擴充功能、重新培訓員工並測試所有東西，無論目標平台如何，你都在尋找大量開發小時。

對於中等複雜 Joomla 網站（50-200 篇文章、5-10 個擴充功能、自訂範本），遷移到 Joomla 6 的工作可能需要 40-80 小時。遷移到無頭 CMS 設定加現代前端？60-120 小時。差距沒有你想像的那麼大，無頭方法為你提供一個增長的生態系統，而不是萎縮的生態系統。

2026 年 Joomla 的現實替代方案

如果你認真考慮替代品，以下是對可選項的誠實評估。

平台 最適合用於 學習曲線 生態系統規模 長期軌跡
WordPress 內容豐富的網站、部落格 低 龐大 穩定但 Gutenberg 有爭議
無頭 CMS + Next.js 性能關鍵網站、應用程式 中-高 快速增長 強勁上升
無頭 CMS + Astro 內容網站、行銷網站 中等 增長中 強勁上升
Drupal 企業、政府、複雜資料 高 大 穩定
Craft CMS 中等規模內容網站 中等 適度 穩定
Statamic Laravel 商店、內容網站 中等 增長中 正面

無頭 CMS 方法

我在這裡有偏見，因為這是我們在 Social Animal 所做的，但無頭 CMS 方法解決了一直在傳統 CMS（如 Joomla）中重複出現的基本問題：內容管理與前端渲染的耦合。

當你的 CMS 是無頭時，CMS 中的管理員 UX 變更不會破壞你的前端。範本渲染由你的前端框架（Next.js、Astro，無論如何）處理，而不是 CMS。你的內容可通過 API 存取，這意味著你永遠不會被鎖定為單一渲染技術。

如果你對這種方法感興趣，我們已經進行了不少 Joomla 到無頭的遷移。我們的無頭 CMS 開發工作與前端的 Next.js 或 Astro 配對良好，取決於你的需求。

WordPress：明顯的選擇？

當有人問起 Joomla 替代品時，WordPress 是默認建議，這並沒有錯。生態系統巨大，代管選項充裕，大多數網頁開發人員都知道它。

但 WordPress 有自己的 UX 爭議（區塊編輯器/Gutenberg 傳奇反映了 Joomla 6 中正在發生的一些事情）。而 WordPress 的市場主導地位使其成為攻擊的最大目標。如果你離開 Joomla 是因為治理問題，WordPress 目前的 Matt Mullenweg 情況也可能會讓你暫停。

Drupal：高級使用者的選擇

如果你的 Joomla 網站有複雜的內容關係、自訂內容類型或企業要求，Drupal 值得考慮。Drupal 11 是穩定的，Drupal 社區比 Joomla 更穩定（如果較小的話）。

缺點：Drupal 的學習曲線陡峭，開發成本通常高於 Joomla 或 WordPress。

實際有效的遷移策略

如果你決定離開 Joomla，以下是如何在不失去理智或 SEO 排名的情況下進行遷移。

步驟 1：內容審計

導出所有內容。Joomla 的資料庫結構文檔完善，你可以直接從 #__content、#__categories、#__menu 和 #__users 表中提取內容。不要依賴 Joomla 的內置導出工具——它們有限。編寫自訂 SQL 查詢或使用 Akeeba 的資料導出功能等工具。

步驟 2：URL 映射

這是每個人都跳過的步驟，也是破壞 SEO 的那個。為你的 Joomla 網站上的每個 URL 建立完整的地圖及其在新平台上的相應 URL。為每一個設定 301 重新導向。

# 範例：從 Joomla 資料庫產生 URL 清單
mysql -u root -p joomla_db -e "
  SELECT CONCAT('/', alias) as url, title
  FROM j_content
  WHERE state = 1
  ORDER BY id;
" > joomla_urls.csv

步驟 3：選擇你的目標架構

決定你是要另一個傳統 CMS 還是無頭設定。如果你的網站主要是內容驅動的（文章、部落格文章、文件），無頭 CMS 配合靜態優先前端框架（如 Astro）將為你提供明顯更好的性能。

步驟 4：並行遷移

不要嘗試進行大爆炸遷移。在舊網站旁邊設定新網站。分批遷移內容。充分測試。只有在你確信所有東西都有效時，才切換 DNS。

如果你需要幫助規劃，請聯繫我們。我們已經為 CMS 遷移開發了可重複的流程，可以保留 SEO 股份並最小化停機時間。你也可以檢查我們的定價頁面，了解遷移專案的大概數字。

常見問題

Joomla 6 何時正式發佈？ Joomla 6 的目標是在 2026 年末推出穩定版本，遵循該專案的新時間表發佈週期。Alpha 和 Beta 版本已經可用於測試。發佈時間表已經延遲了幾次，所以確切日期仍然不確定。

我的 Joomla 5 擴充功能會在 Joomla 6 中工作嗎？ 大多數不會在沒有修改的情況下工作。Joomla 6 的基於 Composer 的擴充功能系統需要新的清單格式和更新的命名空間宣告。依賴已棄用 API 或舊安裝路徑的擴充功能將中斷。在嘗試升級前，請與每個擴充功能開發人員確認他們的 Joomla 6 相容性路線圖。

我可以改為停留在 Joomla 5 上嗎？ 是的，目前可以。Joomla 5 將收到安全更新，直到 Joomla 6 穩定版發佈後約 2 年，大約 2028 年末。之後，你就靠自己了。停留在不受支援的 CMS 版本上是重大的安全風險，所以這充其量只是暫時的解決方案。

Joomla 社區是否因此而分裂？ 有真實的緊張局勢，但還沒有導致正式分叉（還沒有）。幾位傑出的社區成員已公開退出貢獻。Joomla 社區過去曾經歷過內部衝突，但市場份額下降和有爭議的技術決策的結合使這個時期感覺比過去的糾紛更加危險。

遠離 Joomla 的最便宜方式是什麼？ 最經濟有效的遷移路徑取決於你網站的複雜性。對於少於 100 頁的簡單內容網站，手動遷移到 WordPress 或無頭 CMS 可以在 20-30 小時內完成。對於具有自訂擴充功能的複雜網站，預期 80-150+ 小時。使用 CMS2CMS 等自動化遷移工具可以降低直接內容移動的成本，但無法處理自訂功能。

在判斷 Joomla 6 之前，我應該等待它穩定嗎？ 對於 UX 變更，這是公平的建議——第一印象通常比定居意見更嚴厲。但架構變更（Composer 擴充功能、Twig 範本）不會改變。那些是基本設計決策。如果這些是你的問題，等待無法幫助。

Joomla 6 與 Drupal 11 對企業網站的比較如何？ Drupal 11 通常是具有複雜內容模型、細粒度權限和 API 優先要求的企業級網站的更強選擇。Joomla 6 的現代化努力縮小了一些差距，但 Drupal 的企業用例生態系統（內容工作流程、多語言支援、無頭交付）更成熟。如果你已經在考慮遷移工作，Drupal 值得評估。

什麼是替代 Joomla 的最佳無頭 CMS？ 這取決於你的團隊和要求。對於內容豐富的行銷網站，Sanity 或 Contentful 配合 Next.js 或 Astro 是絕佳選擇。對於需要更多結構的網站，Strapi 或 Payload CMS 為你提供對內容模型的更多控制。任何無頭方法的關鍵優勢是你與 CMS 的前端渲染解耦——這意味著你永遠不會再面臨這種範本破損的升級。