Your communications coordinator opens a page she edits every week, and something is different. The fields she normally fills in are not where they were, or the block she used to edit right there on the page now only edits from the panel on the right. She has not changed anything. What changed is that the site updated to WordPress 7.1 on August 19.
Here is the short version, because most of what is being written about this is wrong in a way that will send you looking for a problem you do not have. If your association's site uses ordinary ACF field groups, the panels that appear below or beside the editor. They are almost certainly fine. If your site uses ACF Blocks, something specific and real has changed, and there is no way to turn it off.
Where this comes from. WordPress 7.1 shipped on August 19, 2026. Everything below is from the WordPress 7.1 Field Guide, the Make WordPress Core developer note of August 3, the block editor handbook and ACF's own changelog.
What 7.1 Actually Did
The Field Guide is direct about it, under a heading called Enforced iframed editor: WordPress 7.1 completes the move to an iframe-based post editor, including for sites that register legacy meta boxes.
The developer note is more precise. 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. In 7.0 that decision was conditional and made per post, if every block was API version 3 or higher the editor was iframed, and if any older block was present the iframe was dropped. In 7.1 that condition is gone.
The consequence for developers is a boundary problem. The iframe has its own document and window, separate from the admin page where editor scripts run, so code reaching for the global document or window to touch the canvas is looking at the wrong document.
The Part Being Reported Incorrectly
You will read that ACF field groups are being put inside an iframe for the first time. That is not what happened. Meta boxes did once block the iframe. That is true history. But it stopped being true in WordPress 6.7, released in November 2024, when core introduced a split view so that editor content and meta boxes could be visible together. The Make WordPress Core note from October 2024 says so plainly: the presence of meta boxes was a holdout condition, and the split view resolved it.
So the meta box change is about twenty-one months old, not one day old. If your ACF field groups have survived since November 2024, 7.1 did not newly disturb them. And the migration guidance WordPress publishes for the iframe change is scoped entirely to blocks. It does not address meta boxes at all.
This matters practically, not just pedantically. An agency running an emergency check across every client site, looking for broken date pickers inside ACF field groups, will mostly find nothing, conclude the update was fine, and miss the thing that did change.
What Did Change: ACF Blocks
ACF Blocks are a different feature from ACF field groups. Blocks render into the editor canvas, the part that is now always inside the iframe, and that is where field editing has been lost.
There is a report in the wild already, filed on the WordPress.org support forums on August 20, the day after release: with the update to 7.1, edit mode within the block content is no longer available, and the only way to edit the fields is now through the block panel on the right. That thread drew no maintainer response at the time. ACF Pro 6.8.9, released August 27, speaks to the underlying cause by defaulting blocks to version 3 on 7.1, though it does not answer that thread directly. It is one user across several sites, so treat it as a real early signal rather than a widespread outage, and check which ACF version you are running before assuming the report still applies.
It is also not a surprise if you follow ACF's own release notes. ACF documented back in version 6.3.11 that edit mode is no longer available to ACF Blocks using Block API version 3, because field editing is not supported in the iframe. There are open issues on ACF's GitHub about blocks and the iframed editor going back to 2023. Seven-point-one did not create this problem. It removed the last configuration in which you could avoid it.
There Is No Opt-Out
In WordPress 7.0 there was an escape hatch: insert one older-API block and the editor dropped out of the iframe for that post. That is gone. The developer note, the migration guide and the block editor handbook all describe the 7.1 behavior as unconditional, and none of them documents a filter, a constant or a setting that restores the previous behavior.
A community plugin exists that claims to restore ACF Blocks edit mode. It is unofficial, it is not endorsed by ACF or WP Engine, and it addresses one symptom. If you are considering it on a production association site, treat it as a temporary measure with an owner and a review date, not a fix.
What ACF Has Said, and When They Said It
ACF Pro 6.8.8 shipped on August 19, the same day as WordPress 7.1. The timing invites the assumption that it is a compatibility release. It is not. Its entire changelog entry is a fix so that image and gallery fields no longer reject SVG files. For the eight days after 7.1 shipped there was no 7.1 post on the ACF blog, no changelog entry mentioning the iframe, and no migration guidance. The only compatibility signal ACF had published was the passive one on its plugin listing, which now reads tested up to 7.1.
That changed on August 27, when ACF Pro 6.8.9 shipped. It addresses the iframe directly, and it does so through a default rather than an announcement. ACF Blocks registered without an explicit version now default to version 3 on WordPress 7.1 or later, and version 3 is the version built for the iframed editor. The release also adds a renderPreview option for version 3 blocks and automatically converts blocks that combined edit mode with mode support disabled. There are no security fixes in it, so it is a planned update rather than an urgent one.
What that release changes, and how to tell whether it reaches your site
The contrast in how this was handled is still worth knowing if you are choosing a field plugin. Meta Box, ACF's closest competitor, published a WordPress 7.1 compatibility note on August 11, eight days before the release, stating that its blocks already support the iframe editor through Block API version 3 and that users can upgrade without changes. Same architectural constraint, same trade-off of moving field editing to a panel, but communicated in advance rather than arriving later as a changed default.
The Check, Which Takes Two Minutes and Cannot Be Done From the Front End
None of this shows up on your public site. The front end renders exactly as it did, which is what makes it expensive. It surfaces a week later as a staff member saying the website is broken, with no deployment to correlate it against. An uptime monitor will not catch it and neither will a 200 response.
- Log into wp-admin and open a page that carries ACF fields. Confirm every field renders, accepts input and saves.
- Do the same on one post and one custom post type. They can register different field groups, and a site that is fine on pages is not automatically fine everywhere.
- Find out whether you use ACF Blocks at all. This is the question that actually determines your exposure. If your field groups are all classic panels and you have registered no ACF blocks, you are in the low-risk category.
- If you do use ACF Blocks, click one in the canvas. If editing has moved to the right-hand panel, that is the documented new behavior rather than a fault, and your editors need telling before they file a ticket.
- Open the browser console and look for errors thrown from inside the editor frame. That is where a real JavaScript boundary problem will announce itself.
Two Smaller Things Worth Testing While You Are There
Meta box overflow clipping. This is the one real field-group gotcha, and it also dates from 6.7 rather than 7.1: the meta box container clips overflowing elements, so popover-style interfaces such as dropdowns can be cut off where they extend upward. If you have a date picker or color picker near the top of a panel, that is worth a look.
jQuery UI moved to 1.14.2. Independent of the iframe change, and minor, but it drops support for older browsers and removes four APIs. WordPress core does not use them; the guidance is to check whether your own code does. Do not conflate this with the iframe story. They are separate items that happen to ship together.
Most Sites Are Fine
If your association site uses ACF field groups only, has no ACF blocks registered, and your editors report nothing unusual, this update did not affect your editing experience and no action is required. That is the majority case, and saying so is more useful than manufacturing an emergency.
The organizations that need to act are the ones running ACF Blocks, and the action is mostly communication, tell the people who edit the site that field editing has moved to the panel, before they conclude the site is broken.
If Your Editors Are Reporting Something Odd
Send us the site address and admin access, or just a screen recording of what your editor is seeing. We will tell you whether your fields are classic field groups or ACF blocks, reproduce what your staff are reporting, check the editor console for errors thrown inside the iframe, and confirm which of your environments have actually been promoted to 7.1, because a push often updates development only, and a site that looks fine today may not be running the version you think it is. You will get back a plain answer about whether anything is genuinely broken, and if it is not, we will tell you that too.