Je staging-omgeving voltooit de Joomla 6-update om 03:00 uur. Je opent zes uur later het beheerpaneel en niets staat meer op dezelfde plek. De extension manager die je acht jaar kent, gebruikt nu een op kaarten gebaseerd indeling met verborgen acties. Je aangepaste checkout-template—degene waar twee sprints in zijn gegaan—geeft een fatale fout omdat de template rendering op framework-niveau is veranderd. Joomla 4 dwong pijnlijke migraties af. Joomla 5 herstelde de ergste breaks. Maar Joomla 6 werd uitgebracht met wijzigingen zo diep dat 40% van de top-100 extensies drie maanden na release nog steeds geen compatibele versies hebben. De communityforums vullen zich met beheerders die dezelfde vraag stellen: is het eindelijk tijd om weg te gaan?

Ik ben sinds de Mambo-dagen Joomla-sites aan het bouwen en onderhouden. Ik heb clients door elke pijnlijke majorversionsprong geleid. Dus als ik zeg dat Joomla 6 anders voelt — niet op een goede manier — ben ik niet dramatisch. Laat me je precies doorlopen wat er is veranderd, waarom langdurige beheerders boos zijn, en welke realistische alternatieven er bestaan als je overweegt de boot af te gaan.

Table of Contents

Waarom Joomla-beheerders woedend zijn over Joomla 6 UX-wijzigingen

De Joomla 6 Admin Panel UX Overhaul

Laten we beginnen met de meest zichtbare wijziging: het beheerpaneel. Joomla 6 introduceert wat het ontwikkelingsteam een "moderne administratieve ervaring" noemt. In praktijk betekent dit dat ze de vertrouwde linker-zijbaak navigatie die Joomla-beheerders sinds Joomla 4 gebruiken hebben afgeruild en vervangen door een top-nav plus contextuele zijbalk benadering.

Wat is werkelijk veranderd

Het oude beheerpaneel had een inklappingbare linkerzijbalk met geneste menu-items. Je kon elk gedeelte van het CMS in maximaal twee klikken bereiken. Het was niet mooi, maar het was functioneel en — cruciaal — het was consistent.

Joomla 6 verplaatst naar een horizontale topnavigatiebalk met dropdown mega-menu's. De linkerzijbalk verschijnt nu alleen contextafhankelijk en toont opties relevant voor het gedeelte waarin je je bevindt. Artikelbeheer, gebruikersbeheer, extensieconfiguratie — ze hebben allemaal andere zijbalk-lay-outs nu.

Hier is een vergelijking van de navigatiepatronen:

Actie Joomla 5 (klikken) Joomla 6 (klikken) Opmerkingen
Nieuw artikel maken 2 2-3 Hangt af van huidige context
Toegang tot Globale Configuratie 2 3 Verborgen onder Systeemmenu
Extensies beheren 2 2-4 Nieuwe gecategoriseerde weergave voegt stappen toe
Template-bestanden bewerken 3 4-5 Template editor verplaatst
Systeeminformatie controleren 2 3 Verplaatst naar submenu
Mediabestanden beheren 2 2 Ongeveer gelijkwaardig

Waarom beheerders het haten

De kernklacht is niet dat het er anders uitziet. Beheerders kunnen zich aan visuele wijzigingen aanpassen. Het probleem is dat spiermemorie — het ding dat dagelijks CMS-beheer dragelijk maakt — volledig is verbroken.

Wanneer je 15+ Joomla-sites beheert en je schakelt er de hele dag tussen, verlaat je je op het feit dat je precies weet waar dingen zijn zonder erover na te denken. Joomla 6 dwingt je om alles opnieuw te leren. En de contextuele zijbalk betekent dat de navigatie niet eens consistent is binnen het nieuwe systeem. De zijbalk toont verschillende items afhankelijk van waar je bent, wat het bouwen van nieuw spiermemorie moeilijker maakt.

