Updates and Auto-Updates

WordPress distinguishes five kinds of update. Each has its own default and its own switch.

Security releases are minor releases, so this default applies them without anyone acting: WordPress 7.1.4, a security-only release published on 2026-10-28 (it fixes a remote code execution weakness in the upgrade process and a series of stored XSS issues), was offered to every 7.1 site as a minor update, and the announcement notes that sites with automatic background updates would start updating automatically; on a site that opted out, update to it immediately. Source: WordPress News: WordPress 7.1.4

The 5.6 rule comes from three site options. A fresh install writes auto_update_core_dev, auto_update_core_minor and auto_update_core_major, all enabled; the database upgrade to 5.6 wrote auto_update_core_major as unset on existing sites, which counts as "off". On the test site, freshly installed at 7.1.2:

Source: WP-CLI Commands: wp core check-update

The package is a partial build: only the files that changed between 7.1.2 and 7.1.3. Core falls back to the full package when the partial one cannot be used.

Dashboard > Updates (wp-admin/update-core.php) handles every kind of update. Under "Last checked on …​ at …​" and a Check again link, it has four sections. WordPress offers Update to version 7.1.3, or Re-install version 7.1.3 (a repair for modified or corrupt core files), and a status line with the core policy: "This site is automatically kept up to date with each new version of WordPress." or "…​with maintenance and security releases of WordPress only." A link switches between the two by writing auto_update_core_major as enabled or disabled. Plugins, Themes and Translations list pending updates with Update Plugins, Update Themes and Update Translations buttons.

The policy link disappears when the policy is decided in code: when WP_AUTO_UPDATE_CORE is defined, when the whole updater is disabled, or when any code is hooked to allow_major_auto_core_updates. If a version-control checkout is detected, the status line reads "This site appears to be under version control. Automatic updates are disabled."

Only users with the update_core, update_plugins, update_themes and update_languages capabilities see the screen and its notices, which by default means Administrators on a single site and only Super Admins on Multisite, where the screen lives in the Network Admin (see Multisite Networks).

Other routes: an update now link on each row of Plugins and Appearance > Themes; WP-CLI for scripted updates (Updating with WP-CLI); hosting panels such as WP Toolkit in cPanel and Plesk, whose schedules run alongside core’s updater unless the host disables it (find out which one is in charge); and the manual update (replace everything except wp-config.php and wp-content/, then visit /wp-admin/upgrade.php) for servers where nothing else works.

Background updates are driven by WP-Cron. On init, wp_schedule_update_checks() schedules three twice-daily events: wp_version_check, wp_update_plugins and wp_update_themes. When wp_version_check() runs inside a cron request, it fires the wp_maybe_auto_update action, whose callback creates a WP_Automatic_Updater and calls its run() method. A site whose WP-Cron does not run (disabled with DISABLE_WP_CRON and no system cron, or a site without traffic) never updates itself; see WP-Cron and Scheduled Tasks.

run() returns at once if the updater is disabled, if the site is not the main site of the main network, or if another run holds the auto_updater.lock option (it expires after one hour). Otherwise it updates eligible plugins, then themes, then core (find_core_auto_update(), under its own 15-minute core_updater.lock), then translations, and finally sends the emails and fires automatic_updates_complete with every result.

Before each plugin, theme or core update, the site is put in maintenance mode: a .maintenance file in the WordPress root makes every front-end and admin request answer "Briefly unavailable for scheduled maintenance. Check back in a minute." The file is deleted at the end; if a run dies half-way the file stays, but WordPress ignores it once it is more than ten minutes old.

Lumen Press production defines DISALLOW_FILE_MODS (see Security Hardening): its code is owned by a deploy user, PHP writes only uploads, and every update, security releases included, reaches it through the deployment pipeline after staging has taken it. The background updater therefore runs on staging, where WordPress updates itself in place, and on any classically maintained site. The staging configuration keeps only the constants that must hold even if a must-use plugin is missing:

Source: Advanced Administration Handbook: Constant to Configure Core Updates

Constants are coarse; filters can decide per environment, per item and per day. They belong in a must-use plugin in wp-content/mu-plugins/, never in wp-config.php: WordPress is not fully loaded while wp-config.php runs, so add_filter() there is fragile and the handbook notes it conflicts with WP-CLI. A must-use plugin cannot be deactivated from the dashboard, which is what an update policy needs. Must-use plugins themselves are explained in Choosing and Managing Plugins and Themes.

The Lumen Press policy lives in wp-content/mu-plugins/lumen-update-policy.php on every site the updater maintains (on production DISALLOW_FILE_MODS makes it inert). It complements the site’s plugin policy (the "always update Two Factor and Akismet, never auto-update themes" filters shown on the plugins page): minor core releases everywhere, major releases automatically only on staging, translations always, no plugin or theme updates at weekends when nobody is on call, no routine "success" emails, and a log line for every run.

