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

Als je al enige tijd Joomla-sites beheert, heb je waarschijnlijk dat vertrouwde onbehaaglijk gevoel gevoeld toen een grote versie uitkwam. Joomla 4 was lastig. Joomla 5 gladde enkele ruwtes. Maar Joomla 6? Dit wordt waarschijnlijk de meest controversiële release in de geschiedenis van het CMS. Het admin panel UX is volledig herzien, de extensie-manager is fundamenteel anders, template rendering heeft breekbare wijzigingen die bijna elke aangepaste template beïnvloeden, en de community verwerkt dit... niet goed.

Ik bouw en onderhoud Joomla-sites sinds de Mambo-tijden. Ik heb klanten door alle pijnlijke grote versie-upgrades gemigreerd. Dus wanneer ik zeg dat Joomla 6 zich anders voelt — niet op een goede manier — overdrijf ik niet. Laat me je precies door alle wijzigingen lopen, waarom langdurige beheerders boos zijn, en welke realistische alternatieven beschikbaar zijn als je overweegt het schip te verlaten.

Inhoudsopgave

Why Joomla Admins Are Furious About Joomla 6 UX Changes

De Joomla 6 Admin Panel UX-herziening

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

Wat is echt veranderd

Het oude admin panel had een inklapbare linker sidebar met geneste menu-items. Je kon naar elke sectie van het CMS in maximaal twee klikken. Het was niet mooi, maar het was functioneel en — cruciaal — consistent.

Joomla 6 gaat over naar een horizontale top-navigatiebalk met dropdown mega-menu's. De linker sidebar verschijnt nu alleen contextueel en toont opties relevant voor de sectie waar je momenteel bent. Artikelbeheer, gebruikersbeheer, extensieconfiguratie — ze hebben allemaal nu verschillende sidebar-layouts.

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 Begraven onder Systeem-menu
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 Ruwweg equivalent

Waarom beheerders het haten

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

Wanneer je 15+ Joomla-sites beheert en je ze hele dag door wisselt, vertrouw je erop dat je precies weet waar dingen zijn zonder na te denken. Joomla 6 dwingt je alles opnieuw te leren. En de contextuele sidebar betekent dat de navigatie niet eens consistent is binnen het nieuwe systeem. De sidebar toont verschillende items afhankelijk van waar je bent, wat het opbouwen van nieuw spierspiergeheugen moeilijker maakt.

Er is ook de toegankelijkheidskant. Verschillende community-leden hebben gerapporteerd dat de mega-menu dropdowns niet goed werken met schermlezers en toetsenbordnavigatie is inconsistent. Voor een open-source CMS die zich brüskeert met toegankelijkheid is dit een significante teruggang.

Het dashboard-widgets-probleem

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

Je kunt niet meer aangepaste dashboard-lay-outs per gebruikersgroep maken — een functie die veel Joomla-agencies gebruikten om vereenvoudigde admin-ervaringen voor klanten te creëren. In plaats daarvan is er een enkele dashboard-layout met op rollen gebaseerde zichtbaarheidsaanpassingen op individuele widgets. Dit is een stap achteruit in functionaliteit ingepakt als een stap vooruit in ontwerp.

Extensie-manager: alles wat je wist is fout

Dit is waar het echt pijnlijk wordt. Joomla 6 introduceert een volledig herschreven extensiebeheersysteem en het verbreekt compatibiliteit met hoe extensies meer dan tien jaar zijn verpakt en geïnstalleerd.

De nieuwe extensie-architectuur

Joomla 6 gaat over naar een Composer-gebaseerd extensiebeheersysteem. Op papier is dit een goed idee. Composer is de standaard voor PHP-afhankelijkheidsbeheer, en Joomla in lijn brengen met moderne PHP-praktijken heeft zin.

In de praktijk betekent dit:

  • Extensiepakketten moeten nu een composer.json bevatten met passende namespace-verklaringen
  • Het oude XML-manifestformaat is verouderd (werkt nog steeds in 6.0 maar geeft waarschuwingen, gepland voor verwijdering in 6.2)
  • Extensie-ontdekking en installatiepadden zijn gewijzigd — aangepaste installatiescripts die naar oude paden verwijzen breken
  • Het update-server-protocol is herzien — extensies die het oude update XML-formaat gebruiken moeten migreren naar het nieuwe JSON-gebaseerde update-manifest
// Nieuw Joomla 6 extensie-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 extensie-compatibiliteitscrisis

Hier is de werkelijke impact: een significant deel van het Joomla-extensie-ecosysteem is niet klaar. Volgens gegevens van de Joomla Extensions Directory (JED) vanaf begin 2025 is ruwweg 40% van vermelde extensies niet bijgewerkt voor Joomla 5-compatibiliteit, laat staan Joomla 6.

