Waarom een Service Desk app niet (alleen) in WordPress hoort

Voor een goede helpdesk hoeft je je WordPress site niet te belasten

Een goede service desk app is complex. Je hebt potentieel met complexe processen te maken. Wanneer je een WordPress site hebt, en je op zoek bent naar een helpdesk of service desk toepassing, dan is misschien je eerste zoekopdracht te zoeken naar ‘helpdesk in wordpress’ of ‘helpdesk in woocommerce’. En wat je dan natuurlijk zal vinden is een lange lijst van plugins voor helpdesk applicaties binnen WordPress. Ik heb in het verleden een aantal malen over dit onderwerp geschreven. Maar met de huidige stand van de techniek en mijn ervaring met de implementatie van helpdesk systemen (ik heb gedurende de laatste drie decennia geholpen er talloze te implementeren op diverse platforms), zoek ik zelf liever mijn ‘heil’ in het ‘offloaden’ van het verkeer naar een aparte helpdesk app.

In dit artikel concentreer ik mij op Laravel als ontwikkelomgeving voor die ‘aparte helpdesk app’. Dat is in de eerste plaats omdat dit de omgeving is, die ik het best ken. En ten tweede, omdat Laravel een inmiddels zeer compleet ecosysteem is geworden. Wat WordPress is voor CMS systemen, is Laravel voor (Open Source) ontwikkel frameworks.

Waarom een helpdesk app niet op een WordPress site hoort!

Het maakt nu even niet uit, of je een ‘gewone’ WordPress website hebt, een WooCommerce website, of een online leeromgeving. Wanneer je je werk goed doet, zal slechts een klein aantal van je bezoekers gebruik maken van je helpdesk.

Om even uit te gaan van algemene statistieken: De conversie van een gemiddelde WooCommerce website is rond de 3%. Dat wil zeggen, dat -als je het goed doet- 3% van alle bezoekers aan je site, iets zal kopen.

Bij een duidelijke website, met goede FAQ’s en een goed bestelproces, mag je verwachten, dat ongeveer 2% van je klanten vragen zal stellen. In eerste instantie kan dit percentage hoger zijn, maar wanneer je een goede FAQ voor je klanten hebt op de website, zal het aantal vragen snel afnemen.

Hangen we nummertjes aan de percentages, wil dat zeggen, dat voor iedere 10.000 bezoekers, 300 bezoekers iets van je zullen kopen. En van iedere 300 klanten zullen uiteindelijk 6 mensen gebruik maken van je helpdesk.

Even voor de duidelijkheid, dit geldt voor webwinkels, andere typen websites zullen andere percentages hebben.

Maar omdat WordPress iedere plugin moet bij iedere ‘pageload’ moet laden, zal een helpdesk plugin 9.994 keer ‘voor niets’ geladen moeten worden. En dat, terwijl een goede service desk plugin toch best een ‘zware load’ op je systeem is.

Waarom is een WordPress helpdesk plugin zo zwaar?

WordPress is oorspronkelijk gebouwd als een CMS, een ‘Content Management System’, een systeem om content (tekst, video, afbeeldingen, PDF’s en welke andere ‘inhoud dan ook) op een gebruiker vriendelijke manier aan de wereld ter beschikking te stellen. De kracht van WordPress is het aanbieden van content.

Een helpdesk app is een compleet andere toepassing. Allereerst is het doel niet om de informatie aan de wereld ter beschikking te stellen. Wanneer je een vraag hebt over een product of proces, dan verwacht je een zeker niveau van privacy. De vraag is een persoonlijk contact tussen jou als consument, en de eigenaar van het product of de dienst.

Een helpdesk app heeft dus ook een compleet andere behoefte. Het gaat hier om gestructureerde informatie, processen en autorisaties (niet iedereen mag alles zien). Laten we stap voor stap eens bekijken, waarom WordPress hier tekort kan schieten.

Gestructureerde informatie

Laten we duidelijk zijn. Ik wil niet zeggen, dat de informatie binnen WordPress niet gestructureerd is. Dat is het wel. Maar een structuur dient altijd een specifiek doel, en het specifieke doel van WordPress is op een eenvoudige manier gevariëerde content aan kunnen bieden. En dat doet WordPress perfect.

Door alle ‘posts’, ongeacht het type post (blogpost, pagina, product, testimonial) in één tabel onder te brengen, kan je direct een zoekopdracht door al die typen informatie uitvoeren. Per slot van rekening het staat eigenlijk allemaal in één tabel.

Voor ‘makkelijk zoeken op tekst’ heeft WordPress een ideale structuur.

