WordPress 6.5.3 and How Maintenance Releases Work

WordPress 6.5.3 shipped on 7 May 2024 with 12 bug fixes in core and 9 in the block editor, and most sites installed it overnight without anyone noticing. That is exactly how a maintenance release is supposed to behave. The useful question for a site owner is not what was in 6.5.3, but how these point releases work, why you should let them install automatically, and when you need to step in by hand. This guide answers that, using 6.5.3 and the 2026 releases as examples.

The short answer: leave minor (x.y.Z) updates on, treat major (x.Y) updates as a planned task with a backup and a staging check, and use the constants and filters below when a site has a specific reason to behave differently.

What a maintenance release actually is

WordPress uses a three-part version number, but not in the strict semantic-versioning sense. The first two numbers together are the major version (6.5, 7.0, 7.1). The third number is a minor or “point” release within that branch (6.5.1, 6.5.2, 6.5.3). Point releases come in two flavours:

• Maintenance releases fix bugs that slipped through the major release cycle. 6.5.3 was one of these, as was 7.0.1 in July 2026 with 31 fixes across core and the editor.
• Security releases patch vulnerabilities, sometimes alongside bug fixes. 7.0.2, 7.0.3 and 7.0.4 in July and August 2026 were all security releases, and WordPress.org now flags 7.0 through 7.0.3 as insecure.

Point releases never add features and never change database schema in a way that needs a manual upgrade. That is the whole point: they are designed to be safe to install unattended. The release team keeps them small and short-cycle. 6.5.3 came out about five weeks after 6.5 and about nine weeks before 6.6; the same rhythm held for 7.0, which went through four point releases between 20 May and 12 August 2026 before 7.1 “Mary Lou” arrived on 19 August.

Where to read what changed

Every release has an announcement post on the WordPress.org releases feed and a page on the Versions documentation listing each Trac ticket. For 6.5.3 the fixes were the unglamorous kind: editor regressions introduced in 6.5, a few PHP warnings, and edge cases in the template system. None of them required action from site owners after updating. Security releases are deliberately vague in the announcement; the detail arrives a week or two later once most sites have patched.

How automatic background updates decide what to install

Since WordPress 3.7 (2013), the automatic updater runs twice a day via WP-Cron and installs minor releases of the branch you are on. If you are on 6.5.2 it will take you to 6.5.3; it will not take you to 6.6. Major versions are offered in Dashboard → Updates and, since 5.6, there is a link on that screen to “Enable automatic updates for all new versions of WordPress” if you want majors installed too.

The updater checks several conditions before it runs:

1. The site is not under version control. If it finds a .git, .svn, .hg or .bzr directory in the WordPress root or any parent directory, it assumes a developer is managing deploys and backs off.
2. PHP can write to the WordPress files directly (the direct filesystem method). If your host needs FTP credentials for updates, background updates are disabled.
3. Nothing has defined AUTOMATIC_UPDATER_DISABLED or returned true on the automatic_updater_disabled filter.
4. The specific update type is allowed (see the constants below).

When an update succeeds or fails, WordPress emails the site admin address. If you have stopped reading those emails because there are so many, at least filter them into a folder you check weekly; a failed update email is how you find out a site has been stuck on an old branch.

Branches that are no longer maintained

Officially only the current major branch is supported. In practice the security team backports fixes to older branches for many years (security releases still go out for 4.x and 5.x branches), but bug fixes do not. If a site is on 6.5.3 in 2026 it is getting security patches only, and plugins are increasingly dropping support. Treat anything more than two majors behind as a project, not an update.

Controlling updates with constants and filters

The defaults are right for most sites. When they are not, the controls live in two places: constants in the wp-config file, and filters in a must-use plugin. The WordPress developer handbook is explicit that filters should not go in the config file, because it loads before the plugin API is ready.

Setting	Effect	Where
define( 'WP_AUTO_UPDATE_CORE', 'minor' );	The default: point releases install automatically, majors do not	wp-config file
define( 'WP_AUTO_UPDATE_CORE', true );	Minor, major and development updates all install automatically	wp-config file
define( 'WP_AUTO_UPDATE_CORE', false );	No core updates install automatically (you still get nagged in the dashboard)	wp-config file
define( 'AUTOMATIC_UPDATER_DISABLED', true );	Disables the whole updater: core, plugins, themes, translations	wp-config file
add_filter( 'allow_major_auto_core_updates', '__return_true' );	Enables major updates without changing the constant	mu-plugin
add_filter( 'auto_update_plugin', '__return_true' );	Auto-updates every plugin (overrides the per-plugin toggles)	mu-plugin
add_filter( 'auto_core_update_send_email', '__return_false' );	Stops the result emails	mu-plugin

A pattern we use on client sites that need a bit more control: keep core minors automatic, auto-update a short allowlist of plugins we trust to ship clean point releases, and leave everything else manual.

<?php
/**
 * Plugin Name: Site update policy
 * Description: Auto-update only plugins on the allowlist.
 */
