WordPress 7.1 Release Day: What Happens Wednesday

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Twenty years in, release day is the boring part. It is only boring when the release squad makes it boring, which is exactly the point of publishing an operational playbook the night before a major.

WordPress 7.1 ships Wednesday, August 19, 2026. If you run a WordPress or WooCommerce site for a living, you already know the beats: the beta cycle, the RCs, the field guide, the dev notes. What you may not have read is the release day process itself — the code freeze, the dry run, the exact minute the package goes live. Krupa Nanda published it this week and it is worth the ten minutes.

Nothing about it is dramatic. That is the compliment.

What is actually new

WordPress 7.1 ships on August 19, 2026 at 23:10 UTC, live from WordCamp US in Phoenix. The Release Day Process post by release coordinator Krupa Nanda lays out the timeline in unusual detail: RC4 was tagged on August 17 at 15:00 UTC, the mandatory code freeze started an hour before that at 14:00 UTC, the dry run followed immediately after RC4, and the release party opens in the #core Slack channel at 19:45 UTC on Wednesday. The package publishes three hours and twenty-five minutes later.

The extended code freeze — from August 17 through the general release, rather than the usual twenty-four hour window — is by design. The extra time gives committers room to verify the packaged bundle rather than push commits into the last hour. During the freeze no source code for 7.1.0 can change unless a blocker forces another RC, which restarts the entire process. Non-critical issues get punted to 7.1.1.

Release Candidate 4, announced the same afternoon by Benjamin Zekavica, closes out the RC cycle with more than 26 updates and fixes since RC3 — 8 in the editor, 18 in core. You can test RC4 four ways: the WordPress Beta Tester plugin, the direct zip, wp core update --version=7.1-RC4 via WP-CLI, or a browser tab via WordPress Playground.

The Dev Chat agenda for August 18, published by JB Audras, calls the week what it is: WCUS 2026 is this week, and WordPress 7.1 is slated for release live at WCUS on August 19th. The trunk branch opened for 7.2 back on August 10; the 7.1 branch now requires double sign-off for any commit.

If you missed the substance, the 7.1 Field Guide by Milana Cap is the single index: 310-plus Trac tickets, 100-plus enhancements, 180-plus bug fixes, 600-plus Gutenberg enhancements, and 630-plus Gutenberg bug fixes. Headliners include client-side media processing, the SVG Icon API, the persistent admin toolbar across editor screens, an enforced iframed post editor, the fully-fledged Abilities API, and responsive block styles with configurable viewports.

Why it matters for WordPress / WooCommerce people

Release day is only visible when it goes wrong. The reason it usually does not — for WordPress specifically — is exactly the kind of choreographed handoff Krupa’s post describes. This is the governance layer that scales, and it is one of the quiet reasons WordPress keeps winning enterprise pitches against shinier things. Twenty-two point releases in one afternoon when the 7.0.4 security patch shipped last week came out of the same machinery.

For agencies, three practical points.

The freeze runs from Monday 14:00 UTC through Wednesday’s release. If you run WordPress managed hosting, your compatibility work is now — not Wednesday afternoon. Every hosting partner I have worked with pre-stages the package on a canary fleet before the public URL flips.

The publish moment on Wednesday at 23:10 UTC matters for scheduling. If you run change windows for enterprise WordPress or WooCommerce clients, do not schedule a 7.1 upgrade before twenty-four hours have elapsed post-release. Real-world bugs surface in the first six hours; the second wave takes another day to sort. This is the same discipline you would apply to any load-bearing dependency, and WordPress is exactly that for most of our clients.

WooCommerce 11.0.1 already declared 7.1 compatibility on August 10, so if you are on the current Woo train the store side is not the risk. The risk lives, as always, in the long tail of plugins that stopped receiving updates two years ago and whose author has moved on to a startup in a different vertical.

What I would do (or not do) about it

If you host: pre-stage 7.1 now. Verify your image editor stack (Imagick versus GD) against the client-side media processing pipeline. Warm your CDN’s canary hosts. This is the routine dry run every mature hosting operation already runs; if you are not running one, Wednesday is the day you find out why you should.

If you run production sites: do not enable auto-updates for majors on Wednesday. Keep the switch on auto-minor-only, then walk the majors through your staging environment on Thursday and Friday. This is the boring answer and it is the right one. I have made it every cycle for a decade and I have never regretted the day I said “let’s wait until Friday” — I have regretted the days I said “let’s go now” more than once.

If you are a plugin author: your compatibility tag update belongs in a release cut this weekend, not Wednesday afternoon when the plugin repository is at peak load and your users are hitting update-all. I have watched too many plugin teams collide with the release day traffic surge because they wanted to be first. Be second. Be tested. The users who care will notice, and the users who do not care will not have punished you either way.

If you want to watch it happen: the release party is public. Join #core in the Make WordPress Slack at 19:45 UTC on Wednesday. You will see the dry run, the sign-offs, the final package build, and the URL flip. Best real-time systems-thinking course you will take this year, and free.

Boring is a compliment for a release day. That is what the 7.1 process is being engineered to be, and that is why WordPress is still the platform I choose when the client actually needs the site to work in six months.