Maar binnen een helpdesk toepassing ben je minder geïnteresseerd in een globaal zoeken op tekst. Per slot van rekening wordt de toegang tot de specifieke tekst beperkt door de rol die je in de website hebt. Als ‘client’ van het systeem heb je bijvoorbeeld alleen toegang tot een ‘text search’ over de tickets die jij hebt ingediend. En om het nog eens een beetje lastiger te maken, op die tickets die jij hebt ingediend kunnen ‘interne commentaren’ zijn, die betrekking hebben tot de interne communicatie van de helpdesk aanbieder, waar je geen toegang toe zou mogen hebben.

Een zoekstructuur die rekening houdt met de ‘filters’ op de resultaten die aangeboden mogen worden is binnen WordPress lastig aan te leveren.

Aansluitend, omdat alle informatie uit in principe één basistabel gehaald moet worden (de wp_posts tabel), wordt het ophalen van informatie een tijdrovend karwei.

De Laravel oplossing – Het ORM

Eén van de meest krachtige onderdelen van Laravel in mijn idee is het ORM, de ‘Object Relational Mapping’ met de naam ‘Eloquent‘

Nu is Eloquent slechts één van de vele ORM’s en ik heb er geen zin in, noch de kennis voor, om ‘ORM’s’ met elkaar te vergelijken. Maar een ORM moet je zien als een concept om gegevens te benaderen, waarbij je geen kennis hoeft te hebben over de onderliggende datastructuur.

Een heleboel woorden, die je waarschijnlijk weinig zeggen. Dus laat mij het eens proberen met een eenvoudig voorbeeld.

Wanneer je WordPress gebruikt heb je geen andere keuze dan MySQL (of MariaDB, een database management system wat vrijwel 100% compatible is met MySQL. Je zal met betrekking tot WordPress niet tegen de verschillen tussen MySQL en MariaDB aanlopen).

Eloquent ORM ondersteunt meerdere databases: PostgresSQL, MySQL, MSSQL, MariaDB, MongoDB en SQLite direct ‘vanuit de doos’, extra ‘data-drivers’ zoals bijvoorbeeld CSV, Excell, XML en meer zijn als ‘packages’ (vergelijk dit als plugins bij WordPress) beschikbaar.

Een ORM is een abstractielaag op hoog niveau om te bepalen tot welke gegevens iemand toegang heeft.

Laten we eens met een eenvoudig voorbeeld beginnen.

Wanneer ik inlog in een servicedesk systeem, krijg ik -afhankelijk van mijn rol, andere tickets te zien.

• Wanneer ik een klant ben, zie ik de tickets die ik heb ingediend.
• Ben ik een medewerker van de service balie, zie ik de tickets die aan mij zijn toegewezen.
• Ben ik een teamleader van de service balie, zie ik alle tickets die aan mijn team zijn toegewezen
• Ben ik een medewerker van een beleidsafdeling, zie ik informatie over aantallen tickets, maar niet de inhoud van specifieke tickets.

Ik ben een behoorlijk ervaren WordPress developer. Maar wanneer ik dit soort informatie op dit soort toegangsniveau in een plugin zou moeten gieten, zou ik enkele maanden kwijt zijn.

De belangrijkste reden is, dat WordPress geen standaard functionaliteiten biedt voor dit soort fijnmazige detaillering. Een andere belangrijke reden is, dat ik toch minimaal een week of drie bezig zou zijn om aan de beheerskant een user interface te bouwen waarin per rol de juiste informatie, en de juiste vorm van beheer zou worden aangeboden.

WordPress is geen applicatie platform

Hey… ik moet toegeven, dat ik soms een beetje traag ben. Weet je wel, de hamer en de oplossing. Toen vrijwel niemand in 2010 geloofde dat WordPress een goed platform voor websites zou kunnen worden, begon ik met WordXPression, een bedrijf(je) dat WordPress websites bouwde als websites, en niet als ‘blog sites’. Dezelfde webdesigners die mij toen uitlachten, volgden een decennium later mijn Elementor cursussen.

Maar ik moet ook toegeven, dat ondanks mijn visionaire idee, dat WordPress een goed platform voor websites zou kunnen worden -wat het nu ook is-, heb ik ook een aantal dingen verkeerd ingezien. Je kan veel met WordPress. En ik heb de mogelijkheden met plugins sterk overschat. Zoals -wanneer ik een search doe op plugins voor WordPress- heel veel andere mensen.

Wanneer je WordPress als applicatie platform wilt gebruiken, beperk het dan tot het type van platforms, waarbij de primare focus de content is, en de opvolgende bedrijfslogica eenvoudig.

Zoals bijvoorbeeld een e-commerce toepassing als WooCommerce, of een LMS als MasterStudy.

