fixmation.Get my quote
Websites10 min readPublished August 2026

WordPress 7.1 has landed. Your Orders screen may not have survived

WordPress 7.1 rearranged the markup of post list tables on 19 August. WooCommerce shipped the fix nine days earlier, in 11.0.1. The breaking half can install itself overnight; the fixing half only installs if you turned that on, per plugin.

What happened on 19 August?

WordPress 7.1 shipped, and it changed the HTML of post list tables - the admin screens that list items in rows with checkboxes. WooCommerce already adapted the Orders screen in version 11.0.1, which is how we know that screen is in scope. A store running WooCommerce 11.0.0 when WordPress 7.1 arrives has the new markup underneath code written for the old.

The date was fixed and published in advance:

The scheduled final release date for WordPress 7.1 is August 19, 2026

So if your site takes major updates by itself, it may already be on 7.1.

What exactly changes in the markup?

One cell stops being the row's header and another starts. In every post list table, the checkbox column was the row header; now the title column is. The developer note gives the before and after:

<th scope="row" class="check-column">

<td class="check-column">

and the title cell picks up the role the checkbox gave away:

<th scope="row" class="title column-title column-primary page-title" aria-label="Hello world!">

This is an accessibility improvement, and the reasoning is sound - the note explains it is done by

ensuring that the naming used for screen readers to identify the current row refers consistently to the name of the relevant post, rather than referring to a selection checkbox that may not be present if the post is not currently available for editing

A screen reader announcing "Invoice 1043" instead of "checkbox" is plainly better. The cost is that any code selecting those cells by their old tag now selects nothing, and code that selects by tag is everywhere in plugin land.

Why does an accessibility fix break a shop screen?

Because plugins style and script those tables by pointing at specific cells, and a cell that changed its tag is a pointer that no longer lands. Nothing errors; a rule simply stops matching, and behaviour attached to it stops happening.

WooCommerce confirmed the Orders screen was in that category by fixing it. The 11.0.1 release notes list the change under Updates as "Increased compatibility for the upcoming WordPress 7.1 release", and spell it out:

The Orders list is compatible with WordPress 7.1's updated list-table markup. Checkbox interactions and responsive layouts work correctly with both the old and new primary-cell markup.

Read that as a description of what breaks without it. The two behaviours the vendor names are checkbox interactions and responsive layouts - which in daily terms means selecting orders to act on in bulk, and the Orders screen on a phone.

What will it look like if it hits you?

Not like a crash. The store keeps selling, the Orders screen still lists orders, and the trouble is confined to working with them: ticking boxes, running bulk actions, reading the screen on a small display. Staff will describe it as "the orders page is being weird", which is not a phrase that leads anyone to a WordPress release note.

Two honest limits on what I can tell you here. First, WooCommerce's phrasing names the affected behaviours but not the exact symptom, so the precise way it misbehaves on your setup is not something the vendor has published. Second, 7.1 shipped only hours ago, so there is not yet a body of reports from live stores - which is exactly why checking beats waiting to be told.

One tester has already described the shape of it, though, in a comment on the developer note itself on 16 August: "There is a problem with new list table. If the table has no check box column, when viewing from small screen, the design will breaks. The second column will be pull up next to first column when opened." That was produced by removing columns from an ordinary Posts table in a browser inspector, not from a shop - but it is the same mechanism the Orders screen depends on.

Will WordPress 7.1 install itself on your site?

Maybe, and the answer depends on something most owners have never thought about: how old the installation is. This is the fork that decides whether you have a deadline or a decision. WordPress documents it directly:

Before WordPress 5.6, every site had automatic updates enabled for minor core releases and translation files only by default. Starting with WordPress 5.6, new installations have automatic updates enabled for both minor and major core releases by default, unless WordPress detects a version control checkout. Existing installations keep the previous behavior unless major core auto-updates are enabled by a site administrator, constant, or filter.

The same page says it again, this time describing what happens when the WP_AUTO_UPDATE_CORE constant is not defined:

Existing installations receive minor core updates by default. Fresh installations created on WordPress 5.6 or later receive both minor and major core updates by default, unless WordPress detects a version control checkout.

So the question to answer is which side of WordPress 5.6 your installation was born on. A store set up on 5.6 or later is likely to take 7.1 by itself; an older one probably will not, unless somebody turned major updates on. Neither group is safe by default: the first may already have taken it, the second has a broken screen waiting whenever they get around to updating.

