Hoe herken je een goede WordPress Plugin?

Een goede WordPress plugins – Enkele manieren om deze te herkennen!

Eén van de meest krachtige voordelen van WordPress is dat je WordPress makkelijk in functionaliteiten uit kan breiden door plugins te installeren. Toen ik ergens eind 2005 kennis maakte met WordPress 1.5 vond ik het -naar de maatstaven van die tijd- al een geweldige internet applicatie. Maar toen enkele maanden later WordPress 2.0 kwam, een versie waarbij eigenlijk vanuit WordPress 1.5 en eerder op de kop werd gegooid, was ik compleet enthousiast.

Niet vanwege WordPress zelf. Maar op dat moment werkte ik als system integrator en de manier waarop WordPress plugins integreerde was ongekend.

Voor de duidelijkheid, het gebruikersgemak was absoluut niet wat je nu gewend bent. Er was al wel zoiets als de ‘WordPress repository’, maar dat was een link naar de WordPress.org plugin pagina’s, waar je de plugin kon downloaden. Die moest je vervolgens uitpakken en met een FTP programma naar de site uploaden. Dan moest je vooral niet vergeten dit naar de juiste map te doen.

En het updaten van een plugin was hetzelfde idee. De update downloaden, uitpakken en weer uploaden naar de juiste plaats op de server.

Maar in die tijd was het normaal, dat je in ieder geval ook een aantal configuratiebestanden aan moest passen om een toepassing te laten weten, dat er iets nieuws was toegevoegd. Dat hoefde bij WordPress niet. WordPress ‘merkte’ het zelf. En ook het verwijderen betekende niet, dat je opnieuw allerlei configuratiebestanden bij moest werken.

Met andere woorden, WordPress was een prachtig voorbeeld van ‘de toekomst van het Internet’.

Wat is nu zo’n plugin?

Ik merk in de dagelijkse praktijk, dat er aardig wat mensen zijn, die niet echt een idee hebben over wat nu eigenlijk een ‘plugin’ is. De term is voor zover mij bekend afkomstig van Microsoft, toen deze in -bijna- 1996 uitkwamen met Windows 95. Een ‘plugin’ was een stukje software wat min of meer automagisch geïnstalleerd moest worden, wanneer je een nieuw stuk hardware in je Windows 95 computer prikte.

In het verleden zou je allerlei extra programma’s moeten installeren om het één en ander aan de praat te krijgen, maar dat zou met Windows 95 niet meer nodig zijn. Deze ‘moderne’ technologie werd internationaal al snel ‘Plug and Pray’ genoemd. In Nederland was het ook bekend als ‘Prut and Pray’.

Inmiddels weten we het zelf al. Wanneer we een ongebruikelijk apparaat aan Windows toevoegen downloaden we een programma van het Internet wat de drivers installeert. Ongeveer hetzelfde idee wat we voor Windows 95 deden, behalve dan, dat we het destijds op diskettes met de hardware meegeleverd kregen.

Het ‘plugin project’ van Microsoft was een fiasco.

Het was dus leuk te zien, dat het ‘plugin project’ van WordPress wel goed werkte. Tenminste… in concept.

Want hoewel het concept van de ‘WordPress plugin’ een geweldige vinding is, houdt niet iedere plugin ontwikkelaar zich aan de regels. En dat kan tot heel wat ellende leiden.

Uitbreiding van functionaliteiten

Een WordPress plugin is een uitbreiding van de standaard functionaliteiten van WordPress. In het begin, met de eerste plugins, waren dat vaak kleine uitbreidingen, maar inmiddels zijn er plugins als WooCommerce, Elementor en WP Courseware die eigenlijk van WordPress een compleet nieuw systeem maken. Er is vrijwel niemand meer die WordPress alleen nog maar ziet als ‘blog programma’. Het is een ‘basis Content Management Systeem’ met vele uitbreidingsmogelijkheden.

De kracht van WordPress is vooral gebruik te maken van eenzelfde ‘gegevensstructuur’ die makkelijk met verschillende plugins te delen is. Wil je meer over die gegevensstructuren weten, dan moet je zeker mijn blogartikel over Custom Post Types en Custom Taxonomies eens lezen.