add_filter( 'auto_update_plugin', function ( $update, $item ) {
    $allow = array(
        'akismet/akismet.php',
        'wordpress-seo/wp-seo.php',
        'woocommerce/woocommerce.php',
    );
    return in_array( $item->plugin, $allow, true ) ? true : $update;
}, 10, 2 );

Save that as wp-content/mu-plugins/site-update-policy.php. Note that WooCommerce is on the list deliberately: its point releases are security-relevant often enough that the risk of waiting is higher than the risk of installing. A page builder or a checkout customisation plugin would not be on that list.

The full list of constants and filters is in the Advanced Administration handbook.

A sane update routine for a small site

You do not need a change-management process for a brochure site, but you do need a habit. This is the one we recommend to clients who look after their own WordPress installs.

Automatic, no action needed

• Core point releases (6.5.2 → 6.5.3, 7.0.3 → 7.0.4).
• Translation updates.
• Plugins you have explicitly toggled to auto-update in Plugins → Installed Plugins.

Weekly, ten minutes

1. Open Dashboard → Updates. Read the changelog link for any plugin with a version jump in the first or second digit.
2. Check that your last backup actually ran. Restorable backups are the only real safety net; the backup plugin comparison covers the options if you do not have one.
3. Update plugins and themes, then click through the home page, one inner page, and any form or checkout.

Per major release, an hour

1. Wait for the first point release (x.y.1) unless there is a security reason not to. 7.0.1 landed seven weeks after 7.0 and fixed 31 bugs; that is typical.
2. Update a staging copy first. Most managed hosts give you one; if not, a local copy with Local or Studio is fine.
3. Check PHP version requirements. The official requirements page lists the current minimum and recommended PHP, and many plugins now require 8.1 or later regardless of what core accepts.
4. Update production, clear caches, repeat the click-through.

When an update goes wrong

Point releases rarely break anything, but “rarely” is not “never” and plugin updates fail more often. The symptoms and fixes are predictable.

Symptom	Likely cause	Fix
“Briefly unavailable for scheduled maintenance” stays up	The update was interrupted and the .maintenance file was left behind	Delete .maintenance from the WordPress root via SFTP
Critical error after a plugin update	PHP fatal in the new plugin version	Use the recovery-mode link WordPress emails you, or rename the plugin folder via SFTP, then roll back
Auto-updates never run	Version control directory detected, or filesystem not writable	Check Site Health → Info → WordPress Constants and the Filesystem Permissions section
Update email says “failed” every day	Usually a file permissions problem on a single directory	Ask the host to reset ownership to the PHP user
Block editor behaves differently after a point release	Gutenberg plugin installed alongside core, pinning newer editor code	Decide whether you need the Gutenberg plugin; most production sites do not

For rolling back a plugin, WP Rollback (free, on WordPress.org) lets you pick an earlier version from the plugin’s own release history. For core, download the previous release from the WordPress.org release archive and replace wp-admin and wp-includes; do not touch wp-content.

Updates on community, LMS and store sites

Sites built on BuddyPress, LearnDash or WooCommerce need a slightly more careful approach, because those plugins have their own database tables and their own release cadences. A few rules we follow on our own hosted communities:

• Core point releases still go in automatically. We have never had a 6.x or 7.x point release break BuddyPress or WooCommerce.
• Major WooCommerce updates wait for staging. WooCommerce’s database migrations run on first load after update, and on a large store that can take minutes; you want to watch it happen.
• Theme updates are checked against the child theme. If you have overridden template files in a child of BuddyX or Reign, the update notice on Appearance → Themes lists the overridden templates that have changed upstream.
• Update on a quiet day. For a community that is Tuesday morning, not Friday evening.

If the site is important enough that you do not want to own this routine at all, that is what a maintenance retainer is for. Our WordPress maintenance services cover exactly the weekly and per-release checklist above.

FAQ

Was WordPress 6.5.3 a security release?

No. It was a maintenance release with bug fixes only. The first security release in the 6.5 branch was 6.5.5 in June 2024.

Can I skip point releases and wait for the next major?

You can, but there is no upside. Point releases are cumulative, so the next major includes them anyway, and you spend weeks exposed to anything a security point release fixed in the meantime.

Do auto-updates work on multisite?

Yes. Core updates apply network-wide. Plugin auto-update toggles are set by the network admin under Network Admin → Plugins.

Why does my host say I am on an older version than Dashboard → Updates shows?

Some managed hosts roll out core updates on their own schedule and block the built-in updater. Check with them before trying to force an update; fighting the host’s update system tends to end with both of you confused.

Where to start

Open Site Health → Info → WordPress Constants and confirm WP_AUTO_UPDATE_CORE is minor or unset. Confirm a backup ran this week. Put a recurring fifteen-minute slot in the calendar for plugin updates. That is the entire policy for most sites, and it is the reason 6.5.3, 7.0.4 and whatever ships next month will continue to be non-events.