WordPress ging van open source blogplatform naar het werkpaard van het internet. Bijna de helft van de websites, inclusief deze, draait erop en dat marktaandeel groeit nog steeds. De mogelijkheden zijn, dankzij de open architectuur, eindeloos. En toch stap ik ervan af.
Mijn eerste eigen WordPress-site bouwde ik in 2010, vanaf het voorjaar van 2011 leverde ik ze ook aan klanten. Ergens tussen toen en nu was er een periode van een paar jaar dat ik mijn geld voornamelijk verdiende met het bouwen en volschrijven van WordPress-sites voor kleine ondernemers. En gisteren nog werd ik door zo’n ondernemer gebeld omdat hij eventjes gebruik wilde maken van mijn expertise.
Toen ik tussen neus en lippen door meldde dat ik helemaal klaar was met WordPress, reageerde hij geschokt. ‘Maar jij was toch een echte WordPress-man?’
Ja, dat was ik. Maar WordPress is geboren in 2004 (versie 1.0). En sindsdien is er nogal wat veranderd in hoe we denken over online content en webtechnologie. Ik geef je 5 redenen waarom het tijd iets voor iets anders.
1. Omnichannel stelt andere eisen aan content
Ik begin met de belangrijkste reden. Toen we met zijn allen begonnen met bedrijfssites maken en bloggen, wilden we maar één ding: die pagina in de lucht hebben. Liefst zonder iedere keer code te schrijven. Ik had mijn eerste eigen blog in 2005 en ik herinner me vooral dat ik heel veel tijd kwijt was met het aanpassen van de overzichtspagina’s en de ‘vorige’ en ‘volgende’-links. WordPress was een geschenk uit de hemel, want het deed dat allemaal voor je. Voor bedrijfssites gold nu dat je tekstschrijvers en klanten zelf teksten kon laten aanpassen. Ook dat scheelde enorm veel gedoe.
Maar, even terug naar 2020. Wat we nu hebben is een wereld waarin we met klanten/gebruikers communiceren via tientallen kanalen, op allerlei verschillende devices. De tijd van website-, social media- en e-mail-teams is echt voorbij. We hebben content nodig die bruikbaar is in chat, aan de telefoon, in apps, in voice-toepassingen, in API-koppelingen… Als je je content maakt in de vorm van webpagina’s, dan sluit je hem op in je website en dwing je jezelf om hem voor ieder nieuw kanaal dat je toevoegt opnieuw te maken. Met het risico (of eigenlijk: de garantie) dat je inconsequenties en fouten toevoegt.
En zelfs webpagina’s zijn niet meer alleen webpagina’s. Google laat op mobiel niet je pagina zien, maar de AMP-variant. Facebook doet hetzelfde, maar dan met Instant Articles. In social media timelines en in zoekresultaten worden alleen titels, featured images, subkopjes en metadescriptions getoond. De hoeveelheid metadata die je alleen al nodig hebt om een blog of webpagina te kunnen promoten is enorm toegenomen.
We hebben dus een systeem nodig dat veel meer doet dan alleen een pagina met content online zetten. We moeten sowieso stoppen met in pagina’s denken, en beginnen met denken in content.
Create Once, Publish Everywhere
Wat doet content? Content beantwoordt vragen van gebruikers. Waar doet die content dat? Daar, waar de gebruiker haar vraag stelt. Een omnichannel contentorganisatie maakt content dus zo, dat hij in alle kanalen bruikbaar is. COPE, heet dat: create once, publish everywhere.
WordPress is hier totaal niet op ingericht. Heb je een sterke maag, open dan eens (bijvoorbeeld met het open source-programma PHPMyAdmin, die de meeste webhosts gratis voor je installeren) de tabel ‘wp_posts’ van je WordPress-site en ontdek dat daar niet alleen je blogposts en je pagina’s staan, maar ook al je afbeeldingen, menu-items en alle andere post types, zoals webwinkelproducten. En allemaal vergezeld van al hun vorige versies sinds de lancering van je site. Aan deze tabel hangt een nog warriger tabel, wp_postmeta, met alles wat niet meer in de hoofdtabel paste. Er zijn zelfs analytics-plugins die hier hun bezoekcijfers bewaren… Hoe meer plugins je op je site gebruikt (of hebt gebruikt), hoe meer velden deze tabellen hebben.
Als al je content, gemengd met website-specifieke dingen als menustructuur en zelfs analytics, in zo’n blob is opgeslagen, hoe ga je die dan ooit hergebruiken voor andere kanalen? Pogingen om dit op te lossen leiden vaak tot een hele zwik custom post types en het veelvuldig gebruik van custom fields. Dingen die in mijn ervaring uiteindelijk alleen maar chaos toevoegen.
En dan heb ik het nog niet over de vermenging van vormgeving en content in de content zelf. Door de toepassing van shortcodes en plugins wemelt de tekst van de platform- en zelfs theme-afhankelijke informatie. Ga je over op het gebruik van een sitebuilder die werkt met ‘blokken’ (en dat doet WordPress sinds versie 5 standaard, met de Gutenberg-editor), dan ben je helemaal verloren. Iedere scheiding tussen kanaal en content is dan verdwenen.
2. Snelheid (of het gebrek daaraan)
Als tweede moeten we het over snelheid hebben. Sitesnelheid is een belangrijke factor in SEO en gebruikersvriendelijkheid. Een langzame site jaagt bezoekers weg, dus heeft Google er ook een hekel aan. Ook de effectiviteit van je social media- en advertentiecampagnes lijdt enorm onder langzaam ladende landingspagina’s (wauw, zeg dat eens tien keer snel achter elkaar). Er kan een hoop gebeuren in 4 seconden. Wil je weten waarom je Google voor 100 kliks hebt betaald en er maar 74 zijn aangekomen op je site? Het zou zomaar kunnen dat mensen wegklikken voordat je WordPress-pagina geladen is.
En dan heb ik het nog niet over het werken aan een site. Steeds vaker voel ik een fysieke weerzin tegen het inloggen in en werken aan een WordPress-site… Het wachten op de refresh van de admin-omgeving, iedere keer als je een aanpassing doet, gevolgd door het refreshen van de preview-pagina, dat ook weer een paar seconden in beslag neemt haalt het ritme uit je werkproces en zuigt energie als je het hele dagen moet doen.
Het probleem is niet onoplosbaar. Hoewel je in een standaard WordPress-installatie (te) weinig invloed hebt op wanneer en hoe scripts en media geladen worden, kan een goede PHP-ontwikkelaar daar grote stappen in maken. Dat betekent dan wel dat je iemand nodig hebt die een theme op maat voor je maakt, en dat je vervolgens niet zomaar allerlei plugins mag installeren. Het toevoegen en aanpassen van functionaliteit is dan dus een taak geworden voor een techneut. Ook goede hosting helpt enorm.
Omdat lang niet iedereen een getalenteerde PHP’er op afroep beschikbaar heeft en/of wil betalen voor optimale hosting, is de meest gebruikte oplossing de inzet van optimalisatieplugins. Daar zijn goede bij, die je, met zo 20 punten PageSpeed opleveren. Maar wat heb je eraan om van PageSpeed 42 naar 62 te gaan als er andere technologieën zijn die zonder extra inspanning boven de 90 landen?
3. (On)begrensde mogelijkheden
Het woord is gevallen: plugins. En dat is meteen mijn derde frustratie. Laten we eerlijk zijn: WordPress is een blogplatform, gemaakt door hele knappe programmeurs. Open source, met een enorm ecosysteem van developers en software eromheen. Ik kan daar alleen maar diep respect voor hebben. Maar, zoals met zoveel dingen die goed beginnen, is WordPress een monster geworden. Het maakt binnen heel veel bedrijven nauwelijks meer uit wat de vraag is, het antwoord lijkt wel altijd WordPress te zijn.
De ongekende populariteit van WordPress maakt dat er ook heel veel mensen zijn die werken aan plugins. Je kunt in WordPress vrijwel ieder probleem fixen met een plugin. En dat werkt heel goed als je functionaliteit wilt toevoegen. De makkelijkste manier om een webwinkel te maken? Een WordPress-site met de WooCommerce-plugin. De makkelijkste manier om je teksten te optimaliseren voor SEO? De Yoast SEO-plugin. Voor heel veel toepassingen werkt dit perfect.
Het gedonder begint meestal als je meerdere dingen tegelijk wilt, die elkaar raken.
Iedereen die wel eens in de clinch heeft gelegen met WPML (WordPress Multi-Language) bij het maken van een meertalige site weet waar ik het over heb. Menu’s die verdwijnen of in de verkeerde taal verschijnen, vertalingen die onvindbaar zijn, sites die crashen bij het installeren of updaten van een plugin… WordPress is a priori niet gemaakt om meertalig te zijn. Het toevoegen van die functionaliteit ‘bovenop’ de WordPress core, zal altijd problemen geven.
Informatiearchitectuur
Een vergelijkbaar probleem is het werken met informatiearchitectuur. Er zijn dappere pogingen gedaan om WordPress zover te krijgen dat het werkt met een goed gestructureerd contentmodel. Daar zijn, je raadt het al, plugins voor. Stephany Leary is daar heel ver mee gekomen. Lees daarover haar boek Content Strategy for WordPress. De OmnichannelX-website is op deze manier opgebouwd, dus het kán. Voor mijn nieuwe site heb ik deze aanpak serieus overwogen, maar uiteindelijk niet gekozen omdat het performanceprobleem van WordPress ermee niet opgelost wordt. Het verandert ook de database-structuur van je site niet (alles blijft opgeslagen in een ‘blob’). Sterker nog, de blob wordt alleen maar groter omdat je al je data in stukjes opslaat. Het werken met plugins verzandt zo in ‘throwing more at the problem’: de neiging om problemen op te lossen met het toevoegen van dingen. Dat werkt soms, maar soms ook niet. De fundamentele begrenzingen van WordPress, waaronder het werken met informatiearchitectuur en het bouwen van meertalige sites, zijn alleen op te lossen door van de grond af opnieuw te beginnen.
4. Usability
Al die uitbreidingen en toevoegingen hebben een naar bij-effect. Het beheer van een WordPress-site is er namelijk niet overzichtelijker van geworden. De standaardprocedure voor het oplossen van technische fouten, het uitschakelen en daarna één voor één weer inschakelen van alle plugins, is een hele klus op een site met 30 plugins. Iedere pluginbouwer heeft ook zo zijn eigen ideeën over hoe configuratieschermen eruit moeten zien en waar ze thuishoren in het menu. Maar nog niemand heeft de moeite genomen om na te denken over sneltoetsen voor power users. Een dagje werken aan een WordPress-site is een dagje klikken. Veel klikken. Om te beginnen met het wegklikken van de, al dan niet commerciële, boodschappen die al die plugins boven in je scherm zetten als je inlogt.
Ik zal hier geen lijst maken van mijn frustraties in de WordPress-backend, maar na wéér het verkeerde menu te hebben aangepast omdat ik niet eerst op ‘select’ heb gedrukt en weer een half uur te hebben verspild omdat de pagina ‘About’ niet wordt gevonden als je ‘about’ invoert in het zoekvak was ik er op een gegeven moment wel echt klaar mee. Zeker omdat ik inmiddels weet dat het maken van een menustructuur in JSON-code 10x zo snel is en het beheren van je content als bestanden op je harde schijf (voorzien van versiebeheer) je ongelooflijk veel zoektijd scheelt.
5. Verouderde technologie
WordPress draait op technologie die we de ‘LAMP stack’ noemen. Stack (letterlijk vertaald: stapel) is de term die techneuten gebruiken voor een uit lagen opgebouwde IT-architectuur. De onderste laag van de LAMP-stack (de L) is Linux, het besturingssysteem waar vrijwel alle webservers op draaien. De webserver-software heet Apache (de A dus) en wordt vergezeld door een MySQL (spreek uit: ‘my sequel’)-database. De P is de PHP-code waar WordPress in gebouwd is. Al deze componenten zijn gratis en open source. Dit is een deel van de reden dat deze stack zo populair is.
Het belangrijkste nadeel is de verwevenheid van data (content) en de presentatie ervan. Systemen als WordPress, Drupal en Joomla (de bekendste van de LAMP-stack CMS’en) serveren webpagina’s vanuit een grote, ondoorzichtige klomp PHP-code die nauwelijks scheiding kent tussen de datalaag en de presentatielaag. Nu het web steeds meer wegbeweegt van dit soort ‘monolieten’ en een semantisch web begint te vormen waarin kleine klompjes informatie in steeds andere combinaties, in steeds andere vormen en via steeds andere kanalen de vragen van gebruikers beantwoorden is het moeilijk om in LAMP de dingen te bouwen die je als online business nodig hebt.
Het principe van LAMP is ook dat pagina’s dynamisch gegenereerd worden. Dat wil zeggen dat een webpagina pas samengesteld wordt op het moment dat een gebruiker hem aanvraagt. Dat is ongelooflijk traag. Daarom gebruiken vrijwel alle WordPress-sites een of andere vorm van ‘caching’: het opslaan en hergebruiken van eerder gegenereerde pagina’s. Maar ook dit geeft weer extra complexiteit en dus kans op fouten en inconsistenties.
Er zijn ook fundamentele security-issues met de LAMP-stack. Omdat de volledige database én de volledige php-code online toegankelijk moeten zijn, zijn die dus ook benaderbaar voor mensen met kwade bedoelingen. Kijk eens in het logbestand van je beveiligingsplugin (je hebt toch wel een goede beveiligingsplugin hopelijk?). Gegarandeerd dat je alleen al van afgelopen week een hele lijst malafide inlogpogingen hebt. Er is maar één beveiligingslek nodig in een oude versie van een plugin, één zwak gebruikerswachtwoord en hackers kunnen de enorme rekenkracht van jouw PHP-installatie en webserver inzetten voor hele andere doeleinden. Het idee dat er bij tientallen van mijn voormalige klanten nog sites draaien waarvan ik geen idee heb of iemand ze, na mijn vertrek, nog af en toe van updates en backups voorzien, daar kan ik behoorlijk wakker van liggen.
Op zoek naar een alternatief
WordPress heeft wereldwijd als CMS nog lang niet afgedaan en er zijn nog steeds goede redenen om ervoor te kiezen. Maar dit zijn de redenen dat ik op zoek ben gegaan naar een alternatief. Inmiddels heb ik ook al een andere oplossing gekozen. In een volgend blog vertel ik je daar alles over.
