Since Gutenberg was created, WordPress has become an over-complicated platform filled with user experience issues, quirks with non-existent standards for site building.
While Gutenberg continues to challenge everyone's patience, question their life choices, and cause anxiety, solutions to this problem do exist. It involves extending the editor with custom blocks—tailored to your site’s unique requirements. This one move takes your WordPress site from a little more than a frustrating and basic Squarespace experience to a fully robust CMS that behaves like a modern CMS,
That’s where tools like Advanced Custom Fields (ACF) and custom post types come into play, letting you build custom blocks that fit your workflow perfectly. This is what allows us to take over the Gutenberg Editor and use it as a Live Preview area instead.
Introduction to WordPress Block Editor
The WordPress block editor, also known as Gutenberg, has transformed the way content is created and managed on WordPress websites. The Gutenberg Editor was introduced in WordPress 5.0 in 2018, replacing the Classic Editor. Instead of relying on the classic editor’s single content field, the block editor introduces a modular approach—allowing you to build pages and posts using a variety of blocks. Each block represents a distinct piece of content, such as paragraphs, images, galleries, or custom elements, giving you full control over layout and design with just a few clicks. The change was significant and confused clients, annoyed long-time WordPress developers, and opened the doors to a DIY and wild west culture of building sites in WordPress. Now, anything goes and anything can break. This brand new world was the beginning of the end for a lot of WordPress developers, but opened up new opportunities as well.
This shift to block-based editing has made WordPress a more powerful content management system, enabling both developers and content editors to create rich, structured content without needing to touch code. With this new powerful tool, has come many setbacks and failures for WordPress. The block editor is hard to control for novice users and is mostly a frustrating experience. Because of this, we had to take a different approach to building WordPress sites that want to take advantage of this visual editing experience capability.
Some of the biggest issues with the Gutenberg block editor include:
- Inconsistent editing experience: The layout users see in the editor often looks different from what appears on the front end.
- Overwhelming interface: Panels, settings, and nested blocks create confusion for non-technical editors trying to make simple updates.
- Frequent breaking changes: Core updates often alter how blocks behave or render, forcing developers to constantly patch layouts.
- Poor control over design integrity: It’s too easy for users to accidentally break spacing, typography, or alignment—especially when theme styles aren’t fully respected.
- Performance issues: The React-based editor can be slow to load, particularly on large or plugin-heavy sites.
- Lack of true field relationships: Unlike structured CMS platforms, Gutenberg doesn’t easily manage repeatable or relational content.
- Plugin fragmentation: Many third-party block libraries overlap or conflict, creating inconsistency and bloat.
- Accessibility gaps: The editor interface itself and many third-party blocks still fall short of WCAG accessibility standards.
- Limited lock-down options: Developers can’t easily restrict what editors can move, delete, or modify without complex workarounds.
- Poor long-term maintainability: The constant evolution of the block API makes it difficult to ensure stable builds over time.
Our solution to the Gutenberg block editor problem
It become clear we needed to use custom blocks to avoid this madness. To add blocks, you can either install a plugin with a set of blocks created by another team (examples: Kadence Blocks, Spectra Blocks, Generate Blocks), introducing another ecosystem and style paradigms, or make your own blocks. Building your own native blocks with react is one option. While we have React skills at our agency, we often find that the juice is not worth the squeeze when it comes to building them. The process is painful and often never fits into development budgets.
We believe that modern WordPress development doesn’t have to mean working inside React or fighting Gutenberg’s constantly changing code. You can still build a clean, flexible site using ACF blocks, custom fields, and proper structure. Done right, it gives you all the benefits of a block-based editing experience in the Gutenberg editor, where each Gutenberg block serves as a modular content element. This modular approach stands in contrast to the traditional content editor found in the classic editor, offering more flexibility and customization without turning your development process into a complicated project.
Our solution involves using ACF Blocks as modular components, a resizable sidebar feature, and editable fields located in the sidebar, separated from the editor canvas. The editor is then used as a Visual Preview area only. If you take a look at just about any modern CMS, this is how the visual editing experience works. Examples are: Craft CMS, Storyblok, Statamic, Prismic, Sanity, Contentful, Cloud Cannon, and just about any modern CMS. Website builder platforms such as WIX, Squarespace, Webflow and Framer all work similarily to the Core Gutenberg blocks, where editing takes place right on the canvas.
Why We chose ACF for Custom Blocks
ACF is what gives WordPress it's content management powers. We've been using it since 2011 and it's the leading solution in it's category. It only makes sense to utilize blocks with ACF given the field options and wide-spread support and reliability of the plugin.
ACF blocks give developers the ability to model content cleanly — defining fields once and rendering with PHP templates. It’s the perfect balance between flexibility and control.
Many developers face a steep learning curve when starting to build Gutenberg blocks due to the complexity of setting up the development environment. Developers often require extensive knowledge of JavaScript, Node.js, React, and Redux to create custom Gutenberg blocks effectively.
Instead of building React components, you define your block fields in ACF, write your HTML and logic in a PHP template, and, using a callback function in a php file, render the block dynamically while maintaining compatibility with WordPress core. Let WordPress handle the editor preview. That’s it. No build step. Just clean, maintainable code that your team — and your clients — can actually work with.
A Better Editing Experience with Sidebar Fields
By default, ACF fields appear at the bottom of the editor, which can feel disconnected from the actual editing flow. Using a plugin like SeeMax Resizable Editor Sidebar, we move all ACF block fields into the editor sidebar, giving editors a clean, contextual experience.
This approach mirrors the inline editing feel of modern CMS platforms like Storyblok, Contentful, or Statamic — where fields are logically grouped and always within reach. The difference is, you’re still working inside WordPress, without the clutter or confusion of nested blocks and side panels everywhere.
Structuring Template Parts: Header, Footer, and Locked Layouts
To maintain consistency and prevent accidental changes, we build Header and Footer ACF blocks that can only be placed once — inside the header and footer template parts.
Menus are still handled dynamically, using WordPress’s native menu system. Editors can modify menus from the familiar “Menus” screen, while the header and footer blocks automatically render them. This keeps your structure clean and prevents layout-breaking edits inside the block editor.
ACF for Custom Post Types
For custom post types, we take a similar approach. Each post type have one dedicated main block — pre-inserted by default and locked in place. There's no risk of deleting the wrong element. Inside that block, editors access exactly the fields they need through the sidebar. By placing all post meta fields in the editor sidebar, there's no scrolling through a sea of fields buried below the content area. You can use custom fields for anything such as creating relationships between posts and display related content. This is a structured editing environment that prevents elements from being moved or deleted avoiding the main problems with Gutenberg all together.
Keeping Full Site Editing Somewhat Sane
Full Site Editing (FSE) introduced powerful concepts but also chaos for developers managing real-world projects.
By locking down the header, footer, and custom post type templates, this model lets us enjoy the benefits of block-based layouts without losing control over design integrity. Clients can safely edit text and images, but not accidentally delete the entire layout.
Why We Recommend This Approach
The combination of the block editor and ACF gives you full control over your content management system—empowering you to build websites that are both powerful and easy to manage.
ACF restores WordPress to a fully functional CMS. It restores clarity, structure, and reliability for both developers and content editors. Without it, WordPress is more like a page builder than a CMS — a patchwork of blocks rather than a system.
And while we often recommend moving to modern CMS platforms like Storyblok, Contentful, or Statamic for larger, scalable projects, ACF remains one of the few reasons we still consider WordPress a valid option for specific use cases.
Some of the reasons why building in WordPress, even with ACF blocks, is not our first choice over a headless CMS include:
- Using ACF blocks may lead to performance issues if not optimized, primarily when many complex blocks are used on the same page.
- Developers commonly encounter compatibility issues when using ACF blocks alongside other plugins or themes, requiring workarounds.
- WordPress FSE Limitations, such as attempting to restrict blocks to specific areas of the editor, for example, Header Blocks, which are only accessible in the Header Template Part.
- WordPress requires developers to load website styles on both the frontend and the editor, while carefully avoiding CSS from overriding the WordPress admin UI outside of the editor.
- Debugging ACF blocks can be challenging because of the complexity of integrating PHP and JavaScript in the block structure.
- Some users report that patterns with ACF blocks can't be edited since a specific WordPress update, highlighting a lack of adequate support.
When implemented thoughtfully, ACF blocks let you deliver a site that’s fast, easy to manage, and truly sustainable.
Future of Block Editor and ACF
The WordPress community continues to invest heavily in the block editor, with new features and improvements arriving in each latest version of WordPress core. Extensions like ACF Extended add over 100 additional features to the ACF framework, enhancing its functionality. As the block editor evolves, so does the Advanced Custom Fields plugin—introducing more blocks, enhanced field types, and better integration with full site editing. ACF Pro remains a powerful PHP-based framework for building custom Gutenberg blocks, and its support for JSON files and field group exports makes it a favorite among developers
