WordPress 7.1 Beta 4 Is Here: 114 Fixes and 5 Things to Check Before You Update 

The beta window closed on 29 July. What ships on 19 August is, barring a late reversal, what you will be running. 

WordPress 7.1 Beta 4 arrived on 29 July with more than 114 fixes behind it. Fifty-one of them landed in the editor and sixty-three in core. 

It was the last beta. 

Release candidates run from 5 August to 18 August and WordPress 7.1 ships on 19 August at WordCamp US. The feature set is settled. You have roughly three weeks to find out what it does to your site. 

Methodology note

This article is based directly on the official WordPress 7.1 Beta 4 notice and related project documentation. Dates, fix counts, and feature descriptions come from those sources. The pre-update checklist and any judgments about risk or priority are our own interpretation, not official WordPress guidance. Beta features can change before release, so verify anything critical against current documentation.

What Beta 4 fixed 

Beta 4 is a bug-fix release and the fixes cluster around Notes. 

Notes now stay tied to the passage they refer to. Tagged people display cleanly. Both sound small. A comment that drifts away from the paragraph it was written about is worse than no comment at all. 

Every beta in this cycle was a bug-fix release and the full list is public. WordPress publishes the Gutenberg commits and the closed Trac tickets covering everything settled between 22 and 29 July. More will land during the release candidates. 

Most site owners can skip both lists. If you maintain a plugin, that ticket list is where you find out whether something you depend on moved. If you maintain a plugin, that ticket list is where you find out whether something you depend on moved.  

Fixes are the last thing to matter before release. What matters now is what 7.1 actually puts in front of you.

What 7.1 brings to your site 

Two features in 7.1 change how people work in WordPress. The Beta 1 announcement carries the full list. 

Notes is the first. Inline comments with @mentions and rich text formatting, built for feedback that does not need everyone inside the editor at the same time. Reviewing a draft stops meaning that you export it to email or a shared doc. 

Responsive styling is the second. You can set how a block looks at each screen width from inside the editor, for global styles and for individual blocks, without writing CSS. 

Around those sit fuller styling controls, interactive styling, a smoother media experience and a more personalized admin. 

The media fixes from Beta 3 deserve a mention. Long animated GIF uploads no longer hang. EXIF-rotated images process correctly. And a single HEIC file uploaded in Safari stops creating two entries in the media library. 

Unicode email address support was cut from 7.1 partway through the cycle. Features do move late, which is the reason to re-check anything you read in a beta announcement before you build on it. 

That is the case for wanting 7.1 now. It is also the case for testing it somewhere that does not matter.

Do not put this beta on a live site 

WordPress says this plainly and it is worth repeating. Beta releases are for testing and development. 

Use a local install or a staging environment. A production site running beta code will cost you more hours than the testing saves. 

Report what you find. General reports go to the Alpha/Beta area of the WordPress support forums. Reproducible bugs go to Trac. Read the known-bugs list first. Someone may have logged it already. The Make Core test team publishes what needs attention in each release.  

7.1 arrives whether you tested it or not. These five checks take an afternoon and save you the alternative.

5 things to check before you run the WordPress update 

The WordPress update itself takes one click. The work is everything you do before it. 

1. Test on a staging site first 

A WordPress staging site is a copy of your live site where you can run the update and watch what happens. 

Update the copy. Click through the pages that earn you money. Check your forms and anything running on a plugin you did not write. 

If the staging copy survives, the live one probably will. 

2. Audit your plugins and themes now 

Core updates rarely break WordPress. Plugins break WordPress. 

Open your plugin list and check each entry for a compatibility note against 7.1. Anything unmaintained for a year is where your risk lives. Every WordPress plugin update page on wordpress.org shows a “tested up to” version and that figure is the developer’s claim rather than a promise. An empty one tells you something too. 

Themes carry the same exposure. If you are updating a WordPress theme you customised directly instead of through a child theme, your customisations are the thing at risk. 

Three weeks is enough time to email a plugin developer and get an answer. It is not enough time on 18 August. 

3. Check your PHP version 

WordPress 7.1 runs on whatever PHP version your host gives you and an old one narrows what works. 

Find your current version under Tools, then Site Health, then Info. 

Updating PHP in WordPress is not done in WordPress. It happens in your hosting control panel, which makes it the one item here you cannot handle from the dashboard. 

Change it on staging first. Code written for PHP 7.4 can fail quietly on PHP 8.3. The PHP project publishes its own support dates and anything past end of life stops getting security patches whatever your host says. 

4. Verify your backup and your way back 

A backup you have never restored is a hope. 

Before 19 August, take a backup and restore it somewhere. Confirm the database came with it. 

Then find out how long a restore takes. Ten minutes and forty minutes are different decisions when the site is already down. 

5. Decide whether WordPress updates itself 

WordPress installs minor and security releases on its own by default. Major releases like 7.1 are opt-in and you switch them on from the Updates screen. 

Turning auto-updates off is defensible for a site carrying heavy plugin dependencies. Leaving them on is defensible for a site you log into twice a year. Not knowing which setting you are on is the only indefensible option. 

To disable auto-updates in WordPress, use the Updates screen for core and the Plugins screen for individual plugins. Setting it in wp-config.php also works and it survives someone else changing their mind in the dashboard. 

Timing is the point. You decide when 7.1 lands, which means you decide whether it lands on a day you can watch it.

If something breaks after you update 

A white screen after an update usually points at a plugin rather than core.

Deactivate every plugin, then switch them back on one at a time until the site breaks again. The last one you enabled is your answer.

If you cannot reach the dashboard at all, rename the plugins folder over SFTP. WordPress deactivates everything and lets you back in.

A WordPress site that crashes after a plugin update is a common problem and a recoverable one. WordPress update failures that lose data are almost always failures of backup rather than failures of WordPress.

Beta 4 is the last look you get before 19 August. Three weeks is enough time to email a developer, restore a backup once to prove it works and find out that something you depend on has not been touched since 2024. It is not enough time on the eighteenth.

Fourth beta, last look,
one hundred fourteen fixes,
go check your plugins.