Van de extensies die Joomla 5-compatibel zijn, suggereert vroeg testen dat ongeveer 60-70% niet-triviale wijzigingen nodig zal hebben om met Joomla 6's nieuwe extensie-architectuur te werken. We hebben het niet over kleine aanpassingen. We hebben het over herstructurering van hoe extensies worden verpakt en verspreid.

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

Wat dit betekent voor site-eigenaren

Als je Joomla-site afhankelijk is van vijf of meer externe extensies (en dat zijn er de meeste), moet je alles voorafgaand aan de upgrade controleren. Maak een spreadsheet. Controleer elke extensie-ontwikkelaarssite op Joomla 6-aankondigingen. Als er geen mention van Joomla 6-ondersteuning is, neem aan dat het niet zal werken.

Ik heb deze audit voor drie client-sites gedaan. Twee hiervan hebben ten minste één kritieke extensie zonder Joomla 6-routekaart. Dat is een migratieblokker.

Template rendering breekbare wijzigingen

De template-systeemwijzigingen in Joomla 6 zijn het soort ding dat ervaren ontwikkelaars doen winnen. Joomla is verplaatst van zijn traditioneel PHP-gebaseerde template-override-systeem naar een hybride aanpak die een nieuwe template-laag introduceert.

De nieuwe template-engine

Joomla 6 introduceert Twig als optionele (maar duidelijk voorkeurs-) template-engine naast de traditionele PHP-overrides. De core-admin-templates zijn nu geschreven in Twig. Frontend-templates kunnen PHP of Twig gebruiken, maar het template-override-ontdekkingssysteem 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-ontdekkingsvolgorde is gewijzigd. In Joomla 5 stonden template-overrides 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-ontwikkelaar zowel PHP als Twig-overrides levert (wat veel zullen doen ter ondersteuning van de overgang) je aangepaste PHP-overrides stilzwijgend kunnen worden genegeerd. Ik heb al gezien dat dit mensen in beta-testen bijt.

Bovendien is het template-parameters-systeem herzien. Template-parameters gedefinieerd in templateDetails.xml hebben nu corresponderende entries nodig in een nieuw template.config.php-bestand. 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 template-providers zoals JoomlArt, GavickPro en Youjoomla zitten in een moeilijke positie. Hun bedrijfsmodel berust op het onderhouden van template-frameworks die over Joomla-versies werken. De Twig-introductie en override-prioriteitswijzigingen betekenen dat ze eigenlijk hun template-frameworks moeten herbouwen.

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

Why Joomla Admins Are Furious About Joomla 6 UX Changes - architecture

Community-reactie: forums, GitHub en social media

De community-respons is... intens. En meestal negatief.

GitHub-issues en pull-requests

De Joomla GitHub-repository heeft een piek gezien in issue-rapportages gelabeld met de J6-milestone. Verschillende prominente community-leden hebben gedetailleerde issues geopend met UX-regressies. Een bijzonder opvallende thread met meer dan 200 opmerkingen betoogt dat de admin panel-wijzigingen zonder adequate community-raadpleging zijn doorgevoerd.

De pull-request die de nieuwe extensiebeheersarchitectuur introduceerde ontving aanzienlijke tegenstand tijdens review, waarbij verschillende langdurige bijdragers tegen de merge stemden. Het werd toch samengevoegd, met het productie-leiderschap-team citeerde de noodzaak om de codebase te moderniseren.

Forum-sentiment

Het Joomla Community Forum en de onofficiële Joomla subreddit zijn overstroomd met posts van gefrustreerde beheerders. Veel voorkomende thema's zijn onder meer:

  • "Waarom iets repareren wat niet stuk was?" — Het admin panel UX was, hoewel niet perfect, functioneel en vertrouwd
  • "Extensie-apocalyps" — Angsten dat het Composer-gebaseerde systeem het extensie-ecosysteem zal doden
  • "Wie vroeg om Twig?" — Template-ontwikkelaars voelen zich overvallen door de template-engine-wijziging
  • "Waar is het migratiepad?" — Gebrek aan duidelijke, geautomatiseerde migratietools voor bestaande sites

De bredere context

Dit gebeurt niet in een vacuüm. Joomla's marktaandeel is gestaag afgenomen. Volgens W3Techs-gegevens van 2025 voorziet Joomla ruwweg 1,5% van alle websites met een bekend CMS, omlaag van 2,6% in 2022. WordPress zit op meer dan 62%. Elke controversiële beslissing versnelt de migratie van sites weg van het platform.

De community-frustratie gaat niet alleen over Joomla 6 specifiek. Het is de verzameling van jaren waarin je voelt dat de projectleiding niet naar de mensen luistert die de software dagelijks echt gebruiken. Joomla 6 is de katalysator, maar de ressentimenten zijn al jaren aan het opbouwen.

Wat de Joomla-leiding zegt

