Joomlaサイトをしばらく管理していれば、メジャーバージョンが落ちてくるたびに、あの親友みたいな不安感を感じたことがあるでしょう。Joomla 4は大変でした。Joomla 5はいくつかの粗を削りました。でもJoomla 6？これはCMSの歴史で最も分裂を招くリリースになろうとしています。管理画面のUXは完全に改装され、拡張機能マネージャーは根本的に異なり、テンプレートレンダリングは事実上すべてのカスタムテンプレートに影響を与える破壊的な変更があり、そしてコミュニティは...うまく処理できていません。

Mambo時代からJoomlaサイトを構築・保守してきました。痛みを伴うメジャーバージョン変更のたびにクライアントを移行させてきました。だからJoomla 6が違う感じがする—良い意味ではなく—と言うときは大げさではありません。何が変わったのか、なぜベテラン管理者が怒っているのか、そして船から飛び降りることを検討している場合に実現的にどんな選択肢があるのかを、正確に説明させてください。

目次

Why Joomla Admins Are Furious About Joomla 6 UX Changes

Joomla 6管理画面UXの完全改装

最も目に見える変更から始めましょう：管理画面です。Joomla 6は開発チームが「最新的な管理体験」と呼ぶものを導入しています。実際には、これはJoomla 4以来Joomla管理者が使用してきた親友のような左サイドバーナビゲーションを引き抜いて、トップナビゲーションとコンテキストに応じたサイドバーのアプローチに置き換えたことを意味します。

実際に何が変わったか

古い管理画面には、ネストされたメニュー項目を持つ折りたたみ可能な左サイドバーがありました。CMSのどのセクションにでも最大2クリックでアクセスできました。見た目は良くありませんでしたが、機能的で—重要なことに—一貫していました。

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は完全に書き直された拡張機能管理システムを導入し、10年以上の間拡張機能がパッケージ化・インストールされてきた方法との互換性を破ります。

新しい拡張機能アーキテクチャ

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拡張機能エコシステムのかなりの部分が準備できていません。2025年初期のJoomla Extensions Directory（JED）からのデータによると、リストされた拡張機能のおよそ40％はJoomla 5互換性のために更新されていません、Joomla 6については言うまでもなく。

Joomla 5互換性のある拡張機能のうち、初期テストはおよそ60-70％がJoomla 6の新しい拡張機能アーキテクチャで機能するために些細でない修正が必要になることを示唆しています。私たちは微調整について話しているのではありません。拡張機能のパッケージ化・配布方法の再構築について話しています。

Akeeba Backup、RSForm、JCE Editorのような一般的な拡張機能については、開発者はすでにJoomla 6互換性のあるバージョンが開発中であることを発表しています。しかし数千のソロ開発者や小さなチームによって保守されている小さな拡張機能については？それらの多くは単に放棄されるでしょう。

これがサイト所有者にとって意味すること

あなたのJoomlaサイトが5個以上のサードパーティ拡張機能に依存している場合（そしてほとんどはそうです）、アップグレードを考える前に、すべての拡張機能を監査する必要があります。スプレッドシートを作成してください。各拡張機能の開発者サイトをJoomla 6アナウンスメント用にチェックしてください。Joomla 6サポートについての言及がない場合、機能しないと仮定してください。

これまでに3つのクライアントサイトについてこの監査を行いました。そのうち2つは重大な拡張機能を少なくとも1つ持っており、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サポートを完全にスキップし、彼ら自身のページビルダーツールに焦点を当てるか、または別のプラットフォームに移行することを発表しました。これはテンプレートコミュニティがこれらの変更をどのように見ているかについての有意な信号です。

Why Joomla Admins Are Furious About Joomla 6 UX Changes - architecture

コミュニティの反応：フォーラム、GitHub、ソーシャルメディア

コミュニティの応答は...激しい。そしてほぼ否定的です。

GitHubの問題とプルリクエスト

Joomla GitHubリポジトリはJ6マイルストーンでタグ付けされた問題報告のスパイクを見ました。いくつかの高プロファイルコミュニティメンバーはUX後退を文書化する詳細な問題をオープンしました。特に注目すべきスレッド—200を超えるコメントで—は、管理画面の変更が十分なコミュニティ協議なしにプッシュされたと主張しています。

