Wanneer WordPress niet de juiste keuze is (en dat is ok)

Wanneer de grenzen van WordPress zichtbaar worden, ben je al te laat…

Soms is WordPress niet de juiste keuze!

WordPress is zonder twijfel één van de meest gebruikte platforms ter wereld. En de kans, dat ook jouw website hierop draait is heel groot, helemaal natuurlijk omdat je op dit moment op een website bent, waarbij vrijwel ieder blogartikel over WordPress gaat. En in veel, zo niet de meeste van die gevallen, is WordPress een prima keuze.

Maar WordPress is niet altijd de juiste keuze. En sterker nog, in veel gevallen is het een structureel verkeerde keuze, die je groei, performance en flexibilitiet beperkt.

En nee, dat wil niet zeggen, dat je nu direct van WordPress af moet om mee te gaan doen aan de nieuwste rage van dit moment. Het betekent echter wel, dat je moet begrijpen, waar WordPress ophoudt, en waar iets anders begint!

Waar WordPress goed in is – En waarom WordPress dan ook beslist de hiervoor juiste keuze is!

WordPress is extreem sterk in contentbeheer. In de vroege jaren 10 van deze eeuw, zorgde WordPress letterlijk voor een revolutie. Op zich was WordPress niet het eerste CMS. Wanneer je een oudgediende in de Open Source wereld bent, dan komen namen als PhpNuke, en PostNuke, Drupal en Joomla je waarschijnlijk bekend voor.

Zelf ben ik in een grijs verleden bijdrager geweest aan een ander CMS, wat een beperkte tijd razend populair was -en nu nog steeds bestaat overigens, al doe ik er niets meer mee- TikiWiki

En denk je aan bloggen, dan waren Movable Type, GreyMatter en b2/cafelog ook razend populair. b2/cafelog was overigens de directe voorloper van WordPress, WordPress is ontstaan als een ‘fork’ van dit project.

Wat uniek was aan WordPress was, dat het een brug sloeg tussen traditionele CMS-en aan de éne kant, blog-systemen aan de andere kant en bovendien de gebruikersinterface enorm vereenvoudigde, waardoor het bijhouden van je eigen website met blog ineens een stuk makkelijker werd.

En dat ‘content management’ is nog steeds een krachtige factor, waardoor WordPress zoveel jaren later nog steeds de ‘default go-to’ oplossing is voor veel websites.

Plugins stapelen

Toch kent WordPress de nodige beperkingen en vorig jaar heb ik serieus de vraag durven stellen, of WordPress het einde van 2025 wel zou halen.

WordPress is als een hamer. En hoewel een hamer beslist niet mag ontbreken in je gereedschapskist, is het een minder geschikt stuk gereedschap om een plank in te korten, of een schroef in de muur te krijgen. Sommige zaken -zoals de schroef- lukt nog wel met een hamer, maar voor sommige andere oplossingen heb je toch echt een zaag nodig.

Eén van de sterke onderdelen van WordPress is de mogelijkheid om plugins te gebruiken. Maar het is direct ook de grootste valkuil. Omdat het zo makkelijk is een plugin aan WordPress toe te voegen, wordt WordPress vaak gezien als een ‘container’ voor je plugins. Je voegt een bepaalde plugin toe om bepaalde functionaliteiten in WordPress te krijgen.

Wat dat als gevolg heeft, kan je in het bovengenoemde artikel nog eens nalezen. Scan dan de tekst vooral op de term ‘monolith’.

Hoe meer plugins je toevoegt, hoe ‘zwaarder’ WordPress wordt. Tot het tenslotte de molensteen om je nek wordt.

Waar WordPress niet echt goed in is.

WordPress is minder geschikt voor systemen met een zware interactie met de klant. En dit is om een aantal redenen. Laten we die eens één voor één bekijken:

Het flexibele datamodel nekt de performance