Het Open Source Matters (OSM)-bestuur en Joomla-productie-leiding hebben op de kritiek gereageerd, hoewel veel voelen dat de reacties verkeerd zijn geweest.

De officiële positie is dat deze wijzigingen nodig zijn voor Joomla's lange-termijn-overleven. Het Composer-gebaseerde extensiesysteem brengt Joomla in lijn met moderne PHP-ontwikkelingspraktijken. De Twig-template-laag maakt het platform toegankelijker voor ontwikkelaars van andere frameworks. De admin UX-wijzigingen zijn gebaseerd op gebruikersonderzoek (hoewel de onderzoeksmethodologie en steekproefgrootte in twijfel zijn getrokken).

Een blogpost van de Joomla-productieafdeling in begin 2025 erkende de transitiepijn maar betoogde dat korte-termijn-verstoring nodig is voor lange-termijn-levensvatbaarheid. De post trok vergelijkingen met de Joomla 1.5 tot 2.5-overgang, wat ook pijnlijk was maar uiteindelijk het platform naar voren bracht.

De vergelijking is toepasselijk, maar niet op de manier waarop ze het bedoelen. De 1.5 naar 2.5-overgang dreef een massief deel van de community weg. Veel van die gebruikers zijn nooit teruggekomen.

Moet je migreren of weggaan?

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

Blijf als...

  • Je site gebruikt meestal core Joomla-functionaliteit zonder zware extensie-afhankelijkheden
  • Je template is gebaseerd op Cassiopeia of een framework dat zich heeft ingespannen voor Joomla 6-ondersteuning
  • Je hebt interne PHP-ontwikkelaars die het migratiewerk kunnen afhandelen
  • Je organisatie is om politieke/institutionele redenen aan Joomla gebonden

Ga weg als...

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

De kostrealiteit

Hier is iets waar mensen niet genoeg over praten: migratie van Joomla 5 naar Joomla 6 kan bijna evenveel kosten als migratie naar een volledig ander CMS. Als je templates moet herbouwen, extensies moet bijwerken, personeel opnieuw moet trainen en alles moet testen, kijk je naar aanzienlijke ontwikkelingsuren ongeacht het doelplatform.

Voor een middelmatig complexe Joomla-site (50-200 artikelen, 5-10 extensies, aangepaste template), kijk je waarschijnlijk naar 40-80 uur migratiewerk naar Joomla 6. Een migratie naar een headless CMS-setup met een modern frontend? 60-120 uur. 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 2025

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

Platform Geschikt voor Leercurve Ecosysteem-grootte Lange-termijn-richting
WordPress Content-zware sites, bloggen Laag Massief Stabiel maar Gutenberg omstreden
Headless CMS + Next.js Prestatie-kritische sites, apps Gemiddeld-Hoog Snel groeiend Sterke opwaartse trend
Headless CMS + Astro Content-sites, marketing-sites Gemiddeld Groeiend Sterke opwaartse trend
Drupal Enterprise, overheid, complexe gegevens Hoog Groot Stabiel
Craft CMS Mid-size content-sites Gemiddeld Matig Stabiel
Statamic Laravel-winkels, content-sites Gemiddeld Groeiend Positief

De headless CMS-benadering

Ik ben voorgeparandeerd hier omdat dit wat we doen bij Social Animal, maar de headless CMS-benadering lost het fundamentele probleem op dat steeds opnieuw terugkomt met traditionele CMS'en zoals Joomla: de koppeling van contentbeheer met frontend-rendering.

Wanneer je CMS headless is, kunnen UX-wijzigingen in het CMS je frontend niet breken. Template rendering wordt afgehandeld door je frontend-framework (Next.js, Astro, wat dan ook), niet het CMS. En je content is toegankelijk via API's, betekenende je bent nooit vergrendeld aan een enkel rendering-technologie.

Als je in deze benadering geïnteresseerd bent, hebben we al behoorlijk wat Joomla-naar-headless-migraties gedaan. Ons headless CMS-ontwikkelingswerk werkt goed samen met ofwel Next.js of Astro aan de frontend, afhankelijk van je behoeften.

WordPress: De voor de hand liggende keuze?

WordPress is de standaard suggestie wanneer iemand naar Joomla-alternatieven vraagt, en het is niet verkeerd. Het ecosysteem is enorm, hosting-opties zijn rijkelijk en de meeste webontwikkelaars kennen het.

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

Drupal: De keuze van de power-user

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

Het nadeel: Drupal's leercurve is steil en ontwikkelings-kosten zijn meestal hoger dan Joomla of WordPress.

Migratiestrategieën die echt werken

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

Stap 1: Content-audit

Exporteer alles. Joomla's databasestructuur is goed gedocumenteerd en je kunt content rechtstreeks trekken uit de #__content, #__categories, #__menu en #__users-tabellen. Vertrouw niet op Joomla's ingebouwde exporttools — ze zijn beperkt. Schrijf aangepaste SQL-query's of gebruik een tool zoals Akeeba's data-export-functionaliteit.