新しい拡張機能マネージャーアーキテクチャを導入したプルリクエストはレビュー中に重大な反発を受け、何人かの長期貢献者はマージに反対票を投じました。コードベースを最新化する必要があるとしてプロダクションリーダーシップチームを引用して、それでもマージされました。

フォーラムセンチメント

Joomla Community ForumとJoomlaのオフィシャルsubredditは、イライラした管理者からの投稿であふれています。一般的なテーマは以下を含みます：

  • 「何が壊れていないなら、なぜ修正するのか？」—管理画面UX、完璧ではありませんが、機能的で親友のような
  • 「拡張機能の黙示録」—Composerベースのシステムが拡張機能エコシステムを殺すという恐れ
  • 「誰がTwigを要求したのか？」—テンプレート開発者がテンプレーティングエンジン変更に不意を打たれた
  • 「移行パスはどこ？」—既存サイト用の明確な、自動化された移行ツールの欠如

より広いコンテキスト

これは真空の中で起こっていません。Joomlaの市場シェアは着実に低下しています。W3Techs 2025からのデータによると、Joomlaは既知のCMSを持つすべてのウェブサイトのおよそ1.5％を強化しており、2022年の2.6％から下がっています。WordPressは62％以上です。すべての物議を醸す決定は、サイトのプラットフォームから離れた移行を加速させます。

コミュニティの不満はJoomla 6について特定的ではありません。それは年間の蓄積で、プロジェクトリーダーシップは実際にソフトウェアを日々使用する人たちの言うことを聞かないと感じます。Joomla 6は触媒ですが、不満は蓄積されています。

Joomla指導部が言っていること

Open Source Matters（OSM）ボードとJoomlaプロダクションリーダーシップは批評に応答しましたが、多くはそれらの応答がトーンデフになっていると感じています。

公式の立場は、これらの変更がJoomlaの長期的な生存に必要であるということです。Composerベースの拡張機能システムはJoomlaをモダンPHP開発プラクティスに沿わせます。Twigテンプレート層は、他のフレームワークから来ている開発者にプラットフォームをより親友にしやすくします。管理UX変更はユーザー研究に基づいています（ただしリサーチ方法論とサンプルサイズは質問されています）。

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への移行はJoomla 5からまったく異なる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の管理UX変更がフロントエンドを破りません。テンプレートレンダリングはあなたのフロントエンドフレームワーク（Next.js、Astro、その他）によって処理されます、CMSではありません。そしてあなたのコンテンツはAPIを介してアクセス可能です、意味としてあなたは決してシングルレンダリング技術にロックされていません。

あなたがこのアプローチに興味がある場合、私たちはかなりの数のJoomlaからヘッドレスへの移行を行いました。私たちのヘッドレスCMS開発作業はNext.jsまたはあなたのニーズに依存してAstroのいずれかとフロントエンドで良く組み合わさります。

WordPress：明白な選択？

WordPressはだれかがJoomla代替案について尋ねるたびにデフォルト提案であり、それは間違っていません。エコシステムは莫大で、ホスティングオプションは豊富で、ほとんどの小売ウェブ開発者がそれを知っています。

しかしWordPressはそれ自身のUXです論争があります（ブロックエディタ/Gutenberg寿司はJoomla 6で起こるいくつかをミラーします）。そしてWordPressの市場支配は攻撃の最大のターゲットにしています。あなたがガバナンス懸念のためにJoomlaを去っている場合、WordPressの現在のMatt Mullenweg状況も一ポーズを与えるかもしれません。

Drupal：パワーユーザーの選択

Drupal はあなたのJoomlaサイトが複雑なコンテンツ関係、カスタムコンテンツタイプ、またはエンタープライズ要件を持つ場合、検討する価値があります。Drupal 11は堅実で、Drupalコミュニティはより安定しています（より小さい場合）Joomlaより。

欠点：Drupalの習得曲線は急勾配であり、開発コストは一般的にJoomlaまたはWordPressより高いです。

実際に機能する移行戦略