Het aardige -of juist het trieste?- van WordPress is, dat hetgeen WordPress groot maakte, ook de ontwikkeling van WordPress beperkt. Het zal je ongetwijfeld opgevallen zijn, dat de invoerschermen voor content in WordPress wel heel erg op elkaar lijken. En dat is geen toeval. Vanaf versie 3.0 heeft WordPress iets als ‘Custom Post Types‘.

De gedachte hierachter is dat je alle soorten van informatie in één vaste structuur in kan passen, die -even ruwweg- bestaat uit een titel, een body, taxonomiën (zoals tags en categorieën), bijlagen (bestanden, zoals een uitgelichte afbeelding bijvoorbeeld) en ‘meta velden’, alle ‘overige velden’ die je nodig hebt.

Het voordeel hiervan, is dat je in principe geen extra userinterface hoeft te programmeren om de informatie op te slaan.

Er kleeft echter ook een aantal nadelen aan. Het eerste nadeel merk je in de userinterface: De informatie die je bij een ‘custom post type’ in moet vullen staat op verschillende plaatsen op de pagina, er is geen logische volgorde voor het invoeren van de gegevens.

Het tweede nadeel, is dat door deze structuur, waarbij verschillende informatiemodellen (denk bij een informatiemodel aan zaken als ‘blogpost’, ‘pagina’, ‘product’, ‘testimonial’) allemaal opgeslagen worden in eenzelfde groep tabellen. Wanneer je deze informatie aan elkaar moet relateren, dan moet er een enorme hoeveelheid van vragen (‘queries’) op de database worden afgevuurd. Hoeveel dat er kunnen zijn, kan je zien, wanneer je de ‘QueryMonitor‘ plugin gebruikt. Om een ‘gewone’ pagina te laden, worden soms honderden vragen richting database gestuurd.

Wat dus extra tijd kost.

De ‘Monoliete’ laadstructuur van plugins

Een tweede reden waarom wordpress niet de juiste keuze voor iedere oplossing is, omdat WordPress een monolithe laadstructuur heeft. Bij het laden van een pagina wordt iedere plugin geladen, in ieder geval tenminste voor een deel. Wanneer ik bijvoorbeeld WooCommerce heb zal WooCommerce op iedere pagina geladen worden. Of het nu een winkelpagina is, of niet.

Hierdoor wordt het geheugengebruik van WordPress voor een site met een groot aantal plugins wel heel zwaar. Ik heb ik in het verleden meer dan eens over geschreven.

De monoliete logica

Een tweede probleem met betrekking tot WordPress als een monoliet is, dat door de monoliete structuur er niet echt een ‘beveiligingslaag’ is. Iedere plugin heeft in principe toegang tot alles. Er is geen ‘beschermingslaag’.

Er is weinig structurele standaardisatie voor WordPress

WordPress is oud. In 2003 zag de eerste versie van WordPress het licht. En het is best uitzonderlijk, dat na 23 jaar software zo dominant is, zonder echt een complete overhaul van de code gehad te hebben. In die 23 jaar is er heel wat aan PHP, de onderliggende programmeertaal, veranderd. Ook aan de ‘code standaard’ waarmee gewerkt wordt. De afspraken van ‘hoe‘ PHP gebruikt moest worden zijn in de loop der jaren een aantal malen aangepast. Je ziet dus allerlei stijlen van coderen door elkaar.

Inmiddels hebben de makers van WordPress besloten, dat op dit moment alleen nog PHP 8.x ondersteund wordt, waardoor er veilig gebruik kan worden gemaakt van een meer georganiseerde opzet van de code, maar er is nog een erfenis van 2 decennia aan ‘oude’ code.

Wat echter nog veel verontrustender is, is dat er voor WordPress wel een code-stijl standaardisatie bestaat, maar geen structurele standarisatie. Wat ik daarmee bedoel leg ik later uit.

Gebrek aan uniforme applicatie interface

