WordPress 7.1 admin tables: what actually breaks

What we found, in one table

The short version, before the reasoning.

If you run stock plugins and nobody has written custom CSS or JavaScript for your admin, that table is the whole article. The rest is for the people who need to prove it, or who have custom code and need to find it.

What changed in the markup

Here is the definition, in one sentence you can forward to whoever maintains your site.

In WordPress 7.1 the checkbox cell in every admin list row stops being the row header and becomes a plain cell, while the title cell becomes the row header and carries the item's name as a label for screen readers.

This is what WordPress 7.0.3 produces for the first row of the posts list:

<th scope="row" class="check-column"> … checkbox
<td class="title column-title has-row-actions column-primary page-title"> … title

And this is the same installation, minutes later, on 7.1-RC2:

<td class="check-column"> … checkbox
<th scope="row" class="title column-title has-row-actions column-primary page-title"
    aria-label="Articolo di prova 3"> … title

The classes are identical. What changes is the tag carrying them, plus the new label. That is the entire breaking change.

The reason is good, and it is worth stating plainly: until now a screen reader announced each row as "checkbox". From 19 August it announces the post title. The developer note published on 3 August puts it like this:

"This change significantly improves accessibility for post list tables by ensuring that the naming used for screen readers to identify the current row refers consistently to the name of the relevant post."

The one plugin that breaks: Admin Columns

In assets/js/table.js, Admin Columns collects the checked rows with this selector, verbatim:

querySelectorAll("tbody th.check-column input[type=checkbox]:checked")

On WordPress 7.0.3 that selector matches four checkboxes in our test list. On 7.1-RC2 it matches zero. That is not a prediction; it is a count run against the two saved pages, the same screen before and after the upgrade.

The function feeds three others directly above it in the same file: how many rows are selected, which cells belong to the selected rows, and whether everything is selected. With zero where four used to be, the selection layer still draws but has nothing to work on.

The current public version is 7.0.19, released on 29 May 2026 — two months before this change was announced. Elsewhere in the same file the plugin uses .check-column input[type=checkbox] without naming the tag, which survives the change untouched. The breakage is one selector, not a plugin-wide problem, and it is the kind of thing that gets fixed in a point release.

The two false alarms, and why they matter

The posts screen with our twelve plugins active loads 195 stylesheets and scripts. We downloaded every one of them and searched for the names of the two cells. Three plugins came back. Two of them are noise, and the reason each one is noise is the useful part.

All in One SEO has six rules written on th.check-column across two stylesheets that the posts screen genuinely loads. Every one of them is prefixed with .aioseo-wp-table, which scopes them to the tables the plugin draws on its own screens. The WordPress posts list never sees them.

Yoast SEO ships a closest("th") in edit-page.js, which to an automated search looks exactly like the problem. Read in full, it walks up from a help icon in the table header — the row of column names at the top, which stays th in 7.1. Yoast is not affected.

Seven screens, not just posts

Here is where the test found something the announcement does not say.

The developer note is titled Post list tables row headers changed, and the coverage that followed repeated the same scope: post, page and custom post type lists. We checked seven different admin screens. All seven changed.

The reason is in the core source, and it makes the result predictable in hindsight. The change does not live in the class that draws the posts list. It lives in WP_List_Table, the base class every admin list table inherits from. This is the line, in wp-admin/includes/class-wp-list-table.php:

if ( 'cb' === $column_name ) {
    echo '<td class="check-column">';
    echo $this->column_cb( $item );
    echo '</td>';
}

If you have a custom plugin with its own admin list — and extending that class is the documented way to build one — you inherit the change without having touched anything. That is the part worth passing on to whoever wrote it for you.

How we tested it

Nothing here is hard to reproduce, which is the point.

One clean install in an isolated container, twelve plugins active at once, seven screens saved as HTML, core upgraded in place, the same seven screens saved again with the same session. Then a search across every asset the posts screen loads.

Who is actually at risk

Check your own site in ten minutes

Without a terminal. Open the posts list in the admin, right-click a checkbox and choose Inspect. If the highlighted element is a <th>, you are still on 7.0. Then look at your active plugins and ask which of them add columns, reorder rows, or do bulk editing on that screen. Those are your candidates, and they are the only ones worth putting on a test copy.

With a terminal, from the site root:

grep -rn "th\.check-column" wp-content/plugins wp-content/themes
grep -rn "td\.column-title\|td\.title\b" wp-content/plugins wp-content/themes

Every hit is a suspect. To tell whether it is a real problem, ask two questions. Is the file actually loaded on the list screens, or does it live on a settings page of its own? And is the rule prefixed by a class belonging to the plugin, the way All in One SEO scopes its own? A yes to the second question means you can move on.

The developer note also gives the fix, and it applies just as much to two lines of custom CSS in an admin theme:

"Retaining both td and th selectors will support retaining compatibility with versions of WordPress prior to 7.1."

In practice: do not swap th.check-column for td.check-column. Write both, separated by a comma. The rule then works on either version and you never have to come back to it.

What does not happen on 19 August

• The public site does not change. No page, no form, no price, no load time. The change lives entirely inside /wp-admin/.
• No column disappears. In our test all fourteen columns on the posts screen kept their place and their data, including the six Yoast adds.
• This is not a security issue. It is a planned accessibility fix, announced sixteen days ahead. Security releases look different — the WooCommerce Social Login flaw from earlier this month is what one of those looks like.
• Core's own quick edit keeps working. WordPress updated its own selectors together with the markup; list-tables.css in 7.1-RC2 declares both the old and the new form in the same rule.
• Nothing changes for search. No indexed content is touched, so there is nothing to re-crawl and nothing to fix afterwards.

Who says they have tested it, eight days out

Every plugin in the official directory declares the WordPress version it has been tested up to. It does not declare compatibility; it declares that somebody looked. It is the only public signal you get, and reading it is free.

Added up, those twelve are over 66 million active installs — and WordPress.org rounds those figures down, so the real number is higher. Eight days before a release, eleven of twelve still saying 7.0.3 is ordinary: many authors update the line on release day or in the week after. It is not evidence that eleven plugins will break. It is a measure of how many houses have the lights on.

Glossary, for the people who sign off the update

Three levels: find yours

• Stock plugins, no custom admin code. First level. Update whenever you like, open the posts list once afterwards, move on.
• Plugins that add columns, reorder rows or do bulk edits. Second level. Test on a copy before the 19th, and if the author has not declared 7.1 yet, wait a week. Waiting costs you nothing.
• A bespoke plugin, an admin theme, or CSS somebody wrote for you. Third level. Run the two searches today. If they return anything, the fix is a comma and two words, and whoever wrote it can apply it in half an hour.

If the test copy is the part you do not have — and for small sites that is the common case — that is the real problem, and it did not start with this update. Managed WordPress hosting with a staging environment exists precisely so that a Wednesday in August is not a decision. We set it up for the sites we look after, and it is not something you buy in a hurry: it is something you prepare once and then forget about.

Questions nobody has actually asked us

Nobody has written to us about WordPress 7.1 yet: the release candidate is a week old and the change is buried in a developer note. These are the questions we would ask reading the announcement cold, plus the ones that come up every time a major update approaches.

Last updated: 11 August 2026. WordPress 7.1 is scheduled for 19 August 2026 according to the official WordPress.org roadmap; release candidate 2 is the most recent build on the beta channel. The test described on this page was run on 11 August 2026 against WordPress 7.0.3 and 7.1-RC2, on PHP 8.3, with the twelve plugins listed in the table. We will repeat the same test on the final release on 19 August and update this page with the result, including the tested-up-to column, which changes for almost every plugin on release day.