Maar beide toepassingen zijn nog steeds ‘content-concentrated’. De content in het geval van WooCommerce is het product, de content in het geval van MasterStudy is een cursus.

In beide gevallen is de content een product, en de content is bedoeld als een manier om het product te presenteren. Maar wat, wanneer je geen ‘product’ aanbiedt, maar een dienst?

Processen

Wat wanneer je bijvoorbeeld een toepassing hebt, waar de nadruk niet op de content ligt, maar op werkprocessen. Een aardig voorbeeld is een helpdesk of servicedesk applicatie. Waar je hierbij bijvoorbeeld ook te maken krijgt, is dat er processen uitgevoerd moeten worden op de achtergrond. Bijvoorbeeld om herinneringsmails te versturen, wanneer bepaalde tickets nog niet beantwoord zijn binnen de overeengekomen tijd.

Hier loop je bij WordPress tegen een probleem aan. Of eigenlijk meerdere problemen. Standaard doet WordPress namelijk niets, activiteiten worden getriggerd door het laden van een pagina. Wordt er geen pagina geladen, dan wordt er ook niets gedaan. Dat is natuurlijk niet handig, wanneer er allerlei emails dienen te worden aangemaakt en verzonden. Ook bij WordPress moet een aantal processen op de achtergrond uit worden gevoerd. Om dat mogelijk te maken kent WordPress iets wat WP-Cron heet. In een ver verleden heb ik al eens uitgelegd, wat dit is.

Bij iedere keer dat er een pagina wordt geladen, wordt er een aantal van die uitgestelde opdrachten uitgevoerd. Maar dat heeft natuurlijk ook zijn invloed op de laadtijd van de pagina.

Bij Laravel hebben de makers er heel anders tegenaan gekeken. Laravel kent zogenaamde ‘Job queues’ en alles wat een beetje langer dan gemiddeld duurt, hoort in zo’n queue gezet te worden. Door zogenaamde ‘worker’ processen, die onafhankelijk van de webpaginas lopen, worden die jobs dan uitgevoerd. Dit levert merkbare snelheidswinst op.

Beveiliging

Standaard is de beveiliging van WordPress ‘role based’. Je krijgt als gebruiker een rol, en daar wordt door bepaald, wat je wel of niet mag doen. Aan zo’n rol zijn bepaalde ‘capabilities’ gekoppeld en met een plugin zoals bijvoorbeeld de ‘User Role Editor‘ kan je die bevoegdheden wat fijnmaziger instellen.

De beveiliging van Laravel is eigenlijk niet veel anders. Tenminste niet, wat de definitie van de bevoegdheden betreft. Waar Laravel echter compleet anders is, is de plaats waar er op die bevoegdheden gecontroleerd wordt.

In WordPress is het eigenlijk niet zo goed geregeld. De databaselaag WPDB geeft iedere functie binnen de WordPress core en in de plugins ongelimiteerde toegang tot het $wpdb object. Controleren of iemand iets mag doen, wordt op het niveau van de functies in de plugin gedaan. Dat maakt de beveiliging niet alleen meer tijdrovend om te implementeren, maar maakt het risico dat iemand iets vergeet ook groter.

Laravel pakt dat op een iets andere manier aan. De autorisaties zelf zijn gecentraliseerd. Het is goed om te controleren of ik de rechten heb om iets op te slaan op een ‘hoog’ niveau, zoals bijvoorbeeld om de knop ‘Opslaan’ te verbergen, wanneer ik toch geen rechten heb om iets op te slaan.

Maar die rechten worden ook afgedwongen in de ‘gates’, een onderdeel van de tussenlaag tussen de gebruikersinterface en de database. Op exact dezelfde plaats waar gekeken wordt of die ‘Opslaan’ knop wel getoond zal worden, wordt bij het opslaan zelf gecontroleerd of het wel mag. Dus wanneer ik in een scherm zou vergeten bij de zichtbaarheid van een knop te controleren of deze mag worden getoond, nog steeds geen mens overboord. De applicatie zal automatisch het opslaan weigeren, wanneer op de knop gedrukt wordt, indien de gebruiker geen toegang zou moeten hebben.

Load on Demand / Autoloading

Ik heb in meerdere blogartikelen verteld, hoe ‘zwaar’ WordPress is. Want alles wat je aan plugins gebruikt wordt allemaal iedere keer opnieuw geladen.

Omdat in de tijd, dat WordPress ontstond, er allerlei technieken nog niet mogelijk waren, om het anders te doen.

