Nobody edited a template. Nobody deployed anything. Your development partner did not touch the site, because you may not have one. And yet the blocks your staff use to build pages can now render through a different code path than they did last month, because a plugin updated itself and a default changed underneath.
That is the actual story of Advanced Custom Fields 6.8.9, released on August 27, 2026. It is a small release with a short changelog. It is also a good example of the category of change that association websites are least equipped to notice.
What 6.8.9 Actually Changes
The headline item is a default, not a feature. ACF Blocks registered through acf_register_block_type() or through block.json without an explicit version now default to version 3 on WordPress 7.1 or later. Previously, a block that did not declare a version got the older behavior. Now, on 7.1 and up, it gets the new one.
This is ACF's answer to the change WordPress made in 7.1, where the editing canvas is rendered inside an iframe by default for block themes and classic themes alike. Version 2 blocks were built for a world where the editor was not isolated that way, and they suffer functional problems inside it. Version 3 blocks are built for the iframe.
The release also adds a renderPreview option for version 3 blocks in block.json. Setting it to false displays a placeholder in the editor instead of rendering the block template, which is useful for blocks that are expensive to render or that do not preview meaningfully. And blocks that combined "mode": "edit" with "supports": { "mode": false } are converted automatically when they are upgraded to version 3.
Why a Default Matters More Than a Feature
A new feature is opt-in. Somebody has to decide to use it, which means somebody knows about it. A changed default is the opposite. It applies to sites where nobody decided anything at all, which is most sites.
The exposure is specific: a block that never declared its version, on a site that has moved to WordPress 7.1. That is not an unusual combination. Blocks built a few years ago frequently did not declare a version, because at the time there was only one. Those are exactly the blocks most likely to be sitting in an association site that was built once and has been running since.
To be fair to ACF, the direction is correct. Version 3 is the version that works properly in the iframe, and defaulting to it is better than leaving sites on a version that misbehaves. The point is not that the change is wrong. The point is that it is invisible, and invisible changes are the ones that get discovered by an editor rather than by a plan.
Whether This Reaches You at All
Three questions settle it, and they can be answered in an afternoon.
Are you on WordPress 7.1? If you are still on 7.0, none of this applies yet. It applies the day you update, which makes this worth knowing before that update rather than after.
Do you use ACF Blocks? This is the question that actually determines exposure, and a surprising number of organizations do not know the answer. ACF field groups attached to pages and posts are not affected by any of this. ACF Blocks are a separate feature, used to build editor blocks out of ACF fields. If your site does not use them, the block version default is not your concern.
Do your blocks declare a version? If they were built against a recent ACF and declare version 3 explicitly, the new default changes nothing for you, because you were never relying on the default.
If the answer to the first two is yes and the third is no or unknown, this release changed how your site renders and no one sent you a message about it.
The Smaller Fixes, Which Are Not Nothing
Three bug fixes ship alongside the default change. Inline editable fields in version 3 blocks no longer require a second click before they become editable, which was a small daily irritation for anyone building pages. Radio buttons now display correctly on ACF admin screens. And image and gallery fields accept SVG uploads when the Safe SVG plugin is active.
There are no security fixes in this release and no CVEs. That is worth stating plainly, because it changes the urgency. This is not a drop-everything update. It is a read-the-notes-and-plan-it update, which is a different thing and is handled differently.
The Pattern, Not the Release
It would be easy to read this as a post about one plugin. It is not. The same shape recurs constantly on association websites, and the specifics change every month.
A dependency updates. A default moves. Nothing in your own code changed, so nothing looks like it should have broken, and the symptom surfaces weeks later as a staff member saying that a page looks wrong. By then the change is several updates back and the connection is no longer obvious.
The organizations that catch these are not the ones with better websites. They are the ones where somebody reads release notes, keeps a staging environment that mirrors production, and applies updates deliberately rather than automatically. That is a standing job, and it is the job most associations have nobody assigned to.
What Watching Releases Actually Looks Like
Concretely, for this release, it is four steps. Read the changelog and decide whether it applies. Check the site against the three questions above. Apply the update on staging and open the pages that use ACF Blocks. Then update production on a Tuesday morning rather than discovering it on a Friday afternoon.
None of that is difficult. All of it requires somebody whose job includes it. When nobody owns it, updates either pile up until the site is dangerously behind, or they apply themselves automatically and the first signal is an editor reporting that something looks off.
This is one of the things a digital partnership covers, and it is the least visible one. There is no deliverable to point at in a month where the answer was that a release did not affect you. The value is that somebody read it, checked, and told you so, instead of nobody reading it at all.
We run WordPress 7.1 with ACF PRO on this site. We read this changelog the day it came out, for the same reason we read it for the organizations we work with.
Stop Fighting With Free Platforms
Our partnership plans give associations and nonprofits a dedicated web team without the overhead of hiring one. From ongoing maintenance to full-scale builds, every plan includes strategy, development, and support tailored to organizations like yours.