Bijgewerkt op 14 min leestijd

Automatische updates van WordPress: inschakelen of uitschakelen?

Sébastien Nobour

Oprichter van DEVEDANOS

Praktijken

Laat u WordPress zijn updates zelf installeren, of schakelt u ze uit? Voor plugins en thema’s raden wij de automatische updates af die WordPress zelf toepast, zonder enige test. Die van een hostingprovider die elke update test voordat hij die toepast, en kan terugkeren naar de vorige versie, zijn wel geschikt: naar ons idee volstaan die controles bij WordPress over het algemeen om te zien dat er iets niet klopt. Zonder zo’n hostingprovider werkt u één plugin, of één thema, tegelijk bij, en controleert u daarna of die geen storing veroorzaakt; bij een probleem gaat u terug naar de vorige versie.

Het Britse NCSC, het nationale centrum voor cyberbeveiliging, vraagt alle organisaties “software-updates zo snel mogelijk te installeren, en idealiter automatisch”, omdat aanvallers vaak een gepatchte kwetsbaarheid bestuderen om er een exploit voor te schrijven; volgens Amazon maakt AI dat werk goedkoper. Het NCSC wijst erop dat de maker zijn updates zelf test, maar vraagt ze ook op de eigen systemen te testen en ze gefaseerd uit te rollen. Voor software die u installeert en ongewijzigd gebruikt (Windows, macOS, een telefoon, een browser, kantoorsoftware), raden wij dus aan de automatische updates van die software in te schakelen. Bij een onlinedienst is het de leverancier die de patches installeert. Een WordPress-site valt in geen van beide categorieën: de eigenaar ontwikkelt de software niet en gebruikt haar ook niet ongewijzigd, hij stelt haar samen en configureert haar.

De maker van een besturingssysteem test zijn updates voor het hele systeem. De update van een WordPress-plugin daarentegen kan niet vooraf worden getest met alle andere plugins die op uw site staan.

Waarom wij de updates afraden die WordPress zelf toepast

WordPress wordt in oktober 2026 gebruikt door bijna vier op de tien websites, en de meeste kwetsbaarheden zitten niet in WordPress zelf. Volgens Patchstack werden in 2025 11.334 nieuwe kwetsbaarheden gevonden in het WordPress-ecosysteem: 91 % in plugins, 9 % in thema’s, en maar 6 in de kern van WordPress. En voor 46 % van die kwetsbaarheden had de ontwikkelaar op het moment van publicatie nog geen patch uitgebracht (Patchstack). Deze cijfers komen van een bedrijf dat bescherming tegen deze kwetsbaarheden verkoopt.

Die updates installeren een nieuwe versie kort na het verschijnen ervan, voordat iemand er een probleem in heeft kunnen melden: kwaadaardige code die in een net gepubliceerde versie is gesmokkeld, of een nieuwe kwetsbaarheid. De site is daardoor niet per se beter beschermd. WordPress.org houdt daar rekening mee: sinds 5 juni 2026 wacht elke nieuwe pluginversie uit de plugindirectory tot 24 uur voordat de automatische updates haar verspreiden, zodat iedereen de tijd heeft de wijzigingen te bekijken. Bovendien combineert een WordPress-site de kern van WordPress, een PHP-versie, en plugins en thema’s van auteurs die los van elkaar werken. Niets garandeert dat de nieuwe versie van een plugin werkt met de versie van een andere, of met de PHP-versie van de server. Toch zet WordPress haar in productie zonder dat een test of een mens heeft gecontroleerd of de site nog werkt.

Een hostingprovider die elke update test voordat hij die toepast, en kan terugkeren naar de vorige versie, kan dat automatisch van u overnemen (zie hieronder). Zonder zo’n hostingprovider blijft de methode hetzelfde, of u het nu zelf doet of een dienstverlener dat voor u doet. Ze begint met een back-up: WordPress vraagt de bestanden en de database te back-uppen vóór elke update, automatisch of handmatig. Daarna werkt u één plugin, of één thema, tegelijk bij, en controleert u na elke update of die geen storing veroorzaakt. Bij een probleem gaat u terug naar de vorige versie door de back-up terug te zetten: eerst de bestanden, daarna de database.