Hoewel er duidelijke richtlijnen zijn over hoe een goede plugin geschreven dient te worden, houdt niet iedere programmeur aan deze richtlijnen. En het is je wellicht wel eens overkomen, dat na het installeren of upgraden van je plugin ineens je site verdwenen is. Het enige wat je te zien krijgt is een blanco scherm, of een foutmelding.

Dat is één van de redenen, dat je eigenlijk altijd eerst een back up moet maken, of je site in een staging omgeving moet updaten, voor je dit in je liveomgeving doet.

Maar stel nu, dat er inderdaad iets fout gaat. Je hebt een aantal nieuwe plugins geïnstalleerd en plotseling is je site verdwenen. Wat nu?

Waarom gaat het eigenlijk wel eens fout bij het updaten van je plugin?

En hoe komt het nu eigenlijk, dat het fout gaat? Dat kan een aantal redenen hebben. Een goede WordPress plugin houdt zich in ieder geval aan een aantal regels. En één van die regels is, dat je zoveel mogelijk probeert naamgevingsconflicten te voorkomen. Maar hoe doe je dat?

Stel je nu voor, ik heb een nieuwe plugin gemaakt. En deze plugin doet iets met producten. Het is dus logisch om een functie die producten ophaalt ‘get_products’ te noemen.

Maar een andere WordPress Developer heeft ook een plugin gemaakt die ‘iets’ met producten doet. En omdat ‘get_products’ inderdaad een logische naam is, heeft ook hij een functie gemaakt niet ‘get_products’ heet.

Nu vindt PHP -de ontwikkeltaal waarin WordPress is geschreven- het geen goed idee om twee verschillende functies eenzelfde naam te geven, dus bij het opstarten zal PHP al klagen, dat het niet is toegestaan om een functie voor een tweede maal te definiëren.

Dat is de reden, dat in de richtlijnen voor het maken van plugins wordt aangegeven, dat je een functie altijd moet beginnen met een ‘prefix’. Ik kom echter genoeg plugins tegen, waar de maker van de plugin dit niet heeft gedaan. En deze plugins vormen dus een potentieel risico voor plugin conflicten. In mijn ‘snippet base‘ zie je dat ik zelf de letters wxp_ graag gebruik als prefix voor mijn functies. Soms in combinatie met een tweede prefix voor een klantproject.

Meerdere malen dezelfde bibliotheek toevoegen

Een tweede oorzaak van plugin conflicten is minder een fout van de maker van de plugin, maar een ontwerpfout in WordPress zelf.

Omdat niet iedereen alles zelf wil programmeren, wordt er veel gebruik gemaakt van externe bibliotheken. Om een voorbeeld te geven: Wanneer jij op de één of andere manier middels een plugin contact maakt met MailChimp, dan zal vrijwel iedere plugin gebruik maken van de MailChimp PHP bibliotheek. Dat scheelt je een hoop om het wiel opnieuw uit te moeten vinden.

En omdat die bibliotheek natuurlijk wel eerst aanwezig zal moeten zijn, zal de maker van de plugin deze ook meeleveren in een subfolder van zijn eigen plugin. Vaak heet zo’n folder ‘vendors’, omdat je hier de libraries van derde partijen vindt, maar dat is geen vaste regel.

En zo’n bibliotheek moet geladen worden.

Eén van de regels voor het schrijven van een goede plugin is dat je controleert of een bepaalde bibliotheek niet al geladen is, door op te vragen, of een functie wel of niet al bestaat.

Bestaat die functie al, wil dat zeggen, dat hoogstwaarschijnlijk die specifieke bibliotheek al door een andere plugin is geladen. Als je dit voor een tweede keer zou proberen, krijg je een foutmelding.

Deze routine ziet er ongeveer als volgt uit :

<?php 

