WordPress 7.1 broke ACF Pro blocks on a subset of sites. The edit toggle vanishes from the block toolbar, and the mode value in block.json gets ignored, so editors land in preview with no way to reach the fields. You fix it with a block.json change, a temporary core rollback, or both.
What broke in ACF blocks after WordPress 7.1
On affected installs, ACF Pro blocks registered through block.json come up in preview mode and stay there. The pencil icon in the block toolbar, the one that flips a block from rendered preview to the field form, does not appear. The mode property in block.json is read but not respected, so blocks you shipped as "mode": "edit" still render as preview.
What that looks like on a client site: the marketing coordinator clicks a hero block, gets the rendered hero, and has nowhere to type. Nothing throws an error. Nothing logs. The page looks fine on the front end. The client assumes they broke something, waits a day, then calls you at 4:45 on a Friday.
That is the part that costs money, and there is no outage to point at. Your uptime monitor is green, the site is fast, and no 500 error ever fires. If your first instinct is to treat it like a downed site, read our 20-minute triage order for a site you suddenly cannot access and then rule that path out fast, because this failure lives entirely inside the editor.
WordPress 7.1 shipped several editor-level changes, including the wp_pre_execute_ability filter and media library behavior we covered in the WordPress 7.1 update notes. The ACF block regression is the one that generates client tickets, because it hits the people who touch the site daily rather than the people who maintain it.
How to check every client site for the ACF block regression
Give this 20 minutes across your whole portfolio. You need three data points per site: core version, ACF Pro version, and whether the site registers ACF blocks at all. A site on 7.0.x is not affected yet, and a site with no ACF blocks is not affected at all.
Run this per site with WP-CLI:
wp core version
wp plugin get advanced-custom-fields-pro --field=version
wp eval 'var_dump( array_keys( array_filter( WP_Block_Type_Registry::get_instance()->get_all_registered(), fn($b) => str_starts_with($b->name, "acf/") ) ) );'
If you manage sites through a single control plane, script it across the fleet and dump the output into a sheet. You are building a triage list, nothing more: sites on 7.1 that register acf/ blocks go to the top.
Then open one page per site that uses a registered ACF block and click the block. If the toolbar has no toggle to reach the fields, that site is affected and someone on the client side will find it within a week.
| Core version | ACF blocks registered | Editor risk | Action this week |
|---|---|---|---|
| 7.0.x | Yes | None yet | Hold the update, add to watch list |
| 7.1 | Yes, "mode": "preview" or "auto" | High, editors are locked out | Patch block.json or roll back |
| 7.1 | Yes, "mode": "edit" already | Medium, reported inconsistently | Verify manually in the editor |
| 7.1 | No ACF blocks, fields only | None | No action |
| Any | ACF free version | None for blocks | No action |
The manual verification step matters. Two sites with identical plugin stacks can behave differently depending on theme registration order and whether a page builder wraps the editor. Ten minutes of clicking beats an assumption.
Workarounds that get editors back into the fields
Patch at the block level when you can. Setting "mode": "edit" in the block's block.json forces the field form to render, which restores editing on most affected builds. You lose the in-editor preview until the regression is resolved upstream, and most clients will happily trade preview for the ability to type.
{
"name": "acf/hero",
"title": "Hero",
"acf": {
"mode": "edit",
"renderTemplate": "blocks/hero.php"
},
"supports": {
"mode": false
}
}
Setting supports.mode to false removes the toggle from the UI entirely, which is worth doing while the toggle is unreliable. A missing control that was never supposed to be there reads as intentional. A missing control that used to work reads as a bug, and clients file tickets about bugs.
After you edit block.json, flush caches so the block registry rebuilds:
wp cache flush
wp acf cache flush 2>/dev/null || true
Then hard-refresh the editor. A stale object cache is the most common reason a correct fix appears not to work, and it sends people down a rabbit hole chasing a problem they already solved.
Two other things to check before you escalate. First, confirm the site is on the current ACF Pro release, since the fix for a regression like this usually lands on the plugin side. Second, if the block is registered with the older acf_register_block_type() PHP call instead of block.json, set 'mode' => 'edit' there. Mixed registration across an older build is common and easy to miss when you patch only the JSON files.
How to roll back WordPress 7.1 without breaking the site
Rollback is the right call when a site has a dozen custom ACF blocks and the client publishes daily. Patching twelve block.json files on a Friday afternoon is a billable project. Reverting core is 15 minutes and buys you until the upstream fix ships.
Do it in this order:
- Take a fresh full backup, files and database, and confirm you can restore it. Our WordPress backup strategy guide covers what a usable backup includes.
- Run the rollback on staging first:
wp core update --version=7.0.3 --force --skip-plugins --skip-themes - Run
wp core update-dband load the editor to confirm the toggle is back. - Repeat on production during a low-traffic window.
- Set a calendar reminder for 14 days out to re-evaluate.
The caveat is real. Sitting on an older core release means sitting on older security patches, and that risk grows every week. Give yourself a fixed window rather than an open-ended pause. We wrote about how to think about this tradeoff in our WordPress update strategy for core, plugins, and themes. A two-week hold with a reminder attached is disciplined; a six-month hold is a liability.
Never roll back production without staging it first. If your current host does not give you a one-click staging environment per site, this regression is a decent argument that the hosting line item is costing you more than it saves.
What an emergency ACF fix costs an agency
Run the numbers on a 40-site portfolio where 12 sites use ACF blocks. The cost difference between finding this yourself and hearing about it from a client is not the engineering time. It is everything attached to the engineering time.
| Path | Who finds it | Hours per site | Cost at $125/hr | Client sees |
|---|---|---|---|---|
| Staging update, caught pre-deploy | You | 0.4 | $50 | Nothing |
| Production update, you spot it in QA | You | 0.8 | $100 | Nothing |
| Production update, client reports it | Client | 2.5 | $313 | A broken editor for 1-3 days |
| Client reports it, you roll back under pressure | Client | 3.5 | $438 | Broken editor plus an incident email |
Across 12 affected sites, the staging path runs about $600 of internal time. The client-reports-it path runs closer to $3,750, and almost none of it is billable, because nobody pays you to fix a problem the update caused. Then add the part that does not fit in a table: the retainer conversation three months later where the client remembers the week they could not edit their own homepage.
According to W3Techs, WordPress runs roughly 43% of all websites (2026), and ACF is one of the most widely deployed development dependencies inside it. Core update regressions that touch ACF land on a lot of desks at once. The agencies that come out fine are the ones that saw it on staging on a Tuesday, not the ones that heard about it from a client on a Friday.
We broke down where this kind of non-billable time goes in what DIY WordPress hosting costs an agency every month. ACF block breakage is a textbook example: no server failed, no security incident happened, and the bill still arrives.
Why staging-first update testing catches this before the client calls
A staging-first workflow catches editor regressions because a human opens the editor before the update reaches production. That is the whole mechanism. There is no clever automation here, just a copy of the site, a core update, and five minutes of clicking blocks on the two or three templates the client edits most.
At TopSyde, every site gets its own staging environment, and core updates run there first with a checklist that includes loading the block editor on real content rather than a blank test page. Our plugin and core update testing workflow walks through how the queue works, and our staging environment guide covers the mechanics if you want to build the same process on your current host.
When something like the 7.1 ACF regression does show up, the update gets held on affected sites, the block.json patch goes out to the ones that need it, and the client never learns there was a decision to make. That is what managed WordPress hosting is supposed to cover in 2026, and the difference between hosts is mostly whether anyone actually does it.
Monitoring runs 24/7 on our side. Human support answers in under 2 hours during business hours, which matters when you have a client on the phone and 12 sites to check.
Getting this off your plate
If you are reading this with a spreadsheet of client sites open, do the audit first. Core version, ACF version, block registration, ten minutes of clicking. Patch or hold based on what you find, and put a date on the rollback.
Then look at why you found out about it here instead of from your host. Plans start at $89/mo per site with staging, per-site backups, and update testing included, and we handle the migration. See what is covered on the pricing page, check the technical spec sheet if you want the infrastructure detail, or look at how the agency program works if you are moving a portfolio rather than a single site. There is a 30-day money-back guarantee, so moving one site to test the workflow costs you a week of attention and nothing else.
Frequently Asked Questions
Is the ACF block issue in WordPress 7.1 a bug in ACF or in core?
It surfaces as an ACF Pro block problem, but the trigger is a WordPress 7.1 editor change that affects how block modes are handled. Fixes for regressions like this typically ship from the plugin side first, so keep ACF Pro current and check its changelog before you plan a core rollback.
Can I just tell clients to use the block sidebar instead?
Not reliably. ACF block fields render in the block body, not in the settings sidebar, so if the block is stuck in preview there is no sidebar fallback to point clients toward. Forcing "mode": "edit" in block.json is the workaround that restores editing.
How long should I stay on WordPress 7.0.3 after rolling back?
Set a hard window of two to four weeks and put a reminder on the calendar. Older core releases stop receiving security fixes as newer branches move forward, so an indefinite hold trades an editor annoyance for a security exposure. Re-test on staging weekly and update the moment the block toggle behaves.
Does every site running ACF Pro have this problem?
No. It depends on whether the site registers ACF blocks at all, how those blocks declare their mode, and theme registration order. Plenty of sites use ACF only for field groups on posts and pages, and those are unaffected. Run the audit rather than assuming either way.
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
