I’m having an issue where I am unable to edit Gutenberg patterns that contain ACF blocks. After clicking the “Edit original” link to edit the pattern containing the ACF block, the fields for that block appear but the styling is missing (see attached).
I created a test site with only ACF Pro installed, the underscores theme and a simple ACF block defined and was able to reproduce the issue.
I’ve contact WP Engine about the issue and got this response:
===============
This behavior is actually due to a limitation introduced in recent versions of WordPress core.
Our development team is actively looking into possible workarounds to improve usability in this context, but we don’t have an estimated timeline for a solution just yet.
===============
I’m curious if others have come across this issue and if there are any fixes or workarounds.
I noticed the same issue and editing reusable blocks is a real pain now. I wrote a support ticket too and I am glad, that this issue will be investigated and hopefully fixed within next update.
I only develop self-built themes, so it must definitely have to do with wordpress core and not the theme or incompatibility with a plugin.
I’m afraid it’s not something you can fix yourself (unless you want to edit the core files of ACF).
Looks like the latest update is forcing preview mode when editing patterns. We force edit mode on site, so this causes a different issue where an unstyled version of the front end code renders in the editor.
Is there an issue with the way Gutenberg uses an iframe in the pattern editor?
The solution to force preview mode is not satisfying if you use “big” fields like tinymce editor or fields next to each other.
Please find a solution for auto mode as it works without reusable blocks. This seems to be more a workaround than a fix.
Are there any timelines for when this will be fixed ?
This has really broken our functionality with patterns, and we’re going to get a lot of negative feedback from our content managers
I’m having this issue too, and my theme setup heavily relies on patterns with ACF.
To overcome that critical problem right after updating WP to 6.8 I was using Gutenberg 19.4 from official github repo (last version before Gutenberg forced iframes in patterns) – before release of ACF 6.4.1.
The workaround I use for now: very simple plugin (uses only jQuery from core WP) to easily drag and resize right sidebar of Gutenberg – then you can edit fields without frustration. Not perfect solution, but way better than having to fight with tiny fixed sidebar.
https://wordpress.org/plugins/resizable-editor-sidebar/
I hope ACF team will find perfect way to overcome problem.
+1 Having the same issue. We build custom themes based on Sage starter theme using AcfComposer library. Right now the Patterns are pretty much unusable. The resize plugin mentioned by @stertee is a nice workaround though.
Does anyone know when this issue was introduced? I downgraded WP to 6.7.2 but that didn’t help.
Sorry about this folks. WordPress 6.8 renders more blocks inside iframes, and libraries like TinyMCE don’t support targeting inside a local iframe, so the block crashes.
To avoid this, we disabled in-block edit mode whenever the iframe is used, forcing you to the sidebar.
We’re working on a new edit mode view which will use a modal so you’re not forced to the sidebar, and this will be available later this summer, but the resizeable block editor sidebar plugin is the best bet until that’s available.
Thanks,
Liam
Thank you for clarification Liam. Do we have to use the new modal edit mode globally or is it possible to use it only for block patterns?
I really like the idea of editing blocks in a modal, since editing in auto mode often results in loosing focus (for example when I use some large fields like tinymce in one block).
Another huge improvement will be the option to assign/divide fields within the same block to inspector controls (for recurring block settings like spacings and colors) and content fields like tinymce, which open in auto / modal edit mode as it is now. Since this is a already a feature in “lazy blocks” plugin, it should also be possible in ACF. This would be a huge improvement of usability and eliminates the need to use tabs or accordions.
Do you already have this feature on your roadmap?
The fix will be ready this or next year? Because it is like 2+ months when the bug was discovered.
+1 our clients are having this same issue.
We use Sage so all of our blocks are based on ACF, our clients are unable to edit properly in Patterns since WP 6.8. Hoping that a fix can be released soon!
Honestly, it feels like ACF development has completely stalled. You’ve been working on micro features for months, but a major bug like this still isn’t fixed three months after being reported. It’s a shame – even a bit sad – that we’re paying for a yearly subscription when development feels dead and important bugs like this are just being patched with workarounds instead of real fixes.
This is a major issue for all our clients, and some of the websites are no longer usable. We urgently request a solution, as this problem has been persisting for over two months. It is unacceptable that we’ve had to rely on a temporary workaround for such a critical issue over the course of several months.
For anyone waiting for solution like me, this is official reply from support:
Unfortunately, we do not have an ETA on this, but the developers are working on it.
In the meantime, the workaround, like copying the block out of the pattern editor, editing it on a page, then pasting it back, is currently the best temporary solution.
We’ll keep you updated as soon as we have more information or a patch available.
Make up your own mind, but this bug has been known for almost 4 months now. For example, HPOS was introduced in 2023, and ACF added support in 2025. So I guess we can expect a fix in about two years…
Yeah, huge bummer. I can understand why they are having issues and how ridiculous it is that iframes are being used for this. It makes targeting nearly impossible. REACT WAS A MISTAKE haha.
Anywho, maybe just make a patch for non-WYSIWYG-havin’ field groups. I could easily figure out how to manage my ACF fields knowing that WYSIWYG field wasn’t an option.
Really does suck that I have about 25 sites that utilize ACF Blocks and Patterns. Just gonna stop using Patterns.
+1 same issue on multiple client sites and complaints from clients.
Just a friendly reminder that the ACF team has been successfully ignoring this bug for exactly 3 months.
+1 with this issue, now getting reports from clients on how to deal with this.
Any update on current progress?
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.