ステージング環境でのJoomla 6アップデートが午前3時に完了する。6時間後、管理パネルを開くと、これまでと同じ場所に何もない。8年間使い込んできた拡張機能マネージャーはカード形式のレイアウトになり、アクションは隠れている。2スプリントかけて構築したカスタムチェックアウトテンプレートは、フレームワークレベルでテンプレートレンダリングが変更されたために致命的エラーをスローする。Joomla 4は苦しい移行を強いた。Joomla 5は最悪の問題にパッチを当てた。しかし、Joomla 6はリリース後3ヶ月の時点で、トップ100の拡張機能の40%がまだ互換バージョンを持たないほど深い変更とともにリリースされた。コミュニティフォーラムは同じ質問をするプロジェクト管理者でいっぱいだ：そろそろ去るべき時が来たのか？

Mambo時代からJoomlaサイトを構築・保守してきた。すべての苦しいメジャーバージョン移行をクライアントに説明してきた。だから、Joomla 6は異なる感じがする—良い意味ではなく—と言うとき、大げさではない。正確に何が変更されたのか、なぜ長年のプロジェクト管理者が怒っているのか、そして移行を検討している場合に現実的な選択肢は何かを詳しく説明しよう。

Joomla 6管理パネルのUXオーバーホール

最も目立つ変更から始めよう：管理パネルだ。Joomla 6では開発チームが「モダンな管理画面」と呼ぶものが導入される。実際には、Joomla 4から使用されていたおなじみの左側バーナビゲーションが廃止され、トップナビゲーション＋文脈依存サイドバーアプローチに置き換わる。

実際に何が変わったのか

古い管理パネルには、折りたたみ可能な左側バーにネストされたメニュー項目があった。CMSのどのセクションにも最大2クリックで到達できた。見栄えは良くなかったが、機能的で—重要なことに—一貫性があった。

Joomla 6は水平のトップナビゲーションバーにドロップダウンメガメニューを移動させる。左側バーは現在のセクションに関連するオプションを表示する場合にのみ表示される。記事管理、ユーザー管理、拡張機能設定—それらすべて異なるサイドバーレイアウトを持つようになった。

ナビゲーションパターンの比較：

アクション Joomla 5（クリック数） Joomla 6（クリック数） 備考
新しい記事の作成 2 2-3 現在のコンテキストによる
グローバル設定へのアクセス 2 3 システムメニューの下に埋もれている
拡張機能の管理 2 2-4 新しいカテゴリ化ビューが手順を追加
テンプレートファイルの編集 3 4-5 テンプレートエディタが移動
システム情報の確認 2 3 サブメニューに移動
メディアファイルの管理 2 2 概ね同等

プロジェクト管理者がなぜ嫌うのか

コア的な不満は見た目が異なることではない。プロジェクト管理者は視覚的な変更に適応できる。問題は筋肉記憶だ—日々のCMS管理を耐えられるものにする要素—が完全に壊れていることだ。

1日中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拡張機能エコシステムの重要な部分は準備ができていない。2026年初期のJoomla Extensions Directory（JED）のデータによると、リストされている拡張機能の約40%はJoomla 5互換性のために更新されていない。

Joomla 5互換の拡張機能のうち、早期テストではJoomla 6の新しい拡張機能アーキテクチャで動作するために約60-70%が重大な修正を必要とすることが示唆されている。マイナーな調整について話しているのではない。拡張機能がどのようにパッケージされ、配布されるかを再構成することについて話しています。

Akeeba Backup、RSForm、JCE Editorなどの人気のある拡張機能では、開発者はJoomla 6互換バージョンが開発中であると既に発表している。しかし、ソロ開発者または小さなチームによって保守される数千の小さな拡張機能の場合？これらの多くは単に放棄されるだろう。

これはサイト所有者にとって何を意味するのか

あなたのJoomlaサイトが5つ以上のサードパーティ拡張機能に依存している場合（ほとんどはそうである）、アップグレードを考える前にすべてをあたる必要がある。スプレッドシートを作成する。各拡張機能の開発者サイトでJoomla 6のお知らせを確認する。Joomla 6サポートについて言及がない場合、機能しないと仮定する。

これまでに3つのクライアントサイトでこの監査を行った。そのうち2つはJoomla 6ロードマップなしの重要な拡張機能を少なくとも1つ持っている。それは移行ブロッカーだ。

テンプレートレンダリング破壊的変更

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コミュニティフォーラムと非公式のJoomla Subredditは、フラストレートしたプロジェクト管理者からのポストにあふれている。共通のテーマは以下を含む：

  • 「なぜ壊れていないものを修正するのか？」—管理パネルUXは完全ではなかったが、機能的で親しみやすかった
  • 「拡張機能の黙示録」—Composerベースのシステムが拡張機能エコシステムを殺す恐れ
  • 「誰がTwigを求めたのか？」—テンプレート開発者がテンプレートエンジンの変更に驚いている
  • 「移行パスはどこにあるのか？」—既存サイトのための明確で自動化された移行ツールが不足している

より広い背景

これは真空状態で起こっていない。Joomlaの市場シェアは着実に減少している。2026年のW3Techsデータによると、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変更はユーザー調査に基づいている（ただし研究方法論とサンプルサイズは疑問视されている）。

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アプローチは、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を去ることに決めたなら、ここはあなたがあなたの心や検索エンジン最適化ランキングを失うことなく移行にアプローチする方法である。

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

すべてをエクスポートする。Joomlaのデータベース構造は十分に文書化されており、#__content、#__categories、#__menu、#__usersテーブルから直接コンテンツをプルできます。Joomlaの組み込みエクスポートツールに依存しない—それらは制限されている。カスタムSQLクエリを記述するか、Akeebaのデータエクスポート機能などのツールを使用する。

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

これはすべての人がスキップするステップであり、検索エンジン最適化を破壊するそれだ。JoomlaサイトのすべてのURLと新しいプラットフォーム上のそれに対応する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エクイティを保存し、ダウンタイムを最小化する。また、移行プロジェクトのおよその数値については価格ページを確認できます。

FAQ

Joomla 6の公式リリースはいつですか？

Joomla 6は、プロジェクトの新しい時間ベースのリリースサイクルに従って、2026年後期に安定リリースを対象としている。アルファとベータバージョンはテスト用に既に利用可能。リリースタイムラインは数回移動しているため、正確な日付は流動的なままだ。

私の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ファースト要件を持つエンタープライズグレードのウェブサイトのための強い選択肢だ。エンタープライズ使用の場合のDrupalのエコシステム（コンテンツワークフロー、多言語サポート、ヘッドレス配信）はJoomla 6のより成熟している。あなたが既に移行のセットアップを考えているなら、Drupalは評価する価値がある。

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

それはあなたのチームと要件に依存する。コンテンツ豊富なマーケティングサイトの場合、SanityまたはContentfulは、Next.jsまたはAstroと組み合わせて、優れた選択肢だ。より多くの構造が必要なサイトの場合、StrattiまたはPayload CMSはあなたのコンテンツモデルの上により多くの制御を与える。すべてのヘッドレスアプローチの利点は、CMSのフロントエンドレンダリング—あなたがこの種のテンプレート破壊アップグレードに直面することは二度とないという意味である。