WordPress automatische updates onder controle krijgen

Vanuit het dashboard ziet WordPress's automatische update-systeem er simpel uit. Eronder zit een gelaagd mechanisme met vier bewegende delen: de auto_update_$type filter-familie die er al is sinds WordPress 3.7 in oktober 2013, de per-plugin en per-thema site option-arrays die in WordPress 5.5 in augustus 2020 zijn toegevoegd, de UI voor major core auto-updates uit WordPress 5.6 in december 2020, en een handvol constantes in wp-config.php die de hele zaak overrulen. Weten welke hendel je waar omtrekt is belangrijk, want aan de verkeerde hendel trekken op de verkeerde laag is precies hoe sites zonder security-patches eindigen.

Dit artikel gaat ervan uit dat je shell-toegang hebt tot de server (of in elk geval bij wp-config.php en wp-content/ kunt), PHP kunt bewerken en op WordPress 5.6 of nieuwer draait. Heb je alleen wp-admin? Gebruik dan de per-plugin- en per-thema-toggles die in 5.5 zijn toegevoegd; de rest van dit artikel gaat je niet helpen.

Hoe WordPress automatische updates écht werken

Auto-updates draaien via een WP-Cron event. Wanneer een uitgelogde bezoeker een willekeurige pagina raakt, vuurt WordPress op de achtergrond de wp_version_check-actie af. Die functie staat beschreven in de wp_version_check() reference en is geïntroduceerd in WordPress 2.3.0. Hij belt naar api.wordpress.org, haalt beschikbare updates op en triggert vervolgens de wp_maybe_auto_update-actie. Daarna loopt WP_Automatic_Updater::run() (zie de WP_Automatic_Updater class reference) elke openstaande core-, plugin-, thema- en vertalingsupdate af en stelt per item één vraag: moet deze update automatisch installeren?

Het antwoord komt van het dynamische auto_update_{$type} filter, waar $type core, plugin, theme of translation is. Het filter krijgt twee parameters mee: een boolean (of null als nog niemand een beslissing heeft genomen) en het update-offerobject. Wat het filter teruggeeft, eert de updater. Dat ene filter is de stam waar het hele systeem aan hangt.

De eerste praktische implicatie: WP-Cron moet wel daadwerkelijk afgaan. WP-Cron in WordPress is geen echte cron-daemon. Het draait meeliftend op gewoon HTTP-verkeer. Dus op sites met weinig bezoekers, of op sites waar de loopback naar wp-cron.php wordt geblokkeerd door een firewall, BasicAuth of een verkeerd geconfigureerde cache, stoppen auto-updates stilletjes. De WP Crontrol-uitleg over missed cron events beschrijft de faalmodi netjes. Vuurt wp_version_check niet, dan draait er ook geen enkele auto-update, hoe je filters en constantes ook staan.

De tweede implicatie: het systeem heeft meerdere lagen aan controle, en die evalueren in een specifieke volgorde. De WP_Automatic_Updater-class checkt eerst of updates compleet zijn uitgezet (via de AUTOMATIC_UPDATER_DISABLED-constante of het automatic_updater_disabled-filter), dan of de directory een version-control checkout is, dan pas evalueert hij auto_update_$type. Wat eerder in die keten zit, kortsluit alles erna. Daarom is de verkeerde laag aanpakken zo zwaar: AUTOMATIC_UPDATER_DISABLED = true legt de héle pijp eraf, inclusief de security-patches die je vrijwel zeker wél wilt.

Referentie: elke constante, elk filter, elke site option

De volgende tabel is het volledige oppervlak om WordPress auto-updates te besturen, gemeten op WordPress 6.7. Gebruik hem als naslag; de scenario's hieronder laten zien hoe je de juiste rijen combineert tot een werkende configuratie.

Filter-precedence in één zin. Een returnwaarde van auto_update_plugin of auto_update_theme overruled wat de gebruiker in wp-admin heeft aangevinkt. De WordPress 5.5-aankondiging zegt het bot: "Any value returned using these filters will override all auto-update settings selected in the admin (and super admin). Changes made using these filters also will not be reflected to the user in the interface." Die laatste zin is de valkuil. Heeft een developer ooit een filter op een klant-site gezet en zet vervolgens een junior-admin de UI-toggle om? Dan doet die toggle stilletjes niets.