Voor een applicatie op maat leggen wij de exacte versie van elke dependency vast, en gaat elke update, één tegelijk, door de deployment-pipeline en zijn geautomatiseerde tests voordat hij de productie bereikt. Deze regel komt uit “Continuous Delivery” (Continue oplevering), van Jez Humble en Dave Farley, en uit de Top 10-lijsten van OWASP, de toonaangevende stichting voor de beveiliging van webapplicaties. Dave Farley is de bedenker van de deployment-pipeline, vaak CI/CD-pipeline genoemd. De deployment-pipeline is de geautomatiseerde keten die elke wijziging in de code oppakt, test, vastlegt en klaarzet om naar productie te gaan. Voor een WordPress-site zijn vastgezette versies, een pipeline en geautomatiseerde tests moeilijk toe te passen. Ze zijn de moeite waard wanneer de site meer op een applicatie gaat lijken, met code die op maat is geschreven: dat is het geval dat hieronder wordt beschreven.

Wat WordPress standaard doet

Standaard installeert WordPress maar een deel van zijn updates zelf. Op dit moment (oktober 2026) worden sinds WordPress 3.7 de kleine updates van de kern standaard automatisch geïnstalleerd (WordPress). Voor plugins en thema’s moeten automatische updates sinds WordPress 5.5 één voor één worden ingeschakeld, en WordPress voert ze dan twee keer per dag uit. Voor de grote updates van de kern hangt de standaardinstelling af van de datum waarop de site is geïnstalleerd (zie hieronder). Dezelfde pagina van WordPress begint met deze zin: “Om uw WordPress-site veilig te houden, moet u uw plugins en thema’s altijd bijwerken naar hun nieuwste versie” (WordPress).

Patchstack mat in 2025 een mediane tijd van vijf uur tussen de publicatie van een veel misbruikte kwetsbaarheid en het eerste misbruik. Meldingen laten zich automatiseren; de beslissing om bij te werken neemt een mens, en wel zodra de melding binnenkomt. Op een WordPress-site start de beheerder de update van een plugin met één klik, en controleert hij daarna of de site werkt. Heeft het bedrijf niemand die dat doet, dan kan een dienstverlener het overnemen, zoals we hieronder beschrijven.

Twee andere factoren tellen even zwaar. Omdat in 2025 bijna de helft van de kwetsbaarheden in het WordPress-ecosysteem op de dag van publicatie geen patch had, dekt geen enkel updatebeleid, automatisch of handmatig, ze op die dag. Minder geïnstalleerde plugins betekent minder mogelijke kwetsbaarheden, zoals bij elke dependency van een applicatie. En een plugin die door zijn auteur is verlaten, krijgt geen patches meer: die vervangt u.

Automatische updates van WordPress in- of uitschakelen

Voor plugins en thema’s raden wij aan de automatische updates uit te schakelen; voor de kern van WordPress, alleen de kleine updates vanzelf te laten installeren.

Op dit moment (oktober 2026) stelt u de automatische updates van plugins en thema’s één voor één in, vanuit het beheerpaneel. In het scherm Plugins toont de kolom “Automatische updates” bij elke plugin een link die de updates ervan in- of uitschakelt; met een bulkactie doet u dat voor meerdere plugins tegelijk. Voor een thema staat de link in het scherm Weergave, in het venster dat opengaat wanneer u op de miniatuur van het thema klikt. Verschijnen die links niet, dan is de functie waarschijnlijk uitgeschakeld door de hostingprovider of door een plugin.

Voor de kern van WordPress hangt de standaardinstelling af van de datum waarop de site is geïnstalleerd. Sinds WordPress 5.6 krijgen nieuwe installaties automatisch zowel de kleine als de grote updates; een oudere installatie houdt haar instelling, en krijgt standaard alleen de kleine updates. In het scherm Updates van het beheerpaneel kunt u die instelling wijzigen.

De kleine updates van de kern dichten kwetsbaarheden en verzorgen het onderhoud, en WordPress noemt het uitschakelen ervan “sterk afgeraden”. De grote updates brengen nieuwe functionaliteiten; naar ons idee gaan ze net als die van plugins en thema’s: één tegelijk, waarna u controleert of de site werkt.

Voor uw technische team