if (!function_exists('my_incredible_library_function')) {
   require_once('./vendor/my_incredible_library.php);
}

Ik zeg hier dus eigenlijk, wanneer de functie ‘my_incredible_library_function’ niet bestaat, dan mag je ‘my_incredible_library.php’ laden, anders niet.

Maar wat nu, wanneer ik een plugin heb gemaakt die vertrouwt op versie 3.0 versie van ‘my_incredible_library’, terwijl een andere plugin versie 2.0 van diezelfde bibliotheek heeft meegeleverd. Dan hebben we een serieus probleem, tenminste, wanneer die andere plugin als eerste wordt geladen.

Want wie het eerst komt, het eerst maalt, en wanneer ik de functie ‘my_v30_function’ nodig zou hebben, die in versie 2.0 niet bestaat, krijg ik een foutmelding. En daar valt niet veel aan te doen anders dan te hopen, dat de maker van de plugin met de 2.0 versie maar zo snel mogelijk zal upgraden.

Dit is ook een belangrijke reden waarom jij als WP gebruiker regelmatig updates uit moet voeren!

Hoe los je plugin conflicten op?

Het oplossen van plugin conflicten is eigenlijk onbegonnen werk voor de leek. Maar het identificeren van een plugin conflict is dat niet.

Heb jij net een update gedaan en je site ligt ineens plat, dan is een goede manier om het probleem te identificeren het volgende:

1. Je begint met het deactiveren van alle plugins.
2. Eén voor één test je de plugins, en kijkt of het probleem daadwerkelijk is verholpen.
3. Dit blijf je doen, tot het probleem zich voordoet.

Wanneer je het probleem gereproduceerd hebt, dan weet je in ieder geval welke plugin het directe probleem heeft veroorzaakt. Dit zegt nog steeds niet, dat dit de veroorzaker van het probleem is.

Wanneer je hierboven kijkt naar de verschillende libraries als oorzaak van een probleem, dan is het eigenlijk zo, dat de plugin met de meest recente versie van een library niet de veroorzaker is, maar juist het ‘slachtoffer’.

Daarom is het verstandig deze test nog een keer uit te voeren. Ditmaal schakel je als eerste de plugin in die zorgde, dat je site down ging.

Daarna de andere plugins één voor één.

Op het moment dat je nu een foutmelding krijgt, of je site weer op blanco springt, weet je dat in ieder geval die beide plugins niet leuk met elkaar samen willen werken.

De beste stap om nu te zetten is contact op te nemen met beide makers van de plugins.

Verkeerde PHP versies

Een andere oorzaak van problemen met je website kan een verkeerde PHP versie zijn. Op dit moment wordt officieel geen enkele versie van PHP 7.x meer ondersteund. Draait jouw site nu nog steeds onder PHP 7.x is het heel goed mogelijk, dat bij een upgrade van een plugin in de nabije toekomst ineens je site ‘down’ is. Omdat deze plugin gebruik maakt van functies die wel in PHP 8, maar niet in PHP 7 voorkomen. Het enige wat je hier kan doen is gewoon je PHP versie upgraden.

Het nadeel is hier wel, dat dit niet zo snel zichtbaar is, wat de oorzaak is. En de bovengenoemde ‘liquidatie test’ zal je ook niet verder helpen.

De oorzaak van het probleem is meestal uitsluitend in de errorlog bestanden terug te vinden.

Tips bij het ‘kiezen’ van een plugin

Of een plugin ‘goed’ is wordt natuurlijk in de eerste plaats door de functionaliteit van de plugin bepaald. In dit artikel ga ik echter helemaal voorbij aan de functionaliteit van de plugin, en kijk ik uitsluitend naar wat een plugin ’technisch goed’ maakt.

1. Gebruik uitsluitend betrouwbare resources om je plugins te vinden / downloaden

WordPress is het meest gebruikte CMS ter wereld. Dat maakt WordPress natuurlijk ook een heel gewild doel voor hackers. Eén van de makkelijkste manieren om je site gehackt te krijgen, is een plugin te downloaden van een ‘niet gerenommeerde bron’.

De meeste betrouwbare bron voor gratis WordPress plugins is de WordPress Repository. De plugins die daar staan worden regelmatig geëvalueerd en mocht de plugin niet (meer) aan de technische eisen voldoen, dan wordt deze ook weer uit de repository verwijderd.

Bij het zoeken naar een passende plugin is er nog een aantal andere zaken waar je op kunt / moet letten. Een heel handig hulpmiddel hierbij is de Chrome Extension van WPHive. Deze extension geeft belangrijke informatie, die niet in de pagina’s van de repository zelf te vinden is. Zolang deze extensie actief is, zal dit getoond worden bij iedere plugin in de repository

In het voorbeeld hierboven zie je een plugin die het eigenlijk heel goed doet. Wat je moet weten is dat ‘No problems were detected during tests’ geen extra melding is, maar slechts een aanduiding, dat er problemen waren. Het gedetecteerde probleem is dus, dat ‘Frequently Updated’ hier geen vinkje krijgt.

Dat is de enige issue met deze plugin.

Hoe belangrijk ‘frequently updated’ is, is echter heel relatief. Er zijn plugins die uitsluitend de basisfunctionaliteiten van WordPress gebruiken. Omdat er in deze basisfunctionaliteiten eigenlijk weinig verandering is is ‘frequently updated’ voor mij persoonlijk nooit een probleem op zich. Ik download de plugin, inspecteer de code en besluit alsnog. Voor iemand die zelf dit soort inspecties niet zou kunnen doen, zou ik toch aanraden goed na te denken, of deze plugin wel of niet gebruikt moet worden.

Een tweede bron voor goede WordPress plugins is de CodeCanyon site van Envato. Hier vind je een groot aantal betaalde plugins die op code kwaliteit en betrouwbaarheid zijn getest. Het is een gecontroleerde marktplaats voor (onder meer) plugins. Het aardige van de Envato producten is, dat je slechts éénmalig hoeft te betalen voor een licentie, en dit dus geen jaarlijks terugkerende uitgave is.

Als derde bron noem ik natuurlijk graag de sites van gerenommeerde betaalde plugins, zoals bijvoorbeeld de WooCommerce site, waar je talloze plugins voor WooCommerce kan vinden, de Elementor Site en nog vele, vele andere sites.

Wat ik je beslist af zou raden zijn plugins die door goedwillende amateurs worden aangeboden als ‘hobby projectjes’ op persoonlijke pagina’s. Je mist hier de ‘second opinion’ die door een organisatie als de WordPress community (voor de repository) of Envato gegeven wordt, en niet iedere plugin op dit gebied is even veilig.

En wat ik je nog veel meer afraad is gebruik te maken van zogenaamde ‘nulled plugins’.

2. Lees bij een betaalde plugin altijd de ‘return policy’

Een plugin die het prima elders doet, kan een ramp zijn met jouw eigen website. Let bij de aankoop dus altijd op de ‘return policy’. Persoonlijk koop ik een plugin uitsluitend, indien de aanbieder van de plugin een ‘no questions asked’ return policy heeft.

Dat wil niet zeggen, dat ik geen vragen wil beantwoorden -dat doe ik graag als hij die heeft, maar dat ik -wanneer ik de plugin niet ‘aan de praat’ kan krijgen, ik hier niet teveel tijd in wil steken.

3. Test je plugin altijd eerst op een staging site en breng hem niet zomaar ineens in productie!

Een plugin die gedeïnstalleerd wordt laat meestal toch wat ‘rommel’ achter in de database. Test de plugin daarom altijd eerst op zijn geschiktheid in een staging omgeving en zet niet alles zomaar direct live.

4. Vergelijk de performance van je site voor- en na installatie van de plugin

Ik heb je al eerder verteld over Matomo. Een soort ‘Google Analytics, maar dan anders’. Voor het installeren van een nieuwe plugin klik ik graag op een 60-100 links in de site om een ‘baseline’ vast te stellen.

Na het installeren van de plugin doe ik dat nogmaals. En kijk wat de impact op de performance is.

Wat bij deze test vooral belangrijk is, is dat je op het moment van de test niet bent ingelogd. Wanneer je bent ingelogd als beheerder heb je op de ‘achtergrond’ vaak meer processen actief dan wat een gewone bezoeker heeft.

5. Lees regelmatig de WordXPression blog

Ik bespreek regelmatig plugins, waarbij ik ook de technische kant van de plugins niet uit de weg ga. Wil je op de hoogte blijven? Meld je dan aan voor de browser notificaties door op de rode knop links onder te klikken. Ontvang je liever een e-mail? Dan kan je je via het formulier hieronder aanmelden voor de nieuwsbrief.

Samenvattend

Het aanbod op het gebied van WordPress plugins is gigantisch. En je zou al heel snel door de bomen het bos niet meer zien. Een goede keuzehulp bij het selecteren van een plugin is ook te kijken naar de technische aspecten. In dit artikel heb je in ieder geval een mooie leidraad gekregen voor de technische evaluatie.

Persoonlijk kan ik de WP Hive Browser Extension voor Chrome zeker aanbevelen voor de evaluatie / vergelijking van plugins binnen de repository.

Wil je zelf plugins leren ontwikkelen? Dan is deze WordXPression cursus wellicht iets voor jou!