Controlling WordPress Automatic Core Updates

This constant is about core, and core is the part least likely to break you. WP_AUTO_UPDATE_CORE decides whether WordPress updates itself. Its default already does the sensible thing — security and maintenance releases apply automatically, major upgrades wait for a person. Most snippets that change it set it to false, which stops security patches arriving and is rarely what the site actually needed.

The three values

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Note that 'minor' is a string and the other two are booleans. Writing 'false' in quotes is truthy in PHP, so it enables everything — the opposite of the intent, and a mistake that is invisible on inspection because the line reads correctly in English.

Why false is the wrong default

A site that does not update core accumulates known, published vulnerabilities. The changes in a security release are documented, which means the gap between release and patch is a window in which the specific weakness is public knowledge and the site still has it.

The instinct behind disabling updates is reasonable — nobody wants a site changing without warning. But minor releases are deliberately conservative and are the least likely update to break anything. The updates that break sites are plugins and themes, and this constant does not govern those at all.

If updates genuinely must not happen unattended, the responsibility does not disappear. It becomes a scheduled human task, and a site where that task is not actually performed is worse off than one left on the default.

What it does not cover

• Plugins and themes have their own automatic update toggles, set per item in the dashboard. A site relying on this constant for those is not getting what it expects.
• Translation files update on their own schedule.
• A site with DISALLOW_FILE_MODS set cannot update anything regardless of this value, because file modification is blocked outright. That constant wins, and it is the one to check when automatic updates are silently not happening — see DISALLOW_FILE_EDIT for how the two differ.

The last point catches deployed sites in particular. Setting DISALLOW_FILE_MODS is correct there, and it means updates must arrive through deployment. If they do not, the site is unpatched and the dashboard reports nothing unusual.

Making major upgrades safe rather than avoided

Setting true is defensible when the site can absorb a bad outcome:

1. Backups that are taken automatically and have actually been restored at least once.
2. A staging copy where the upgrade runs first, as described in creating a WordPress staging site.
3. Monitoring that would notice the front end breaking, rather than waiting for a customer to report it.

With none of those, true means an unattended major upgrade on a site nobody is watching. With all three, it is a reasonable way to stay current.

When an update leaves the site broken

Core updates are transactional enough that a failed one usually rolls back, but a failure partway through can leave the site in maintenance mode with a .maintenance file in the root. Deleting that file restores access, and the route through is stuck maintenance mode.

If the site is broken rather than merely locked, the cause is more often a plugin that was incompatible with the new core version than core itself. Deactivating plugins to find it is the standard procedure, covered in fixing plugin conflicts.

Verify what the site is doing

Open the Updates screen and read the line describing the automatic update status — it states in words whether the site is set to apply all, minor only, or none, which is the quickest confirmation the constant is being read.

If it reports something other than what wp-config.php says, check the line is above the stop-editing comment and that no plugin is filtering the behaviour. A site that reports it cannot update at all is usually blocked by file permissions rather than by this constant, and that diagnosis starts at FS_METHOD.