Source: Code Reference: auto_update_{$type} and Code Reference: allow_major_auto_core_updates

The weekend rule also holds back forced security releases of plugins until Monday; checks run twice a day, so the delay is at most about two days. A site that cannot accept that delay should drop the rule.

An updater that rewrites files would fight a deployment that also writes them. So is_vcs_checkout() looks for a .svn, .git, .hg or .bzr directory in the update’s context directory and in every parent up to the filesystem root, and always also in ABSPATH and its parents. When one is found the update is skipped; for a core offer, WordPress falls back to sending the "WordPress x.y.z is available" email (if WordPress.org flags the release). Directories outside PHP’s open_basedir are not checked (since 6.2).

The context differs by type: ABSPATH for core, WP_PLUGIN_DIR for plugins, the theme root for themes and WP_CONTENT_DIR for translations. The last three rows of the probe table above show the effect: a repository that versions only wp-content (the usual layout, see Deployment and CI/CD) blocks plugin, theme and translation updates but not core security releases. A .git anywhere above the WordPress root, such as a whole server directory under version control, blocks everything. Site Health reports it under Background updates as "The folder …​ was detected as being under version control (.git)."

If the checkout is deliberate but WordPress may still update (a server where a configuration repository happens to sit above the site, for example), return false from automatic_updates_is_vcs_checkout, at priority 1 as the handbook recommends, so that later callbacks can still say true for specific paths:

Source: Code Reference: WP_Automatic_Updater::is_vcs_checkout()

Lumen Press does not need the override: its production servers receive releases by rsync of a build without .git and define DISALLOW_FILE_MODS, and on staging its update policy alone decides.

All update emails go to the address in the admin_email option (Settings > General, "Administration Email Address"), not to every administrator. They are sent with wp_mail(), so a site that cannot send mail (see Email Delivery) silently loses them.

The success email from a real background update of the test site from 7.1.2 to 7.1.3 (captured with a pre_wp_mail filter in a test-only must-use plugin, without the Lumen policy that suppresses it):

With the Lumen policy active, the same update sent nothing, left [lumen-updates] core WordPress 7.1.3: ok in wp-content/debug.log, and still recorded "type":"success" with the address and version in the auto_core_update_notified site option, which is how WordPress avoids repeating an email.

Core failures are also remembered, in the auto_core_update_failed site option. A critical failure (disk_full, an error while copying files, or a failed internal rollback) stops all later core auto-updates until an administrator completes a manual update. A non-critical one stops retrying that same version; download_failed, incompatible_archive, insane_distro and locked are retried once after an hour. After fixing the cause, wp option get auto_core_update_failed shows what happened, and a successful wp core update clears the block.

Three mechanisms exist, each narrow:

The second and third are described with their limits (inactive plugins and themes are not checked, non-fatal breakage is not detected, database changes are not undone) in Choosing and Managing Plugins and Themes.

One more limit matters to administrators: a loopback request that fails counts as a fatal error. has_fatal_error() returns true when wp_remote_get() to the home URL returns an error. On the test site, whose home URL (https://lumenpress.test) the server could not reach on port 443, every auto-update of the active Two Factor plugin was undone although 0.17.0 has no fatal error (log from WP_DEBUG_LOG with timestamps removed, and the Lumen policy’s log line at the end):

Afterwards wp plugin list still showed 0.16.0, active, with 0.17.0 available. With the home URL reachable from the server, the same update was kept ("The update for 'two-factor' has no fatal errors."). Behind a load balancer, a firewall that blocks the server’s own requests, HTTP basic auth (only forwarded when the cron request itself carried it) or a split DNS, active plugins therefore never auto-update, and the emails report them as failed. Check Tools > Site Health ("Your site can perform loopback requests") on every environment that auto-updates plugins; see Debugging, Site Health and Troubleshooting.

Automatic minor updates are low-risk and should stay on. Major releases, plugin and theme updates, and anything on a site with custom code deserve a process. Lumen Press follows this one:

Downgrading core is discouraged. Newer releases contain security fixes, and a major release can change the database schema in ways the older code does not understand. If it is unavoidable, the handbook’s procedure is a full restore: replace the files with the backed-up ones (everything except wp-config.php) and restore the database backup taken before the update. Without both backups, it calls a successful rollback near impossible.

wp core update --version=7.1.2 --force replaces the files; the test site was moved back that way to repeat the update, and it worked cleanly only because 7.1.2 and 7.1.3 share a database version (61833). Across a major release, wp core update-db merely rewrites the stored db_version and leaves the newer schema and data in place; restore the database instead, as shown in Versions and Release Cycle. With an automatic minor policy, the site also updates itself again at the next check unless the policy changes. Re-install version on Dashboard > Updates re-installs the current version only; it is a repair, not a rollback.