Automatische updates van WordPress core configureren (WP_AUTO_UPDATE_CORE)

Sinds WordPress 3.7 werkt het platform delen van zichzelf automatisch bij zonder dat iemand iets aanklikt. De meeste site-eigenaren zijn zich hier vaag van bewust, maar weinigen hebben een duidelijk beeld van wat er precies wordt bijgewerkt, wanneer en hoe de standaardinstelling te wijzigen. Deze gids gaat door de vier niveaus van automatische updates die WordPress core ondersteunt, wat elk niveau daadwerkelijk doet en welke de juiste keuze is, afhankelijk van of u een enkele site, een bureauportfolio of een beheerde hostingsetup beheert.

Wat WordPress standaard automatisch bijwerkt

Standaard doet elke WordPress-installatie in 2026 het volgende zonder te vragen:

• Kleine core-updates. Van 6.5.1 naar 6.5.2 gaan gebeurt automatisch, op de achtergrond, op dezelfde dag als de release wordt gepubliceerd. Deze releases zijn bugfixes en beveiligingspatches. Ze zijn expliciet ontworpen om veilig te installeren zonder te testen.
• Updates van vertaalbestanden. Taalpakketten worden automatisch ververst.
• Core-beveiligingsreleases voor oudere branches. Zelfs als uw site nog op 6.4 staat omdat u geen grote update hebt uitgevoerd, worden beveiligingsfixes terug-geport en automatisch toegepast.

Wat niet standaard automatisch gebeurt:

• Grote core-updates. Van 6.5 naar 6.6 gaan vereist een handmatige klik. WordPress toont de banner in de admin maar installeert het niet uit zichzelf.
• Plug-in- en thema-updates. Beide kunnen per item worden ingeschakeld via de admin-UI (sinds WordPress 5.5), maar geen van beide staat standaard aan. Ze zijn een apart onderwerp en worden niet bestuurd door WP_AUTO_UPDATE_CORE.

De reden voor deze splitsing is goed engineering: kleine releases worden gepubliceerd onder een strikt beleid van "geen breaking changes", dus stilletjes bijwerken is werkelijk laag risico. Grote releases introduceren af en toe nieuwe API's of veranderen gedrag waarvan thema's en plug-ins afhankelijk kunnen zijn, en stilletjes een grote versie verhogen op productie heeft historisch gezien voldoende breuk veroorzaakt dat het project voor de conservatieve standaard heeft gekozen.

De vier niveaus van automatische core-updates

De constante WP_AUTO_UPDATE_CORE in wp-config.php regelt dit alles. Hij accepteert vier waarden:

• true: Alle core-updates worden automatisch geïnstalleerd, zowel klein als groot. De agressieve optie.
• 'minor': De standaard als de constante helemaal niet is gedefinieerd. Alleen kleine en beveiligingsreleases worden automatisch geïnstalleerd. Grote releases blijven handmatig.
• 'beta' en 'rc': Gebruikt door sites die pre-releasebuilds willen. Realistisch alleen op een staging- of testomgeving, nooit op productie.
• false: Alle automatische core-updates zijn uitgeschakeld. De site doet niets uit zichzelf. U bent verantwoordelijk voor elke patch, inclusief beveiligingsfixes.

Een van deze instellen is een enkele regel in wp-config.php, ergens boven het commentaar /* That's all, stop editing! Happy publishing. */:

define('WP_AUTO_UPDATE_CORE', true);

of

define('WP_AUTO_UPDATE_CORE', 'minor');

Sla het bestand op, geen herstart nodig. WordPress controleert op updates volgens een schema (standaard tweemaal per dag) en past toe wat de huidige instelling toelaat.

Welke instelling is logisch voor welk soort site?

Het eerlijke antwoord hangt af van drie dingen: hoeveel testen er gebeurt voordat een release live gaat, wie het opmerkt wanneer er iets breekt, en hoe goed de back-upstrategie is.

