Why Is Everything in ACF Pro? A Question I Had to Ask

I recently sat down with a WordPress website: fresh install, modern setup and the first thing that caught my eye was that everything was built using Advanced Custom Fields Pro.

Blocks, headings, paragraphs, sections, even the navigation menu was hardcoded inside header.php. Not a single block editor instance in sight.

My immediate reaction? Why?

Not in a judgemental way. Genuinely curious! Because WordPress in 2026 is a very different beast from WordPress five years ago, and the block editor has come a long way. So what’s the reasoning here?

via GIPHY

Let Me Set the Scene

For anyone who hasn’t come across it, ACF Pro (Advanced Custom Fields Pro) is a plugin that lets you create custom fields and forms that attach to pages, posts, or custom post types in WordPress. Instead of editing content inside the editor, you scroll down to a set of labelled fields “Hero Headline”, “Button Text”, “Background Colour” — and fill them in. The developer then pulls those values into the theme templates.

It’s powerful. It’s been around since 2012. And for a long time, it was basically the solution for giving non-technical clients a structured way to edit their website.

But WordPress has evolved. The block editor has been the default since WordPress 5.0 back in 2018, and it’s genuinely good now. Drag and drop. Visual editing. What you see is (more or less) what you get. So why would someone building a fresh site in 2026 skip all of that and go full ACF?

Where the Questions Started

When I looked into this setup, the conversation that followed was less “here’s why we built it this way” and more both of us trying to figure out the why together. The developers on this project hadn’t worked with WordPress in years, this was their first project back in the ecosystem in a while and the questions coming back were the same ones I was asking: Can’t the block editor do this? Why ACF for everything? Why is the menu hardcoded?

We were approaching it fresh, which actually made it a more interesting exercise.

What became clear fairly quickly was that the decision wasn’t really about the developer’s tooling preferences at all. It was about the client’s comfort with editing their own website.

The client; a non-coder, wanted a simple, reliable way to update content on the site. They wanted a form. Labelled fields. Something that felt predictable and safe every time they logged in. And from a client management perspective, that’s a completely reasonable thing to want.

That framing shifted the question for me. It stopped being “why didn’t they use the block editor?” and became “is ACF actually the right tool for this client’s needs — and does the block editor have an answer?”

The Part That Made It More Interesting

When I recreated the same sections in the block editor and showed how it could work including the Custom HTML block for inline code there was a genuine realisation that the block editor covers more ground than most people assume.

And that opened up a question I keep coming back to: Is part of this an education gap?

The block editor has a learning curve. That’s not a criticism, just a fact. And here’s the thing the majority of non-technical WordPress users never fully made the switch from the Classic editor. A lot of them still use the Classic Editor plugin to this day. So there’s an entire generation of WordPress workflows both developer-side and client-side that were built around the old way of doing things, and the full transition simply never happened for many people.

(The Classic vs block editor debate is its own post entirely, so I’ll leave that thread for another day.)

So Is ACF Pro Actually the Wrong Choice Here?

Not necessarily. Let’s be fair about where ACF still earns its place.

The client editing experience can genuinely be better in ACF. When a non-technical client opens a page in ACF, they see a clean form with labelled fields. There’s no risk of accidentally deleting a block, no confusion about layout, no chance of breaking the structure of the page. The block editor looks visual, but it’s surprisingly easy for a non-developer to move, delete, or corrupt a layout without realising it. ACF puts guardrails around the editing experience that the block editor doesn’t do out of the box.
Structured data is cleaner. ACF stores content as clean, queryable post meta. The block editor, by contrast, serialises block content into an HTML comment-delimited format and saves it inside post_content in the WordPress database which works fine for display, but becomes harder to work with when you need to query or transform that data programmatically. → WordPress Block Editor: Data Flow and Data Format
Some field types just don’t exist in the block editor natively. The ACF Pro upgrade unlocks Repeater fields, Flexible Content layouts, Gallery fields, and the Clone field none of which have direct block editor equivalents without custom block development. The free version of ACF covers standard types like text, image, relationship, and taxonomy; the Pro-only fields are where ACF really pulls ahead for complex content structures. → ACF Pro — Field Types

But the Block Editor Has More Than People Realise

Here’s where I think the education gap shows up most clearly.

The Custom HTML block lets you drop in raw HTML, and from WordPress 7.0, it has dedicated panels for CSS and JavaScript as well (available to users with the unfiltered_html capability). Shortcodes work inside it too. It’s not always the cleanest approach for JavaScript specifically inline scripts can occasionally be stripped or cause issues depending on how WordPress processes content but for straightforward use cases it’s a capable tool that a lot of people don’t know exists. → WordPress Documentation: Custom HTML Block
Block locking is the bigger one. Most people building client sites don’t know you can lock blocks in the editor to prevent them from being moved or deleted. You can lock individual blocks, apply templateLock to an entire group of inner blocks with options like all, insert, or contentOnly mode, and control which user roles can lock or unlock blocks at all using the block_editor_settings_all filter. In other words: the “a client might accidentally break the layout” argument which is the strongest argument for ACF in a client-facing context is something the block editor can actually address, with the right setup. → Full Site Editing: How to Lock Blocks and Templates

None of this means the block editor is automatically the better choice. It means the decision deserves a proper comparison rather than defaulting to the familiar option.

Where the Setup Is Harder to Defend

There are parts of this particular build that are genuinely harder to justify on a fresh 2026 install.

The hardcoded menu in header.php is the main one. WordPress has a perfectly good menu management system built in. It’s flexible, it’s client-friendly, and it doesn’t require touching code to update. Hardcoding the navigation means the client can never change their menu without developer involvement. Unless the navigation is genuinely static and complex in a way the built-in system can’t handle, this creates a maintenance dependency that doesn’t need to exist.

The “client wanted a simple form” argument for ACF is valid but it isn’t the only answer. For this client’s specific need, ACF is a reasonable solution. But a properly structured block editor setup with locked templates, labelled block patterns, and restricted editing permissions — can provide a very similar experience. The question is whether anyone took the time to explore that option or whether ACF was reached for first because it was familiar.

Who Is ACF Pro Actually Better For?

To be straightforward about it:

ACF Pro makes more sense when you’re building data-heavy sites where content needs to be queried or consumed outside the editor, when you need complex field types like repeaters or flexible content layouts that have no native block equivalent, when the site is going to be built headlessly or driven by an API, or when the client’s editing needs are genuinely form-based and structured in a way that a visual editor doesn’t serve well.

The block editor makes more sense when you want a visual editing experience that reflects the front end, when you’re building something other developers will maintain using standard WordPress tooling, or when the content is relatively straightforward and can be made client-safe through locking and permission controls.

Neither is universally better. The right choice depends on the project and increasingly, on whether the person making the decision has a full picture of what both tools can actually do.

The Takeaway

What started as a head-scratching moment looking at a fully ACF-powered WordPress site turned into a more layered question than I expected. It’s not just about tool preference. It’s about client needs, workflow assumptions, and a genuine education gap around block editor capabilities that the WordPress community hasn’t fully closed.

If you’re a developer defaulting to ACF for everything on client sites, it’s worth spending time with block locking, template locking, and the contentOnly editing mode. You might find the block editor handles more of your client-safety requirements than you assumed.

And if you’re all-in on the block editor ACF Pro is still genuinely worth having in your toolkit for the right use case.

Have you inherited a setup like this, or been part of the conversation trying to figure out why the choices were made? I’d love to hear how others are navigating this.