Een ander probleem met WordPress is dat er een gebrek is aan een uniforme applicatie voor een groot aantal functionaliteiten. Om een tweetal voorbeelden te geven. Vrijwel iedere zakelijke website doet wel iets met listbuilding. De toepassing die je voor listbuilding gebruikt kan echter verschillend zijn. Denk hier bijvoorbeeld aan ActiveCampaign, MailChimp en nog wat andere namen. Vanuit verschillende plugins kan het handig zijn, wanneer iemand op jouw mailinglijst zou komen te staan. Dat kan direct via een formulier, maar ook bijvoorbeeld omdat iemand bij je koopt.

Ik heb bij mij op de website 4 verschillende plugins staan, die allemaal iets met betrekking tot email koppelingen aanbieden. Een functionaliteit die dus viermaal apart geprogrammeerd is, en wanneer ik het van iedere plugin zou willen gebruiken, een functie die viermaal geconfigureerd moet worden.

Eenzelfde situatie kan je hebben met een betaalfunctie. Er zijn allerlei verschillende betaalproviders: PayPal, Stripe, Mollie. Deze providers bieden soms dezelfde betaaldiensten aan: Met PayPal, Stripe en Mollie kan een klant per creditcard betalen, met Stripe en Mollie kan er met iDEAL Wero betaald worden. Omdat er een extreem groot aantal betaalaanbieders is en Nederland maar een klein land is, waren de aanbieders die iDEAL/Wero aanboden zeer beperkt. En was het voor pluginbouwers ondoenlijk om ook in de Nederlandse behoeften te voorzien. (Door het groot worden van Mollie is dat inmiddels veranderd).

Veel WordPress plugins met betaalopties bieden alleen PayPal en creditcard (meestal via Stripe) aan. En als extra ‘uitstapmogelijkheid’ wordt een optie voor het betalen via WooCommerce aangeboden. Omdat voor WooCommerce voor vrijwel ieder betaalsysteem van betekenis een betaalplugin bestaat, kan op deze manier WooCommerce als ‘laag’ tussen bijvoorbeeld WP Courseware en de betaalprovider. WooCommerce is echter een zware plugin, en door het e-commerce systeem op deze manier in te zetten creëer je een grote overhead.

De Plugin Overkill

Bovenstaand voorbeeld maakt ook gelijk een ander probleem duidelijk: De ‘Plugin Overkill’. Omdat de maker van een plugin natuurlijk wil, dat zijn plugin door zoveel mogelijk mensen gebruikt wordt -liefst tegen betaling- zal hij er zoveel mogelijk functionaliteit aan toe willen voegen.

Hierdoor ontstaat een nieuw probleem: De meeste plugins bevatten meer functionaliteit, dan de eigenaar van de website echt wil gebruiken. Het voorbeeld van WooCommerce als ‘betaaltussenlaag’ is misschien wel het meest extreme voorbeeld (een complete webshop installeren om alleen maar betaallinks te genereren), maar in zijn algemeenheid zie ik toch, dat WordPress websites veel overhead hebben. En al die overhead kost natuurlijk weer extra geheugen en laadtijd, omdat voor iedere pagina vrijwel iedere plugin moet worden geladen.

Nogmaals in schema:

Een pleidooi voor een hybride oplossing

Toen in 2003 WordPress het levenslicht zag, was het implementeren van een directe interface tussen twee applicaties best nog een huzarenstukje, wat aardig wat tijd kostte. Dat is in de laatste jaren gelukkig stukken beter geworden. Het Internet hangt aan elkaar van communicerende apps.

Door de ontwikkeling van nieuwe communicatiemethoden als REST, en formaten als JSON en betere tools om dit soort communicatie te debuggen, is het ‘aan elkaar koppelen’ van toepassingen niet meer het probleem wat het vroeger was.

In plaats van één monoliet, zoals een WordPress website, is het natuurlijk ook mogelijk om een deel van het werk ‘uit te besteden’ aan een aparte server-applicatie.

Wanneer is zo’n hybride oplossing nuttig?