In wp-config.php bepaalt de constante WP_AUTO_UPDATE_CORE wat de kern zelf installeert, en ze gaat vóór de instelling in het scherm Updates: true voor alle updates, 'minor' voor alleen de kleine updates, false voor geen enkele (WordPress). De constante AUTOMATIC_UPDATER_DISABLED schakelt alle automatische updates uit, ook die van de kern en de vertalingen. Naar ons idee is die constante alleen zinvol als elke update van de kern op een andere manier wordt getest, zoals met Bedrock, hieronder beschreven.

// In wp-config.php: de kern installeert zelf alleen zijn kleine updates
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Voor plugins en thema’s beslissen de filters auto_update_plugin en auto_update_theme in plaats van de links in het beheerpaneel. WordPress raadt aan deze filters in een must-use-plugin te zetten, en nooit rechtstreeks in wp-config.php. Een must-use-plugin staat in de map wp-content/mu-plugins, wordt vanzelf geactiveerd en kan niet vanuit het beheerpaneel worden gedeactiveerd.

<?php
// wp-content/mu-plugins/disable-plugin-theme-auto-updates.php

/**
 * Plugin Name: Disable plugin and theme auto-updates
 */

defined( 'ABSPATH' ) || exit;

// Schakelt de automatische updates van alle plugins en alle thema's uit
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

Een automatische update van WordPress is mislukt: wat nu?

Tijdens een update zet WordPress de site in onderhoudsmodus: het maakt een bestand .maintenance aan in de hoofdmap van de site, en bezoekers zien een melding over gepland onderhoud. Wordt de update onderbroken, dan blijft het bestand staan, en de melding ook. WordPress beschrijft wat u dan doet:

  1. Verwijder het bestand .maintenance uit de hoofdmap van de site, via FTP of via het bestandsbeheer van de hostingprovider. De melding verdwijnt.
  2. Start de update opnieuw. Mislukt ze weer, voer haar dan met de hand uit, volgens de procedure van WordPress.
  3. Werkt de site na de update niet meer, zet dan de back-up terug: eerst de bestanden, daarna de database.

De laatste stap veronderstelt een recente back-up waarvan het terugzetten al eens is uitgeprobeerd: WordPress vraagt dat te controleren voordat u de automatische updates van plugins inschakelt.

Zijn plugins of thema’s automatisch bijgewerkt, dan krijgt de eigenaar van de site een e-mail, ook als sommige updates zijn mislukt. Ook voor de kern meldt een e-mail dat de update is mislukt. In het beheerpaneel ziet de melding er zo uit: “Een geautomatiseerde WordPress update is niet voltooid - probeer de update nu opnieuw”.

Starten de automatische updates nooit, kijk dan naar de foutmeldingen in het scherm Tools > Sitediagnose: de updates werken met de geplande taken van WordPress, die niet op elke server goed worden uitgevoerd.

Wie werkt PHP bij, en wie verzorgt het onderhoud?

Updates van WordPress werken alleen WordPress bij, nooit PHP: afhankelijk van uw hosting installeert de hostingprovider de PHP-patches, of doet u dat zelf. Wij raden aan een hostingprovider te kiezen die dat voor u doet, en hem vooraf te vragen wie de patches installeert op uw hostingpakket, en hoe snel.

Voor een WordPress-site hoeft u dit onderhoud niet zelf te verzorgen. Hostingproviders die gespecialiseerd zijn in WordPress zorgen voor de updates van de serversoftware, waaronder PHP, en voor automatische back-ups. De beveiligingsgids van WordPress beschrijft de betrouwbare hostingprovider: die “levert de meest recente stabiele versies van alle serversoftware” en “betrouwbare methoden voor back-up en herstel”, en praat graag over de beveiligingsmaatregelen die hij biedt.

Een pakket met beheerde WordPress-hosting werkt PHP en WordPress doorgaans voor u bij. Sommige pakketten werken ook de plugins automatisch bij. De methode verandert daardoor niet: de hostingprovider werkt één plugin tegelijk bij, controleert de site na elke update, en kan terugkeren naar de vorige versie. Dat is de automatische optie die wij aanvaardbaar vinden: bij WordPress volstaan die controles over het algemeen om te zien dat er iets niet klopt.

