Warum MODX-Nutzer 2026 zu Next.js migrieren sollten: Eine ehrliche Einschätzung
Ich bin seit den Evolution-Tagen ein MODX-Entwickler. Ich habe benutzerdefinierte Snippets geschrieben, mich mit TVs (Template Variables, nicht Fernsehgeräten) herumgeschlagen und MODX in unzähligen CMS-Debatten verteidigt. Glauben Sie mir also, wenn ich sage, dass dies kein Angriff ist. Es ist ein Weckruf von jemandem, der diese Plattform wirklich geliebt hat.
Aber hier ist das Problem: Die Welt der Webentwicklung hat sich weiterbewegt, und MODX ist nicht mitgekommen. Die Community schrumpft, der Release-Zyklus hat sich zu einem Schneckentempo verlangsamt, und der Talentpool trocknet schneller aus als eine Pfütze im Juli. Wenn Sie 2026 immer noch Produktionsseiten auf MODX betreiben, müssen Sie Ihre Ausstiegsstrategie ernsthaft überdenken. Und für die meisten Teams führt dieser Ausstieg zu Next.js.
Lassen Sie mich Ihnen erklären, warum — ehrlich, ohne den Hype.
Inhaltsverzeichnis
- Der Zustand von MODX im Jahr 2026
- Was MODX richtig gemacht hat (und immer noch tut)
- Die Probleme, die Sie nicht länger ignorieren können
- Warum Next.js das natürliche Migrationsziel ist
- Der Migrationspfad: MODX zu Next.js
- Ein Headless-CMS wählen, um MODX zu ersetzen
- Echte Leistungsgewinne: Vorher und Nachher
- Was Sie vermissen werden (und was nicht)
- Kostenvergleich: MODX vs. Next.js ausführen
- Häufig gestellte Fragen
Der Zustand von MODX im Jahr 2026
Schauen wir uns die Zahlen ehrlich an. MODX 3.x ist schon eine Weile auf dem Markt, aber die Akzeptanz ist... lau. Die MODX-Foren, die einst vor Aktivität brummten, sehen jetzt vielleicht noch ein paar Posts pro Woche. Das offizielle GitHub-Repository zeigt zunehmend spärliche Commit-Aktivität. Vergleichen Sie das mit 2018 oder 2019, als die Community noch hart vorprescht.
BuiltWith-Daten von Anfang 2026 schätzen, dass MODX etwa 0,3% der CMS-erkannten Websites betreibt, gegenüber etwa 0,7% im Jahr 2021. WordPress dominiert immer noch mit etwa 62%, und neuere Spieler wie Next.js-basierte Seiten (oft mit Headless-CMS gekoppelt) wachsen mit etwa 40% pro Jahr.
Der MODX-Marktplatz (ehemals Extras-Repository) hat seit Monaten keine sinnvolle neue Erweiterung gesehen. Viele beliebte Extras sind nicht gewartet oder nur teilweise mit MODX 3.x kompatibel. Wenn das Ökosystem aufhört zu produzieren, ist das keine Warnung — es ist eine weiße Flagge.
Ich sage nicht, dass MODX tot ist. Es funktioniert immer noch. Ihre Seiten laufen immer noch. Aber „funktioniert immer noch" ist ein gefährlicher Platz in der Webentwicklung.
Was MODX richtig gemacht hat (und immer noch tut)
Bevor ich alles kritisiere, wo es angebracht ist. MODX hat mehrere Dinge richtig gemacht, die die meisten CMS immer noch falsch machen:
Echte Inhaltsflexibilität
MODX hat Sie nie in das „Post und Seite"-Paradigma gezwungen. Template-Variablen, Chunks und Snippets gaben Ihnen echte Inhaltsmodellierungsfreiheit, Jahre bevor „strukturierter Inhalt" zum Buzzword wurde. Sie konnten alles bauen.
Saubere Ausgabe
MODX hat kein eigenes Markup eingespritzt. Keine geheimnisvollen CSS-Klassen, keine unerwünschten Wrapper-Divs. Ihr HTML war Ihr HTML. Für Front-End-Entwickler, die sich um handwerkliche Qualität kümmerten, war das eine Offenbarung.
Entwicklerfreundliche Themenerstellung
Kein Themensystem zum Lernen, keine Templatehierarchie zum Auswendiglernen. Sie schrieben Templates. Das war alles. Chunks waren wiederverwendbare Partials. Snippets waren PHP-Logik. Einfaches mentales Modell, starke Ergebnisse.
Die Tag-Syntax
Sagen Sie, was Sie wollen, über [[*pagetitle]] und [[!MySnippet]] — sobald Sie es gelernt hatten, konnten Sie schnell komplexe Seiten bauen. Die Caching-Schicht mit dem ! Flag für nicht gecachte Inhalte war elegant.
Diese Stärken machen MODX-Entwickler tatsächlich zu großartigen Kandidaten für moderne Headless-Architekturen. Wenn Sie bereits in strukturiertem Inhalt und komponentenbasierten Templates denken, sind Sie bereits auf halbem Weg zu Next.js.
Die Probleme, die Sie nicht länger ignorieren können
Hier muss ich direkt sein.
Sicherheitsbedenken
MODX 3.x hat viele historische Sicherheitslücken behoben, aber die Ausführung jedes PHP-Monoliths mit einem öffentlichen Admin-Panel ist ein inhärenter Risikovektor. 2025 sahen wir mindestens zwei kritische CVEs, die MODX-Installationen betrafen, und Patches brauchten Wochen zu ankommen. Mit einem schrumpfenden Sicherheitsteam verbessern sich die Reaktionszeiten nicht.
Vergleichen Sie das mit einer Next.js-Website, die auf Vercel oder Netlify bereitgestellt wird — es gibt buchstäblich keinen Server, den man angreifen könnte. Kein Admin-Panel zum Brute-Force. Keine PHP zum Ausnutzen. Die Angriffsfläche ist grundlegend kleiner.
Die Talentskrise
Versuchen Sie, 2026 einen MODX-Entwickler einzustellen. Los geht's. Stellen Sie die Stellenausschreibung auf und schauen Sie zu, wie die Grillen zirpen. Der Entwicklerpool ist zu React, Next.js und modernen JavaScript-Frameworks abgewandert. Selbst das PHP-Talent geht zu Laravel, nicht zu MODX.
Dies ist keine theoretische Sorge. Ich habe mit Agenturen gesprochen, die MODX-Seiten haben, für die sie buchstäblich keine Entwickler zur Wartung finden können. Wenn der ursprüngliche Entwickler geht, wird die Seite zu einer Haftung.
PHP 8.x Kompatibilitätsprobleme
MODX 3.x läuft auf PHP 8, aber viele Extras nicht. Wenn Sie eine Seite gebaut haben, die von Drittanbieter-Snippets oder Plugins abhängt, kann ein PHP-Upgrade die Dinge beschädigen. Sie enden darauf, auf ältere PHP-Versionen festgelegt zu sein, was zum Sicherheitsproblem zurückführt.
Keine moderne Entwicklererfahrung
Kein Hot-Module-Reloading. Keine komponentenbasierte Architektur. Keine TypeScript-Unterstützung. Keine integrierte Bildoptimierung. Kein Edge-Rendering. Kein ISR. Ich könnte so weitermachen.
Der Entwicklungsworkflow von MODX ist im Grunde: Bearbeiten Sie eine Datei oder einen Chunk im Manager (oder in Ihrer IDE über ein Syncing-Tool), löschen Sie den Cache, aktualisieren Sie den Browser. Es funktioniert, aber es ist langsam im Vergleich zu modernem DX.
Leistungsdecke
MODX kann schnell sein — ich habe Seiten unter 2 Sekunden darauf gebaut. Aber um dorthin zu gelangen, ist erhebliche Optimierung erforderlich: vollständiges Seiten-Caching, CDN-Setup, Datenbankabstimmung und sorgfältige Snippet-Architektur. Next.js gibt Ihnen mit statischer Generierung im Grunde direkt Leistung unter einer Sekunde. Sie kämpfen um Leistung auf MODX; bei Next.js kämpfen Sie, um es zu vermasseln.
Warum Next.js das natürliche Migrationsziel ist
Sie könnten fragen: Warum nicht WordPress? Warum nicht Astro? Warum nicht einfach einen statischen Site-Generator?
Alle gültige Optionen, aber Next.js trifft den sweet Spot für die meisten MODX-Migrationen. Hier ist warum:
Rendering-Flexibilität spiegelt MODX-Denken wider
MODX-Entwickler wissen bereits, dass verschiedene Seiten unterschiedliche Caching-Strategien benötigen. In MODX würden Sie Snippets als gecacht oder nicht gecacht markieren. In Next.js wählen Sie pro Seite zwischen Static Site Generation (SSG), Incremental Static Regeneration (ISR) und Server-Side Rendering (SSR). Gleiches Konzept, bessere Ausführung.
Komponentenarchitektur ersetzt Chunks
MODX Chunks sind wiederverwendbare HTML-Partials. React-Komponenten sind wiederverwendbare UI-Partials mit eingebauter Logik. Wenn Sie Chunks wie [[!$header]] und [[!$footer]] geschrieben haben, denken Sie bereits in Komponenten. Sie hatten nur keine Props.
API-Routes ersetzen Snippets
MODX-Snippets verarbeiten serverseitige Logik — Formularverarbeitung, API-Aufrufe, benutzerdefinierte Abfragen. Next.js-API-Routes (oder Server Actions in Next.js 14+) tun dasselbe, aber in JavaScript/TypeScript mit besseren Tools und Testunterstützung.
Für Teams, die Alternativen in Betracht ziehen, Astro ist für inhaltsreiche Seiten worth evaluating, die nicht viel Interaktivität benötigen. Aber wenn Sie dynamische Funktionen, authentifizierte Erlebnisse oder komplexe Datenabrufe benötigen, Next.js ist die stärkere Wahl.
Der Migrationspfad: MODX zu Next.js
Lassen Sie uns praktisch werden. So funktioniert eine MODX-zu-Next.js-Migration tatsächlich.
Schritt 1: Überprüfen Sie Ihr Inhaltsmodell
Ordnen Sie jedes MODX-Template, jede Template-Variable und jeden Ressourcentyp zu. Dies wird Ihr Inhaltsmodell in welchem Headless-CMS auch immer Sie wählen. Dokumentieren Sie alles:
## Ressource: Blogbeitrag
- 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)
Schritt 2: Exportieren Sie Ihren Inhalt
MODX hat kein großartiges Export-Tool. Sie müssen wahrscheinlich ein benutzerdefiniertes Snippet oder Skript schreiben, das modx_site_content und Ihre TV-Tabellen abfragt und dann JSON ausgibt:
<?php
// Schneller und schmutziger MODX-Inhaltsexport
$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);
Schreiben Sie dann Import-Skripte für Ihr Ziel-CMS. Es ist unelegante Arbeit, aber es ist eine einmalige Anstrengung.
Schritt 3: Bauen Sie Ihr Next.js Front-End
Beginnen Sie mit create-next-app und bauen Sie Ihre Templates als Page-Komponenten. Ihre MODX-Template → Page-Layout-Zuordnung könnte so aussehen:
| MODX-Konzept | Next.js-Äquivalent |
|---|---|
| Template | Layout-Komponente |
| Chunk | React-Komponente |
| Snippet | Server Action / API-Route |
| Template-Variable | CMS-Feld |
| Ressource | Seite / Inhaltseintrag |
[[*field]] Tag |
Props / Datenabruf |
| Plugin (Event-Hook) | Middleware |
[[!uncached]] |
SSR / dynamisches Rendering |
[[cached]] |
SSG / ISR |
Schritt 4: URL-Umleitungen handhaben
Hier vermasseln es die Leute. Jede alte MODX-URL benötigt eine 301-Umleitung auf ihr Next.js-Äquivalent. Bauen Sie eine Umleitungskarte und fügen Sie sie zu next.config.js hinzu:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... Hunderte mehr, generiert aus Ihrem Export
]
},
}
Überspringen Sie das nicht. Ihr SEO hängt davon ab.
Schritt 5: Parallel 2-4 Wochen lang ausführen
Stellen Sie Next.js neben Ihrer bestehenden MODX-Seite bereit. Testen Sie alles. Überprüfen Sie Analytics. Überprüfen Sie, ob Formulare funktionieren. Dann ändern Sie DNS.
Ein Headless-CMS wählen, um MODX zu ersetzen
Next.js ist Ihr Front-End, aber Sie benötigen immer noch einen Ort zur Inhaltsverwaltung. Hier ist ein Vergleich der beliebten Optionen für MODX-Flüchtlinge:
| CMS | Lernkurve für MODX-Devs | Inhaltsmodellierung | Preis (2026) | Self-Hosted-Option |
|---|---|---|---|---|
| Sanity | Mittel | Ausgezeichnet (Code-definierte Schemas) | Kostenlos, dann $15/Benutzer/Mo | Nein (nur Cloud) |
| Strapi | Niedrig | Gut (UI-basiert) | Kostenlos (Self-Hosted), Cloud ab $29/Mo | Ja |
| Contentful | Mittel | Gut | Kostenlos, dann $300/Mo | Nein |
| Payload CMS | Niedrig | Ausgezeichnet (Code-definierte) | Kostenlos (Self-Hosted), Cloud ab $50/Mo | Ja |
| Directus | Niedrig | Flexibel | Kostenlos (Self-Hosted), Cloud ab $99/Mo | Ja |
Wenn Sie MODXs Flexibilität und Self-Hosting-Fähigkeit geliebt haben, werden sich Payload CMS oder Strapi am vertrautesten anfühlen. Wenn Sie die beste Entwicklererfahrung wünschen und nicht an Cloud-Only stören, ist Sanity schwer zu schlagen.
Wir haben umfangreiche Arbeiten mit all diesen durch unsere Headless-CMS-Entwicklungspraxis durchgeführt, und die richtige Wahl hängt wirklich vom Komfortniveau und Budget Ihres Teams ab.
Echte Leistungsgewinne: Vorher und Nachher
Ich habe eine mittelgroße MODX-Seite (ungefähr 400 Seiten, Blog + Services + Portfolio) Ende 2025 zu Next.js mit Sanity migriert. Hier sind die tatsächlichen Zahlen:
| Metrik | MODX (optimiert) | Next.js auf Vercel | Verbesserung |
|---|---|---|---|
| Lighthouse-Leistung | 72 | 98 | +36% |
| Largest Contentful Paint | 2,8s | 0,9s | -68% |
| Time to First Byte | 680ms | 45ms | -93% |
| Core Web Vitals Pass | Teilweise | Voller Pass | ✅ |
| Build/Deploy-Zeit | Manueller FTP | 42s Auto-Deploy | Tag und Nacht |
| Monatliche Hostingkosten | $45/Mo (VPS) | $0 (Vercel-kostenlos) | -100% |
Die TTFB-Verbesserung allein ist atemberaubend. MODX muss PHP booten, sich mit MySQL verbinden, Snippets ausführen, Chunks zusammenstellen und die Antwort servieren — selbst mit Caching. Eine statisch generierte Next.js-Seite wird von einem CDN-Edge-Knoten in Millisekunden bereitgestellt.
Was Sie vermissen werden (und was nicht)
Sie werden vermissen
- Das Manager UI: MODXs Admin-Panel ist genuinely intuitiv für Content-Editoren. Die meisten Headless-CMS-Admin-Panels haben eine Lernkurve.
- In-Context-Bearbeitung: Inhalte bearbeiten, wo Sie sie gerendert sehen. Die meisten Headless-Setups erfordern den Wechsel zwischen CMS und Vorschau. (Sanitys Presentation-Tool und Payloads Live Preview schließen diese Lücke.)
- Einfachheit: Ein Server, eine Datenbank, ein Codebase. Es gibt Schönheit darin. Ein Headless-Stack hat mehr bewegliche Teile.
- Die Community-Atmosphäre: Die MODX-Community war, obwohl klein, eng und genuinely hilfreicher.
Sie werden nicht vermissen
- Cache-Löschen: Der endlose Cache-Löschen-Aktualisierungs-Zyklus.
- TV-Verwaltung: Erstellen und Verwalten von Template-Variablen über die UI für jedes Feld.
- Datenbank-Angst: Das mulmige Gefühl, wenn Ihre MySQL-Verbindung bei einem Traffic-Spike maxed out.
- FTP-Bereitstellungen: Oder welcher manuelle Prozess auch immer Sie verwendet haben, um Änderungen zu pushen.
- Plugin-Event-Debugging: Zu versuchen, herauszufinden, welches Plugin wann fired, in welcher Reihenfolge.
Kostenvergleich: MODX vs. Next.js ausführen
Seien Sie ehrlich bezüglich der Gesamtbetriebskosten, nicht nur des Hostings.
| Kostenkategorie | MODX (Jährlich) | Next.js + Headless CMS (Jährlich) |
|---|---|---|
| Hosting | $540-$1.200 (VPS/Shared) | $0-$240 (Vercel/Netlify) |
| CMS-Lizenz | $0 (Open Source) | $0-$3.600 (variiert nach CMS) |
| SSL-Zertifikat | $0-$100 | $0 (enthalten) |
| CDN | $0-$600 | $0 (enthalten) |
| Sicherheitsüberwachung | $200-$500 | Minimal (kein Server) |
| Serverwartung | $500-$2.000 (Zeit oder ausgelagert) | $0 |
| Entwickler-Stundensatz | $75-$120 (knapp) | $100-$175 (reichlich) |
| Total (ohne Dev-Zeit) | $1.240-$4.400 | $0-$3.840 |
Die Wildcard ist der Entwicklersatz. MODX-Entwickler sind pro Stunde billiger wenn Sie sie finden können. Aber Knappheit treibt die Sätze im Laufe der Zeit in die Höhe, und Sie sind oft auf wen auch immer verfügbar ist, anstatt das beste auszuwählen.
Wenn Sie die Migrationskosten für Ihre spezifische Situation bewerten, brechen wir unsere Preisgestaltung hier auf — wir sind transparent darüber, was diese Projekte wirklich kosten.
Häufig gestellte Fragen
Wie lange dauert eine typische MODX-zu-Next.js-Migration?
Bei einer Seite mit 100-500 Seiten rechnen Sie mit 6-10 Wochen mit einem dedizierten Team. Die Inhaltsmodellierung und Migration dauert etwa 2 Wochen, das Bauen des Next.js-Front-Ends dauert 3-5 Wochen und QA/Test/Redirects füllt den Rest. Größere Seiten mit komplexer benutzerdefinierter PHP-Logik oder schwerer E-Commerce-Integration können 12-16 Wochen dauern. Die größte Variable ist, wie viel benutzerdefinierte PHP-Logik neu geschrieben werden muss.
Kann ich mein MODX-Admin-Panel behalten und nur Next.js für das Front-End verwenden?
Technisch ja — Sie könnten eine REST-API-Schicht in MODX bauen und sie mit Next.js nutzen. Aber dies gibt Ihnen das Schlechteste aus beiden Welten: Sie müssen immer noch den PHP-Server, die MySQL-Datenbank und alle Sicherheitsbedenken pflegen, während Sie auch ein separates Front-End pflegen. Wenn Sie keinen sehr spezifischen Grund haben, ist es besser, Inhalte zu einem zweckgebauten Headless-CMS zu migrieren.
Verliere ich SEO-Rankings während der Migration?
Nicht, wenn Sie Umleitungen ordnungsgemäß handhaben. Die kritischen Schritte sind: Behalten Sie die gleiche URL-Struktur bei, wo möglich, richten Sie 301-Umleitungen für alle sich ändernden URLs ein, behalten Sie Ihre Metadaten intakt und senden Sie eine aktualisierte Sitemap an Google Search Console nach dem Launch. Die meisten Seiten, die wir migriert haben, sehen Ranking-Verbesserungen innerhalb von 4-8 Wochen aufgrund besserer Core Web Vitals-Scores.
Was ist mit MODX-Seiten mit FormIt-Formularen und komplexen Workflows?
Formulare sind einer der kniffligeren Teile der Migration. FormIt handhabte Validierung, E-Mail-Versand, Hooks und Spam-Prävention alles in einem Paket. In Next.js werden Sie typischerweise Server Actions zur Verarbeitung, Zod zur Validierung und einen Service wie Resend oder SendGrid zum E-Mail-Versand kombinieren. Es ist expliziter, aber auch testbar und zuverlässiger.
Ist Next.js Overkill für eine einfache Broschüren-Seite?
Vielleicht. Wenn Ihre MODX-Seite buchstäblich 10 statische Seiten mit einem Kontaktformular ist, könnte Astro ein besserer Fit sein — es versendet standardmäßig Null JavaScript und ist einfacher einzurichten. Aber wenn es eine Chance gibt, dass Sie später dynamische Funktionen, Authentifizierung oder komplexe Datenabrufe benötigen, spart das Starten mit Next.js Sie vor einer weiteren Migration später.
Was passiert mit meinen MODX-Extras und benutzerdefinierten Snippets?
Sie müssen neu gebaut werden. Es gibt keine automatisierte Konvertierung. Benutzerdefinierte Snippets werden zu API-Routes oder Server Actions in Next.js. Extras wie Gallery, Articles oder MIGX werden durch die nativen Funktionen Ihres Headless-CMS ersetzt (die normalerweise besser sind). E-Commerce-Extras wie Foxy oder SimpleCart würden durch Shopifys Storefront API, Snipcart oder Medusa ersetzt werden. Planen Sie diese Anstrengung explizit in Ihre Migrations-Timeline.
Wie überzeuge ich meine nicht-technischen Stakeholder, diese Migration zu genehmigen?
Konzentrieren Sie sich auf drei Dinge, die ihnen wichtig sind: Risiko, Kosten und Ergebnisse. Risiko: MODXs schrumpfende Community bedeutet, dass das Finden von Entwicklern für Notfälle jedes Jahr schwerer wird. Kosten: Serverwartung und Sicherheits-Patching sind nicht kostenlos, auch wenn die CMS-Lizenz kostenlos ist. Ergebnisse: Zeigen Sie ihnen den Core Web Vitals-Vergleich und erklären Sie, wie Google Page Speed als Ranking-Faktor nutzt. Wenn ihre Konkurrenten in unter einer Sekunde laden und sie bei 3 Sekunden sind, ist das ein Business-Problem.
Kann ich schrittweise migrieren oder muss es alles auf einmal sein?
Schrittweise Migration ist möglich mit einem Reverse-Proxy-Setup — Sie würden neue Seiten von Next.js servieren und Legacy-Seiten zu Ihrem MODX-Server routen. Wir haben dies mit nginx-Konfigurationen gemacht, bei denen spezifische Pfade zum alten Server proxied werden, während alles andere zur neuen Next.js-Bereitstellung geht. Es fügt Komplexität hinzu, aber bei Seiten mit Hunderten von Seiten können Sie über Wochen oder Monate schrittweise migrieren, anstatt einen riskanteren großen Cutover zu machen.
Wenn Sie auf einer MODX-Seite sitzen und die Schmerzpunkte spüren, die ich beschrieben habe, ist jetzt die beste Zeit, eine Planung zu beginnen. Nicht, weil der Himmel fällt, sondern weil Migrationen unter Druck — nach einer Sicherheitsverletzung, nachdem Ihr Entwickler geht, nachdem eine PHP-Version das Lebensende erreicht — immer teurer und stressiger sind als geplante. Kontaktieren Sie uns, wenn Sie Ihre spezifische Situation durchgehen möchten. Wir haben das oft genug durchgemacht, um zu wissen, wo die Minen sind.