MODXのEvolution時代からサイトを構築してきました。カスタムスニペットを書き、TV（テンプレート変数であり、テレビではありません）と格闘し、無数のCMSの議論でMODXを擁護してきました。だから、これが批判記事ではないことを信じてください。これは、このプラットフォームを心から愛していた人からの警鐘です。

しかし、ここが問題です。Webの開発世界は先に進み、MODXはそれについていっていません。コミュニティは縮小し、リリースサイクルは停滞し、人材プールは7月の水たまりのように早く乾いています。2026年にまだ本番サイトをMODXで実行している場合は、終了戦略を真剣に検討する必要があります。ほとんどのチームにとって、その終了はNext.jsにつながります。

理由を説明します。正直に、大げさではなく。

目次

2026年にMODXユーザーがNext.jsに移行すべき理由：正直な見方

2026年のMODXの状態

数字を正直に見てみましょう。MODX 3.xはしばらく前から存在していますが、採用は...控えめです。かつて活気に満ちていたMODXフォーラムは、今では週にわずか数個の投稿しか見られません。公式のGitHubリポジトリは、ますますまばらなコミットアクティビティを示しています。2018年または2019年と比べてください。当時、コミュニティはまだ頑張っていました。

2026年初頭のBuiltWithデータは、MODXが約0.3％のCMS検出Webサイトを動かしていると推定しており、2021年の約0.7％から低下しています。WordPressはまだ約62％で支配していますが、Next.jsベースのサイト（多くの場合、ヘッドレスCMSと組み合わせ）のような新しいプレーヤーは、年間約40％で成長しています。

MODXマーケットプレイス（以前のExtrasリポジトリ）は、何ヶ月も意味のある新しい拡張機能を見ていません。多くの人気のあるエクストラはメンテナンスされていないか、MODX 3.xとのみ部分的に互換性があります。エコシステムが生産を停止した場合、それは赤旗ではありません。それは白旗です。

MODXが死んでいると言っているのではありません。それでも機能します。あなたのサイトはまだ実行されています。しかし「まだ機能している」は、Web開発で危険な場所です。

MODXが正しかったこと（そして今でもそう）

批判を積み重ねる前に、正当な場所に信用を与えましょう。MODXは、ほとんどのCMSが今でも間違っている多くのことを釘付けにしました：

真のコンテンツの柔軟性

MODXは、「投稿とページ」のパラダイムを強制することはありませんでした。テンプレート変数、チャンク、スニペットは、「構造化されたコンテンツ」がバズワードになる数年前に、本当のコンテンツモデリングの自由を与えました。何でも構築できます。

クリーンな出力

MODXは独自のマークアップを注入しませんでした。謎のCSSクラスなし、要求されなかったラッパーdivなし。あなたのHTMLはあなたのHTMLでした。クラフトを気にするフロントエンド開発者にとって、これは啓示でした。

開発者向けテーマ作成

学ぶべきテーマシステムがなく、覚える必要があるテンプレート階層もありません。あなたはテンプレートを書きました。それだけでした。チャンクは再利用可能な部分です。スニペットはPHPロジックです。単純なメンタルモデル、強力な結果。

タグ構文

[[*pagetitle]]と[[!MySnippet]]について何を言いたいのかは関係ありません。一度学んだら、複雑なページを素早く構築できます。!キャッシュなしフラグを使用したキャッシングレイヤーは優雅でした。

これらの強みは、実はMODX開発者を、近代的なヘッドレスアーキテクチャの素晴らしい候補にしています。すでに構造化されたコンテンツとコンポーネントベースのテンプレートで思考している場合、Next.jsへの道を既に半分進んでいます。

もはや無視できない問題

ここで、私は率直である必要があります。

セキュリティの懸念

MODX 3.xは多くの歴史的な脆弱性に対処しましたが、公開管理パネルを備えた任意のPHPモノリスを実行することは、本質的なリスクベクトルです。2025年に、MODXのインストールに影響を与える少なくとも2つの重大なCVEが見られました。修正には数週間かかりました。縮小しているセキュリティチームでは、応答時間は改善していません。

VercelまたはNetlifyにデプロイされたNext.jsサイトと比較してください。攻撃するサーバーは文字通りありません。ブルートフォース攻撃する管理パネルがありません。利用するPHPはありません。攻撃サーフェスは基本的に小さいです。

人材危機

2026年にMODXデベロッパーを雇ってみてください。先に進みます。求人情報を投稿して、クリケットを見てください。開発者プールはReact、Next.js、および最新のJavaScriptフレームワークに移行しました。PHPの才能でさえMODXではなくLaravelに向かっています。

