Why I still use ACF (and what would change my mind)

A look at where ACF Free fits in 2026, what it does that Gutenberg block.json can’t, and the three changes that would move me back to native blocks.

The premise

It’s 2026 and Gutenberg’s block API is excellent. The Block Editor handles 90% of what ACF was originally for. So why am I still installing ACF Free on every B2B marketing site I ship?

The honest answer: editorial workflow. Gutenberg solves the “how does this look?” problem really well. ACF solves the “where does this content live?” problem better than any alternative in 2026.

What ACF Free still does best

Named fields with clear labels

The marketing team I’m working with shouldn’t have to know what a “block attribute” is. They should see a tab called “Hero” with named fields: “Eyebrow”, “Title”, “Subtitle”, “Primary CTA label”, “Primary CTA URL”. ACF Free gives me that with two minutes of setup per content type.

You can build this in Gutenberg with InspectorControls + dynamic blocks, but the marketing team’s first encounter with the editor is a sidebar of “this is a block, click here to add a heading” generic onboarding. ACF’s named-field UX cuts that to “fill these fields, save.”

Editorial workflow that isn’t layout-driven

Gutenberg’s editing model is “see the layout, edit the layout.” ACF’s editing model is “fill the fields, see the layout once.” For sites where the layout is locked and editors are filling fields, ACF is faster and more reliable.

Where Gutenberg wins: sites where the editor is also the designer, deciding layout per page. Where ACF wins: sites where the design system is fixed and the editor’s job is to feed it content.

Numbered named-slot rows (ACF Free, not Pro)

The standard ACF Pro repeater is useful but breaks free-tier sustainability. The workaround: numbered named-slot fields. Eight rows of pp_decision_1_title / pp_decision_1_body / pp_decision_2_title etc. The editor sees a clear tab with eight numbered slots; the developer reads them with a tiny helper function; nobody pays for ACF Pro.

It’s a hack. It also works. Three years of this on Care Plan retainers, zero migrations to Pro, zero complaints from editors who actually use the admin.

What would change my mind

Block-level conditional visibility in core

Currently the only sane way to do “show this block on these pages only” is via a plugin (Block Visibility) or via ACF field conditions. If core ships first-class conditional visibility per block in 2026 — and it’s on the roadmap — that’s one less reason to install ACF.

Native named fields per block, not just attributes

Gutenberg attributes are key-value pairs. ACF fields are typed, labelled, validated. If the Block Editor adds first-class typed-and-labelled fields to block.json (with admin UI matching ACF’s), that’s two of the three reasons gone.

A native repeater that doesn’t require a plugin

The InnerBlocks API is the current answer. It’s powerful but error-prone for editors — moving blocks around can break the parent-child relationship. A first-class “repeating field” type in core would close the gap entirely.

The compromise I run today

ACF Free for hero, intro, CTA fields per page type. Gutenberg native blocks for the body content (paragraphs, headings, lists, images, embeds). The editor uses Gutenberg for prose; they use ACF for the fixed scaffolding. Editors who’ve used both tell me this is the most comfortable workflow they’ve shipped against.

For my own theme code, the pattern is documented in pixypuala/site‘s inc/acf.php module. Numbered named-slot fields per CPT, read via read_numbered_rows() helper, registered with native fallback meta boxes so the site works even when ACF is deactivated.

The verdict

I’d happily move off ACF if Block Editor shipped the three changes above. Until then, ACF Free + native fallback is the right answer for B2B marketing sites with editorial teams that aren’t engineers. For sites where the editors are engineers — like this one — Gutenberg-only is the right answer, and that’s what I’d recommend.