WordPress 7.1.1 Arrives September 17 to Clean Up After 7.1. Test the RC on the 10th, Not Your Live Site on the 17th.

WordPress 7.1.1 is scheduled for Thursday, September 17, 2026 at 15:00 UTC, with a release candidate a week earlier on September 10 at 17:30 UTC. It is a bug-fix only maintenance release, which normally means nobody outside the core team pays it much attention. This one deserves a closer look, because 7.1 shipped with a backwards-compatibility break that took production sites down in the field, and 7.1.1 is where the core side of that gets cleaned up.

The useful thing about a scheduled point release is that the release candidate is public a full week before the final. That week is the whole opportunity. You can find out whether WordPress 7.1.1 breaks your specific site on a copy, on the 10th, while there is still time to say something, instead of finding out on the 17th on the site your customers use.

TL;DR

• WordPress 7.1.1 final: Thursday, September 17, 2026, 15:00 UTC. RC1: Thursday, September 10, 17:30 UTC. Both times are estimates and can move.
• The release is co-led by Adam Silverstein, Adrian Duffell, and Andrei Draganescu, with bug scrubs on September 3, 4, 8, 9, and 15 in the #core Slack channel.
• Scope is defect-only: tickets qualify only if they were introduced during the 7.1 cycle or were deliberately deferred at the end of it. No new features.
• On a default configuration, 7.1.1 will install itself without anyone clicking anything. Minor core updates are on by default. Your real choice is whether you test first.
• Test RC1 on a staging copy from September 10, using the WordPress Beta Tester plugin (Point Release channel, Nightlies stream) or WP-CLI.
• The fix for the 7.1 hook callback key type change (Trac #65919) has been reopened for 7.1.1 merge consideration. Consideration is not confirmation. The RC1 announcement carries the final ticket list.
• Before you update anything, know your rollback: a backup taken before the update, and a way into the filesystem that does not go through wp-admin.

What a maintenance release is, and why "low risk" is the trap

A maintenance release fixes defects in an existing major version. It does not add features, change the editor, or introduce anything you have to prepare for. The scope is written down and it is narrow: for 7.1.1, a ticket qualifies only if the problem was introduced during the 7.1 development cycle, or if it was a fix that got deliberately pushed out of 7.1 at the end. Everything else waits for 7.2.

That narrow scope is why maintenance releases are genuinely lower risk than major ones, and it is also exactly why they cause more trouble than they should. A major release comes with weeks of warning, dev notes, a field guide, and a general sense that you should probably look before you leap. A point release comes with a version number and a changelog nobody reads. So the same site owner who carefully tested 7.1 on staging in August lets 7.1.1 land on production in September without a glance, because it is "just a maintenance release."

Two things follow from that. First, the surface area is smaller but not zero. A defect fix changes behaviour by definition, and code that depended on the defective behaviour changes with it. Second, the fixes in a maintenance release are disproportionately the ones that touch things plugins interact with, because that is where regressions get reported from. A release full of small, targeted changes to widely-used internals is not the same thing as a release full of nothing.

There is one scheduling detail worth knowing, because it tells you when the contents stop moving. At the September 8 bug scrub, the 7.1.2 milestone opens and some tickets get punted to it. Up to that point the ticket list is still being negotiated. After RC1 on the 10th, it is effectively fixed.

The WordPress 7.1.1 release schedule

The schedule was published on Make/Core on September 2 by Adam Silverstein. The release is co-led by Adam Silverstein, Adrian Duffell, and Andrei Draganescu.

Two caveats come straight from the schedule post and matter if you are planning around these dates. The times are estimates, and the exact timing of scrubs, the RC, and the general release depends on who is available. Final confirmation happens in the 7.1 Release Leads Slack room, with code decisions made in #core.

For what it is worth as a track record, the previous maintenance release in this cycle held its date: 7.0.1 was scheduled for Thursday, July 9 and shipped on Thursday, July 9. Plan for the 17th, but do not build anything that breaks if it slips by a few days.

Why this maintenance release is worth more attention than the last one

WordPress 7.1 shipped on August 19 at WordCamp US. Within hours, sites running a popular caching plugin started returning fatal errors, including sites whose owners could no longer reach wp-admin to fix them. We covered what happened and how to recover a downed site at the time, and the plugin side was patched the next day.

The core side is what connects that incident to 7.1.1. As part of a performance improvement, 7.1 changed how WordPress generates the internal ID for a registered hook callback, moving from spl_object_hash() to spl_object_id(). The new ID is cast to a string, but PHP converts a canonical decimal string back to an integer the moment it is used as an array key. The result: for callbacks that are a bare object, meaning a closure or a class with __invoke(), the keys in WP_Hook::$callbacks became integers where they had always been 32-character strings.

Any plugin that iterates those keys and runs a string function on them, under strict_types, gets a TypeError instead of a value. That is a fatal error, on every request, on init.

This was not one vendor's problem. A separate report on the WordPress.org support forums describes a security-logging plugin hitting the same class of crash from strtolower() receiving an integer callback ID while walking $wp_filter. The pattern is generic: read the callback keys, treat them as strings, declare strict types, crash on 7.1. Plugins that do not declare strict types coerce silently and nobody notices.

The core fix is tracked as Trac ticket #65919. It prefixes the generated ID with a non-numeric string so PHP has nothing to coerce, and applies the same treatment to WP_Widget_Factory, which had the identical problem. It landed in trunk and the ticket has since been reopened for 7.1.1 merge consideration.

Read that phrasing precisely, because it is the difference between useful and wrong. "Reopened for merge consideration" means the fix is a candidate for 7.1.1, not that it is confirmed in it. The definitive list of what 7.1.1 contains appears in the RC1 announcement on September 10, the same way the 7.0.1 RC post listed every core ticket and Gutenberg pull request included. Until then, treat any specific fix as proposed.

If it does land, the practical effect is that plugin code which broke on 7.1 starts working again on 7.1.1 whether or not the plugin was updated. That is good news and a slightly awkward incentive: it means a site limping along on a hand-edited plugin file or a mu-plugins workaround is about to have the underlying reason for that workaround disappear, with the workaround still sitting there. If you patched something manually in August, September is when you take it out.

You probably do not get to choose when 7.1.1 installs

This is the part most articles about maintenance releases skip, and it changes what the advice above is actually for.

WordPress enables automatic background updates for minor core releases by default. Per the WordPress developer documentation, on a stable site the WP_AUTO_UPDATE_CORE constant defaults to minor, and since WordPress 5.6 new installations get automatic major updates as well unless a version control checkout is detected. Existing installations keep the older behaviour, which is minor-only.

In plain terms: unless somebody on your team deliberately turned it off, WordPress 7.1.1 is going to install itself on your site some time after September 17, without a decision, a notification you will read, or a maintenance window.

You can check where a given site stands from the dashboard. Go to Dashboard → Updates and read the sentence at the top. A minor-only site says it is automatically kept up to date with maintenance and security releases of WordPress only. A fully automatic site says it is kept up to date with each new version. A site with updates disabled says it will not receive automatic updates for new versions.

From the command line:

wp core version
wp core check-update
wp config get WP_AUTO_UPDATE_CORE

The last command returns an error if the constant is not defined in wp-config.php, which is itself the answer: not defined means the default applies, and the default on a stable site is minor updates on.

Managed hosts frequently manage core updates at the platform level too, which can override or replace whatever wp-config.php says. If you are on managed hosting, check the host's setting as well as WordPress's own, because those two answers are not always the same.

The conclusion is uncomfortable but simple. Turning minor auto-updates off is the wrong response, because it means missing security releases, which is a far worse exposure than a maintenance regression. The right response is to stop treating the release date as your decision point. The release candidate is your decision point. By the 17th, the outcome is already determined by whatever you did or did not do in the preceding week.

How to test 7.1.1 RC1 on September 10

A release candidate is not an advanced or risky thing to run. It is a normal WordPress install with a version number that is one commit ahead of the release. The only rule is where you run it.

Step one: make a copy

Clone production to staging. Not a fresh WordPress with your theme on it, and not a six-month-old copy. The whole point is to test your actual plugin set, your actual theme, your actual custom code, and your actual data, because the crashes that matter are the ones caused by a specific combination that nobody else has.

Take a backup of production before you start, even though you are not touching it. You want a restore point that predates the whole exercise. If you have never actually restored one of your backups, test the restore path rather than assuming it works.

On MagicWP this is two clicks: clone production to a staging site and take an on-demand backup before you change anything, alongside the daily off-site snapshots with one-click restore that are already running. Core updates run with rollback available, which is the specific capability that matters on a maintenance release day.

Step two: install the RC on the copy

There are two supported routes, and they behave slightly differently.

The WordPress Beta Tester plugin is the official method. For a minor release candidate, select the Point Release channel and the Nightlies stream. That gives you the latest build including the RC plus any commits that have landed on the branch since, which is what you want when you are trying to help catch problems rather than pin an exact build.

WP-CLI points at the RC package directly and gives you an exact, repeatable version:

wp core update https://wordpress.org/wordpress-7.1.1-RC1.zip
wp core version

The RC1 announcement on Make/Core publishes the exact download URL when the RC ships. Take it from the announcement rather than assuming the filename, since the URL is the authoritative form and the pattern is not a guarantee.

Either way, confirm what you are actually running before you start testing. Testing 7.1 and thinking you tested 7.1.1 is a real and quiet failure mode.

Step three: check the things that break first

Keep this short and concrete. You are not doing QA on WordPress; the core team is. You are checking whether your combination survives.

Two of those deserve emphasis. Check wp-admin separately from the front end, because they are different request paths and one can crash while the other looks fine. And actually complete a checkout or a form submission rather than loading the page it lives on. A page rendering is not the same as a transaction completing, and the failures that cost money are on the second path.

If your site has custom code that reads WordPress internals, this is the release to look at it. Anything that walks $wp_filter, inspects WP_Hook::$callbacks, or does string operations on callback identifiers is directly in the path of the change 7.1.1 is expected to address.

How to report a regression while it can still be fixed

This is the part of the week that people skip, and it is the part where a site owner has the most leverage they will ever have over WordPress core. Bug scrubs are running, the release leads are actively triaging, and the milestone is small enough that a well-formed report gets read.

If you find something on the RC:

1. Confirm it is the RC. Reproduce it on the RC and confirm it does not happen on 7.1. If it happens on both, it is not a 7.1.1 regression and belongs in a normal ticket.
2. Narrow it. Deactivate plugins until you have the smallest set that reproduces it. "My site breaks" is not actionable; "these two plugins plus the RC produce this fatal on init" is.
3. File it on Trac at core.trac.wordpress.org with the file and line, the exact error text, reproduction steps, and your environment: WordPress version, PHP version, plugin versions.
4. Raise it in #core on the Making WordPress Slack, during a scrub if you can make one. The scrub times are in the schedule table above.

The model report here is the one that preceded the 7.1 incident: it named the file and line, explained the mechanism, gave reproduction steps, stated the environment, and included a one-line fix. That report was correct and complete, and it still sat for six weeks, which is a separate problem. But the reason it could sit and still be immediately actionable when someone finally looked at it is that it was written properly.

Timing matters. Report before the September 8 scrub and your ticket is competing for the 7.1.1 milestone. Report after RC1 on the 10th and, unless it is a serious regression in the RC itself, you are realistically filing for 7.1.2. Neither is wasted, but they are not the same window.

If the final release goes badly anyway

Testing reduces the odds. It does not eliminate them, because the thing that breaks your site may be a combination you did not think to test.

Before September 17, make sure two things are true. First, you have a backup taken immediately before the update, not a nightly from twelve hours earlier with orders in between. Second, you can reach the filesystem of every site you run without going through wp-admin, over SFTP or a host file manager. That second one is what separates a ten-minute outage from a lost afternoon, because a fatal error on init takes the dashboard with it and every recovery route assumes filesystem access.

Rolling a point release back is a single command:

wp core update --version=7.1 --force
wp core verify-checksums

Three caveats before you rely on it. Rolling back core files does not undo anything an update did to the database, so check for a db_version change before assuming a downgrade is clean. On managed hosting, host-level update management may reinstall the newer version, so use the host's rollback rather than fighting it. And a rollback is a holding action, not a fix: you are back on 7.1 with whatever the 7.1.1 fixes were meant to address, so it buys you time to diagnose rather than ending the problem.

WordPress also has fatal error protection built in. When an update produces a fatal error, core attempts to email the site administrator a recovery-mode link that lets you get into the dashboard with the offending plugin paused. This depends on your site being able to send email, which is worth verifying now rather than discovering on release day.

Frequently Asked Questions

When is WordPress 7.1.1 released? WordPress 7.1.1 is scheduled for Thursday, September 17, 2026 at 15:00 UTC, with Release Candidate 1 on Thursday, September 10 at 17:30 UTC. Both times come from the release schedule published on Make/Core on September 2, and both are described there as estimates that depend on contributor availability. Final timing is confirmed in the 7.1 Release Leads channel on the Making WordPress Slack. Plan around the 17th, but do not schedule anything that breaks if the release slips by a day or two.

What is included in WordPress 7.1.1? Bug fixes only. A ticket qualifies for 7.1.1 if it is an issue introduced during the 7.1 development cycle or a fix that was intentionally deferred at the end of that cycle. There are no new features, no editor changes, and nothing you need to prepare for beyond compatibility. Proposed fixes are tracked on Trac report 4 and the 7.1.x editor tasks board on GitHub, and the definitive list appears in the RC1 announcement on September 10. The ticket list is still moving until the September 8 scrub, when the 7.1.2 milestone opens and some tickets are punted.

Will WordPress 7.1.1 install automatically? On a default configuration, yes. WordPress enables automatic background updates for minor core releases out of the box, and on a stable site the WP_AUTO_UPDATE_CORE constant defaults to minor. Check Dashboard → Updates: a minor-only site says it is kept up to date with maintenance and security releases only. Managed hosts often control core updates at the platform level as well, so check both. Disabling minor auto-updates to avoid this is a bad trade, because the same mechanism delivers security releases.

Do I need to test a maintenance release on staging? You should, and it costs about twenty minutes. The risk from a defect-only release is lower than from a major one, but it is not zero, and the fixes in a maintenance release concentrate in exactly the internals that plugins touch. The stronger argument is scheduling: because minor updates install automatically, the release date is not a decision point for you. If you want a say in what happens on the 17th, the release candidate on the 10th is where you get one.

How do I install the WordPress 7.1.1 release candidate? Two ways, both on a staging copy rather than production. The WordPress Beta Tester plugin is the official route: install it and select the Point Release channel with the Nightlies stream, which gives you the RC plus any subsequent commits on the branch. Or use WP-CLI with the RC package URL published in the RC1 announcement on Make/Core, in the form wp core update https://wordpress.org/wordpress-7.1.1-RC1.zip. Confirm with wp core version afterwards, because testing the wrong build is easy and silent.

Does 7.1.1 fix the fatal errors some sites hit after updating to 7.1? The core-side fix for the hook callback key type change, Trac ticket #65919, has been reopened for 7.1.1 merge consideration. That means it is a candidate, not a confirmed inclusion, and the RC1 announcement is where the final list is published. Separately, the plugin most visibly affected shipped its own fix on August 20, so do not wait for 7.1.1 as a remedy for a site that is broken now. Update the plugin, and remove any manual code workaround you applied in August once you do.

How do I roll back if 7.1.1 breaks my site? Restore a backup taken immediately before the update, or downgrade core with wp core update --version=7.1 --force followed by wp core verify-checksums. Rolling back core files does not reverse database changes, so check whether the update changed db_version first. On managed hosting, use the host's rollback rather than WP-CLI, since platform-level update management may reinstall the newer version. Either route assumes you can reach the site, which is why filesystem access without wp-admin matters more than the command itself.

Should I skip 7.1.1 and wait for 7.1.2? No. Maintenance releases are cumulative and skipping one does not reduce your exposure, it postpones and compounds it. Minor releases are also the delivery mechanism for security fixes, and a site parked on an older point release to avoid a maintenance regression is trading a small compatibility risk for a real security one. If a specific 7.1.1 change genuinely breaks your site, the answer is a short, deliberate rollback with a ticket filed, not an indefinite hold.

Conclusion

WordPress 7.1.1 lands on September 17, it is defect-only, and on most sites it will install itself. The single decision worth making in advance is what you do on September 10, when the release candidate becomes public and you can run your own plugin set against it on a copy for the cost of twenty minutes and a clone.

The reason 7.1's problems became a story and 7.1.1's should not is that this fix is scheduled, public, and testable a week early. The sites that get hurt by point releases are the ones where "maintenance release" was read as "safe to skip testing." Before the 10th, confirm three things: you can clone production to staging, you have a backup you have actually restored at least once, and you can reach the filesystem of every site you run without wp-admin.

If any of those is currently a maybe, that is the thing to fix this week. Managed WordPress hosting with one-click staging, pre-change backups, and core updates with rollback makes the whole sequence routine, but the habit matters more than the platform. Decide it now, while nothing is on fire.