あなたはJoomlaを去ることを決めた場合、心と心も失わずにSEOランキングも失わずにどのように移行に接近するかです。

ステップ1：コンテンツ監査

すべてを輸出してください。Joomlaのデータベース構造は十分に文書化されており、直接#__content、#__categories、#__menu、#__usersテーブルからコンテンツを引き出すことができます。Joomlaの組み込みエクスポートツールに頼らないでください—それらは限定されています。カスタムSQLクエリを書くか、Akeebaのデータエクスポート機能のようなツールを使用してください。

ステップ2：URLマッピング

これはステップ1です。すべてはスキップします、そしてそれはあなたのSEOを破壊するものです。あなたのJoomlaサイト上のすべてのURLとそれに対応するURLのマップを新しいプラットフォーム上で完全に作成してください。一つひとつ301リダイレクトを設定してください。

# 例：Joomlaのデータベースからユーザーリストを生成
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が必要か、ヘッドレスセットアップが必要かを決めてください。あなたのサイトがプライマリコンテンツ駆動型（記事、ブログ投稿、ドキュメンテーション）の場合、Astroのようなスタティックファーストフロントエンドフレームワークを持つヘッドレスCMSは劇的に優れたパフォーマンスを与えます。

ステップ4：並列で移行

大きなバン移行をしないでください。古いものの隣に新しいサイトをセットアップしてください。バッチでコンテンツを移行してください。完全にテストしてください。あなたがすべてが機能していることを確信したときだけDNSをスイッチしてください。

あなたがこれを計画するのを手助ける必要がある場合、私たちに連絡してください。私たちはSEO資産を保護し、ダウンタイムを最小化するCMS移行のための反復可能なプロセスを開発しました。あなたはまたあなたの価格設定ページをチェックしてミグレーションプロジェクトの大ざっぱな数字を得ることができます。

FAQ

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コミュニティは実際にこれに分裂していますか？

本当の緊張がありますが、それは公式フォークに至っていません（yet）。いくつかの著名なコミュニティメンバーは公開して貢献することから後ろに下がりました。Joomlaコミュニティは過去に内部紛争を乗り越えていますが、市場シェア低下とまたは物議を醸す技術上の決定の組み合わせはこの期間をより危険に感じさせます。

Joomlaから移行する最も安い方法は何ですか？

最も費用効果的な移行経路はあなたのサイトの複雑さに依存します。100ページより少ないシンプルなコンテンツサイトの場合、WordPressまたはヘッドレスCMSへの手動移行は20-30時間で行うことができます。複雑なサイトでカスタム拡張機能の場合、80-150+時間を期待してください。CMS2CMSのような自動化された移行ツールを使用すると、単純なコンテンツ移動のコストを削減できますが、カスタム機能は処理しません。

Joomla 6が安定化するのを待ってから判断すべきですか？

UX変更にとってはそれは公正なアドバイスです—新しいインターフェースの最初の印象はしばしば定住した意見より厳しいです。しかし建築上の変更（Composer拡張機能、Twigテンプレート）は変わらないでしょう。これは根本的な設計決定です。もしそれがあなたの懸念なら、待つことは助けになりません。

Joomla 6は企業サイト向けのDrupal 11と比較されますか？

Drupal 11は一般的に複雑なコンテンツモデル、きめ細かい権限、API最初の要件を持つ企業グレードのウェブサイトに対してより強い選択です。エンタープライズ使用例のためのDrupalのエコシステム（コンテンツワークフロー、多言語サポート、ヘッドレス配信）はより成熟しています。あなたが既に移行努力を検討している場合、Drupalは評価する価値があります。

Joomlaを置き換えるための最良のヘッドレスCMSは何ですか？

それはあなたのチームと要件に依存します。コンテンツヘビーなマーケティングサイトの場合、Next.jsまたはAstroとペアになったSanityまたはContentfulは素晴らしい選択です。より多くの構造を必要とするサイトの場合、StrapiまたはPayload CMSはあなたのコンテンツモデルをより多く制御します。ヘッドレスアプローチの主な利点はあなたがCMSのフロントエンドレンダリングから分離していることです—意味としてあなたはこのタイプの壊れるアップグレードに直面することはありません。