Stap 2: URL-toewijzing

Dit is de stap waar iedereen overheen springt en het is de stap die je SEO vernietigt. Maak een compleet kaart van elke URL op je Joomla-site en de corresponderende URL op het nieuwe platform. Stel 301-omleidingen in voor elk daarvan.

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

Beslis of je een ander traditioneel CMS of een headless-setup wilt. Als je site primair content-gedreven is (artikelen, blogposts, documentatie), zal een headless CMS met een statisch-first frontend-framework zoals Astro je dramatisch betere prestaties geven.

Stap 4: Migreer parallel

Probeer geen big-bang-migratie. Stel het nieuwe site naast het oude in. Migreer content in batches. Test grondig. Schakel DNS alleen over wanneer je zeker bent dat alles werkt.

Als je hulp nodig hebt bij het plannen, neem contact met ons op. We hebben een herhaalbaar proces voor CMS-migraties ontwikkeld dat SEO-waarde bewaart en downtime minimaliseert. Je kunt ook ons prijzingspagina controleren voor grove cijfers op migratieprojecten.

Veelgestelde vragen

Wanneer is Joomla 6 officieel uitgebracht? Joomla 6 streeft naar een stabiele release in late 2025, volgend op het nieuwe op tijd gebaseerde release-cyclus van het project. Alpha- en bètaversies zijn al beschikbaar voor testen. De timeline voor de release is al een paar keer verschoven, dus de exacte datum blijft vloeiend.

Zullen mijn Joomla 5-extensies in Joomla 6 werken? De meesten werken niet zonder wijzigingen. Joomla 6's Composer-gebaseerde extensiesysteem vereist nieuwe manifest-formaten en bijgewerkte namespace-verklaringen. Extensies die vertrouwen op verouderde API's of oude installatiepadden zullen breken. Controleer bij elke extensie-ontwikkelaar hun Joomla 6-compatibiliteitsroutekaart voordat je een upgrade probeert.

Kan ik in plaats daarvan op Joomla 5 blijven? Ja, voor nu. Joomla 5 zal veiligheidsupdates ontvangen tot ongeveer 2 jaar na de stabiele Joomla 6-release, wat ruwweg late 2027 betekent. Daarna ben je op jezelf aangewezen. Op een niet-ondersteunde CMS-versie blijven is een aanzienlijk beveiligingsrisico, dus dit is maximaal een tijdelijke oplossing.

Splitst de Joomla-community zich echt over dit? Er is echte spanning, maar het heeft niet geresulteerd in een formele fork (nog niet). Verschillende prominente community-leden hebben publiekelijk afstand genomen van bijdragen. De Joomla-community heeft voor interne conflicten weerstand geboden, maar de combinatie van afnemend marktaandeel en controversiële technische beslissingen maakt deze periode voelbare precairder dan eerdere geschillen.

Wat is de goedkoopste manier om weg te migreren van Joomla? Het meest kosteneffectieve migratiepad hangt af van je site-complexiteit. Voor eenvoudige content-sites met minder dan 100 pagina's kan een handmatige migratie naar WordPress of een headless CMS worden gedaan in 20-30 uur. Voor complexe sites met aangepaste extensies, verwacht 80-150+ uur. Het gebruik van geautomatiseerde migratietools zoals CMS2CMS kunnen kosten reduceren voor eenvoudige content-moves maar zal aangepaste functionaliteit niet afhandelen.

Moet ik wachten tot Joomla 6 stabiliseert voordat ik het oordeel? Dat is goed advies voor de UX-wijzigingen — eerste indrukken van nieuwe interfaces zijn vaak harder dan de stabiele mening. Maar de architecturale wijzigingen (Composer-extensies, Twig-templates) gaan niet veranderen. Dat zijn fundamentele ontwerpbeslissingen. Als dit je zorg is, zal wachten niet helpen.

Hoe verhoudt Joomla 6 zich tot Drupal 11 voor enterprise-sites? Drupal 11 is over het algemeen een sterkere keuze voor enterprise-grade websites met complexe content-modellen, granulaire permissies en API-eerste eisen. Joomla 6's moderniseringsinspanningen sluiten enkele gaten, maar Drupal's ecosysteem voor enterprise-use-cases (content-workflows, meertalige ondersteuning, headless-levering) is volwassener. Als je al over de migratiepoging nadenkt, is Drupal het beoordelen waard.

Welke headless CMS is het best voor Joomla te vervangen? Dit hangt af van je team en eisen. 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 kernvoordeel van elke headless-benadering is dat je ontkoppeld bent van het CMS's frontend-rendering — betekenende je zal dit soort template-breekende upgrade nooit meer tegenkomen.