# WordPress 7.1 admin tables: what actually breaks

> We ran WordPress 7.1-RC2 against 12 popular plugins on one install: 7 admin screens changed, 3 plugins name the moved cells, 1 actually breaks.

Source: https://cittago.com/blog/wordpress-7-1-tabelle-pannello-2026/  
Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011  
Published: 2026-08-11  
Language: en

---

We installed the release candidate with twelve of the most popular plugins and compared the HTML of seven admin screens, before and after. Three plugins reference the cells that move. One of them stops working. Here is which, and how to check your own site.

**What we did.** WordPress 7.1 ships on 19 August 2026 and moves the row header in admin list tables from the checkbox cell to the title cell. We ran the release candidate against WordPress 7.0.3 on the same installation, with twelve popular plugins active, and diffed the HTML of seven admin screens.

**What we found.** Every one of the seven screens changed, not only the post lists. Of the 195 stylesheets and scripts the posts screen loads, three name the cells that move. Only one of the three actually breaks: Admin Columns loses its row selection. No column disappeared, and the public site is untouched.

**Why it is worth half an hour.** Because the update lands on many installs automatically, because it is a Wednesday in the middle of August, and because the check that tells you whether you are one of the few takes ten minutes with two grep commands.

- The exact markup, before and after, from a real install.
- The one selector that goes from four matches to zero.
- Why two of the three plugins our search flagged are false alarms.
- The two lines to search for in your own theme and plugins.

On this page

