De automatische updates voor kleine versies van WordPress hebben hun waarde al jaren bewezen. Maar werkt dit ook met plugin-updates? En zo ja, onder welke voorwaarden? WordPress ontwikkelaar Florian Simeth onderzocht deze vraag.

Iedereen die WordPress al een tijdje gebruikt weet dat de automatische updates van de kernsoftware vrij goed en meestal zonder problemen werken. Als de plugins er niet waren. Doorgaans doet de gedachte aan automatische plugin-updates de nekharen van de meeste websitebeheerders overeind staan. Iedereen die wel eens met zijn tanden heeft geknarst voordat hij op de update-knop klikte, weet waar ik het over heb.

Er is geen fundamentele zekerheid dat de updates correct zullen verlopen. Ook niet als de update zelf niet mislukt, maar de fouten ergens, onzichtbaar, ondergronds op de loer liggen. De meeste collega's die ik vroeg zouden geen automatische plugin-updates uitvoeren, althans niet voor alle WordPress-plugins. Maar waarom is dat eigenlijk het geval?

Automatische plugin-updates: de risico's

Honderden vrijwilligers dragen bij aan nieuwe versies van WordPress. Niet elk plugin project heeft deze kracht. De meeste gratis plugins in de WordPress plugin directory zijn ontwikkeld door slechts één persoon (of misschien een klein team). Dit betekent niet dat deze plugins per se slecht zijn. We weten echter uit het verleden dat het meestal de plugins zijn die beveiligingslekken openen en zo de eigen WordPress instantie veranderen in een aanvalsoppervlak voor hackers.

Daarom kan worden aangenomen dat de kwaliteit van de code eronder lijdt of onvoldoende wordt getest. Ik wil niet langer uitleggen waarom dit het geval is. Maar het verklaart wel waarom ik bij bekende plugins als YoastSEO snel op de update-knop klik en bij andere niet.

"In principe kun je problemen herkennen omdat er eerder iets fout is gegaan," schreef WordPress ontwikkelaar Marc Nilius in een e-mail interview. Volgens zijn eigen informatie onderhoudt hij momenteel ongeveer 200 WordPress instanties en kent hij zijn "vrienden" maar al te goed.

Nu heeft Yoast zeker een groot team achter zijn eigen gratis YoastSEO plugin, die actief is op meer dan vijf miljoen WordPress sites. Voor het vlaggenschip van het bedrijf doet het er alles aan om ervoor te zorgen dat er niets mis gaat. Dat kost moeite. Een inspanning die een ontwikkelaar alleen misschien niet aan kan of wil. Dus wat kan er gedaan worden?

Manieren om het risico van plugins te minimaliseren

1. Gebruik geen oude plugins

"Democratizing Publishing" is een duidelijke leidraad voor WordPress. Het feit dat iedereen gewoon snel een WordPress website kan opzetten is schitterend, maar leidt er automatisch toe dat deze mensen de site op een gegeven moment willen uitbreiden. En dat doen ze met plugins. Omdat ze meestal niet zelf kunnen programmeren, zoeken ze op het eeuwige WorldWideWeb naar een remedie. En die zijn er genoeg. 

Momenteel staan er alleen al in de WordPress plugin directory bijna 55.000 extensies. Er wordt gebruikt, wat werkt. Zonder erop te letten of de plugin verder ontwikkeld wordt en of hij compatibel is met de huidige WordPress-versie. Dit is niet altijd waar en leidt uiteindelijk vaak tot het verwerven van een gezond wantrouwen tegenover updates. Want vaak werken zulke plugins op een gegeven moment niet meer. Ook al kan dit een paar jaar duren.

Natuurlijk zijn er ook positieve voorbeelden. Er zit bijvoorbeeld een enorm bedrijf achter WooSidebars. Toch kreeg de WooCommerce plugin lange tijd geen updates. Het werd niet getest met de nieuwste WordPress versies, maar werkt in veel gevallen nog steeds perfect. Hoe lang nog? Eerdere opmerkingen in de support sectie wezen al op een einde. De gebruiker heeft er echter niets van gemerkt. Tijdens de installatie geeft alleen een kleine, onopvallende mededeling dit gebrek aan. Een gevaarlijk zaak.

Natuurlijk heb je bij het begin van je blogcarrière vaak geen geld voor individuele ontwikkeling. Voor deze mensen is er soms geen ander alternatief. Toch moet je in gedachten houden dat je – vanwege de hierboven genoemde veiligheidsrisico's – geen verouderde WordPress plugins mag gebruiken.

2. Plugins stel jezelf niet aan