Scenario A: de site dichttimmeren (geen auto-updates van wat dan ook)

Dit is de configuratie die ik het minst vaak schrijf, want hij wijst bijna altijd op een misverstand. De hele auto-updater uitzetten betekent dat je geen minor core-releases meer ontvangt, en dat zijn precies de releases waar de security-patches in zitten. Het WordPress security-team is daar duidelijk over: minor releases zijn het kanaal voor security-leveringen.

Gebruik dit alleen als:

• Je WordPress via Composer deployt (Bedrock, project-managed dependencies) en je CI-pipeline updates beheert.
• Je site via een managed-update-dienst draait, zoals Kinsta beschrijft in hun WordPress plugins en thema's automatic updates documentatie, waar de host plugins en thema's op een schema bijwerkt en pre-update visual regression breakage opvangt.
• De site een harde freeze is, end-of-life loopt, voor uitfasering staat of onder formele change control valt waar elke wijziging eerst goedgekeurd moet worden.

Voor iedereen anders: doe dit niet. Skip naar Scenario B.

Heb je echt een harde lock nodig? Voeg dit toe aan wp-config.php, boven de regel die /* That's all, stop editing! Happy publishing. */ zegt:

// Zet alle WordPress automatische updates uit, inclusief minor security releases.
// Combineer dit met een extern update-proces dat je daadwerkelijk draait.
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Dat is één regel. Drie regels als je ook bestandswijzigingen wilt dichttimmeren:

// Blokkeer bestandswijzigingen via wp-admin volledig.
// Impliceert DISALLOW_FILE_EDIT en zet ook de plugin/thema-installer uit.
define( 'DISALLOW_FILE_MODS', true );

DISALLOW_FILE_MODS is agressiever dan AUTOMATIC_UPDATER_DISABLED: het sluit de handmatige installer, de plugin- en thema-uploadpaden én de wp-admin code-editors af. De trade-off is dat updates dan via git, Composer of een CI-pipeline moeten lopen. Voor een agency met een deployment-verhaal: prima. Voor een ZZP'er die dat verhaal nog niet heeft: ramp.

Verifieer. Op de wp-admin Updates-pagina hoort er "This site is automatically kept up to date with maintenance and security releases of WordPress" te staan, met de maintenance-regel weggehaald als AUTOMATIC_UPDATER_DISABLED actief is. Draai wp core check-update via WP-CLI om te bevestigen dat core nog steeds nieuwe versies ziet; alleen wordt er niets meer geïnstalleerd.

Scenario B: alleen security en vertalingen (de default die ik aanraad)

Dit is de configuratie die ik op de meeste sites die ik draai gebruik. Minor core-releases installeren automatisch, vertalingsupdates installeren automatisch, plugin- en thema-updates vereisen een expliciete per-item-toggle of een filter, en major core-releases vragen om een handmatige klik. De site blijft gepatcht tegen bekende kwetsbaarheden, en niets wat zichtbaar is voor bezoekers verandert zonder dat een mens daar 'ja' op heeft gezegd.

Voeg dit toe aan wp-config.php:

// Sta minor core-updates toe (X.Y.Z), blokkeer major core-updates (X.Y).
// Vertalingen en security minor releases installeren automatisch door.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE accepteert drie waardes: true (alle core-updates inclusief major), false (geen enkele core-update) of 'minor'. De WordPress upgrading handbook zet de drie waardes expliciet op een rijtje.

Die ene regel dekt core af. Plugins en thema's staan standaard op handmatig: een verse WordPress-installatie auto-update geen plugins of thema's, behalve als een admin de per-item-schakelaar in wp-admin > Plugins (toegevoegd in 5.5) aanzet. Vertalingen staan standaard aan. Met die ene regel heb je dus de configuratie die hierboven beschreven staat.

