WebApps voor WordPress kunnen jouw Website het leven lichter maken

WordPress is eigenlijk een geweldig platform voor ondernemers. Laten we hier eerlijk over zijn. Ik ken geen enkel platform waarin zoveel verschillende functionaliteiten met elkaar verenigd kunnen worden. Ben je op zoek naar een online leeromgeving, geïntegreerd met een webshop en een forum? Met de juiste plugins draait WordPress daar de hand niet voor om. Ik durf zonder enige twijfel te zeggen, dat veel mensen die nu online hun brood verdienen, dit niet gekund hadden zonder WordPress als platform voor de realisatie van hun ideeën.
Het nadeel van deze ‘opeenstapeling’ van plugins is echter dat naarmate het aantal plugins groeit, er steeds meer dingen fout lijken te gaan. Wat dat betreft, zijn plugins net mensen. Zet een groot aantal mensen die elkaar niet goed kennen in een kleine ruimte en binnen de kortste tijd heb je conflicten.
In deze blogpost wil ik je eens een andere manier van denken voorhouden. Een manier waarbij je de functionaliteiten binnen WordPress de ruimte geeft die ze verdienen. En, zoals het ook meestal in het zakelijk leven gebeurt, een aantal functionaliteiten niet meer per-sé binnen WordPress wilt blijven houden, maar uitbesteed aan een dienst die hier beter voor uitgerust is. Uitbesteden aan WebApps voor WordPress.
De beperkingen van WordPress plugins
Zoals ik al in mijn artikel over ‘De Toekomst van WordPress‘ heb aangegeven, kleeft er een aantal grote bezwaren aan de manier waarop WordPress plugins zijn geïmplementeerd. Op zich is daar niets fout mee! Toen in 2003 WordPress het daglicht zag, was het ‘plugin systeem’ van WordPress het best haalbare in die tijd.
Wat echter niet was voorzien, was het feit, dat deze ‘plugin cultuur’ niet beperkt zou blijven tot kleine functionaliteiten, die het makkelijker moesten maken bepaalde content te kunnen tonen, maar dat er complete systemen in WordPress gebouwd zouden worden. En hoewel de hele ‘plugin architectuur’ van WordPress bij heeft gedragen aan de democratisering van het online ondernemen, kleeft er ook een aantal bezwaren aan. En daar wil ik graag samen met jou nader bij stilstaan.
1. Complexiteit
WordPress lijkt allemaal zo makkelijk. En van de gebruikerskant (waarbij ik de site eigenaar als de gebruiker zie) is dat in hoge mate ook zo. Het installeren, configureren en updaten van plugins gaat heel eenvoudig. Een kind kan de was doen. Sterker nog, het updaten van plugins kan helemaal automatisch gebeuren.
Verschillende PHP versies
Maar wanneer je onder de motorkap kijkt dan zie je eigenlijk een heel merkwaardig samenraapsel van PHP code voor PHP5, PHP7, PHP8. En ja, het klopt dat PHP6 hier in het rijtje mist. Dit was een versie die een lange beta geschiedenis heeft gehad, en tenslotte toch maar helemaal werd overgeslagen. Na PHP5 kwam PHP7.
En bij die verschillende versies van PHP hoorden ook verschillende coding standards. Veel van de mooie dingen die nu bijvoorbeeld in PHP8 geboden worden, waren toen nog niet mogelijk.
En omdat plugins in 2005, 2010 of 2015 nooit geschreven zouden kunnen worden met de code standaards van vandaag, volgen deze oude plugins vanzelfsprekend de code standaarden van vandaag niet. Maar omdat PHP zelf regelmatig functies aanmerkt als ‘deprecated’ (het doet het nog wel, maar mag je eigenlijk niet meer gebruiken, omdat het in de toekomst verwijderd kan worden), kun je je voorstellen, dat oude plugins, die destijds prima aan de regels voldeden, het ineens ‘niet meer doen’, omdat functionaliteiten uit PHP zijn verdwenen.
WordPress moet dan ook in een voortdurende spagaat staan, om de ondersteunde versies van PHP te kunnen overbruggen. Hoewel PHP7 officieel niet meer onderhouden wordt, moet WordPress eigenlijk een compromis weten te vinden tussen alles wat ‘wat eigenlijk verouderd is’, en alles wat ’te nieuw is om je vingers aan te branden’.
Geen gedeelde externe libraries / package manager
Wanneer we het over computers en programmeren hebben, dan is een library niet je verzameling e-boeken, maar een ‘programmabibliotheek’ een serie functies -vaak gedeeld over vele applicaties- die je helpen bij een bepaalde taak te verrichten.
Een aantal van dit soort mogelijke libraries zijn
- Een library om contact te leggen met MailChimp
- Een library om te betalen via PayPal
- Een library om informatie uit Google Analytics op te halen
kortom, allerlei verschillende libraries die door verschillende plugins gebruikt kunnen worden. Wanneer je vier of vijf plugins met een ‘mailchimp integratie’ installeert dan maak je een redelijk grote kans, dat je ook vier of vijf keer dezelfde library installeert.
En dat kan goed fout gaan! Want wanneer je functies of classes laadt (wat dat precies is, is niet belangrijk, maar het zijn onderdelen van de PHP taal, die ervoor zorgen, dat taken uitgevoerd kunnen worden), dan zijn er heel wat fouten die gemaakt kunnen worden.
PHP heeft een ingebouwde beveiliging, waarmee je kan voorkomen, dat bestanden tweemaal geladen worden. Dit is vooral belangrijk voor bestanden waarin je PHP functies en PHP classes definieert, want twee functies mogen niet dezelfde naam hebben.
Stel je voor, ik bied een interface aan met ‘mijngeweldigsysteem’ en die functies staan in het bestand mijngeweldigsysteem.php
Om te voorkomen, dat dit tweemaal geladen wordt, zal de maker van ‘mijngeweldigeplugin’ bij het laden van die interface ongeveer het volgende in de code zetten:
if (!function_exists('init_mijngeweldigsysteem')) {
require_once( plugin_basename(__FILE__) . '/includes/mijngeweldigsysteem.php');
}
Klinkt allemaal heel ingewikkeld, maar wat hij eigenlijk zegt is ‘laad het bestand vanuit de folder ‘wp-content/mijngeweldigeplugin/includes’
Je hebt ook een plugin geïnstalleerd van een andere ontwikkelaar ‘mijnbestwelslechteplugin’. En hij heeft ook een regel in zijn code met ongeveer dezelfde tekst:
require_once( plugin_basename(__FILE__) . '/includes/mijngeweldigsysteem.php');
Maar omdat ‘mijnbestwelslechteplugin’ in een andere folder staat -het is immers een andere plugin- laadt hij een andere versie van de interface met mijngeweldigsysteem.
En daardoor kan er wat mis gaan. Of er wat mis gaat en wat er mis zal gaan ligt aan de volgorde waarin ze geladen worden.
Als de eerste code als laatste wordt geladen, gaat er niets fout. Developer 2 laadt zijn bestand, zorgt daarmee dat de functie ‘init_mijngeweldigsysteem’ gedefinieerd wordt, en Developer 1 test netjes en laadt de code niet.
En je begrijpt het al, gebeurt het omgekeerd, dan knalt de applicatie.
Dit is slechts één van de vele voorbeelden hoe het kan komen dat plugin A en plugin B niet goed samen willen spelen.
Omdat dit soort problemen zich niet alleen voordoet bij WordPress, en niet alleen in PHP, maar in vrijwel iedere taal, wordt er tegenwoordig bij toepassingen als WordPress, of frameworks als Laravel, NodeJS of Flutter gebruik gemaakt van een package manager.
Voor PHP heet die package manager bijvoorbeeld ‘composer’. Wanneer je zo’n gedeelde functionaliteit als communicatie met MailChimp wilt installeren, dan is het de afspraak met dit soort ‘packages’, dat deze in een speciale folder -vendors- geïnstalleerd worden. Zou het WordPress plugin systeem ongeveer net zo werken zou Developer A zeggen ‘Ik heb hier ook nog de interface met MailChimp’ en de package manager zou zeggen, ‘ok, die slaan we op in de folder ‘vendors’.
Komt Developer B en zegt hij hetzelfde, dan zegt de package manager ‘dank je wel, maar die hebben we al op de plank liggen.’
En hiermee wordt dit soort conflicten als boven beschreven voorkomen. Maar helaas, WordPress kent geen ‘package manager’ achtig update systeem.
2. Performance
Ik heb de laatste jaren, wanneer ik het over WordPress heb, meer dan eens de term ‘monolithische applicatie’ laten vallen. Deels doe ik dit, omdat ik van dure woorden houd, deels omdat ik sinds Asterix en Obelix toch iets met menhirs heb. Een monolith is -net zoals een menhir en de oorspronkelijke obelisken- een indrukwekkend stuk steen, uit één stuk gehouwen.
Wanneer je een pagina van een WordPress site laadt, dan is dat ook indrukwekkend: bij iedere pagina die je laadt, laad je in ieder geval een stukje van een plugin mee. Iedere plugin wordt meegeladen bij iedere pagina, al was het alleen maar vanwege het stukje code wat moet vertellen ‘mij heb je voor deze pagina niet nodig’.
En veel plugins vergeten dat gewoon te vertellen, waardoor ze toch iedere keer voor alles worden meegeladen.
Met andere woorden, wanneer je simpel een blogpost wilt lezen, dan laad je ook de plugins voor WooCommerce, koppelingen met MailChimp en nog heel veel dingen die jou niet interesseren mee. Maar omdat jij niet de enige bent die dat doet, heeft jouw server constant meer werk te verrichten, dan eigenlijk zou hoeven.
Hoe je die performance kan verbeteren heb ik in tientallen blogposts al beschreven, dus daar ga ik niet verder op in, maar het is een serieus probleem.
3. Veiligheid
Een keten is net zo sterk als de zwakste schakel. Het gebeurt regelmatig dat in de blogs en mailings van Search Engine Journal of Sucuri WordPress genoemd wordt in verband met de zoveelste ‘vulnerability’ in een plugin. Het probleem met WordPress, en sowieso de meeste Open Source CMS-en uit die tijd, is dat iedere uitbreiding een potentieel risico is, omdat in principe iedere plugin de toegang heeft tot het complete systeem. Eén van de redenen, dat ‘code snippet’ plugins, ‘file manager plugins’ en ‘database management’ plugins eigenlijk uit den boze zijn om te installeren op je website.
En wanneer we het over de plugins hebben die de Search Engine Journal of Securi blog, dan hebben we het over plugins van bedrijven met een groot aantal medewerkers die beslist niet van plan zijn een systeem te hacken. Maar hoe zit dat met plugins die je ‘genulled’ download?
4. Toenemende onderhoudskosten
Naar mate jouw systeem complexer wordt, zal het onderhoud ook steeds meer gaan kosten. Je moet naar duurdere servers, je moet vaker hulp van externen inroepen voor technische problemen en het door die technische problemen zal het steeds vaker gebeuren, dat je website even niet beschikbaar is.
Het ontwikkelen van ’technical debt’
Technische debt, of technical debt, is een term uit de softwareontwikkeling die verwijst naar de kosten die ontstaan door snelle, maar niet duurzame keuzes in softwareontwikkeling. Bij WordPress gebeurt dit vaak wanneer je steeds meer plugins toevoegt om functionaliteit te bieden. Hoewel dit op korte termijn handig lijkt, creëert het op de lange termijn problemen.
WordPress is slechts beperkt schaalbaar. In een artikel in het verleden over WooCommerce versnellen in de cloud, heb ik geprobeerd het één en ander uit te leggen over de horizontale en verticale schaalbaarheid van WooCommerce, en ieder woord wat ik daar heb geschreven is in principe ook van toepassing op WordPress, omdat WooCommerce natuurlijk binnen WordPress draait.
Het ontkoppelen van je business en je presentatie
Tot voor kort was ik mij er van bewust wat de beperkingen van WordPress zijn (daar schrijf ik al meer dan vier jaar over, terwijl ik best enthousiast over WordPress ben), maar zag ik het nooit als een mogelijk risico in mijn of jouw bedrijfsvoering. Want WordPress gaat nog zeker een tien jaar langer mee, toch?
Het recente conflict tussen Matt Mullenweg en WP Engine maakte mij echter duidelijke, dat er nog een tweede gevaar is. Omdat de toekomst van WordPress toch sterk afhankelijk is -ondanks het feit dat WordPress Open Source is- van één enkele persoon (Matt), kunnen de persoonlijke luimen van één persoon het voortbestaan van WordPress ernstig bedreigen.
We leven in een ‘multi channel’ tijd. Informatie vanuit één bron kan op verschillende soorten displays gepresenteerd worden. Een mobiele app voor WooCommerce of een mobiele app voor je LMS is al lang geen ‘onhaalbare zaak’ meer voor de gemiddelde ondernemer. En wanneer je een ‘Brick and Mortar’ shop hebt, hoef je tegenwoordig geen kapitalen meer te investeren, om jouw klanten de gelegenheid te geven de producten die je niet op voorraad hebt direct bij jou in de winkel te bestellen.
Wat vooral belangrijk is, is je back-office. En in een ideale situatie zou je een back office hebben, met verschillende ‘presentaties’ van je aanbod aangepast aan de devices die je hebt.
En vandaag is misschien een goed moment om eens te beginnen met na te denken, hoe je jouw online business los zou kunnen koppelen van de presentatie van jouw online business.
Dat is iets wat mij de laatste vier jaar sterk bezig heeft gehouden, en ik wil je graag mijn oplossing laten zien. En in die oplossing staat WordPress nog steeds centraal, maar het is geen ‘brekende factor’ meer.
WebApps voor WordPress: Ondersteuning vanuit andere bronnen
Het grote probleem van WordPress natuurlijk is dat in één massieve (ja hoor, ik gebruik het woord weer) monolithische toepassing alle functionaliteit wordt ondergebracht. Maar wanneer hier iets valt, valt alles.
Tien jaar geleden was maatwerk software nog vrijwel onbetaalbaar voor de gemiddelde zelfstandige, of ondernemer in het midden- en kleinbedrijf. Maar daar is heel wat verandering in gekomen.
Een aardig voorbeeld is Laravel, een project wat in 2011 begonnen is, maar rond 2016 pas echt grote aandacht kreeg. Laravel is een framework in PHP, wat er helemaal op gericht is het ontwikkelen van webtoepassingen eenvoudiger en efficiënter te maken.
Laravel werkt helemaal volgens het idee van de ‘package managers’, wat ik eerder in dit artikel heb besproken. En ik wil niet al te diep ingaan op Laravel zelf, voor meer informatie is dit artikel misschien interessant, maar zelf gebruik ik Laravel graag in combinatie met Filament.
Filament heeft slechts één doel: Het makkelijk bouwen van beheerschermen voor Laravel apps.
De kracht van Laravel
Je zal je waarschijnlijk afvragen, waarom Laravel goed geschikt zou kunnen zijn voor jouw WordPress sites. Vooral wanneer ik zojuist heb gezegd, dat het geen deel van jouw site uit zou maken.
Maar één van de sterke punten van Laravel, is dat met Laravel het relatief makkelijk is een REST interface te ontwikkelen. Want was is een webapp nu eigenlijk?
Het is een programma waarmee informatie opgeslagen, beheerd en ontsloten kan worden. En dat is precies waar Laravel heel sterk in is.
1. Informatie opslaan
Informatiebeheer is niet de sterkste kant van WordPress. Wanneer een programmeur zich niet aan de regeltjes houdt, kan hij doen met de informatie wat hij wil, er zit geen enkele bescherming op de integriteit van de data. De enige regels die worden ‘afgedwongen’ zijn de regels van de database zelf.
Bij Laravel loopt het beheer van de informatie via een ORM, Object Relational Mapping. Zonder hier al te diep op in te willen gaan, een ORM is een ‘logische laag’ tussen je applicatie en de database. Dit is een extra beschermingslaag, dat iemand alleen die informatie aan kan passen, die ook aangepast mag worden (door die persoon).
2. Informatie beheren
Natuurlijk moeten gegevens ingevoerd kunnen worden. Wanneer ik dat in WordPress wil heb ik als ontwikkelaar twee mogelijkheden: Ik gebruik de standaard schermen van WordPress voor het onderhouden van posts en ‘vertaal’ ieder informatieobject naar een Custom Post Type, en dan heb ik vrijwel automatisch een beheerinterface. Maar niet alle informatie laat zich opslaan in Custom Post Types, en dan moet ik code gaan kloppen. En dat is dan gelijk ook veel code.
Wanneer ik Laravel met Filament gebruik, dan is het enige wat ik hoef te doen mijn datamodel goed te definiëren. Heb ik de relaties tussen alle gegevenstypen goed duidelijk gemaakt, dan kan ik vrijwel automatisch de beheerschermen voor Filament genereren.
Ok, om het allemaal wat gebruikersvriendelijker te maken, zal ik de code een klein beetje moeten tweaken, maar beheerschermen voor Laravel zijn met Filament zo gemaakt. Tijdens een cursus -die ik volgde, niet die ik gaf- heb ik in vier uur tijd de complete beheerschermen voor een blog-toepassing met posts, tags, categorieën, gebruikers, rollen en afbeeldingen gemaakt. Alleen het beheergedeelte, geen presentatie op een website.
Wanneer ik 20 jaar geleden iets vergelijkbaars zou hebben willen maken zou ik hier maanden mee bezig geweest zijn.
Of om het in het kort te zeggen, een webapp voor het beheren van informatie kan een stuk minder kosten, dan je nu misschien zou denken!
3. Ontsluiten van informatie
En het derde sterke punt van Laravel is, dat Laravel is ontwikkeld om informatie gemakkelijk beschikbaar te maken. In letterlijk 5 minuten per ‘informatie object’ is het mogelijk -na het definiëren van het datamodel- om voor dat specifieke model een REST interface te implementeren.
Dat wil zeggen, dat de informatie in een paar muiskliks en toetsaanslagen beschikbaar komt voor andere apps. En het maakt hierbij niet uit of dit webapps, mobiele apps of desktop apps zijn.
En jouw ‘WebApp’ kan heel goed in jouw WordPress website worden opgenomen.
SPA of Webpage?
Wanneer je informatie uit een externe bron, en in ons voorbeeld is de Laravel app een externe bron, op moet halen, heb je eigenlijk twee keuzes? Wil je dit als een traditionele webpagina ophalen, of als een ‘Single Page Application’ (SPA).
Eigenlijk is het antwoord op deze vraag vrij eenvoudig.
Sommige gegevens wil je vindbaar hebben via Google. Andere gegevens niet.
Wanneer je de gegevens vindbaar wilt hebben via Google, is het een goed idee om te kiezen voor individuele pagina’s die gevoed worden door jouw gegevensbron. Eigenlijk verschilt het niet zoveel van wat WordPress al doet! Alleen de gegevensbron is veranderd. In plaats van een database is het een bron van informatie via het REST protocol geworden.
Wanneer het gegevens zijn, die je liever niet publiek wilt tonen, dan is een ‘Single Page Application’ een betere oplossing. Want in dat geval zijn de gegevens niet ‘vindbaar’ op het internet. Maar ze zijn wel extreem snel toegankelijk.
In onderstaande tabel vind je een aantal voorbeelden van informatie die beter via een ‘Webpage’ of via een ‘SPA’ beschikbaar zouden kunnen worden gesteld.
Webpage | SPA |
---|---|
Beschikbare cursussen | De cursus zelf |
Formulier voor een Service Desk applicatie | Ingeschoten tickets |
Boekbare objecten (hotelkamer, BnB locatie, auto, gereedschap of service afspraak) | Een pagina met ‘mijn boekingen’ |
Cursussen en trainingen | Geboekte cursussen en trainingen en extra online informatie |
Inschrijfformulier sportschool | Persoonlijk trainingsplan en voltooide oefeningen |
En nu het vervolg
In deze blogpost hebben we vooral gekeken naar de mogelijkheden om WordPress te ontlasten van een aantal taken. Deze blogpost is nauw gerelateerd met een andere blogpost die je over een week mag verwachten, waar we verder ingaan op de verschillende manieren om informatie aan onze doelgroep te presenteren.
Deze blogpost beantwoord onderstaande vragen:
- Wat zijn de beperkingen van het gebruik van meerdere plugins binnen WordPress?
- Hoe kunnen WebApps dienen als alternatief voor traditionele WordPress-plugins?
- Wat zijn de voordelen van het gebruik van WebApps ten opzichte van plugins in WordPress?
- Hoe kunnen WebApps de prestaties en veiligheid van een WordPress-website verbeteren?
- Welke stappen zijn nodig om WebApps te integreren met een bestaande WordPress-website?