Om ontwikkelingstijd te besparen worden officiële en onofficiële WordPress plugins vaak gewoon aangepast door hun eigen ontwikkelaars. Als het versienummer of de naam van de plugin niet is gewijzigd, biedt WordPress een update aan, hoewel die misschien niet wordt uitgevoerd omdat hij anders de eigen wijzigingen zou overschrijven.

"Aangepaste plugins hangt vaak te veel af van theme functionaliteiten", weet ook Marc. Als er iets verandert in de theme, loopt de plugin niet meer correct. Dus er zijn veel problemen. Maar alles zelf van de grond af aan doen, d.w.z. alleen gebruik maken van je eigen ontwikkelingen, is ook hier geen echt alternatief.

3. Gebruik geen slechte plugins

Wat is een "slechte" plugin? Deze vraag is niet gemakkelijk te beantwoorden. Vooral niet voor de leek. Je kunt je natuurlijk afvragen of er geautomatiseerde tests van nieuwe versies worden uitgevoerd. Maar wie doet dat? Veel WordPress gebruikers weten niet eens dat zoiets mogelijk is. Bovendien hebben dergelijke tests (als ze worden uitgevoerd) vaak niets te maken met live situaties.

Dat is begrijpelijk vanuit het oogpunt van de ontwikkelaars. Wie test elke plugin met elk mogelijk WordPress theme? Of elke plugin met elke andere plugin? Dat is niet mogelijk. Je kunt degenen die WordPress plugins ontwikkelen daar ook niet op vertrouwen.

Ook hier geldt: Soms is het niet mogelijk om "slechte" plugins te gebruiken, omdat ze eenvoudigweg niet altijd herkenbaar zijn. Hoewel de kwaliteitsbeoordeling voor veel gebruikers al de eerste horde is, zou je nieuwe plugins op zijn minst zelf actief moeten testen voordat je ze op een live pagina integreert. Maar daarover dadelijk meer.

Waarom automatische plugin-updates mislukken

Het is een feit: je kunt WordPress plugins niet zomaar niet-gebruiken. De bovengenoemde problemen zullen altijd blijven bestaan. Er moet dus een andere oplossing gevonden worden. De vraag die je jezelf dus moet stellen is: "Hoe kun je, ondanks alle problemen, toch automatische updates voor WordPress plugins uitvoeren?". En deze vraag leidt onvermijdelijk tot de volgende: "Wat zou er eventueel mis kunnen gaan?"

Hier zijn enkele mogelijkheden:

1. PHP-Fatal-Error: De website werkt helemaal niet vanwege een ernstige fout.
2. De plugin werkt niet (meer) met andere plugins en/of de theme. Dit manifesteert zich op verschillende manieren:
   a) functies zijn niet langer beschikbaar of
   b) de lay-out verandert in de frontend.
3. Niet-bestaande achterwaartse compatibiliteit maakt rollback moeilijk.
4. De database is zo groot dat een backup erg lang zou duren.

Benaderingen voor succesvolle plugin-updates

Slecht plugins herkennen

Laten we beginnen met de gebruikers. Hoe zouden ze een "slechte" plugin kunnen herkennen? Omdat de leek niet kan controleren of de kwaliteit van de code goed is, zou er een systeem moeten komen dat dit wel kan. De vraag is: zou zoiets werken? En het antwoord is heel duidelijk: Ja!

Het aardige is dat een klein WordPress team al aan zo'n systeem werkt. Het heet Tide. De visie van Tide is om geautomatiseerde kwaliteitstesten uit te voeren voor alle WordPress plugins en thema's en deze testresultaten zichtbaar te maken voor zowel de auteurs als de gebruikers van deze plugins en themes.

Het is nog niet klaar, maar in de toekomst zal Tide leken helpen om beter te identificeren wat voor WordPress plugins ze installeren. Tot die tijd moet je je houden aan de plugin-metadata, die op wordpress.org in de plugin-directory voor elke afzonderlijke plugin worden weergegeven:

1. De datum van de laatste update. Frequente updates kunnen wijzen op een actief ontwikkelingsproces. In de meeste gevallen zorgen de ontwikkelaars ook voor het oplossen van bugs.
2. Aantal installaties. Een zeer hoog aantal duidt niet alleen op populariteit, maar kan ook een aanwijzing zijn dat de auteurs geld verdienen met de plugin (bijv. via een pro-versie). Hierdoor ontstaat een zekere druk bij de fabrikant. Ze hebben er zeker belang bij dat de gratis plugin ook foutloos werkt.
3. Getest tot. Dit is ook slechts een versienummer dat op elk moment door de fabrikant aangepast kan worden zonder dat het door een derde partij bewezen hoeft te worden. Een actueel versienummer is echter een indicatie dat de plugin regelmatig wordt bijgewerkt.
4. PHP-versie. Hoewel het fijn is dat ontwikkelaars lage versienummers van PHP blijven ondersteunen, zou een hogere versie veiliger zijn.

