If you’re doing website development on WordPress right now, something changed recently, and it’s already causing website problems. Here’s what you need to know. In WordPress 7.1, the page editor now runs inside its own separate ‘box’ (iframe) all the time, not just sometimes like before. That single shift is enough to break older ACF Blocks, and if you manage websites for clients, this means extra support requests you didn’t plan for.

Here’s why this matters: ACF Blocks V2 depends on scripts and styles loaded in wp-admin, things like the classic WYSIWYG editor and jQuery UI date pickers. With WordPress 7.1, the editor canvas is completely separated from wp-admin for both block themes and classic themes.

Because of this change, some older plugin fields can no longer connect to the editor properly. Instead of letting you edit content directly on the page, they just show a preview now, which is a step down from what editors are used to.

We’ve gotten a lot of questions about this all week. So let’s go over what changed, why it’s happening, and how to fix it before it costs you a client. This is the difference between careful website development and work that breaks the moment WordPress updates.

What WordPress 7.1 Actually Changed

Now, the editor always shows your page inside a separate frame (iframe). WordPress has been slowly moving to this for a while, and version 7.1 makes it permanent for every site, whether it uses a block theme or a classic theme. The idea is to make what you see in the editor match what visitors see on the actual site. But this same separation is what breaks older ACF Blocks.

ACF PRO 6.8.9 responded by changing the default block version. Any block that doesn’t explicitly declare a version now registers as V3 automatically on WordPress 7.1 and later. No code changes required for those blocks. But the editing experience changes, and your clients will notice. If website development is part of your job, this is exactly the kind of core-level shift you need to track before it lands on your desk as a support ticket.

Why ACF Blocks V2 Breaks Inside the Iframe

ACF built V2 edit mode on the assumption that the editor and the admin shared the same JavaScript context. It leaned on wp-admin libraries for rich text editing, date pickers, and media selection. Once the canvas moves into an iframe, those libraries simply aren’t there. Fields that used to render inline now show a placeholder with an edit button, and editors have to work from the sidebar instead.

If your blocks already explicitly set a version (acf.blockVersion or acf_block_version set to 1 or 2), ACF PRO 6.8.9 doesn’t touch them. They keep running on V2, and they’ll keep hitting the iframe problem until you migrate them yourself.

ACF Field Groups vs. ACF Blocks: Don’t Confuse Them

This trips people up constantly, so let’s be clear. ACF field groups are the custom fields you attach to posts, pages, or other content types. They’re not versioned, and they aren’t affected by any of this.

ACF Blocks are a separate feature: blocks registered specifically for the block editor, either through acf_register_block_type() in PHP or through block.json for JS-registered blocks. The V2-to-V3 migration only touches ACF Blocks. Your field groups keep working exactly as they always have.

When You Actually Need to Migrate

Not every block needs immediate attention. If a block already explicitly declares V3 or has no version set and is now defaulting to V3 under ACF PRO 6.8.9, you’re already fine. The blocks that need your attention are the ones with an explicit V2 or V1 declaration, especially any that use mode: ‘edit’ with supports: { mode: false } to lock editors into inline editing.

Those are the blocks most likely to frustrate your content team right now.

How to Migrate a Custom Block

For blocks registered in PHP with acf_register_block_type(), migration is one line. Add ‘acf_block_version’ => 3 to the registration array, and the block moves to V3. For JS-registered blocks, add “acf”: { “blockVersion”: 3 } to block.json.

Here’s the part that surprises people and the part that matters most for anyone billing hours on website development: your rendering templates and your ACF fields usually don’t need to change at all. V3 changes how editors interact with the block in wp-admin—it doesn’t touch how the block renders on the front end. If your front-end markup depends only on the fields themselves and not on V2-specific editor behavior, you can flip the version and move on.

Practical Examples

Take an accordion block made with repeater fields. If it displays purely based on the field data on the live site, updating it to V3 is simple; just add the version flag, and no other changes are needed. The same goes for an Image Link Button block that pulls an image, a link, and text from field groups.

A custom button block using mode ‘edit’ to force inline editing needs a bit more care: add render. Preview: false alongside the V3 flag so editors still get a clean, direct editing experience instead of a live preview they have to click through.

Third-Party and Plugin ACF Blocks

If a block ships from a plugin you didn’t build, don’t edit it directly—your changes vanish on the next plugin update. Instead, flag the issue with the plugin developer and ask when they’re planning their own V3 migration.

Most active WordPress plugins are already tracking this, since it affects any WordPress web developer maintaining blocks for someone else’s product, and it’s a routine part of the website maintenance services we run for clients who use several third-party plugins at once.

The Temporary Bridge: ACF’s Compatibility Plugin

If you’re not ready to migrate everything today, ACF has published an official compatibility plugin that restores V2 editing behavior on WordPress 7.1 while you plan your migration. It’s explicitly a bridge, not a long-term fix. Install it, buy yourself time, and use that time to actually migrate rather than letting it become a permanent crutch.

Any WordPress web developer relying on it past a few release cycles is taking on unnecessary risk, since WordPress core keeps evolving the iframe-ed editor, and nothing guarantees the bridge keeps working forever.

Testing Before You Touch Production

Never migrate blocks directly on a live site. Set up a staging or local WordPress 7.1 environment first, install ACF PRO 6.8.9 or later, and test every block your site actually uses in content. Check the front-end render, check the admin editing experience, and check for console errors.

This is the kind of testing discipline that separates a careful WordPress web developer from someone who’s going to get a panicked call at 11pm. It’s exactly what TechSimba builds into every staging environment we set up, whether the change comes from ACF, WordPress core, or the website hosting stack underneath.

A Practical Migration Checklist

• Audit every custom block for its current acf_block_version or block Version setting
• Identify blocks using mode: ‘edit’ with supports: { mode: false }—these need the most attention
• Update ACF PRO to at least 6.8.9 across every site you manage
• Test each migrated block in a staging WordPress 7.1 environment before touching production
• Check third-party and plugin blocks with their maintainers instead of patching them yourself
• Install the official ACF compatibility plugin only as a temporary bridge, never a permanent fix
• Document which blocks are migrated and which are still pending, especially across a website development portfolio with many client sites.

Good website development work has always meant staying ahead of changes like this instead of reacting to them after a client complains. That’s true of the code itself, and it’s just as true of the infrastructure underneath it. Website hosting environments that lag behind WordPress core versions create their own compatibility headaches, separate from anything ACF-related. Keeping WordPress core, PHP, and your website hosting stack current is part of the same discipline as migrating your blocks.

This is also where ongoing website maintenance services earn their keep. A site that gets regular plugin and core updates, tested in staging before anything touches production, doesn’t get blindsided by changes like the WordPress 7.1 iframe shift. Sites running without that kind of active oversight tend to discover these issues the hard way, usually when a client calls asking why the editor looks broken.

At TechSimba, we handle exactly this kind of website development work for clients who don’t have an in-house WordPress web developer watching every core release. Our website maintenance services include exactly this: staging tests before core updates, block audits when plugins like ACF ship breaking changes, and website hosting configurations built to handle updates without downtime.

If you’re managing WordPress sites and don’t have the bandwidth to track every ACF release note, that’s precisely the gap our team fills.

Whether you need a full website development project, a WordPress web developer, or someone quietly managing website maintenance services in the background, this kind of update is exactly why that relationship pays for itself.

Frequently Asked Questions