これは理論的な懸念ではありません。私は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では、それを台無しにするために戦っています。

2026年にMODXユーザーがNext.jsに移行すべき理由：正直な見方 - アーキテクチャ

Next.jsが自然な移行ターゲットである理由

あなたは聞くかもしれません。なぜWordPressではなく？なぜAstroではなく？なぜ単に静的サイトジェネレータを使用しないのか？

すべて有効なオプションですが、Next.jsはほとんどのMODX移行のためにスイートスポットにぶつかります。理由は次のとおりです：

レンダリングの柔軟性はMODXの思考を反映しています

MODXデベロッパーはすでに、異なるページが異なるキャッシング戦略を必要とすることを理解しています。MODXでは、スニペットをキャッシュされたまたはキャッシュされていないものとしてマークします。Next.jsでは、ページごとに静的サイト生成（SSG）、増分静的再生成（ISR）、またはサーバー側レンダリング（SSR）の間で選択します。同じコンセプト、より良い実行。

コンポーネントアーキテクチャはチャンクを置き換えます

MODXチャンクは再利用可能なHTMLの部分です。Reactコンポーネントは、組み込みロジック付きの再利用可能なUIの部分です。[[!$header]]や[[!$footer]]のようなチャンクを書いている場合、既にコンポーネントで考えています。あなたはただpropを持っていませんでした。

APIルートはスニペットを置き換えます

MODXスニペットはサーバー側のロジック（フォーム処理、API呼び出し、カスタムクエリ）を処理します。Next.js APIルート（またはNext.js 14以降のサーバーアクション）は同じことを行いますが、JavaScriptまたはTypeScriptでより優れたツールとテストサポートがあります。

代替案を検討しているチームについては、Astroは、あまり相互作用が必要ないコンテンツ豊富なサイトを評価する価値があります。ただし、動的機能、認証済みエクスペリエンス、または複雑なデータ取得が必要な場合は、Next.jsがより強い選択です。

移行パス：MODXからNext.js

実用的に行きましょう。MODX-to-Next.jsの移行は実際にどのように機能するかです。

ステップ1：コンテンツモデルの監査

すべてのMODXテンプレート、テンプレート変数、およびリソースタイプをマップします。これは、選択するヘッドレスCMSのコンテンツモデルになります。すべてをドキュメント化します：

## リソース：ブログ投稿
- pagetitle → title (text)
- longtitle → seo_title (text)
- content → body (rich text)
- TV: hero_image → hero_image (media)
- TV: author → author (reference)
- TV: category → category (taxonomy)

ステップ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は、新しいNext.js同等物への301リダイレクトが必要です。リダイレクトマップを作成し、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をフリップします。

MODXに代わるヘッドレスCMSの選択

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ページ、ブログ+サービス+ポートフォリオ）をNext.jsとSanityに移行しました。実際の数は次のとおりです：

メトリック MODX（最適化） Vercel上のNext.js 改善
Lighthouse パフォーマンス 72 98 +36%
最大の内容豊富なペイント 2.8秒 0.9秒 -68%
最初のバイトまでの時間 680ms 45ms -93%
Core Web Vitals パス 部分 フルパス ✅
ビルド/デプロイ時間 手動FTP 42秒自動デプロイ 歴然
月額ホスティングコスト $45/月（VPS） $0（Vercel無料階層） -100%

TTFB改善だけでも驚異的です。MODXはPHPをブートし、MySQLに接続し、スニペットを実行し、チャンクを組み立て、応答を提供する必要があります。キャッシング時でも。静的に生成されたNext.jsページは、数ミリ秒でCDNエッジノードから提供されます。

失うもの（失わないもの）

あなたは失うものです

  • マネージャーUI：MODXの管理パネルは、コンテンツエディタにとって本当に直感的です。ほとんどのヘッドレスCMS管理パネルには学習曲線があります。
  • コンテキスト内編集：レンダリングされた場所でコンテンツを編集します。ほとんどのヘッドレスセットアップでは、CMSとプレビューを切り替える必要があります。（SanityのプレゼンテーションツールとPayloadのLivePreviewはこのギャップを縮めています。）
  • シンプルさ：1つのサーバー、1つのデータベース、1つのコードベース。その中に美しさがあります。ヘッドレススタックにはより多くの移動部品があります。
  • コミュニティの雰囲気：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デベロッパーは、見つかれば時給当たり安いです。しかし、スカーシティは時間とともに料金を上げます。しばしば利用可能な人が誰でもあなたは選択肢ではなく、最適な適切を選択します。