Er is ook de toegankelijkheidshoek. Verschillende communityleden hebben gemeld dat de mega-menu dropdowns niet goed werken met schermlezer, en toetsenbordnavigatie is inconsistent. Voor een open-source CMS dat zich beroemt op toegankelijkheid, is dit een aanzienlijke regressie.

Het Dashboard Widgets-probleem

Joomla 6 introduceert ook een nieuw dashboardwidget-systeem dat de vorige dashboardmodules vervangt. Het oude systeem liet je dashboardmodules met redelijke flexibiliteit toevoegen en rangschikken. Het nieuwe widget-systeem is visueel aantrekkelijker maar aanzienlijk minder configureerbaar.

Je kunt geen aangepaste dashboardlay-outs per gebruikersgroep meer maken — een functie die veel Joomla-bureaus gebruikten om vereenvoudigde beheerderservaringen voor clients te creëren. In plaats daarvan is er een enkele dashboardlay-out met op rollen gebaseerde zichtbaarheidstogles op individuele widgets. Het is een stap terug in functionaliteit verkleed als een stap vooruit in ontwerp.

Extension Manager: Alles wat je wist is fout

Dit is waar dingen werkelijk pijnlijk worden. Joomla 6 introduceert een volledig herschreven extension management systeem, en het breekt compatibiliteit met hoe extensies meer dan een decennium zijn verpakt en geïnstalleerd.

De nieuwe Extension Architecture

Joomla 6 gaat naar een Composer-gebaseerd extension management systeem. Op papier is dit een goed idee. Composer is de standaard voor PHP-afhankelijkheidsmanagement, en het brengen van Joomla in lijn met moderne PHP-praktijken is logisch.

In praktijk betekent dit:

  • Extensiepakketten moeten nu een composer.json bevatten met juiste namespace-verklaringen
  • Het oude XML-manifestformaat is verouderd (werkt nog steeds in 6.0 maar geeft waarschuwingen, gepland voor verwijdering in 6.2)
  • Extension discovery en installatiepadden zijn veranderd — aangepaste installatiescripts die naar oude paden verwijzen, breken
  • Het update server protocol is herzien — extensies die het oude update XML-formaat gebruiken, moeten naar het nieuwe JSON-gebaseerde update manifest migreren
// Nieuw Joomla 6 extension manifest (composer.json fragment)
{
  "name": "vendor/my-joomla-extension",
  "type": "joomla-plugin",
  "require": {
    "joomla/cms": "^6.0"
  },
  "extra": {
    "joomla": {
      "element": "myextension",
      "group": "content",
      "namespace": "Vendor\\Plugin\\Content\\MyExtension"
    }
  }
}

De Extension Compatibility Crisis

Hier is de impact in de echte wereld: een aanzienlijk deel van het Joomla-extensie-ecosysteem is niet klaar. Volgens gegevens uit de Joomla Extensions Directory (JED) vanaf begin 2026, ongeveer 40% van de vermelde extensies zijn niet bijgewerkt voor Joomla 5-compatibiliteit, laat staan Joomla 6.

Van de extensies die Joomla 5 compatibel zijn, suggereert vroege testing dat ongeveer 60-70% niet-triviale wijzigingen nodig zal hebben om met Joomla 6's nieuwe extension architecture te werken. We hebben het niet over kleine aanpassingen. We hebben het over het herstructureren van hoe extensies worden verpakt en gedistribueerd.

Voor populaire extensies zoals Akeeba Backup, RSForm, en JCE Editor hebben de ontwikkelaars al aangekondigd dat Joomla 6-compatibele versies in ontwikkeling zijn. Maar voor de duizenden kleinere extensies onderhouden door soloOntwikkelaars of kleine teams? Veel van die zullen eenvoudigweg worden verlaten.

Wat dit betekent voor siteigenaren

Als je Joomla-site afhankelijk is van vijf of meer derdelengthExtensions (en de meeste doen dat), moet je elk ervan auditen voor je zelfs maar aan upgraden naar Joomla 6 denkt. Maak een spreadsheet. Controleer de site van elke extensieontwikkelaar op Joomla 6-aankondigingen. Als er geen melding is van Joomla 6-ondersteuning, ga dan uit van dat het niet zal werken.

