U werkt een plugin bij, ververst de pagina en ziet dat de opmaak is verschoven of dat het formulier weg is. Op zo’n moment is een plugin versie terugzetten in WordPress bijna altijd de verstandigste eerste actie. Niet omdat u de nieuwe versie nooit meer wilt, maar omdat u eerst uw site terug wilt hebben en daarna pas gaat uitzoeken wat er speelde.
Er zijn drie routes, met elk hun eigen risico. En er is één situatie waarin terugzetten juist schade oplevert. Die bespreken we ook, want dat is de fout die het duurst uitpakt.
Route 1: met een plugin die versies bewaart
De eenvoudigste manier is een hulpplugin die van elke plugin de vorige versies kan terugzetten. U kiest de plugin, kiest een oudere versie uit een lijst en bevestigt. De hulpplugin haalt die versie op uit de officiële voorraad en zet hem terug.
Voordelen: het werkt vanuit het beheerscherm, u hoeft niets te downloaden en het duurt een minuut. Nadeel: het werkt alleen voor plugins uit de officiële map. Betaalde plugins met een eigen updatekanaal vallen erbuiten.
Zet na het terugzetten de automatische update voor die plugin uit. Anders staat de nieuwe versie er de volgende ochtend gewoon weer op en zoekt u opnieuw.
Route 2: handmatig een plugin-versie terugzetten in WordPress
Voor plugins uit de officiële map kunt u elke eerdere versie los downloaden vanaf de pluginpagina; onderaan staat een overzicht met oudere uitgaven. Bij betaalde plugins vindt u de vorige versies meestal in uw account bij de maker.
- Maak eerst een back-up. Ook bij deze kleine ingreep, want u weet nog niet wat de oorzaak is.
- Download de gewenste versie en pak het bestand uit.
- Deactiveer de plugin in het beheerscherm. Verwijderen hoeft meestal niet.
- Verwijder de map van de plugin via SFTP of bestandsbeheer en zet de oude map terug.
- Activeer de plugin en controleer of het probleem weg is.
Blijft de fout bestaan, dan lag het niet aan deze plugin en zet u de nieuwe versie gewoon weer terug. Hoe u de werkelijke veroorzaker vindt, staat in het stappenplan om een pluginconflict op te sporen.
Route 3: de back-up terugzetten
Heeft u vlak voor de update een moment vastgelegd, dan is dat de snelste weg terug. U herstelt dan de hele situatie, inclusief database, en bent gegarandeerd terug bij hoe het was.
Het nadeel is groot genoeg om te benoemen: alles wat na dat moment is gebeurd, verdwijnt. Nieuwe bestellingen, ingevulde formulieren, reacties, een pagina die een collega net had aangepast. Bij een webshop is dit vrijwel altijd de verkeerde keuze, tenzij de update tien minuten geleden was.
Kunt u kiezen, zet dan alleen de bestanden terug en laat de database staan. De meeste back-upprogramma’s kunnen dat onderscheid maken. Hiermee draait u de code terug zonder uw gegevens te verliezen.
De valkuil: updates die de database aanpassen
Hier zit het echte risico. Sommige plugins voeren bij een grote versiesprong een aanpassing aan de database uit: velden hernoemen, tabellen omzetten, gegevens verplaatsen. Een webshopplugin die de opslag van bestellingen wijzigt is daar het bekendste voorbeeld van.
Zet u dan alleen de bestanden terug, dan draait de oude versie op een database die al is omgezet. Het gevolg is niet altijd een duidelijke foutmelding; soms verdwijnen er stilletjes gegevens uit beeld of worden ze verkeerd gelezen. Dat is de meest verraderlijke vorm van schade, omdat u het pas dagen later merkt.
Praktische regel: gaat het om een sprong tussen hoofdversies, bijvoorbeeld van 3 naar 4, lees dan eerst de wijzigingsnotities voordat u terugzet. Staat daar iets over een aanpassing aan de database, zet dan bestanden én database samen terug, of laat de nieuwe versie staan en los het probleem vooruit op. Kleine versiesprongen zijn vrijwel altijd veilig terug te zetten.
Wat u doet nadat het weer werkt
Terugzetten is geen oplossing, het is uitstel. De oude versie krijgt geen beveiligingsherstel meer zodra er een nieuwe uitgave is, dus u wilt binnen enkele weken alsnog vooruit. Werk deze punten af.
- Noteer wat er misging, met versienummer en de foutmelding of het gedrag dat u zag. Zonder aantekening staat u over drie maanden weer op hetzelfde punt.
- Zet de plugin op handmatig bijwerken, zodat hij niet vanzelf terugspringt.
- Probeer de nieuwe versie in een kopie van de site. Daar mag hij stuk.
- Zoek de oorzaak. Meestal is het een conflict met een andere plugin, een aanpassing in uw thema die op de oude versie leunde, of een PHP-versie die niet meer past.
- Meld het bij de maker. Een goed onderbouwde melding met versienummers levert vaak binnen een paar weken een herstelversie op.
- Werk daarna alsnog bij, met een back-up klaar en op een moment dat u tijd heeft.
Een adviesbureau dat wij overnamen had drie plugins op een oude versie staan, elk ooit teruggezet na een storing en daarna vergeten. Twee ervan hadden inmiddels een bekend lek. Terugzetten had toen goed geholpen; het niet oppakken van het vervolg kostte uiteindelijk een middag opruimwerk.
Voorkomen is hier echt eenvoudiger
Twee gewoontes halen het grootste deel van dit werk weg. De eerste: leg vlak voor elke updateronde een terugzetbaar moment vast. De tweede: werk plugins in kleine groepjes bij en kijk telkens of de site nog doet wat hij moet doen. Vinkt u alles tegelijk aan, dan weet u bij een storing niet welke plugin het was.
Voor sites waar omzet doorheen loopt, gaat een grote versiesprong eerst naar een testomgeving. Dat is precies de reden dat in vast beheer met een vaste updateronde een testmoment zit ingebouwd; het scheelt geen euro’s aan licenties maar wel uren aan herstel.
Concrete volgende stap: kijk in uw pluginoverzicht of er plugins bij zitten die al maanden niet zijn bijgewerkt terwijl er wel een nieuwe versie klaarstaat. Dat is meestal een plugin die ooit is teruggezet en daarna is blijven liggen.