特定の状況に関する移行コストを評価する場合、ここで価格設定アプローチを説明しています。これらのプロジェクトが実際にどのくらい費用がかかるのかについて、透明性があります。

FAQ

典型的なMODXからNext.jsへの移行にはどのくらい時間がかかりますか？

100～500ページのサイトの場合、専用チームで6～10週間を想定してください。コンテンツモデリングと移行は約2週間、Next.jsフロントエンドの構築は3～5週間、QA/テスト/リダイレクトは残りを埋めます。複雑なカスタムスニペットまたは重いe-コマース統合を備えた大規模なサイトは12～16週間かかります。最大の変数は、書き直す必要があるカスタムPHPロジックの量です。

MODX管理パネルを保持して、フロントエンドにNext.jsを使用できますか？

技術的には、はい。MODXにREST APIレイヤーを構築して、Next.jsで消費できます。しかし、これはあなたに両方の世界の最悪をあたえます：あなたはまだPHPサーバー、MySQLデータベース、およびすべてのセキュリティ上の懸念を維持しながら、別のフロントエンドも維持します。非常に具体的な理由がない限り、目的に構築されたヘッドレスCMSにコンテンツを移行する方が良いです。

移行中にSEOランキングを失いますか？

リダイレクトを適切に処理すれば、いいえ。重要なステップは：可能な限り同じURL構造を維持、変更されるURLの301リダイレクトを設定、メタデータを保持、更新されたサイトマップをGoogle Search Consoleに送信することです。移行したほとんどのサイトでは、より良いCore Web Vitalsスコアのため、4～8週間以内にランキングの改善が見られます。

FormItフォームと複雑なワークフローを使用しているMODXサイトはどうですか？

フォームは移行のより難しい部分の1つです。FormItは、1つのパッケージでの検証、電子メール送信、フック、およびスパム防止を処理しました。Next.jsでは、一般的にサーバーアクションを処理用に、検証用にZodを、電子メール配信用にResendまたはSendGridのようなサービスと組み合わせます。より明示的ですが、より試験可能で信頼性があります。

シンプルなパンフレットサイトにはNext.jsは過剰ですか？

多分。あなたのMODXサイトが文字通り10個の静的ページと連絡先フォームである場合、Astroはより適切かもしれません。デフォルトではゼロのJavaScriptを出荷し、セットアップが簡単です。しかし、動的機能、認証、または複雑なデータ取得の必要性がある可能性がある場合、Next.jsで開始することは、別の移行から救われます。

MODXのエクストラとカスタムスニペットはどうなりますか？

再構築する必要があります。自動変換はありません。カスタムスニペットはNext.jsでAPIルートまたはサーバーアクションになります。Gallery、Articles、またはMIGXのようなエクストラは、ヘッドレスCMSのネイティブ機能で置き換えられます（通常はより優れています）。FoxyやSimpleCartのようなe-コマースエクストラは、ShopifyのストアフロントAPI、Snipcart、またはMedusaに置き換えられます。この努力を明示的に移行タイムラインで計画します。

技術的でないステークホルダーにこの移行を承認するように説得するにはどうすればよいですか？

彼らが気にする3つのことに焦点を当てます。リスク、コスト、結果。リスク：MODXのコミュニティの縮小は、緊急時のためにデベロッパーを見つけることが毎年難しくなっていることを意味しています。コスト：サーバーのメンテナンスとセキュリティパッチは、CMSライセンスが無料でも無料ではありません。結果：Core Web Vitals比較を見せて、Googleがランキング要因としてページ速度を使用する方法を説明します。競合他社が1秒未満で読み込まれており、3秒で速い場合、それはビジネス上の問題です。

段階的に移行できますか。または全て一度にする必要がありますか？

段階的な移行は、リバースプロキシセットアップを使用して可能です。新しいページをNext.jsから提供し、レガシーページをMODXサーバーにルーティングします。nginx設定を使用してこれを行いました。特定のパスは古いサーバーにプロキシされ、他はすべて新しいNext.jsデプロイメントに行きます。複雑性を追加しますが、数百ページのサイトの場合、数週間または数ヶ月の段階で移行できます。危険な大爆発カットオーバーではなく。

MODXサイトに座っていて、説明した痛みを感じている場合、計画を立てるのに最も良い時期は今です。空が落ちているからではなく、セキュリティ侵害の後、開発者が辞めた後、またはPHPバージョンがサポート終了に達した後に圧力の下で行われた移行は、計画されたものより常に高価でストレスがあります。特定の状況を通じて話したい場合は、お問い合わせください。地雷がどこにあるかを知るのに十分な時間これを行ってきました。