Wanneer er achter de gegevensverwerking op je website ingewikkelde bedrijfsregels toegepast moeten worden, wanneer er een complexe rechtenstructuur op de toegang van gegevens van toepassing is, wanneer je verschillende accountstypen hebt, of simpelweg je site niet meer vooruit te branden is, kan het nuttig om eens serieus te kijken, wat de beste oplossing is.

Laten we het op voorhand eens zijn: Voor wat betreft het opmaken van een website, de aanlevering van content en het gebruiksgemak wint WordPress het op alle mogelijke fronten. Dus aan de frontend blijf je het liefst WordPress gebruiken. Maar voor wat er aan de achterkant gebeurt, kan het goed zijn om ook andere opties te overwegen.

En dan komt wat mij betreft Laravel als eerste om de hoek kijken.

Een korte geschiedenis van Laravel

Laravel is een PHP-framework dat in 2011 werd ontwikkeld door Taylor Otwell als alternatief voor bestaande frameworks zoals CodeIgniter, die destijds beperkt waren in moderne features. Laravel bracht direct een frisse aanpak met zich mee, gericht op ontwikkelgemak en duidelijke structuur.

De basis van Laravel ligt in het MVC-patroon (Model-View-Controller), waardoor code logisch gescheiden blijft. Het framework introduceerde Eloquent ORM, waarmee database-interacties objectgeoriënteerd en veilig worden uitgevoerd.

Daarnaast biedt Laravel krachtige tools zoals Artisan CLI voor het genereren van code en automatiseren van taken, en volgt het principe “convention over configuration”, waardoor je minder hoeft te configureren en sneller kunt ontwikkelen.

Met ingebouwde ondersteuning voor routing, authenticatie, queues, events en testing is Laravel uitgegroeid tot een compleet ecosysteem voor moderne webapplicaties — van kleine tools tot complexe SaaS-platformen.

Het Model-View-Controller patroon

Het MVC patroon is een manier om naar een applicatie te kijken, als een model in drie lagen. Het ‘Model’ is de laag, waarin de data gedefinieerd is en is verantwoordelijk voor de koppeling tussen data en logica. Omdat alle database toegang via het model verloopt, en de autorisatie ook op dit niveau wordt uitgevoerd, is de beveiliging van de data -zowel voor wat betreft de data integriteit als de privacy- beter beschermd.

Door het ORM (Object Relational Mapping) te gebruiken, worden vragen aan de database op uniforme wijze gesteld. Bovendien worden gegevens gecached, zodat een tweede vraag binnen een ingestelde tijd, niet via de database, maar vanuit de cache wordt afgehandeld.

Bovendien beschermt het ORM de database tegen ‘SQL Injecties’, pogingen van hackers om via SQL opdrachten toegang te krijgen tot een applicatie.

Convention over configuration

Het meest krachtige uitgangspunt van Laravel is denk ik wel ‘Convention over Configuration’. Het onderliggende idee is eigenlijk kinderlijk eenvoudig. Heel veel tijd gaat er verloren aan het coderen van invoerformulieren. Door in het MVC van uniforme conventies uit te gaan, zit veel ‘uitvoering’ van code al in het framework verwerkt.

Bijvoorbeeld:

Er is een afspraak dat tabellen in de database altijd een ‘naam in meervoud’ hebben, en een Model altijd een ‘naam in enkelvoud’. Bovendien is de tabelnaam altijd in lowercase.

Hierdoor ‘weet’ Laravel, dat het model User de gegevens haalt uit de tabel ‘users’. Dit gaat zo op veel niveaus, waardoor allerlei verwijzingen, waarbij tabellen expliciet aangesproken dienen te worden in Laravel vrijwel niet voorkomen.

artisan code generatie

Omdat we al deze conventies hebben, is het mogelijk om met de Laravel CLI-tool ‘Artisan’ een groot deel van de structuur van de code al op te zetten.

Met een commando als

php artisan model:make Product -m