Standaard productiesite, geen toegewijd onderhoudscontract

Aanbevolen instelling: true (alle updates automatisch).

De intuïtie dat "automatische grote updates gevaarlijk zijn" is grotendeels achterhaald. Grote WordPress-updates zijn al jaren stabiel, en het realistische alternatief is "niemand werkt de site zes maanden bij omdat er geen contract voor is, en een bekend beveiligingsgat blijft open". Een onderhouden WordPress-site is een slechtere uitkomst dan de zeer zeldzame automatische update die iets breekt. Als een grote release de site breekt, is herstellen vanuit een back-up sneller dan de tijd die u anders zou besteden aan het later achternajagen van de handmatige update. De automatisering is de winst.

Beheerde hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Aanbevolen instelling: wat het dashboard van de host doet, meestal 'minor' op WordPress-niveau.

De meeste beheerde hosts draaien hun eigen updateflow bovenop WordPress. Ze maken eerst een snapshot, installeren de grote release op een staging-kloon, voeren een basaal visueel verschil uit en passen het pas dan toe op productie. Dat is aanzienlijk veiliger dan vanille auto-updates. Als u op dit type host zit, vecht het instellen van WP_AUTO_UPDATE_CORE op iets anders dan de standaard meestal met de eigen logica van de host. Laat het met rust, laat de host zijn werk doen, en controleer het hostdashboard voor de updategeschiedenis.

Bureauportfolio met een onderhoudscontract

Aanbevolen instelling: 'minor' op productie, true op staging.

Als een onderhoudscontract specificeert dat u updates test voordat ze live gaan, is het bureau het vangnet. Productie zou nog steeds automatisch kleine en beveiligingsreleases moeten krijgen (die zijn niet optioneel vanuit beveiligingsoogpunt), maar grote updates gaan door de testflow van het bureau. Stagingomgevingen zijn de juiste plek om de meer agressieve waarde in te stellen, zodat testers vroeg breuk vangen.

Aangepaste WordPress-build met zware thema- of plug-in-aanpassingen

Aanbevolen instelling: 'minor', plus een echt testproces voor grote updates.

Sites die zwaar zijn aangepast (herbouwde koptekst, aangepaste Gutenberg-blokken, vreemde page builder-integraties, aangepaste REST-endpoints) zijn precies het geval waarin een grote update iets subtiels kan breken. De standaardinstelling 'minor' is de juiste ondergrens: geef de beveiligingspatches niet op, maar behandel grote releases als een aparte taak met een echte testronde.

Hoogbeschikbare site die absoluut niet mag breken

Aanbevolen instelling: false voor core, plus een echt releaseproces.

Dit is het enige geval waarin het volledig uitschakelen van automatische core-updates zinvol is. Bankieren, gezondheidszorg, gereguleerde omgevingen waar elke wijziging door een releaseproces gaat. Merk op dat u volledige verantwoordelijkheid accepteert voor het binnen uren na een release handmatig toepassen van beveiligingspatches, op elke site. De meeste teams die deze instelling kiezen, hebben ook monitoring op de WordPress-beveiligingsmailinglijst en een deploymentpipeline die patches dezelfde dag kan verzenden.

Hoe verifieert u dat uw instelling actief is

1. Ga in de WordPress-admin naar Hulpmiddelen, Site Health, Info.
2. Vouw de sectie WordPress-constanten uit.
3. Zoek naar WP_AUTO_UPDATE_CORE. Als deze uw waarde toont, wordt de constante uitgelezen.
4. Voor een diepere controle, kijk naar Updates in de adminzijbalk. Recente automatische updates verschijnen daar met tijdstempels.

Als de constantewaarde niet in Site Health verschijnt, is de meest waarschijnlijke oorzaak dat deze later is ingesteld nadat het bestand deze al eerder had gedefinieerd (de eerste define wint, en PHP genereert een melding die u mogelijk niet ziet), of dat u de verkeerde wp-config.php hebt bewerkt.