1. [What we found, in one table](#what-we-found)
2. [What changed in the markup](#what-changed)
3. [The one plugin that breaks: Admin Columns](#admin-columns)
4. [The two false alarms, and why they matter](#false-alarms)
5. [Seven screens, not just posts](#seven-screens)
6. [How we tested it](#method)
7. [Who is actually at risk](#who-is-at-risk)
8. [Check your own site in ten minutes](#ten-minutes)
9. [What does not happen on 19 August](#what-does-not)
10. [Who says they have tested it, eight days out](#tested-up-to)
11. [Glossary, for the people who sign off the update](#glossary)
12. [Three levels: find yours](#three-levels)
13. [Questions nobody has actually asked us](#questions)

## 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:

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

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](https://make.wordpress.org/core/2026/08/03/post-list-tables-row-headers-changed/) 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 reference page for [single_row_columns()](https://developer.wordpress.org/reference/classes/wp_list_table/single_row_columns/) still shows <th scope="row" class="check-column">, because it documents the stable release. The code quoted above comes from the 7.1-RC2 files on a running install, not from the docs. That gap is exactly why we ran the test instead of trusting the note.

## The one plugin that breaks: Admin Columns

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

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](https://wordpress.org/plugins/codepress-admin-columns/), 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.

Searching for the cell name in your codebase gives you suspects, not culprits. Out of three plugins the search flagged, one breaks, one changes some padding on its own screens, and one has nothing to do with it. Anyone who hands you a grep output and calls it an audit has done the first half of the job.

## 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](https://developer.wordpress.org/reference/classes/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 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.

*This is the screen that changes. What your visitors see stays exactly as it was, before and after the update.*

## 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:

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](https://cittago.com/blog/woocommerce-social-login-cve-2026-8457/) 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.

That field is a sentence written by the plugin author, not a certification issued by WordPress. A plugin declaring 7.0.3 is not automatically broken on 7.1, and one declaring 7.1 is not automatically fine. It tells you who has already looked, nothing more.

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.

*19 August 2026 is a Wednesday. Sites on automatic updates will find out on their own; a shop trading through August should pick the day.*

## 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](https://cittago.com/services/hosting/) 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.

*Same installation, WordPress 7.0.3 and 7.1-RC2, 11 August 2026*

| Question | Answer |
| --- | --- |
| Does the public site change? | No. Not one page, not one byte of front-end markup |
| Do any admin columns disappear? | No. All fourteen columns on the posts screen survived |
| How many admin screens changed? | Seven out of seven we checked |
| How many of twelve plugins reference the moved cells? | Three |
| How many actually break? | One: Admin Columns, row selection |
| How many declare they have tested 7.1? | One: Wordfence |

*Rows with a swapped cell, same site before and after the upgrade*

| Admin screen | Rows | WordPress 7.0.3 | WordPress 7.1-RC2 |
| --- | --- | --- | --- |
| Posts | 4 | header on the checkbox | header on the title |
| Pages | 7 | header on the checkbox | header on the title |
| Media, list view | 2 | header on the checkbox | header on the title |
| Comments | 1 | header on the checkbox | header on the title |
| Plugins | 14 | header on the checkbox | header on the plugin name |
| Users | 1 | header on the checkbox | header on the name |
| Categories | 1 | header on the checkbox | header on the name |

*Test parameters, for anyone who wants to repeat it*

| Parameter | Value |
| --- | --- |
| Starting version | WordPress 7.0.3 |
| Target version | WordPress 7.1-RC2 |
| PHP | 8.3 |
| Database | MariaDB 11 |
| Plugins installed and active | 12, at their public version on 11 August |
| Admin screens compared | 7 |
| Comparison | HTML of the same page, same logged-in user, before and after |
| Test date | 11 August 2026 |

*How much this concerns you, based on what is on your site*

| Your situation | Risk | What to do |
| --- | --- | --- |
| Only plugins from the official directory, no custom code | Low | Update, then open the posts list once |
| Plugins that add columns to the lists | Medium | Test on a copy before the 19th |
| Reordering or bulk-edit plugins | Medium | Test multiple selection on the copy |
| Custom admin CSS | High | Search for th.check-column today |
| Custom JavaScript that reads the checkboxes | High | Search for th.check-column today |
| A bespoke plugin with its own admin list | High | Send the line to whoever wrote it |

*Active installs and declared tested-up-to version. Source: the [WordPress.org plugin directory](https://wordpress.org/plugins/), read through its API on 11 August 2026*

| Plugin | Active installs | Tested up to | Last updated |
| --- | --- | --- | --- |
| Yoast SEO | 10,000,000+ | 7.0.3 | 4 August 2026 |
| Contact Form 7 | 10,000,000+ | 7.0.3 | 15 May 2026 |
| Elementor | 10,000,000+ | 7.0.3 | 6 August 2026 |
| Classic Editor | 9,000,000+ | 7.0.3 | 28 May 2026 |
| WooCommerce | 7,000,000+ | 7.0.3 | 10 August 2026 |
| WPForms Lite | 5,000,000+ | 7.0.3 | 16 July 2026 |
| Wordfence Security | 5,000,000+ | **7.1** | 10 August 2026 |
| Rank Math SEO | 4,000,000+ | 7.0.3 | 28 July 2026 |
| All in One SEO | 3,000,000+ | 7.0.3 | 3 August 2026 |
| Yoast Duplicate Post | 3,000,000+ | 7.0.3 | 22 June 2026 |
| Post Types Order | 600,000+ | 7.0.3 | 18 June 2026 |
| Admin Columns | 100,000+ | 7.0.3 | 29 May 2026 |

*Five terms the rest of the page depends on*

| Term | What it means |
| --- | --- |
| List table | The admin screen that shows rows: posts, pages, products, plugins, users. WordPress calls them list tables. |
| Row header | The cell that names the row, so a screen reader can say "you are on the row for this post". In code it is a <th scope="row">. |
| Selector | The phrase CSS and JavaScript use to point at a cell. th.check-column means: the header cell with the checkbox class. Change the tag and the selector matches nothing. |
| Release candidate | The near-final build, published so people can test before release. 7.1-RC2 is what we tested against. |
| Tested up to | The WordPress version a plugin author says they have tried. A statement, not third-party testing. |

## Questions and answers

**Will WordPress 7.1 break my plugins?**

Almost certainly not. In our test with twelve of the most widely installed plugins, one selector in one plugin stopped matching: row selection in Admin Columns. Nothing else changed behaviour, no column disappeared, and the public site is untouched in every case.

**Should I delay the update?**

Delaying by a week or two on a site that takes orders is a defensible choice, as long as it is a choice and not an oversight. Delaying for months is not: later versions carry security fixes, and a site six months behind is a far more concrete problem than two swapped cells.

**Does this affect WooCommerce product lists?**

Yes, because the product list inherits from the same base class as every other admin list. WooCommerce was active throughout our test and showed no problems of its own; its columns stayed in place. If you sell online, the things to check are plugins that add columns or bulk actions to products.

**I have a custom plugin with its own admin table. What do I tell the developer?**

One line: in 7.1 the checkbox cell becomes a td and the primary column becomes a th, so search our code for th.check-column. The recommended fix from core is to keep both selectors, separated by a comma, so the code works on either version.

**Why is WordPress making a change that can break things?**

Because the old behaviour was wrong for anyone using a screen reader: each row was announced as "checkbox" rather than by the post title. It is an accessibility fix that has been requested for years, tracked as ticket 32892.

**How do I know whether my theme has custom admin CSS?**

Search the theme folder for th.check-column, and separately look for any file whose name suggests the admin — admin.css, admin.js, backend.css. Most themes have none of this. The ones that do are usually themes built for a specific company rather than bought from a marketplace.

**Does this change anything for SEO or page speed?**

Nothing at all. No public page is touched, so there is nothing to re-crawl and no effect on load times. If speed is what you are actually chasing, the answer is somewhere else entirely: why PageSpeed says 68 on mobile and 96 on desktop.

**Is the accessibility improvement worth the disruption?**

On the evidence of this test, the disruption is one selector in one plugin with 100,000 installs, against every screen reader user in the WordPress admin getting the post title instead of the word "checkbox". That trade looks reasonable, and it is the kind of change that is only ever painful once.

**Can I see the change without installing the release candidate?**

Not on your own site, no. The reference documentation still shows the 7.0 markup because it documents the stable release, which is exactly why we quoted the file from a running 7.1-RC2 install rather than the docs. If you want to see it yourself, a throwaway container takes about fifteen minutes.

**What would you do if this were your client's site?**

On the sites we look after we run the update on the staging copy on release day, open the posts list and the products list, try one bulk edit and one quick edit. If those pass, the live site is updated the next day. Fifteen minutes, and it is the same fifteen minutes for any version.

---

Cittago · https://cittago.com · digital marketing, SEO, AI search, Google Ads and web development for small and medium companies in Romania, Italy and the EU.