Wil je daarbovenop ook expliciet plugin auto-updates aanzetten (bijvoorbeeld omdat je bepaalde plugins genoeg vertrouwt om zichzelf bij te werken, maar de site veel admins heeft en je de regel in code wilt vastleggen, niet in de UI)? Gebruik dan een mu-plugin in plaats van per item te toggelen:

<?php
/**
 * mu-plugin: per-plugin policy voor automatische updates.
 * Bestand: wp-content/mu-plugins/auto-update-policy.php
 */

// Plugins die zonder toezicht mogen auto-updaten.
$auto_update_allowlist = [
    'wordfence/wordfence.php',
    'akismet/akismet.php',
    'classic-editor/classic-editor.php',
];

add_filter( 'auto_update_plugin', function ( $update, $item ) use ( $auto_update_allowlist ) {
    return in_array( $item->plugin, $auto_update_allowlist, true ) ? true : $update;
}, 10, 2 );

Het filter krijgt $item mee, het offer-object. Voor plugin-offers is $item->plugin de pad-style slug (folder/main-bestand.php). Voor thema-offers is $item->theme de stylesheet-slug. De $update-parameter is de vorige returnwaarde uit de filterketen of null; doorgeven van die waarde behoudt de beslissing van een ander filter wanneer dit filter niet van toepassing is.