maak ik direct al de bestanden aan om in de database de tabel ‘products’ aan te maken (de -m staat voor ‘migration’, een script om de database aan te maken, plus de code voor het model ‘Product’ (waar ik vervolgens de relatie met andere modellen in kan plaatsen).

Filament

En tenslotte de invoerschermen voor gegevens: Met een ‘package’ voor Laravel met de naam ‘Filament’ is het mogelijk om direct code te genereren voor het beheren van data.

Een vergelijk

Laravel werkt in die zin wezenlijk anders dan WordPress, omdat Laravel alleen laadt, wat op dat moment noodzakelijk is. Of met andere woorden, Laravel hoeft minder te laden, gebruikt dus minder geheugen en is dus sneller.

Omdat WordPress constant dezelfde groep tabellen moet bevragen (wanneer een plugin Custom Post Types gebruikt), moet WordPress meer vragen op een database afvuren. Bovendien kan je bij Laravel de manier van opvragen vergaand optimaliseren, waardoor soms wanneer er een vraag richting database gesteld wordt, je slechts één vraag naar de database stuurt, terwijl je bij WordPress tientallen vragen zou sturen, om dezelfde informatie te vervangen.

En tenslotte, WordPress is ‘database-driven’, vrijwel alle informatie over de te tonen pagina wordt uit de database gehaald. Dat is wat WordPress juist zo flexibel maakt. Laravel is vooral ‘code driven’. Met als extra opmerking, dat die ‘code’ wel heel weinig kan zijn, wanneer je je aan de conventies houdt.

Omdat Laravel code-driven is, heb je niet de flexibiliteit in vormgeving die je hebt met WordPress. En hierdoor is WordPress juist veel meer flexibel met betrekking tot de content.

REST

Kosten

Het mag je vreemd in de oren klinken, maar een Laravel app hoeft helemaal zo duur niet te zijn. Omdat er met Laravel veel met conventies wordt gewerkt, is het mogelijk om veel code automatisch te laten genereren. (en dat zonder AI. De logische opbouw van een Laravel app maakt code generatie eenvoudiger) Om een specifieke oplossing 100% als plugin voor WordPress te bouwen, schat ik zo’n 3-4x langer bezig te zijn.

Tenzij het wel heel complex zou worden, en dan zou het al helemaal niet geschikt zijn als plugin, denk ik dat ik voor het programmeren van een ‘gemiddelde Laravel app’ zo’n 2-3 dagen bezig. Dit doe ik tegen ‘fixed price’, onder meer afhankelijk van de complexiteit.

Laten we zeggen, dat ik het inschat op 1000 euro (rekent makkelijk). Dan komt daar 15% per jaar onderhoud op de code op, dus dat is in 3 jaar 1000 euro in het eerste jaar, 150 in het tweede en derde jaar.

Zou ik dezelfde plugin helemaal in WordPress bouwen, zou mij dat 3 of 4 keer zo lang duren. Laten we het op 3 houden, dus dat is 3000 euro in het eerste, 450 in het 2e en 3e jaar.

In beide gevallen, heb je het recht je plugin op al je sites te gebruiken.

Nu de vergelijking met een commerciële plugin. Een beetje uitgebreide premium plugin kost al snel 300 euro voor één site. Hierbij heb je waarschijnlijk een hoop functies die je niet gebruikt, plus een aantal functies die je wel gehad zou willen hebben, maar nog steeds mist. En die 300 euro komt ieder jaar terug.

Het is dus niet zo, dat een Laravel app goedkoper zou zijn, dan een ‘fixed price’ plugin. Het ontlast je server en de performance ervaring van de klant zal beter zijn.

Maar heb je ideeën om een ‘zware plugin’ op je site te installeren, denk dan ook aan de alternatieve mogelijkheden. Neem contact op via de website, en laten we een belafspraak inplannen, waarop ik naar jouw behoeften kan vragen en je over de mogelijkheden kan informeren.