Betaalde plugins of plugins met een licentiesleutel, en plugins die voor de site zijn geschreven, blijven doorgaans uw verantwoordelijkheid. Elk daarvan werkt u bij volgens de methode die hierboven is beschreven: één tegelijk, waarna u controleert of de functionaliteit die de plugin toevoegt niet is achteruitgegaan, en terugkeert naar de vorige versie als dat wel zo is.

Stel een hostingprovider ook deze vragen voordat u voor hem kiest:

  • Werkt u één plugin tegelijk bij, met een controle na elke update?
  • Test u de updates op een kopie van de site voordat u ze toepast?
  • Hoe zet ik een back-up terug?

Wilt u de plugins en thema’s niet zelf bijwerken, vertrouw die taak dan toe aan iemand die de site en de server ervan beheert. De methode blijft dezelfde: één plugin tegelijk, een controle na elke update, terug naar de vorige versie bij een regressie, en PHP bijgewerkt wanneer de hostingprovider dat niet doet. Wij kunnen dat voor u doen: neem contact met ons op.

Als de site maatwerkcode bevat

Ook een applicatie op maat wordt bijgewerkt na een bewuste beslissing. Elke update, van PHP of van een component, gaat door de deployment-pipeline en zijn geautomatiseerde tests; de patch voor een ernstige kwetsbaarheid gaat nog op de dag van publicatie naar productie.

Voor uw technische team

Alles verandert op de dag dat u de code moet aanraken. De eerste regel van WordPress geldt voor iedereen: “raak de kern van WordPress niet aan”, omdat elke update de bestanden ervan overschrijft; wat u wilt toevoegen of wijzigen, gaat via een plugin. Bij een thema kunt u met een child-thema het thema aanpassen zonder de code ervan aan te raken, en toch de updates blijven ontvangen. Die maatwerkcode, child-thema of plugin, is software die u ontwikkelt. In “Continuous Delivery” vragen Jez Humble en Dave Farley alles wat dient om de software te bouwen en te deployen onder versiebeheer te houden, en elke wijziging door de deployment-pipeline te laten gaan. Concreet staat die code in een Git-repository en gaat ze via de pipeline naar productie, nooit met de hand naar de server gekopieerd.

Niemand hoeft de kern van WordPress aan te passen. Wat een standaardinstallatie mist, zit ergens anders. Plugins worden geïnstalleerd vanuit het beheerpaneel, zonder dat hun versies ergens worden vastgelegd, en de configuratie staat in één bestand, hetzelfde voor alle omgevingen. U kunt de site die in productie staat dus niet identiek nabouwen op een testomgeving, terwijl Jez Humble en Dave Farley dat wel vragen. Dat gat vult Bedrock, van Roots. Het past de kern van WordPress niet aan: het legt er een laag omheen. WordPress, de plugins en de thema’s worden er dependencies, die Composer in een precieze versie installeert en vergrendelt in composer.lock. De configuratie verschilt per omgeving (ontwikkeling, acceptatie, productie) via omgevingsvariabelen. De Git-repository bevat alleen nog de maatwerkcode, de configuratie en de lijst van dependencies, en volgens Roots kunnen de kern en de plugins buiten de ontwikkelomgeving niet meer worden gewijzigd. Roots presenteert deze opzet als de toepassing op WordPress van de methode “The Twelve-Factor App” (de applicatie in twaalf factoren), die beschrijft hoe u webapplicaties bouwt die makkelijk te deployen en te onderhouden zijn. Updates gebeuren dan in de code, één plugin tegelijk, en gaan daarna door de pipeline. De standaardconfiguratie van Bedrock schakelt op dit moment de automatische updates en het installeren van plugins vanuit het beheerpaneel uit (config/application.php).

Naar ons idee is Bedrock de moeite waard zodra een WordPress-site als software wordt onderhouden: maatwerkcode, meerdere omgevingen, een ontwikkelteam, een pipeline. Voor een site die u configureert, met een child-thema of een plugin erbij, is het niet nodig. En Bedrock organiseert het project, meer niet: de kwaliteit van de maatwerkcode blijft de zaak van wie haar ontwikkelt.

// config/application.php van Bedrock, standaardconfiguratie
// Schakelt de automatische updates van WordPress uit
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Schakelt de bestandseditor in het beheerpaneel uit
Config::define('DISALLOW_FILE_EDIT', true);
// Verbiedt het installeren of bijwerken van plugins vanuit het beheerpaneel
Config::define('DISALLOW_FILE_MODS', true);

