Wordpress plugins: de afkomst

  • ± 4 minuten

Het grote voordeel van Wordpress, is direct ook zijn nadeel. Uiteraard hebben we het dan over plugins, hoe verrijkend zijn ze en voor wie? Een beknopte inzage in de kanttekeningen vanuit de bron.

Over performance issues welke (niet samenwerkende) plugins met zich mee brengen als ook upgrade-conflicten, valt een apart artikel te schrijven. Hieronder ga ik echter vooral beknopt een kijkje in de keuken geven, waar een plugin vandaan kan komen en welke issues dit met zich mee brengt.

De plugin programmeur

De programmeur achter een plugin is niet altijd bekend. Gelukkig zijn er review-systemen om na te gaan of plugins onderhouden worden. Maar soms heb je gewoonweg iets nodig, iets dat voldoet aan je wensen. Wat kunnen de risico's zijn?

PHP / programmeer kennis

Een programmeur kan gebrek hebben aan degelijke PHP kennis om te voorkomen dat er kwetsbaarheden in de code opduiken. Diezelfde kwetsbaarheden is een reden dat Wordpress een doelwit is van bots om lekken op te sporen. Niet zelden slagen bots hierin, waarna opgespoorde sites gehacked worden.

Bij gebrek aan goede kennis van (My)SQL, kunnen zelfs langzame queries worden gemaakt, waarmee de plugin en vervolgens de gehele site onnodig vertraagd kan worden. Dit zal een logische impact hebben op zowel benodigd geheugen voor een Wordpress site, als ook de laadtijd van de website: deze wordt langzamer. Dit heb ik onder meer eens in opdracht mogen tackelen voor een auto-portal, waar de Wordpress zoekmodule letterlijk 100 keer sneller werd. Hier heeft iemand het geheugen van 256MB teruggebracht naar 60MB. Helaas weet je niet altijd hoe kwalitatief een plugin is.

CSS / client side kennis

Plugins worden nagenoeg altijd vergezeld met CSS in de vorm van embedded CSS of externe stylesheets, als ook JavaScript, bijvoorbeeld voor slideshows. Echter, soms zijn bepaalde gedragingen welke via JavaScript worden aangestuurd, prima via CSS te realiseren. Dit kan niet alleen HTTP requests of laadtijd beperken, maar kan er ook voor zorgen dat er minder rekenkracht voor een computer of smartphone nodig is om het gewenst doel te behalen; elke slide van links naar rechts bewegen.

Maar ook gebruik van CSS vergt enige kennis, om de gebruikerservaring te waarborgen. Zoals een te veel aan JavaScript voorkomen moet worden, geldt dit ook voor CSS. Bonus feit: Internet Explorer telde tot en met versie 9, bijzondere CSS limieten.
Maar hoe voorkomen je dat een telefoon warm wordt doordat de CPU de pan uit rijst? Een best practice is om je bijvoorbeeld tot het gebruik van translate en opacity voor CSS animaties te beperken, om te voorkomen dat een browser content-lagen opnieuw moet tekenen. Dit laatste kost rekenkracht, en kan dus voorkomen worden. Hiermee loop je niet het risico dat animaties ten koste gaan van je bezoekers. Niet geheel onverwacht, is de tevredenheid van gebruikers, een (volgens dit MOZ-artikel de nummer één) ranking factor voor SEO / Google.

HTML kennis

Dit komt wellicht als een verrassing. Is het niet zo dat iemand die in staat is een plugin in PHP te programmeren, ook HTML kent? Uiteraard is deze stelling correct, maar de mate waarin HTML kennis aanwezig is, zal van invloed zijn op de kwaliteit van de plugin. Bijvoorbeeld:

  • Is de HTML semantisch opgezet, oftewel, worden elementen ingezet waar ze voor bedoeld zijn?
  • Is er kennis omtrent de internationale webstandaarden als ook Nederlandse webrichtlijnen aanwezig?
  • Is men (de plugin programmeur) op de hoogte hoe je HTML dusdanig inzet, dat de plugin daarmee de algehele toegankelijk­heid van een website niet schaadt?

Packages

In sommige gevallen grijpen developers naar NPM packages, zodat ze niet het wiel opnieuw hoeven uit te vinden. Dit bespaart ontwikkel-tijd, maar zorgt voor extra code en dus extra load, met mogelijkerwijs bloated websites als ook security issues (AVG) als gevolg, als ook afhankelijkheid.

Soms is een package gewoonweg niet nodig en wordt er wegens beperkte kennis en kunde of tijdgebrek naar NPM packages gegrepen. Iemand concludeerde al eens, vertaald naar een artikel, dat we niet meer weten hoe we moeten programmeren:

NPM packages kunnen in dit geval vervangen worden door elk soort package systeem voor bijvoorbeeld PHP of Node.js.

Wordpress plugins, kortom

De vrijheid en vooral mogelijkheden van Wordpress heeft dus kanttekeningen, al vanuit het plugin-idee. Plugins werken erg verrijkend voor de gemiddelde bezoeker met desktop op een goed wifi verbinding, maar hoe zit het met smartphone gebruikers die onderweg zijn, of gewoonweg mensen met een visuele beperking?
Een webbouwer zal namelijk niet altijd in staat zijn om fouten op verschillende vlakken op te sporen. Dit kan komen doordat expertise voornamelijk elders (vormgeving/marketing) ligt, ontwetendheid/onkunde, tijdgebrek om de(r)gelijke kennis op te doen of niet het overzicht hebben of kunnen houden over alle geïnstalleerde plugins.

Wordpress heeft namelijk een niche van webbouwers voortgebracht, met een tekort aan kennis met als resultaat dat klanten niet altijd correct geinformeerd kunnen worden. Of Blue 2 Blond hierin wel een adviserende rol in kan spelen? Zeker, ondanks dat onze voorkeur uit gaat naar een systeem dat in de basis op alle vlakken geoptimaliseerd is, waarbij ons maatwerk CMS als startpunt aangeraden zal worden ten koste van Wordpress.

Wordpress plugins out-of-the-box

Het praktische van Wordpress plugins, is dat ze vaak direct, out-of-the-box werken na installeren (conflicten bij updates en upgrades daar gelaten). De directe kanttekening is dat ze niet per defintie samen werken met andere plugins en daardoor eigen bronnen verbruiken.
Zo kan het zijn, dat verschillende plugins eigenlijk dezelfde bronnen verbruiken, maar wellicht net een andere versie (of soms zelfs dezelfde versie). Denk bijvoorbeeld aan de jquery-framework, gebruik van iconen sets. Dit heeft een toename in http requests als gevolg. De meer doorgewinterde Wordpress programmeur is echter in staat, de assets die deze extra requests teweeg zal brengen, uit te schakelen.

Let wel: gebruik van Wordpress plugins heeft meer kanttekeningen, waaronder een zwaardere Wordpress site. Hierover schrijf ik in augustus een apart artikel.

Next up: Een voorbeeld van een plugin is Accelerated Mobile Pages voor Wordpress. Een must-have? Volgende week te lezen in een artikel van mijn hand.