Copy your site, update the copy to WordPress 7.1, then open the post editor and edit a real page with your real plugins active. The front end is not where 7.1 breaks.
WordPress 7.1 is scheduled for 19 August 2026. The release candidate is already downloadable, which means you can run this test before release day rather than after.
Why loading the homepage proves nothing this time
Most "test the update first" advice ends at: put it on staging, look at the site, see if it looks right.
That routine catches theme regressions. It does not catch the biggest change in 7.1, because that change is in the admin.
Starting in 7.1, the post editor is always iframed. The dev note is unambiguous: "Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content."
That is a change from 7.0, where iframing was conditional on the block API versions actually present in the post. Anything that was quietly relying on the non-iframed fallback loses it here.
The practical effect is that editor JavaScript reaching for the global document or window is now reaching for the wrong document. The dev note's fix for block authors is to use ownerDocument and defaultView instead, and useRefEffect for listeners on canvas elements.
None of that shows up on your homepage. It shows up when someone on your team opens a page to edit it and a meta box, a custom field panel, or a page-builder control is dead.
What in 7.1 is worth testing
Three things, in order of how likely they are to bite.
The iframed post editor. The 7.1 field guide says plugins that reach across the editor document boundary should review their JavaScript and CSS. Custom meta boxes, custom blocks, and anything that injects UI into the editor are the candidates.
jQuery UI moved to 1.14.2. The field guide flags this as needing testing for plugins that depend on jQuery UI behaviour or styling. Datepickers, sortable lists, and admin tabs are where you will see it.
Blocks below API version 3. The dev note says most blocks already work in the iframed editor without changes, which is the honest framing. It is the custom ones nobody has touched in two years that need a look.
To be clear about what is not on this list: the new responsive styling controls, the Tabs and Playlist blocks, and the client-side image processing are features, not breakage risks. They are worth trying, but they are not what a compatibility test is for.
Do not test the release candidate on production
This is stated on the release post itself, and it is worth repeating because people do it anyway: "Please do not install, run, or test this version of WordPress on production or mission-critical websites."
The same post recommends evaluating it on a test server and site instead. A release candidate signals the potential to be a final release, which is not the same as being one.
The routine
The goal is one throwaway copy of your real site, on 7.1, that you can break without consequence.
1. Copy the site. Cloner packages the live site and restores it into a sandbox. It reads from production and never writes back, so the source site is untouched.
The copy arrives on whatever WordPress version the source site runs. You update it afterwards, inside the sandbox, which is the point: you are testing the upgrade path, not a fresh install.
2. Update WordPress inside the copy. Over SSH:
sandywp ssh my-site --cmd "wp core update --version=7.1-RC3"
Or from wp-admin, using the WordPress Beta Tester plugin on the "Bleeding edge" channel with the "Beta/RC only" stream. Swap the version number for 7.1 once the stable release is out.
3. Turn the error log on before you start clicking. In the sandbox's Debug section, enable WP_DEBUG and WP_DEBUG_LOG, then read debug.log in the browser. See Debug mode.
A JavaScript failure in the iframed editor will not write to the PHP log, so keep the browser console open too. That is where an iframe boundary error actually surfaces.
4. Click the list. Not "look at the site". This specific list:
- Open an existing post with real content and real meta boxes. Every panel your plugins add should render and accept input.
- Save it. Reload. Confirm the values persisted.
- Insert each custom block your site uses, in the editor, and change one setting on each.
- Open a page built with your page builder and move something.
- Open any admin screen with a datepicker or a drag-to-sort list, which is your jQuery UI check.
- Run one full front-end journey: a form submission, a checkout, whatever your site is actually for.
5. Write down what broke, then throw the site away. If you want to re-run the same test after a plugin author ships a fix, save the copy as a Template first so you can restore that exact starting state instead of cloning again.
If you maintain the plugin rather than the site
Then you want the opposite environment: a clean 7.1 install with only your plugin on it, so nothing else can be blamed.
Our WordPress 7.1 launcher creates one with your plugin or theme already installed, from a wordpress.org slug or an uploaded ZIP. There is also a per-feature test guide on that page adapted from the Help Test WordPress 7.1 post.
Then do the other half, which is the half people skip. Test your plugin alongside the five plugins your customers actually run it with. A clean install tells you your code is fine on its own, which is rarely the question.
The release candidate announcement also asks plugin authors to update the "Tested up to" version in the readme to 7.1. Do that after you have tested, not before. It is a self-declared field, and the whole value of it to a site owner depends on it meaning something.
What a sandbox will not tell you
Being honest about this is more useful than pretending otherwise.
It will not reproduce load. A copied site with one visitor will not surface a query that only degrades at concurrency.
It will not reproduce your host. Object cache, edge cache, WAF rules, open_basedir, and a stale OPcache serving an old compiled file all live above the application, and a sandbox has none of them.
It will not reproduce anything bound to your domain. Licensed pro plugins, real payment gateways, OAuth callbacks, and email deliverability all key off the production hostname, and some pro plugins will refuse to update on a copy.
For those, you want a staging site on the same host, or a canary: update one low-traffic site first and watch it for a few days.
One more thing worth saying plainly. A clone carries your user table, so if the site has customers on it, treat the copy with the same care as production and delete it when you are done.
The short version
Copy the site, update the copy, then open the editor rather than the homepage. WordPress 7.1's headline compatibility risk is admin-side, and the front end will look completely fine while it is broken.
If you do this before 19 August, you also get the version of this problem where the fix is "wait for the plugin author" rather than "roll back production at 9am".
Further reading: testing a plugin update without breaking your live site and upgrade testing.