Verifieer. Push het bestand, wacht op de volgende WP-Cron-tick (of forceer 'm met wp cron event run wp_version_check) en check wp plugin list --format=table. Plugins op de allowlist horen auto-updates: on te tonen in de auto-updates-kolom. Plugins die er niet op staan blijven off.

Scenario C: granular per-plugin controle via mu-plugin

Soms is een toestaan/blokkeren-knop niet genoeg. Voorbeelden die ik daadwerkelijk heb gebouwd:

• Sommige plugins alleen tussen 02:00 en 06:00 site-tijd auto-updaten, nooit tijdens kantooruren.
• Alle plugins van een specifieke uitgever auto-updaten (alles van Yoast bijvoorbeeld), maar plugins van andere uitgevers blokkeren tot ze handmatig zijn beoordeeld.
• Minor versies van elke plugin auto-updaten, major versies nooit, waarbij "major" wordt gedetecteerd door het eerste segment van de versiestring te vergelijken.
• Auto-updates volledig blokkeren op de productie-omgeving, toelaten op staging, met dezelfde codebase op beide.

Elk hiervan is één mu-plugin. Hier is het per-uitgever-voorbeeld, het meest bruikbare patroon:

<?php
/**
 * mu-plugin: alleen auto-updaten voor specifieke uitgevers.
 * Bestand: wp-content/mu-plugins/auto-update-by-publisher.php
 */

add_filter( 'auto_update_plugin', function ( $update, $item ) {
    // Doe alleen iets met plugins van wordpress.org met een gevulde slug.
    if ( empty( $item->slug ) ) {
        return $update;
    }

    // Allowlist op author-slug zoals die op wordpress.org staat.
    // Haal die uit de plugin's wordpress.org-URL: wordpress.org/plugins/<slug>/.
    $auto_update_authors = [
        'yoast',           // Yoast SEO
        'automattic',      // Akismet, Jetpack, etc.
        'wordfence',       // Wordfence Security
    ];

    // De `upgrade_notice`-string van het offer bevat soms de auteur;
    // voor een betrouwbaardere check vraag je de plugins API om de slug.
    $info = plugins_api(
        'plugin_information',
        [
            'slug'   => $item->slug,
            'fields' => [ 'author' => true ],
        ]
    );

    if ( is_wp_error( $info ) || empty( $info->author ) ) {
        return $update;
    }

    foreach ( $auto_update_authors as $author ) {
        if ( false !== stripos( $info->author, $author ) ) {
            return true;
        }
    }

    return $update;
}, 10, 2 );

Dit is zwaarder dan de simpele allowlist omdat hij per offer met plugins_api() praat, maar de kosten worden uitgesmeerd: wp_version_check draait een paar keer per dag, niet bij elke pageload. Voor sites met tientallen plugins, waar een handmatige allowlist onbeheerbaar wordt, is het uitgever-patroon veel makkelijker correct te houden.

Het tijd-window-patroon ziet er zo uit:

<?php
/**
 * mu-plugin: alleen plugins auto-updaten in het maintenance-window.
 * Bestand: wp-content/mu-plugins/auto-update-time-window.php
 */

add_filter( 'auto_update_plugin', function ( $update, $item ) {
    // Gebruik site-timezone, niet server-timezone.
    $timezone = wp_timezone();
    $now      = ( new DateTimeImmutable( 'now', $timezone ) )->format( 'H' );
    $hour     = (int) $now;

    // Window: 02:00 tot 06:00 site-tijd. Daarbuiten blokkeren.
    if ( $hour < 2 || $hour >= 6 ) {
        return false;
    }

    return $update;
}, 10, 2 );

De wijsheid hier komt uit Automattic's a8cteam51 plugin-autoupdate-filter, die Automattic op managed sites gebruikt om update-timing te beheren. Het patroon is simpel genoeg om zonder die dependency over te nemen.

Waar deze bestanden horen. Alle mu-plugins horen in wp-content/mu-plugins/. WordPress laadt elk PHP-bestand in die map automatisch bij elke request, op alfabetische volgorde. Er is geen activatie-stap. Bestand weghalen is automatisch deactiveren. mu-plugins verschijnen niet in de wp-admin Plugins-lijst en kunnen via de UI niet worden gedeactiveerd. Dat is precies waarom ze de juiste plek zijn voor dit soort policy-code: een junior admin kan je update-strategie niet per ongeluk uitzetten met een verkeerde klik.

Auto-update mails uitzetten of doorsturen

Elke geslaagde of mislukte background-update mailt de site-admin. Op een kleine site is dat prima. Op een vloot van vijftig klant-sites wordt dat mailvolume ruis die echte problemen overstemt.

Drie filters bepalen dit, allemaal toegevoegd in WordPress 5.5:

<?php
/**
 * mu-plugin: stuur auto-update-mails door naar ops@example.com,
 * onderdruk success-meldingen, behoud failure-meldingen.
 */

// Verander de ontvanger.
add_filter( 'auto_plugin_theme_update_email', function ( $email, $type, $successful, $failed ) {
    $email['to']      = 'ops@example.com';
    $email['subject'] = sprintf( '[%s] auto-update %s', wp_parse_url( home_url(), PHP_URL_HOST ), $type );
    return $email;
}, 10, 4 );

// Onderdruk success-only mails (laat 'mixed' en 'fail' wel door).
add_filter( 'auto_plugin_update_send_email', function ( $send, $type ) {
    return 'success' === $type ? false : $send;
}, 10, 2 );

add_filter( 'auto_theme_update_send_email', function ( $send, $type ) {
    return 'success' === $type ? false : $send;
}, 10, 2 );

De auto_plugin_theme_update_email filterreference documenteert de vier parameters: het email-array (to, subject, body, headers), het type ('success', 'fail' of 'mixed'), de array van geslaagde updates en de array van mislukte updates. De auto_plugin_update_send_email filterreference is de aan/uit-knop.

Voor het bredere plaatje van hoe WordPress mail verstuurt en waarom die berichten soms helemaal niet aankomen, zie waarom WordPress geen e-mail verstuurt.

Hoe hostingpaneel-tools botsen met WordPress-constantes

De meeste managed WordPress-hosts (Kinsta, WP Engine, SiteGround, Cloudways) leveren hun eigen auto-update-tooling die buiten WordPress draait. Dit is waar ik de duurste misconfiguraties zie, want de twee systemen weten niets van elkaar.

Kinsta's documentatie zegt het ronduit: "When you enable Kinsta Automatic Updates, WordPress auto-updates for all plugins are automatically disabled." Hun tool zet de site options auto_update_plugins en auto_update_themes op lege arrays en voegt een eigen filter toe dat false returned op auto_update_plugin, zodat de WordPress-kant van de updater plugins met rust laat. Hun cron-job draait vervolgens de updates, met pre-update backups, visual regression testing en automatische restore op visual diff. WP Engine's auto-update-documentatie beschrijft een vergelijkbare architectuur: WP Engine doet core minor updates en biedt managed plugin auto-updates aan als losse betaalde feature.

Het conflict-patroon dat ik het vaakst tegenkom:

1. Site draait bij Kinsta. Kinsta auto-updates staan aan in het paneel.
2. Een vorige developer heeft define( 'AUTOMATIC_UPDATER_DISABLED', true ); in wp-config.php gezet "om te voorkomen dat updates dingen stukmaken".
3. Beide lagen denken de baas te zijn. Kinsta's externe cron blijft updates draaien, want dat is een server-side proces, geen WordPress-proces. De constante onderdrukt de WordPress-kant van de auto-updater, die Kinsta toch al had onderdrukt.
4. De site-eigenaar denkt dat er niets meer auto-update. Dat klopt niet.

De fix: kies één systeem en zet het andere op no-op:

• Vertrouw je de host-tool meer? Haal AUTOMATIC_UPDATER_DISABLED uit wp-config.php (in deze configuratie doet hij toch niets), zet WP_AUTO_UPDATE_CORE op 'minor' en laat plugin/thema-beheer aan de host. Hun backups en visual regression doen écht werk.
• Vertrouw je je eigen mu-plugin policy meer? Zet de host-tool in het paneel uit, hou je filters en documenteer expliciet dat de update-strategie van deze site in wp-content/mu-plugins/auto-update-policy.php staat. Toekomstige developers kijken daar dan als eerste.

Draai nooit beide. Het resultaat is onvoorspelbaar, en de onvoorspelbare laag is degene die op de server het eerst draait, wat afhankelijk van de host elk van beide kan zijn.

Het WP Engine support-artikel over WordPress updates en de hierboven gelinkte Kinsta-documentatie zijn de gezaghebbende referenties voor wat elk hosttool werkelijk doet. Lees ze voor je gaat configureren.

Verificatie: wat staat er écht klaar om te updaten

Na elke wijziging aan constantes, filters of mu-plugins wil je bevestigen dat de werkelijkheid overeenkomt met je intentie voor je weer wegloopt. Drie commando's geven het antwoord.

Plugin auto-update-status, per plugin:

# Vereist WP-CLI 2.10+ voor het auto-updates subcommando.
wp plugin list --fields=name,status,auto_update,version

Verwachte output:

+-----------+----------+-------------+---------+
| name      | status   | auto_update | version |
+-----------+----------+-------------+---------+
| akismet   | active   | on          | 5.3     |
| wordfence | active   | on          | 7.11.4  |
| my-custom | active   | off         | 1.2.0   |
+-----------+----------+-------------+---------+

De auto_update-kolom toont de site option auto_update_plugins, dus de UI-toggle-status. Hij weerspiegelt niet wat je filters gaan doen. Een plugin die hier auto_update: off toont kan alsnog auto-updaten als auto_update_plugin true voor 'm returned, want het filter overruled de option.

Verifieer wat het filter daadwerkelijk besluit voor één plugin:

wp eval 'echo apply_filters( "auto_update_plugin", null, (object) [ "plugin" => "wordfence/wordfence.php", "slug" => "wordfence" ] ) ? "WILL update" : "WILL NOT update";'

Dit evalueert je filterketen tegen een synthetisch offer-object en print de daadwerkelijke beslissing. Gebruik het na het deployen van een mu-plugin om te bevestigen dat de policy doet wat je dacht.

Bevestig dat WP-Cron afgaat:

# Lijst geplande events. wp_version_check is degene die hier telt.
wp cron event list

# Wanneer draait wp_version_check de volgende keer?
wp cron event list --fields=hook,next_run_relative | grep wp_version_check

Verwachte output:

hook                  next_run_relative
wp_version_check      9 hours

Staat wp_version_check niet in de lijst, of staat zijn next_run_relative meer dan een paar uur in het verleden? Dan vuurt WP-Cron niet op schema. Diagnose via de cron-log van het hostingpaneel of de WP Crontrol-plugin, en lees WP Crontrol's pagina over missed cron events voor het systematische diagnosepad.

Veelvoorkomende troubleshooting

Auto-updates zijn gestopt na een hostingmigratie. Check eerst WP-Cron. De nieuwe host kan DISABLE_WP_CRON in wp-config.php hebben staan en een systeem-cron die wp-cron.php van buitenaf triggert. Is die systeem-cron niet ingericht of faalt de authenticatie? Dan vuren WP-Cron events, inclusief wp_version_check, nooit meer af. Draai wp cron event list en kijk of events zich opstapelen met next_run_relative-tijden in het verleden.

Een plugin heeft auto-geüpdate ondanks dat de UI-toggle uitstaat. Een filter overruled de UI. Zoek in wp-content/mu-plugins/, wp-content/themes/<actieve-thema>/functions.php en de PHP van elke actieve plugin naar auto_update_plugin. De filter-precedence staat hierboven beschreven: filter wint, UI verliest, stilletjes.

Het Site Health-scherm waarschuwt "Background updates are not working as they should". Dat is WordPress's eigen diagnose, gedraaid door WP_Site_Health::get_test_background_updates(). Hij checkt of het filesysteem schrijfbaar is, of AUTOMATIC_UPDATER_DISABLED of DISALLOW_FILE_MODS is gezet, en of de loopback naar wp-cron.php slaagt. De volledige checklist zie je door op de waarschuwing te klikken. Meestal is de oorzaak een host die loopback-requests blokkeert of een DISALLOW_FILE_MODS-constante die nog blijft hangen na een eerdere security-audit.

De update-mail komt op het verkeerde adres uit. WordPress stuurt update-mails naar get_option( 'admin_email' ), niet naar individuele user-accounts. Heb je laatst je admin gewisseld? Check dan de General Settings-pagina; de admin-mail staat los van de users-tabel. De mail loopt ook door wp_mail(), dus alle SMTP-configuratie geldt. Komt de mail helemaal niet aan? Volg dan waarom WordPress geen e-mail verstuurt.

Het Updates-scherm toont "An automated WordPress update has failed to complete - please attempt the update again now". Dat is een vastgelopen update-lock van een eerdere mislukte run. WordPress zet een transient core_updater.lock (en equivalenten voor plugins en thema's) met een timeout van 15 minuten. Crashte de auto-updater halverwege? Dan kan die lock blijven hangen. Draai wp transient delete core_updater.lock (of wp option delete .maintenance als er ook een .maintenance-bestand vastzit), en probeer opnieuw. Het herstelpad overlapt met de "even niet beschikbaar voor gepland onderhoud"-melding.

Een plugin-update heeft de site stukgemaakt nadat de auto-updater 'm 's nachts draaide. WordPress 6.6 heeft hier een gedeeltelijke mitigatie voor toegevoegd: na een geslaagde background plugin-auto-update vuurt WordPress een loopback HTTP-request af om een fatal error te detecteren, en draait de update terug als de loopback faalt. Dit staat in het merge proposal voor rollback auto-update, uitgeleverd in juli 2024. Het vangt alleen PHP-fatals, geen visuele regressies, JavaScript-fouten of datacorruptie, en het werkt alleen op background auto-updates, niet op handmatige. Voor het volledige diagnose- en herstelpad als dit gebeurt, zie een plugin-update heeft mijn WordPress-site stukgemaakt.

De reden dat auto-updates op WordPress verwarrend zijn: de zichtbare UI en het feitelijke mechanisme zijn het niet altijd eens. Zodra je weet dat het filter wint, dat de option niet meer dan een hint is, en dat WP-Cron in leven moet zijn voor de hele zaak, kun je het systeem in drie minuten configureren. De valkuil is dat je het in vijf seconden configureert met de verkeerde constante, en zes maanden later ontdekt dat "auto-updates stonden uit" eigenlijk betekende "er is sinds oktober geen security-patch meer geïnstalleerd".