如果你管理 Joomla 網站已經有一段時間,當新主要版本發布時,你可能會感到一陣熟悉的不安感。Joomla 4 很艱難。Joomla 5 改善了一些問題。但 Joomla 6?它可能會成為這個 CMS 歷史上最具分裂性的版本。管理員面板的用戶體驗已被完全改造,擴充管理器從根本上改變,模板渲染有破壞性的變更影響幾乎每個自訂模板,社群也...處理得不太好。

自 Mambo 時代以來,我一直在建設和維護 Joomla 網站。我已經引導客戶度過了每次痛苦的主要版本更新。所以當我說 Joomla 6 感覺不同 — 而且不是好的方面 — 我不是在危言聳聽。讓我詳細介紹變更了什麼、為什麼資深管理員感到不滿,以及如果你正在考慮跳槽,有哪些真實的替代方案。

目錄

為什麼 Joomla 管理員對 Joomla 6 UX 變更感到憤怒

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 擴充生態系統的大部分還沒準備好。根據 Joomla 擴充目錄 (JED) 截至 2025 年初的數據,約 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 在傳統的 PHP 覆蓋旁邊引入 Twig 作為可選(但顯然是首選)的模板引擎。核心管理員模板現在用 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 支援,並專注於他們自己的頁面構建工具或過渡到其他平台。這是模板社群對這些變更看法的一個很有說服力的信號。

為什麼 Joomla 管理員對 Joomla 6 UX 變更感到憤怒 - 架構

社群反應:論壇、GitHub 和社交媒體

社群回應一直...激烈。而且大多是負面的。

GitHub 問題和拉取請求

Joomla GitHub 儲存庫看到了標記有 J6 里程碑的問題報告激增。幾位知名社群成員已開啟詳細問題,記錄用戶體驗倒退。一個特別值得注意的議題有超過 200 條評論,論證管理員面板變更在沒有充分社群諮詢的情況下被推動。

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

論壇情緒

Joomla 社群論壇和非官方 Joomla subreddit 已被沮喪的管理員帖子淹沒。常見主題包括:

  • 「為什麼要修補沒有損壞的東西?」 — 管理員面板用戶體驗雖然不完美,但實用且熟悉
  • 「擴充啟示錄」 — 擔心基於 Composer 的系統會殺死擴充生態系統
  • 「誰要求 Twig?」 — 模板開發人員對模板化引擎變更感到措手不及
  • 「遷移路徑在哪?」 — 缺乏清晰的、自動化的現有網站遷移工具

更廣泛的背景

這不是在真空中發生。Joomla 的市場份額一直在穩步下降。根據 2025 年 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 模板化層使平台對來自其他框架的開發人員更容易接近。管理員用戶體驗變更基於用戶研究(儘管研究方法論和樣本量受到質疑)。

2025 年初的 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 小時。差距沒有你想的那麼大,而無頭方法給你的是一個不斷增長的生態系統的平台,而不是萎縮的平台。

2025 年 Joomla 的實際替代方案

如果你認真考慮替代方案,這是對選項的誠實評估。

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

無頭 CMS 方法

我在這裡有偏見,因為這是我們在 Social Animal 所做的事情,但無頭 CMS 方法解決了不斷在像 Joomla 這樣的傳統 CMS 中重複出現的根本問題:內容管理與前端渲染的耦合。

當你的 CMS 是無頭時,CMS 中的管理員用戶體驗變更不會破壞你的前端。模板渲染由你的前端框架(Next.js、Astro,任何東西)處理,而不是 CMS。而且你的內容可通過 API 訪問,意味著你永遠不會被鎖定到單一渲染技術。

如果你對這種方法感興趣,我們已經進行了相當多的 Joomla 到無頭的遷移。我們的 無頭 CMS 開發 工作與前端上的 Next.jsAstro 配對效果很好,取決於你的需求。

WordPress:顯而易見的選擇?

每當有人詢問 Joomla 替代方案時,WordPress 是預設建議,這不是錯誤的。生態系統龐大,託管選項眾多,大多數網頁開發人員都知道它。

但 WordPress 有自己的用戶體驗爭議(區塊編輯器/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 目標在 2025 年底進行穩定版本發布,遵循項目的新時間表發布週期。Alpha 和 beta 版本已可用於測試。發布時間表已經滑動過幾次,所以確切日期仍不確定。

我的 Joomla 5 擴充會在 Joomla 6 中工作嗎? 沒有修改的話大多數不會工作。Joomla 6 的基於 Composer 的擴充系統需要新的清單格式和更新的命名空間宣告。依賴已棄用 API 或舊安裝路徑的擴充將破壞。在嘗試升級之前,請與每個擴充開發商檢查他們的 Joomla 6 兼容性路線圖。

我能否改為保持在 Joomla 5? 是的,目前是這樣。Joomla 5 將在 Joomla 6 穩定版本發布後約 2 年內收到安全更新,這意味著大約 2027 年底。之後,你就靠自己了。保持在不支援的 CMS 版本上是一個重大的安全風險,所以這充其量是一個臨時解決方案。

Joomla 社群實際上在為此分裂嗎? 有真實的緊張關係,但還沒有導致正式分叉(還沒)。幾位知名社群成員已公開退出貢獻。Joomla 社群已經度過了內部衝突,但結合市場份額下降和有爭議的技術決定,這個時期感覺比以往任何衝突都更加危險。

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

在判斷 Joomla 6 之前我應該等待它穩定嗎? 對於用戶體驗變更,這是公平的建議 — 新介面的第一印象通常比既定意見更嚴厲。但架構變更(Composer 擴充、Twig 模板)不會改變。那些是基本的設計決定。如果那些是你的關注,等待不會有幫助。

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

什麼是取代 Joomla 的最佳無頭 CMS? 這取決於你的團隊和需求。對於內容繁多的行銷網站,Sanity 或 Contentful 配合 Next.js 或 Astro 是很好的選擇。對於需要更多結構的網站,Strapi 或 Payload CMS 讓你對內容模型有更多的控制。任何無頭方法的關鍵優勢是你與 CMS 的前端渲染解耦 — 這意味著你永遠不會再面臨這種破壞模板的升級。