Geautomatiseerde browsertests

Nu wordt het iets moeilijker. Vooral voor iedereen die geen enkele programmeerkennis heeft. Iedereen die afhankelijk is van belangrijke functies moet ze regelmatig testen – liefst automatisch natuurlijk.

Puppeteer is een NodeJS bibliotheek die een high-level API biedt voor het besturen van de Chrome browser via het DevTools protocol. Puppeteer draait standaard headless, maar kan worden geconfigureerd om de browser te openen zodat je kunt zien wat er gebeurt.

Functionele tests

Er zijn veel toepassingen voor zulke tests. Als je een webwinkel met WooCommerce hebt, kun je controleren of producten nog aan het winkelwagentje kunnen worden toegevoegd. Of dat er nog formulieren kunnen worden ingediend.

Natuurlijk kunnen niet alle gevallen worden gedekt. Een kleine automatische test is echter in de meeste gevallen doeltreffender dan de eenvoudige visuele inspectie. Je kunt immers niet altijd alle functies van een pagina testen na elke kleine update. Vooral als het zeer uitgebreid is.

Visuele regressietests

Zelfs een "visuele inspectie" zou met de huidige middelen geautomatiseerd kunnen worden. Dit werkt relatief eenvoudig, bijvoorbeeld met BackstopJS. De configuratie gebeurt snel via een JSON bestand. Een backstop test in de console is voldoende om de vergelijking te starten. Tenslotte opent de tool een browservenster en toont de verschillen.

Omdat BackstopJS ook een gedetailleerd, machineleesbaar rapport geeft met een onderscheidingswaarde in procenten, kun je bijvoorbeeld per e-mail geïnformeerd worden als er een belangrijke verandering in de lay-out is geweest.

Rollback

Laten we zeggen dat alle updates gedaan zijn en de automatische tests faalden. Wat moet ik doen? Natuurlijk kunnen back-ups automatisch worden geïmporteerd. Maar dit werkt slechts in drie gevallen: 

1. Als de hoster een interface heeft waarmee automatisch een rollback kan worden uitgevoerd.
2. Of als je SSH-toegang hebt.
3. En als de back-up klein genoeg is. Anders zal de restore in het ergste geval enkele uren duren.

Veel ontwikkelaars weten maar al te goed dat het meeste hiervan vaak niet mogelijk is. Of SSH-toegang is niet beschikbaar of er zijn timeouts door gebrek aan middelen op de server.

Andere oplossingen?

Natuurlijk is mijn opvatting slechts een van de vele. Er zijn andere, meestal duurdere oplossingen. In plaats van achteraf een back-up te importeren, kan bijvoorbeeld vooraf een kopie van de site worden gemaakt (staging concept zoals bij Raidboxes, naast de WordPress back-ups) en daarmee kunnen alle mogelijke updates en tests worden uitgevoerd. Als alles goed gaat in de test, kunnen de updates uiteindelijk ook op de live site worden geïnstalleerd. Dan natuurlijk (meestal) geheel automatisch en zonder dat je nekharen overeind gaan staan.

Een ander idee zou zijn om WordPress gewoon statische pagina's te laten maken. Dan zou de pagina wat onafhankelijker zijn van de eigenlijke kern. Plugins voor dit doel bestaan al acht jaar: WPStatic, bijvoorbeeld. Maar nogmaals: dit werkt niet voor elk gebruik, zeker niet voor zeer dynamische sites zoals webshops.

Mijn conclusie

Hoe je het ook doet, doe je toch verkeerd? Nee. Uiteindelijk hangt het af van je eigen website, je wensen en natuurlijk je portemonnee. Als je geen kritische sites beheert en het okay is dat een website fouten uitgeeft, dan doe je het goed met automatische updates.

Bij Raidboxes kun je ook met het Fully Managed add-on automatische plugin- en theme-updates activeren. In de instellingen van je Box kun je ook individuele plugins en themes waarmee je al problemen hebt gehad uitsluiten van de auto-updates.

Maar automatische plugin updates gaan waarschijnlijk toch relatief soepel voor de meeste kleine sites. Wie grotere websites heeft, beschikt meestal over meer financiële middelen om passende maatregelen te nemen. Iedereen daartussenin moet zijn eigen oplossing vinden.