# Met Bedrock: één plugin bijwerken, in de code, en daarna via de pipeline
composer update wp-plugin/plugin-name

Zonder Bedrock raadt de gids van WordPress over het versterken van de beveiliging aan de bestandseditor in het beheerpaneel uit te schakelen, waarmee standaard de PHP-code van plugins en thema’s kan worden gewijzigd; de gids benadrukt dat dit niet alles tegenhoudt, maar sommige aanvallen wel kan stoppen (WordPress):

// In wp-config.php: schakelt de bestandseditor in het beheerpaneel uit
define( 'DISALLOW_FILE_EDIT', true );

Om één plugin tegelijk bij te werken, houdt u met WP-CLI, de opdrachtregeltool van WordPress, de controle: wp plugin update accepteert --version om een precieze versie te kiezen, --patch om alleen de bugfixes te nemen, en --dry-run om te zien wat er zou worden bijgewerkt zonder iets te wijzigen (WP-CLI). De documentatie van WordPress zelf noemt aanpassingen en het vooraf testen op een acceptatieomgeving als redenen om automatische updates uit te schakelen, en vraagt, voordat u ze voor plugins inschakelt, dat u kunt terugkeren naar de vorige versie van de site.

WordPress-website beveiligen

Ook op een WordPress-site mag niemand de code via de site zelf kunnen wijzigen, en krijgt elk programma alleen de rechten die het nodig heeft. WordPress voorziet hierin: alleen de map met geüploade content (wp-content) hoeft door de webserver te kunnen worden gewijzigd, en de code-editor in het beheerpaneel, volgens WordPress vaak “het eerste hulpmiddel dat een aanvaller gebruikt als hij erin slaagt in te loggen”, kan worden uitgeschakeld.

Voor uw technische team

De beveiligingsgids van WordPress raadt ook aan: MySQL-gebruiker beperkt tot het lezen en schrijven van gegevens (de rechten DROP, ALTER en GRANT kunnen worden ingetrokken, met in het achterhoofd dat sommige updates het schema wijzigen); wp-config.php met bestandsrechten 400 of 440; DISALLOW_FILE_EDIT, hierboven beschreven; een webapplicatiefirewall, waarbij ModSecurity wordt genoemd als de meest gebruikte opensource-optie.

Hoe wij werken

Voor de applicaties die wij ontwikkelen, leggen we elke dependency vast op de exacte versie, controleren we elke dag of een bekende kwetsbaarheid de gebruikte componenten treft, en monitoren we de servers.

Een WordPress-site wordt een applicatie zodra gebruikers er hun eigen gegevens aanmaken, wijzigen en bewaren, en de site bedrijfsregels op die gegevens toepast: bestellingen via WooCommerce, een ledenomgeving, reserveringen die afhangen van beschikbaarheid. Voor zulke applicaties vallen updates en beveiligingspatches, net als voor maatwerkapplicaties, onder het onderhoud dat in ons aanbod is inbegrepen: software op maat met een vast maandbudget, met een nulregressiegarantie.

Verder lezen

Op 21 oktober 2026 bracht het PHP-team met spoed nieuwe versies van de taal uit. Die dichten twee kritieke kwetsbaarheden, die hun ontdekkers PHP2Shell hebben gedoopt. Ons artikel over PHP2Shell legt uit wie risico loopt, wat u doet, in welke volgorde, en hoe u de schade van misbruik beperkt.

Wilt u een applicatie laten ontwikkelen, of weer grip krijgen op een bestaande? Zullen we erover praten?

Bronnen

Lees ook

Shadow IT: betekenis, risico's en voorbeelden

Wat is shadow IT? De definitie van het Britse centrum voor cyberbeveiliging, voorbeelden (Excel, AI-tools), de risico's voor het bedrijf, en waarom het antwoord een tool is die bij het werk past.

Kwetsbaarheden: zo beschermt u uw applicaties

Een webapplicatie beschermen, in welke taal ze ook is geschreven: beperken waar een kwetsbaarheid toegang toe geeft, direct gewaarschuwd worden, dependencies controleren, elke kritieke patch installeren op de dag dat hij verschijnt.