Laravel is opgezet met het idee -een idee wat ook prima geïmplementeerd is- dat ‘Autoloading’ mogelijk moet zijn. Je laadt functionaliteiten pas op het moment, dat je ze gebruikt. En dat kan enorm in je ‘loadsize’ verschillen.

Het nadeel van een ‘data driven’ applicatie

WordPress is ‘Data Driven’. Dat wil zeggen, dat (bijna) alles wat ook maar iets te maken heeft met de configuratie van WordPress wordt opgeslagen in de database. Dat is makkelijk, omdat het daarmee ook makkelijk aanpasbaar is. Maar dat vergt ook heel wat van de capaciteit van het systeem.

Een tweede nadeel is, dat het ook moeilijker maakt een applicatie te ‘stagen’, om verschillende versies voor ontwikkeling, acceptatie en productie te hebben. Want sommige instellingen zijn gerelateerd een die specifieke omgeving.

In Laravel is het mogelijk om delen van de configuratie in aparte configuratiebestanden op te slaan. En het is een goed idee om alles wat geen gebruikersinstelling is op deze manier op te slaan. Het is sneller, het is veiliger en het maakt ‘staging‘ ook een stuk eenvoudiger.

Maatwerk hoeft niet duur te zijn!

De meeste mensen denken dat maatwerk software duur moet zijn. Niets is minder waar! Tenminste niet, wanneer je met een ‘Geopinieerd’ framework als Laravel werkt. Wat is een ‘geopinieerd framework’?

De maker van Laravel – Taylor Otwell – is eigenwijs. Of eigenlijk, gebaseerd op zijn jarenlange ervaring als webdeveloper bedacht hij dat hij toch wel heel vaak dezelfde kunstjes uit had moeten voeren, terwijl hij die tijd beter had kunnen gebruiken. In eerste instantie helemaal voor zichzelf bouwde hij in 2011 een webapplicatie framework wat voor een groot deel gebaseerd was op het destijds populaire ‘CodeIgniter’. Maar CodeIgniter bood een heleboel toch niet onbelangrijke dingen niet.

Gebaseerd op zijn eigen ervaring als ontwikkelaar bouwde hij -omdat het alleen voor hemzelf bedoeld was- de eerste versies van Laravel. Gebaseerd om zijn eigen manier van werken.

Dat laatste bleek juist zijn kracht te zijn. Omdat de meeste frameworks bedoeld waren om binnen verschillende bedrijven met verschillende workflows gebruikt te kunnen worden, konden bepaalde dingen moeilijk ‘gestandariseerd’ worden. Otwell ging er vanuit dat zijn manier de beste was. En zolang hij de enige gebruiker was, had hij natuurlijk gelijk. Het was voor hem de beste manier.

Naast het Framework, bouwde hij er ook een aantal tooltjes omheen. Een programmeur besteedt normaal veel tijd aan repeterende taken. En Otwell ontwikkelde een aantal tools, later samengevoegd in de Artisan CLI (een commandline interface voor Laravel) waarmee het geraamte van bepaalde veel voorkomende taken snel gegenereerd kon worden.

Juni 2011 presenteerde hij voor het eerst Laravel (1.0) aan een publiek. En Laravel won al snel aan populariteit.

Nu, precies 15 jaar later, is Laravel het meest gebruikte PHP applicatie framework voor het Internet. En het is inmiddels meer dan een ‘framework’ geworden. Liever spreken we hier over een ecosysteem. Want ‘Laravel’ is een omgeving geworden, waarmee je, door met gestandaardiseerde methoden te werken, snel professionele websoftware kan bouwen. Vrijwel alle techniek is inmiddels binnen Laravel aanwezig. 80 tot 90% van de gewenste en noodzakelijke functionaliteit voor een goede applicatie is aanwezig. De meeste ontwikkeltijd zit in een goed datamodel, een goed procesmodel en goede autorisaties.

Bij klassieke (niet geopinieerde) ontwikkeling zit vaak 60-80% van de ontwikkeling in het ontwerpen van de gebruikersinteractie. Zelf maak ik bij Laravel development gebruik van het ‘Filament’ package. Het idee hiervan is, dat je vanuit de database en de rechtenstructuur direct de code voor de gebruikersschermen kan ontwikkelen. Na een paar cosmetische aanpassingen met de hand, is meer dan de helft van die 80% al gedaan. En dat alles zonder gebruik te maken van AI hulpmiddelen.

Lees ook het vervolgartikel

Binnenkort komt ook een vervolgartikel op dit artikel, waarin haarfijn wordt uitgelegd hoe de communicatie tussen zo’n Laravel applicatie en je website werkt.

Blijf op de hoogte en schrijf je hieronder in voor onze nieuwsbrief