When your site was first installedWhat 7.1 does by defaultWhat that means for you
On WordPress 5.6 or laterInstalls itselfCheck WooCommerce is on 11.0.1, today
Before WordPress 5.6Waits for youUpdate WooCommerce first, then WordPress, on your schedule
Anywhere, but an admin enabled major auto-updatesInstalls itselfSame as the first row
Managed hostingDepends on the host's own policyAsk the host, in writing, today

Why will the fix not arrive the same way the problem does?

Because core updates and plugin updates run on different consent models. The breaking change can arrive automatically, as the quote above establishes. The fix - WooCommerce 11.0.1 - only arrives automatically if somebody switched auto-updates on for that specific plugin, and WordPress makes that a per-plugin choice:

Navigate to Plugins Screen. For each plugin, there is an "Automatic update" column with an action link used to enable/disable auto-updates plugin by plugin. Click on this action link to enable auto-updates for each specific plugin.

That asymmetry is the whole risk in one sentence: the half that breaks things can install itself while you sleep, and the half that repairs it waits for a decision you may never have been asked to make.

Even with the toggle on, the timing is not instant. WordPress checks on a schedule rather than the moment a release appears:

By default WordPress runs auto-updates twice per day.

How do you check where you stand in two minutes?

Log in and read two version numbers. That is the entire diagnosis, and it costs less than reading this article:

  1. Open Plugins in the admin menu and find WooCommerce. The version sits under the name. If it says 11.0.1 or higher, the Orders screen is already braced and you are done.
  2. If it says 11.0.0, update WooCommerce now. This is the whole fix for most stores, and it works whether or not 7.1 has already arrived.
  3. Check your WordPress version at Dashboard, then Updates. If it already reads 7.1, the change is live on your site right now.
  4. Decide about major auto-updates deliberately. If you cannot tell whether they are on, assume they are and check both versions now.
  5. Ask your host if the site is on managed hosting. Whether they apply their own update schedule, and whether it overrides what you set in the admin, is something only they can tell you - so ask rather than assume.
  6. After both are updated, open Orders and use it properly: tick two orders, run a bulk action, then open the same screen on a phone. Looking at the page is not the same as using it, and the reported symptoms are about using it.

Why not just turn updates off?

Because the alternative failure is worse and slower. Switching off updates converts a one-day compatibility problem into an indefinite security problem, and the security clock does not care that your Orders screen is fine. The gap between a patch being published and installed is its own measurable exposure, and freezing your site makes that gap permanent: the version you stayed on is the version attackers have notes for.

The proportionate response is narrower: update the plugin now so the core release finds a compatible store, keep automatic updates for security releases, and check the screens your staff actually use afterwards.

What if the Orders screen is already misbehaving?

Then check versions before you touch anything else, because this class of problem masquerades as several other ones. A screen that renders but does not respond looks like a caching problem, a theme conflict, or a plugin clash, and each of those sends you down a different rabbit hole.

The tell is timing: if the trouble started with an update rather than with a change you made, the mismatch is between two versions, not inside one of them. That is the same reasoning that applies when an automation that ran fine for months suddenly stops - somebody else's release is a cause, even though nothing in your own setup moved.

When is this worth handing to someone else?

For most stores this is not a job at all: read one version number, press update, use the Orders screen once. If that describes you, stop here and go do it - it is faster than arranging help.

It becomes real work when the store cannot take updates casually: when WooCommerce is behind by more than a patch and the jump carries other changes with it, when custom code or an old theme extends the Orders screen, when there is no staging copy to try it on first, or when the shop takes enough orders per hour that "we will find out tomorrow" is not an acceptable test. Sequencing those updates, checking each screen staff depend on, and having a way back if something breaks is scoped work with a defined end state, which is what a fixed-price Fix S or M covers.

Sources

  • WordPress 7.1 Release Candidate 4 - Make WordPress Core, 17 August 2026, read 18 August 2026. The scheduled final release date of 19 August 2026.
  • Post list tables: row headers changed - Make WordPress Core, 3 August 2026, read 18 August 2026. The before-and-after markup for the check column and title cell, and the accessibility reasoning. Note the scope: the note describes post list tables, not every admin table.
  • WooCommerce 11.0.1 - WooCommerce Developer Blog, 10 August 2026, read 18 August 2026. The Orders list compatibility statement, under the heading about the upcoming WordPress 7.1 release.
  • Upgrading WordPress - WordPress Advanced Administration Handbook, read 18 August 2026. Automatic update defaults for minor and major core releases, and how they differ by installation age.
  • Plugins & Themes auto-updates - WordPress documentation, read 18 August 2026. Per-plugin auto-update toggles and the twice-daily check schedule.

Site down, or broken since the last update? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.