Wat er mis kan gaan met automatische core-updates

Drie storingsmodi zijn realistisch en de moeite waard om te kennen:

• Update mislukt deels. Het downloaden of uitpakken breekt halverwege, vaak omdat de host niet genoeg schijfruimte heeft, een inode-limiet heeft bereikt of vanwege een tijdelijk netwerkprobleem. WordPress laat een .maintenance-bestand achter in de root en de site toont voor altijd "Even niet beschikbaar voor gepland onderhoud". Oplossing: SFTP naar de root en verwijder het .maintenance-bestand, voer daarna de update opnieuw uit vanuit de admin.
• Update slaagt maar een plug-in begint fouten te genereren. Vooral na een grote update kan een onderhouden plug-in breken tegen nieuwe core-API's. Oplossing: zorg voor een back-up, identificeer de gebroken plug-in vanuit het foutenlogboek (of door plug-ins een voor een te deactiveren), en werk de plug-in bij of vervang deze.
• Update wordt stilletjes overgeslagen. Veelvoorkomende redenen: DISALLOW_FILE_MODS is ingesteld in wp-config.php (wat alle updates blokkeert, automatisch of niet), bestandsrechten op de WordPress-map verhinderen PHP om te schrijven, of de site gebruikt Git voor versiebeheer en WordPress detecteert de .git-map en schakelt updates uit als veiligheidsmaatregel. De Site Health-pagina markeert deze gevallen meestal.

Auto-updates en DISALLOW_FILE_MODS

De twee constanten interageren op een manier die mensen verrast. DISALLOW_FILE_MODS (behandeld in onze kennisbank onder het onderwerp bestandseditor) blokkeert alle bestandswijzigingen vanuit de WordPress-kant, inclusief automatische core-updates. Als beide constanten zijn ingesteld:

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

Het resultaat is dat DISALLOW_FILE_MODS wint. WordPress zal niets automatisch bijwerken. Dit is zelden wat mensen bedoelen. Of u wilt een afgeschermde site die van buitenaf wordt bijgewerkt (deploypipeline, WP CLI), in welk geval DISALLOW_FILE_MODS = true juist is en WP_AUTO_UPDATE_CORE irrelevant. Of u wilt dat de site zichzelf bijwerkt, in welk geval DISALLOW_FILE_MODS niet ingesteld zou moeten zijn.

Hoe zit het met automatische plug-in- en thema-updates?

Automatische plug-in- en thema-updates zijn een afzonderlijk mechanisme dat in WordPress 5.5 is geland. Ze worden per item geconfigureerd in de admin (lijst Plug-ins, de link "Auto-updates inschakelen" in elke rij) of globaal via filters. De algemene aanbeveling: schakel auto-updates in voor elke plug-in waarvan u de releasediscipline van de onderhouder vertrouwt, laat ze uit voor plug-ins die regelmatig breaking changes uitbrengen. Vooral grote WooCommerce-releases zijn vaak de moeite waard om vast te houden voor een handmatige update met een snelle test.

Als u programmatisch automatische plug-in-updates voor elke plug-in wilt inschakelen, doet dit filter het:

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Plaats dat in een kleine must-use-plug-in onder wp-content/mu-plugins/ in plaats van in functions.php, zodat een themawisseling het niet uitschakelt.

De bottom line voor core-updates: voor de meeste sites in 2026 is de standaardinstelling 'minor' conservatief in de verkeerde richting. Stel WP_AUTO_UPDATE_CORE in op true en laat het platform zichzelf actueel houden, of verbind u tot een echt onderhoudsproces dat grote releases handmatig binnen redelijke tijd afhandelt. De middenweg van "standaardinstellingen plus niemand kijkt mee" is wat onbeveiligde WordPress-sites produceert die twee versies achterlopen, en dat is de werkelijke hoogrisicostatus.