Waarom MODX-gebruikers in 2026 naar Next.js moeten migreren: Een eerlijk inzicht
Ik bouw sinds de Evolution-dagen al sites op MODX. Ik heb aangepaste snippets geschreven, heb geworsteld met TV's (template variables, niet televisies), en heb MODX verdedigd in talloze CMS-debatten. Geloof me dus als ik zeg dat dit geen aanval is. Het is een wake-up call van iemand die dit platform echt graag mocht.
Maar hier is het probleem: de webontwikkelingwereld is verder gegaan, en MODX niet. De community krimpt, de release cycle is tot een slakkengang vertraagd, en het talentenaanbod droogt sneller op dan een plas in juli. Als je in 2026 nog productiesites op MODX draait, moet je serieus nadenken over je exitstrategie. En voor de meeste teams leidt die exit naar Next.js.
Ik loop je erdoorheen waarom — eerlijk gezegd, zonder de hype.
Inhoudsopgave
- De staat van MODX in 2026
- Wat MODX goed deed (en nog steeds doet)
- De problemen die je niet meer kunt negeren
- Waarom Next.js het natuurlijke migratiedoel is
- Het migratiepad: MODX naar Next.js
- Een headless CMS kiezen om MODX te vervangen
- Echte prestatieverbetering: voor en na
- Wat je zult missen (en wat niet)
- Kostenvergelijking: MODX uitvoeren versus Next.js
- Veelgestelde vragen
De staat van MODX in 2026
Laten we eerlijk naar de cijfers kijken. MODX 3.x is al een tijdje uit, maar de adoptie is... matig. De MODX-forums, die ooit bruistten van activiteit, zien nu misschien een handvol posts per week. De officiële GitHub-repository toont steeds minder commit-activiteit. Vergelijk dat met 2018 of 2019 toen de community nog hard aan het werk was.
BuiltWith-gegevens uit begin 2026 schatten dat MODX ruwweg 0,3% van de CMS-gedetecteerde websites aandrijft, omlaag van ongeveer 0,7% in 2021. WordPress domineert nog steeds met ~62%, en nieuwere spelers zoals Next.js-gebaseerde sites (vaak gekoppeld aan headless CMS'en) groeien met ongeveer 40% per jaar.
De MODX-marktplaats (voorheen de Extras-repository) heeft al maanden geen betekenisvolle nieuwe extensie gezien. Veel populaire extras worden niet onderhouden of zijn slechts gedeeltelijk compatibel met MODX 3.x. Als het ecosysteem stopt met produceren, is dat geen rood vlaggetje — dat is een witte vlag.
Ik zeg niet dat MODX dood is. Het werkt nog steeds. Je sites draaien nog. Maar "werkt nog steeds" is een gevaarlijke plek in webontwikkeling.
Wat MODX goed deed (en nog steeds doet)
Voordat ik kritiek uitspreek, wil ik gegeven krediet waar het toekomt. MODX heeft verschillende dingen goed gedaan die de meeste CMS'en nog steeds verkeerd doen:
Echte inhoudsflexibiliteit
MODX duwde je nooit in een "post en pagina"-paradigma. Template variables, chunks en snippets gaven je echte vrijheid in inhoudsmodellering jaren voordat "gestructureerde inhoud" een modebegrip werd. Je kon alles bouwen.
Schone uitvoer
MODX injecteerde geen eigen markup. Geen mysterieuze CSS-klassen, geen wrapper divs die je niet vroeg. Je HTML was jouw HTML. Voor front-end developers die om craftsmanship gaven, was dit een openbaring.
Ontwikkelaar-vriendelijk theming
Geen themasysteem om te leren, geen sjabloonhiërarchie om te onthouden. Je schreef sjablonen. Dat was het. Chunks waren herbruikbare partials. Snippets waren PHP-logica. Eenvoudig mentaal model, krachtige resultaten.
De Tag-syntaxis
Zeg wat je wilt over [[*pagetitle]] en [[!MySnippet]] — als je het eenmaal onder de knie had, kon je complexe pagina's snel bouwen. De cache-laag met de ! uncached-vlag was elegant.
Deze sterke punten maken MODX-developers eigenlijk ideale kandidaten voor moderne headless-architecturen. Als je al in gestructureerde inhoud en component-gebaseerde sjablonen denkt, ben je halverwege Next.js al.
De problemen die je niet meer kunt negeren
Hier moet ik voorzichtig zijn.
Beveiligingsbedenking
MODX 3.x sprak veel historische kwetsbaarheden aan, maar het draaiien van een PHP-monoliet met een openbaar beheerdersdashboard is een inherent risicovector. In 2025 zagen we minstens twee kritieke CVE's die MODX-installaties beïnvloedden, en patches duurden weken. Met een krimpend beveiligingsteam verbeteren responstijden niet.
Vergelijk dat met een Next.js-site op Vercel of Netlify — er is letterlijk geen server om aan te vallen. Geen beheerdersdashboard om brute-force aan te doen. Geen PHP om uit te buiten. Het aanvalsoppervlak is fundamenteel kleiner.
De talentcrisis
Probeer in 2026 een MODX-developer aan te stellen. Ga je gang. Plaats de vacature en luister naar de stilte. De developer pool is gemigreerd naar React, Next.js en moderne JavaScript-frameworks. Zelfs het PHP-talent gaat naar Laravel, niet MODX.
Dit is geen theoretisch bezwaar. Ik heb met agencies gesproken die MODX-sites hebben waarvan ze letterlijk geen developers kunnen vinden om te onderhouden. Wanneer de originele developer weggaat, wordt de site een verplichting.
PHP 8.x-compatibiliteitskoppelingen
MODX 3.x draait op PHP 8, maar veel extras doen dat niet. Als je een site hebt gebouwd die afhankelijk is van snippets of plugins van derden, leidt upgraden naar PHP vaak tot problemen. Je blijft vastzitten aan oudere PHP-versies, wat je terugbrengt naar het beveiligingsprobleem.
Geen moderne developer experience
Geen hot module reloading. Geen component-gebaseerde architectuur. Geen TypeScript-ondersteuning. Geen ingebouwde afbeeldingsoptimalisatie. Geen edge rendering. Geen ISR. Ik kan doorgaan.
MODX's development workflow is in essentie: bewerk een bestand of een chunk in de manager (of in je IDE via een synctool), maak de cache schoon, vernieuw de browser. Het werkt, maar het is traag in vergelijking met moderne DX.
Prestatiedeksel
MODX kan snel zijn — ik heb sites onder de 2 seconden erop gebouwd. Maar om daar te komen is aanzienlijke optimalisatie nodig: full-page caching, CDN-setup, databaseafstemming en voorzichtige snippet-architectuur. Next.js geeft je prestaties van onder de seconde praktisch out of the box met statische generatie. Je vecht voor prestatie op MODX; op Next.js vecht je om het verpest te maken.
Waarom Next.js het natuurlijke migratiedoel is
Je zou kunnen vragen: waarom niet WordPress? Waarom niet Astro? Waarom niet gewoon een statische sitegenerator?
Alle geldige opties, maar Next.js raakt de sweet spot voor de meeste MODX-migraties. Hier is waarom:
Renderingflexibiliteit weerspiegelt MODX-denken
MODX-developers begrijpen al dat verschillende pagina's verschillende cache-strategieën nodig hebben. In MODX zou je snippets als cached of uncached markeren. In Next.js kies je per pagina tussen Static Site Generation (SSG), Incremental Static Regeneration (ISR) en Server-Side Rendering (SSR). Hetzelfde concept, betere uitvoering.
Component-architectuur vervangt chunks
MODX chunks zijn herbruikbare HTML-partials. React-componenten zijn herbruikbare UI-partials met ingebouwde logica. Als je chunks schrijft als [[!$header]] en [[!$footer]], denk je al in componenten. Je wist het alleen nog niet.
API-routes vervangen snippets
MODX-snippets verwerken server-side logica — formulierverwerking, API-aanroepen, aangepaste queries. Next.js API-routes (of Server Actions in Next.js 14+) doen hetzelfde maar in JavaScript/TypeScript met betere gereedschappen en testondersteuning.
Voor teams die alternatieven overwegen, is Astro het overwegen waard voor inhouds-zware sites die niet veel interactiviteit nodig hebben. Maar als je dynamische functies, geverifieerde ervaringen of complexe dataverzameling nodig hebt, is Next.js de sterkere keuze.
Het migratiepad: MODX naar Next.js
Laten we praktisch worden. Dit is hoe een MODX-naar-Next.js-migratie werkelijk verloopt.
Stap 1: Controleer je inhoudsmodel
Teken elke MODX-sjabloon, template variable en resourcetype in kaart. Dit wordt je inhoudsmodel in welke headless CMS je ook kiest. Documenteer alles:
## Resource: blogbericht
- pagetitle → title (tekst)
- longtitle → seo_title (tekst)
- content → body (rich text)
- TV: hero_image → hero_image (media)
- TV: author → author (referentie)
- TV: category → category (taxonomie)
Stap 2: Exporteer je inhoud
MODX heeft geen geweldig exportgereedschap. Je zult waarschijnlijk een aangepast snippet of script moeten schrijven dat modx_site_content en je TV-tabellen bevraagt en vervolgens JSON uitvoert:
<?php
// Snelle en vuile MODX-inhoudsexport
$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);
Schrijf vervolgens importscripts voor je doel-CMS. Het is onopvallend werk, maar het is eenmalig.
Stap 3: Bouw je Next.js-front-end
Begin met create-next-app en bouw je sjablonen als pagina-componenten. Je MODX-sjabloon → paginalayout-mapping zou er zo uit kunnen zien:
| MODX-concept | Next.js-equivalent |
|---|---|
| Sjabloon | Layout-component |
| Chunk | React-component |
| Snippet | Server Action / API-route |
| Template variable | CMS-veld |
| Bron | Pagina / inhoudsitem |
[[*field]] tag |
Props / dataverzameling |
| Plugin (event hook) | Middleware |
[[!uncached]] |
SSR / dynamische rendering |
[[cached]] |
SSG / ISR |
Stap 4: Verwerk URL-omleidingen
Hier menen mensen het verkeerd. Elke oude MODX-URL heeft een 301-omleiding naar zijn Next.js-equivalent nodig. Bouw een omleidingskaart en voeg deze toe aan next.config.js:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... honderden meer, gegenereerd uit je export
]
},
}
Sla dit niet over. Je SEO hangt ervan af.
Stap 5: Draai parallel gedurende 2-4 weken
Deploy Next.js naast je bestaande MODX-site. Test alles. Controleer analytics. Verifieer dat formulieren werken. Wissel vervolgens DNS.
Een headless CMS kiezen om MODX te vervangen
Next.js is je front-end, maar je hebt nog steeds ergens nodig om inhoud te beheren. Hier vergelijken de populaire opties voor MODX-vluchtelingen:
| CMS | Leercurve voor MODX-devs | Inhoudsmodellering | Prijzen (2026) | Zelfgehost optie |
|---|---|---|---|---|
| Sanity | Gemiddeld | Uitstekend (code-gedefinieerde schema's) | Gratis tier, vervolgens $15/gebruiker/maan | Nee (alleen cloud) |
| Strapi | Laag | Goed (op UI gebaseerd) | Gratis (zelfgehost), Cloud vanaf $29/maan | Ja |
| Contentful | Gemiddeld | Goed | Gratis tier, vervolgens $300/maan | Nee |
| Payload CMS | Laag | Uitstekend (code-gedefinieerde) | Gratis (zelfgehost), Cloud vanaf $50/maan | Ja |
| Directus | Laag | Flexibel | Gratis (zelfgehost), Cloud vanaf $99/maan | Ja |
Als je van MODX's flexibiliteit en zelfhost-mogelijkheid hield, voelen Payload CMS of Strapi het vertrouwdst. Als je de beste developer experience wilt en je geen bezwaar hebt tegen alleen cloud, is Sanity moeilijk te verslaan.
We hebben veel werk gedaan met al deze via onze headless CMS-ontwikkelingspraktijk, en de juiste keuze hangt echt af van het comfort en budget van je team.
Echte prestatieverbetering: voor en na
Ik migreerde eind 2025 een middelgrote MODX-site (ongeveer 400 pagina's, blog + services + portfolio) naar Next.js met Sanity. Dit zijn de werkelijke cijfers:
| Metriek | MODX (geoptimaliseerd) | Next.js op Vercel | Verbetering |
|---|---|---|---|
| Lighthouse Performance | 72 | 98 | +36% |
| Largest Contentful Paint | 2,8s | 0,9s | -68% |
| Time to First Byte | 680ms | 45ms | -93% |
| Core Web Vitals Slagen | Gedeeltelijk | Volledig | ✅ |
| Build/Deploy-tijd | Handmatige FTP | 42s automatisch uitrollen | Dag en nacht |
| Maandelijkse hostingkosten | $45/maan (VPS) | $0 (Vercel gratis tier) | -100% |
De TTFB-verbetering alleen is verbluffend. MODX moet PHP opstarten, verbinding maken met MySQL, snippets uitvoeren, chunks samenstellen en het antwoord serveren — zelfs met caching. Een statisch gegenereerde Next.js-pagina wordt in milliseconden geserveerd vanaf een CDN edge node.
Wat je zult missen (en wat niet)
Wat je zult missen
- De Manager UI: MODX's adminpanel is werkelijk intuïtief voor content editors. De meeste headless CMS admin panels hebben een leercurve.
- In-context bewerking: Inhoud bewerken waar je het weergegeven ziet. De meeste headless setups vereisen schakelen tussen CMS en voorbeeld. (Sanity's Presentation-tool en Payload's Live Preview helpen dit gat dichten.)
- Eenvoud: Één server, één database, één codebase. Er is schoonheid in dat. Een headless stack heeft meer bewegende delen.
- De community-sfeer: De MODX-community was, hoewel klein, hecht en werkelijk behulpzaam.
Wat je niet zult missen
- Cache wissen: De eindeloze cache-wissen-vernieuwen-cyclus.
- TV-beheer: Template variables maken en beheren via de UI voor elk veld.
- Databaseangst: Die zinkkende buikgevoel wanneer je MySQL-verbinding maxed op een verkeerspieken.
- FTP-uitrollingen: Of welk handmatig proces je ook gebruikte om wijzigingen uit te zetten.
- Plugin event-debugging: Proberen uit te zoeken welke plugin wanneer afging, in welke volgorde.
Kostenvergelijking: MODX uitvoeren versus Next.js
Laten we eerlijk zijn over totale eigendomskosten, niet alleen hosting.
| Kostencategorie | MODX (jaarlijks) | Next.js + Headless CMS (jaarlijks) |
|---|---|---|
| Hosting | $540-$1.200 (VPS/gedeeld) | $0-$240 (Vercel/Netlify) |
| CMS-licentie | $0 (open source) | $0-$3.600 (varieert per CMS) |
| SSL-certificaat | $0-$100 | $0 (inbegrepen) |
| CDN | $0-$600 | $0 (inbegrepen) |
| Beveiligingsbewaking | $200-$500 | Minimaal (geen server) |
| Serverwerkzaamheden | $500-$2.000 (tijd of uitbesteed) | $0 |
| Developer uurloon | $75-$120 (schaars talent) | $100-$175 (overvloedig talent) |
| Totaal (exclusief dev-tijd) | $1.240-$4.400 | $0-$3.840 |
De wildcard is developertarieven. MODX-developers zijn goedkoper per uur als je ze kunt vinden. Maar schaarste stuurt de tarieven in de loop der tijd op, en je zit vaak vast met wie beschikbaar is in plaats van de beste keuze te maken.
Als je migratiekosten voor je specifieke situatie evalueert, breken we onze prijsbenadring hier uit — we zijn transparant over wat deze projecten werkelijk kosten.
Veelgestelde vragen
Hoe lang duurt een typische MODX-naar-Next.js-migratie?
Voor een site met 100-500 pagina's, verwacht 6-10 weken met een dedicated team. Inhoudsmodellering en migratie duurt ongeveer 2 weken, het bouwen van de Next.js-front-end duurt 3-5 weken, en QA/testing/redirects vullen de rest. Grotere sites met complexe aangepaste snippets of zware e-commerce-integratie kunnen 12-16 weken duren. De grootste variabele is hoeveel aangepaste PHP-logica moet worden herschreven.
Kan ik mijn MODX-beheerdersdashboard behouden en alleen Next.js voor de front-end gebruiken?
Technisch gezien ja — je zou een REST API-laag in MODX kunnen bouwen en deze gebruiken met Next.js. Maar dit geeft je het ergste van beide werelden: je onderhoudt nog steeds de PHP-server, de MySQL-database en alle beveiligingsbedenking, terwijl je ook een aparte front-end onderhoudt. Tenzij je een zeer specifieke reden hebt, is het beter om inhoud naar een doel-gespecificeerde headless CMS te migreren.
Verlies ik SEO-rankings tijdens migratie?
Niet als je omleidingen correct verwerkt. De kritieke stappen zijn: behoud waar mogelijk dezelfde URL-structuur, stel 301-omleidingen in voor URL's die veranderen, houd je metadata intact en dien een bijgewerkt sitemap in bij Google Search Console na lancering. De meeste sites die we hebben gemigreerd, zien rangrangverbeteringen binnen 4-8 weken vanwege betere Core Web Vitals-scores.
Hoe zit het met MODX-sites met FormIt-formulieren en complexe workflows?
Formulieren zijn een van de lastigere onderdelen van migratie. FormIt verwerkte validatie, e-mailverzending, hooks en spampreventie allemaal in één pakket. In Next.js combineer je meestal Server Actions voor verwerking, Zod voor validatie en een service als Resend of SendGrid voor e-mailverzending. Het is explicieter maar ook beter testbaar en betrouwbaar.
Is Next.js overkill voor een eenvoudige brochuresite?
Misschien. Als je MODX-site letterlijk 10 statische pagina's met een contactformulier is, zou Astro een betere keuze kunnen zijn — het verzend standaard nul JavaScript en is eenvoudiger op te zetten. Maar als er enige kans bestaat dat je later dynamische functies, authenticatie of complexe dataverzameling nodig hebt, begint met Next.js je voor een ander migratietraject op te sluiten.
Wat gebeurt er met mijn MODX extras en aangepaste snippets?
Ze moeten worden herbouwd. Er is geen geautomatiseerde conversie. Aangepaste snippets worden API-routes of server actions in Next.js. Extras zoals Gallery, Articles of MIGX worden vervangen door de ingebouwde functies van je headless CMS (die meestal beter zijn). E-commerce extras zoals Foxy of SimpleCart zouden worden vervangen door Shopify's Storefront API, Snipcart of Medusa. Plan deze moeite expliciet in je migratietijdlijn.
Hoe overtuig ik mijn niet-technische belanghebbenden om dit migratieproces goed te keuren?
Concentreer je op drie dingen die hen interesseren: risico, kosten en resultaten. Risico: MODX's krimpende community betekent dat developers vinden voor noodsituaties elk jaar moeilijker wordt. Kosten: serveronderhoud en beveiligingspatching zijn niet gratis, zelfs als de CMS-licentie gratis is. Resultaten: toon hen de Core Web Vitals-vergelijking en leg uit hoe Google paginasnelheid als rankingfactor gebruikt. Als hun concurrenten in onder de seconde laden en zij bij 3 seconden zijn, is dat een zakelijk probleem.
Kan ik geleidelijk migreren of moet het alles in een keer?
Geleidelijke migratie is mogelijk met een reverse proxy-setup — je serveert nieuwe pagina's vanuit Next.js en routeert legacy-pagina's naar je MODX-server. We hebben dit gedaan met nginx-configuraties waarbij specifieke paden naar de oude server worden geproxied terwijl alles wat anders naar de nieuwe Next.js-implementatie gaat. Het voegt complexiteit toe, maar voor sites met honderden pagina's kun je weken of maanden lang in fases migreren in plaats van een risicovolle big-bang cutover.
Als je op een MODX-site zit en de pijnpunten voelt die ik heb beschreven, is nu het beste moment om planning te starten. Niet omdat de hemel valt, maar omdat migraties onder druk — na een beveiligingsschending, nadat je developer weg is, nadat een PHP-versie einde-of-leven bereikt — altijd duurder en stressvoller zijn dan geplande. Neem contact op als je je specifieke situatie wilt bespreken. We zijn dit genoeg keren doorgegaan om te weten waar de landmijnen zijn.