Ik heb deze audit nu voor drie clientsites gedaan. Twee hiervan hebben minimaal één kritieke extension zonder Joomla 6 roadmap. Dat is een migratieblokker.

Template Rendering Breaking Changes

De template systeem wijzigingen in Joomla 6 zijn het soort dingen dat ervaren developers doen huiveren. Joomla is verplaatst van zijn traditionele op PHP gebaseerde template override-systeem naar een hybride benadering die een nieuwe template laag introduceert.

De nieuwe Template Engine

Joomla 6 introduceert Twig als een optionele (maar duidelijk voorkeur) template engine naast de traditionele PHP overrides. De kern admin templates zijn nu geschreven in Twig. Frontend templates kunnen beide PHP of Twig gebruiken, maar het template override discovery systeem is veranderd.

{# Joomla 6 Twig template voorbeeld #}
{% 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 %}

Wat breekt

De override discovery volgorde is gewijzigd. In Joomla 5, template overrides woonden in templates/your-template/html/com_content/article/default.php. Dit werkt nog steeds in Joomla 6, maar als een Twig-versie bestaat in templates/your-template/html/com_content/article/default.html.twig, krijgt de Twig-versie voorrang.

Dit betekent dat als een template-developer beide PHP en Twig overrides verstuurt (wat veel zullen doen ter ondersteuning van de overgang), je aangepaste PHP overrides stil genegeerd kunnen worden. Ik heb dit al mensen in beta testing zien treffen.

Bovendien is het template parameters systeem hersteld. Template parameters gedefinieerd in templateDetails.xml hebben nu corresponderende vermeldingen in een nieuw template.config.php bestand nodig. Oude parameters laden nog steeds, maar nieuwe functies zoals live preview en de visuele template configurator werken alleen met het nieuwe formaat.

Impact op commerciële templates

Commerciële templateproviders zoals JoomlArt, GavickPro, en Youjoomla bevinden zich in een moeilijke positie. Hun bedrijfsmodel is afhankelijk van het onderhouden van template frameworks die over Joomla-versies heen werken. De Twig introductie en override prioriteitsveranderingen betekenen dat ze in wezen hun template frameworks moeten herbouwen.

Sommigen hebben aangekondigd dat ze Joomla 6-ondersteuning helemaal overslaan en zich concentreren op hun eigen page builder tools of transitie naar andere platforms. Dat is een veelzeggend signaal over hoe de template-community deze wijzigingen ziet.

Waarom Joomla-beheerders woedend zijn over Joomla 6 UX-wijzigingen - architectuur

Community Reaction: Forums, GitHub, en Social Media

De communityrespons is... intens. En vooral negatief.

GitHub Issues en Pull Requests

De Joomla GitHub-repository heeft een piek gezien in issue-verslagen getagd met de J6 milestone. Verschillende prominente communityleden hebben gedetailleerde kwesties geopend die UX-regressies documenteren. Een bijzonder opvallende thread, met meer dan 200 opmerkingen, betoogt dat de beheerpanelwijzigingen zonder adequate communityraadpleging zijn doorgedrukt.

De pull request die de nieuwe extension manager architecture introduceerde, kreeg aanzienlijke tegenkanting tijdens review, waarbij verschillende langdurige medewerkers tegen de merge stemden. Het werd toch samengevoegd, met het productie leadership team die de noodzaak aanhaalt om de codebasis te moderniseren.

Forum Sentiment

Het Joomla Community Forum en de inofficiële Joomla subreddit zijn overstroomd met posts van gefrustreerde beheerders. Veelvoorkomende thema's zijn:

  • "Waarom repareren wat niet kapot was?" — Het admin panel UX was, hoewel niet perfect, functioneel en vertrouwd
  • "Extension apocalypse" — Angsten dat het Composer-gebaseerde systeem het extensie-ecosysteem zal doden
  • "Wie vroeg om Twig?" — Template-developers voelen zich overrompeld door de template engine wijziging
  • "Waar is het migratiepad?" — Gebrek aan heldere, automatische migratietools voor bestaande sites

De bredere context

Dit gebeurt niet in isolement. Het marktaandeel van Joomla daalt gestaag. Volgens W3Techs gegevens van 2026 voorziet Joomla ongeveer 1,5% van alle websites met een bekend CMS, omlaag van 2,6% in 2022. WordPress staat op meer dan 62%. Elke controversiële beslissing versnelt de migratie van sites weg van het platform.

De frustratie van de community gaat niet alleen over Joomla 6 specifiek. Het is de ophoping van jaren voeling alsof de projectleiderschap niet luistert naar de mensen die de software dagelijks gebruiken. Joomla 6 is de katalysator, maar het ressentiment is jaren aan het opbouwen.

Wat de Joomla Leadership zegt

De Open Source Matters (OSM) raad en Joomla production leadership hebben op de kritiek gereageerd, hoewel velen voelen dat de reacties afstandelijk waren.

De officiële positie is dat deze wijzigingen nodig zijn voor Joomla's lange termijn overleven. Het Composer-gebaseerde extension systeem brengt Joomla in lijn met moderne PHP-ontwikkelingspraktijken. De Twig template laag maakt het platform toegankelijker voor developers afkomstig uit andere frameworks. De admin UX wijzigingen zijn gebaseerd op gebruikersonderzoek (hoewel de onderzoeksmethodologie en steekproefgrootte ter discussie staan).

Een blogpost van het Joomla production department in vroeg 2026 erkende de overganspijn maar betoogde dat korte termijn verstoring nodig is voor lange termijn levensvatbaarheid. De post trok vergelijkingen met de Joomla 1.5 naar 2.5 overgang, wat ook pijnlijk was maar uiteindelijk het platform vooruit bracht.

De vergelijking is geschikt, maar niet op de manier die ze bedoelen. De 1.5 naar 2.5 overgang joeg een groot deel van de community weg. Veel van die gebruikers zijn nooit terugkomen.

Moet je migreren of moet je weggaan?

Dit is de vraag die iedereen stelt, en het eerlijke antwoord hangt af van je specifieke situatie.

Blijf als...

  • Je site meestal core Joomla functionaliteit gebruikt zonder zware extensie afhankelijkheden
  • Je template is gebaseerd op Cassiopeia of een framework dat zich aan Joomla 6 ondersteuning heeft verbonden
  • Je hebt interne PHP-developers die de migratiewerk kunnen aanpakken
  • Je organisatie zich om politieke/institutionele redenen aan Joomla heeft verbonden

Ga weg als...

  • Je site afhankelijk is van extensies die geen Joomla 6 roadmap hebben
  • Je bent al gefrustreerd met Joomla en dit is de druppel
  • Je hebt een platform nodig met een groeiend (niet krimpend) ecosysteem
  • De kosten van migratie naar een ander CMS vergelijkbaar zijn met de kosten van upgrade naar Joomla 6

De Cost Reality

Hier is iets wat mensen niet genoeg over praten: migratie van Joomla 5 naar Joomla 6 kan bijna zoveel kosten als migratie naar een compleet ander CMS. Als je templates moet herbouwen, extensies moet bijwerken, staff moet traineren, en alles moet testen, kijk je naar significante development uren ongeacht het doelplatform.

Voor een Joomla-site van gemiddelde complexiteit (50-200 artikelen, 5-10 extensies, aangepaste template), kijk je waarschijnlijk naar 40-80 uren migratiewerk naar Joomla 6. Een migratie naar een headless CMS setup met een modern frontend? 60-120 uren. De kloof is niet zo groot als je zou denken, en de headless benadering geeft je een platform met een groeiend ecosysteem in plaats van een krimpend.

Realistische alternatieven voor Joomla in 2026

Als je serieus alternatieven overweegt, hier is een eerlijke beoordeling van de opties.

Platform Best voor Leercurve Ecosysteem grootte Lange termijn traject
WordPress Content-zware sites, bloggen Laag Massief Stabiel maar Gutenberg omstreden
Headless CMS + Next.js Performance-kritieke sites, apps Gemiddeld-Hoog Snel groeiend Sterk opwaarts
Headless CMS + Astro Content sites, marketing sites Gemiddeld Groeiend Sterk opwaarts
Drupal Enterprise, overheid, complexe data Hoog Groot Stabiel
Craft CMS Mid-size content sites Gemiddeld Gemiddeld Stabiel
Statamic Laravel shops, content sites Gemiddeld Groeiend Positief

De Headless CMS Benadering

Ik ben hier partijdig omdat dit wat wij doen, maar de headless CMS benadering lost het fundamentele probleem op dat steeds terugkeert met traditionele CMS'en zoals Joomla: de koppeling van content management met frontend rendering.

Wanneer je CMS headless is, beheerpaneel UX wijzigingen in het CMS breken je frontend niet. Template rendering wordt behandeld door je frontend framework (Next.js, Astro, wat dan ook), niet het CMS. En je content is toegankelijk via API's, wat betekent dat je nooit aan één rendering technologie vast zit.

Als je in deze benadering geïnteresseerd bent, hebben we behoorlijk wat Joomla-naar-headless migraties gedaan. Ons headless CMS development werk past goed bij ofwel Next.js ofwel Astro op de frontend, afhankelijk van je behoeften.

WordPress: De Duidelijke Keuze?

WordPress is het standaard voorstel wanneer iemand vraagt naar Joomla alternatieven, en het is niet verkeerd. Het ecosysteem is enorm, hosting opties zijn veel voorhanden, en meeste web developers kennen het.

Maar WordPress heeft zijn eigen UX controverses (de block editor/Gutenberg saga spiegelt sommige van wat met Joomla 6 gebeurt). En WordPress's marktdominantie maakt het het grootste doelwit voor aanvallen. Als je Joomla verlaat vanwege concerns over governance, zou WordPress's huidige Matt Mullenweg situatie je ook pauze geven.

Drupal: De Power User's Keuze

Drupal is het overwegen waard als je Joomla-site complexe content relaties, aangepaste content types, of enterprise eisen heeft. Drupal 11 is solide, en de Drupal-community is stabieler (als klein) dan Joomla's.

De downside: Drupal's leercurve is steil, en development kosten zijn typisch hoger dan Joomla of WordPress.

Migratiestrategieën die echt werken

Als je hebt besloten Joomla te verlaten, hier is hoe je de migratie zonder je verstand of je SEO rankings te verliezen aanpakt.

Stap 1: Content Audit

Exporteer alles. Joomla's database structuur is goed gedocumenteerd, en je kunt content direct uit de #__content, #__categories, #__menu, en #__users tabellen trekken. Vertrouw niet op Joomla's ingebouwde export tools — ze zijn gelimiteerd. Schrijf aangepaste SQL queries of gebruik een tool zoals Akeeba's data export functionaliteit.

Stap 2: URL Mapping

Dit is de stap die iedereen overslaat, en het is degene die je SEO vernietigt. Maak een volledige kaart van elke URL op je Joomla-site en de bijbehorende URL op het nieuwe platform. Stel 301 redirects in voor elke enkelen.

# Voorbeeld: een URL-lijst van Joomla's database genereren
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

Stap 3: Kies je doelarchitectuur

Besluit of je een ander traditioneel CMS wilt of een headless setup. Als je site voornamelijk content-gestuurd is (artikelen, blog posts, documentatie), zal een headless CMS met een statisch-eerste frontend framework zoals Astro je dramatisch betere performance geven.

Stap 4: Migreer in parallel

Prober niet een big-bang migratie te doen. Stel de nieuwe site naast de oude in. Migreer content in batches. Test grondig. Schakel DNS alleen in wanneer je zeker weet dat alles werkt.

Als je hulp nodig hebt dit uit te denken, neem contact met ons op. We hebben een herhaalbaar proces voor CMS-migraties ontwikkeld dat SEO equity behoudt en downtime minimaliseert. Je kunt ook onze prijspagina controleren voor ballpark getallen op migratie projecten.

FAQ

Wanneer geeft Joomla 6 officieel uit?

Joomla 6 streeft naar een stabiele release in laat 2026, volgens het projectnew time-based release cycle. Alpha en beta versies zijn al beschikbaar voor testen. De release timeline is al een paar keer verschoven, dus de exacte datum blijft vloeiend.

Zullen mijn Joomla 5 extensies in Joomla 6 werken?

Most zullen niet zonder wijzigingen werken. Joomla 6's Composer-gebaseerde extension systeem vereist nieuwe manifest formaten en bijgewerkte namespace verklaringen. Extensies die op verouderde API's of oude installatiepadden vertrouwen, zullen breken. Check met elke extension-ontwikkelaar op hun Joomla 6 compatibiliteit roadmap voor je een upgrade probeert.

Kan ik in plaats daarvan op Joomla 5 blijven?

Ja, voorlopig. Joomla 5 zal security updates ontvangen tot ongeveer 2 jaar na de Joomla 6 stabiele release, wat betekent ongeveer laat 2028. Daarna ben je op jezelf aangewezen. Blijven op een niet-ondersteunde CMS versie is een aanzienlijk veiligheidsrisico, dus dit is op best een tijdelijke oplossing.

Is de Joomla-community werkelijk over dit uit elkaar gesplitst?

Er is echte spanning, maar het heeft niet tot een formele fork geresulteerd (nog niet). Verschillende prominente communityleden hebben openlijk stappen teruggezet uit bijdragen. De Joomla-community heeft interne conflicten eerder doorstaan, maar de combinatie van dalend marktaandeel en controversiële technische beslissingen maakt deze periode voelbaarder dan voorbijgaande geschillen.

Wat is de goedkoopste manier om van Joomla weg te migreren?

Het meest kosteneffectieve migratie pad hangt af van je site's complexiteit. Voor eenvoudige content sites met minder dan 100 pagina's, kan een handmatige migratie naar WordPress of een headless CMS in 20-30 uren worden gedaan. Voor complexe sites met aangepaste extensies, verwacht 80-150+ uren. Het gebruik van geautomatiseerde migratietools zoals CMS2CMS kan kosten verminderen voor rechtlijnige content moves maar zal aangepaste functionaliteit niet aanpakken.

Moet ik wachten tot Joomla 6 stabiliseert voor ik er over oordeel?

Dat is billijk advies voor de UX wijzigingen — eerste indrukken van nieuwe interfaces zijn vaak harder dan de gevestigde mening. Maar de architectuurwijzigingen (Composer extensies, Twig templates) gaan niet veranderen. Dit zijn fundamentele designbeslissingen. Als die je concern zijn, zal wachten niet helpen.

Hoe vergelijkt Joomla 6 zich met Drupal 11 voor enterprise sites?

Drupal 11 is over het algemeen een sterkere keuze voor enterprise-klasse websites met complexe content modellen, granulaire permissions, en API-first vereisten. Joomla 6's moderniserings inspanningen sluiten enkele gaten, maar Drupal's ecosysteem voor enterprise use cases (content workflows, meertalige ondersteuning, headless delivery) is rijper. Als je al migratiepoging overweegt, is Drupal evalueren het proberen waard.

Wat is de beste headless CMS om Joomla te vervangen?

Het hangt af van je team en vereisten. Voor content-zware marketing sites zijn Sanity of Contentful gekoppeld aan Next.js of Astro uitstekende keuzes. Voor sites die meer structuur nodig hebben, geven Strapi of Payload CMS je meer controle over je content modellen. Het sleutelvoordeel van elke headless benadering is dat je ontkoppeld bent van het CMS's frontend rendering — wat betekent dat je nooit meer met dit soort template-breaking upgrade geconfronteerd wordt.