# ACF / Cardbon fields / or alternative, what's the latest thing for block ins Sage 11?

**URL:** https://discourse.roots.io/t/acf-cardbon-fields-or-alternative-whats-the-latest-thing-for-block-ins-sage-11/30036
**Category:** sage
**Tags:** sage11, sage10
**Created:** 2025-11-10T16:21:44Z
**Posts:** 7

## Post 1 by @Tim — 2025-11-10T16:21:45Z

Hey all,

For the last few Sage versions I’ve been using Carbon Fields to make blocks for the gutenberg editor. But now starting with a new project that I switch to Sage 11, I wonder if this is still the way to go.

What’s the current standard to have a fool-proof (sorry, should have said client proof) approach for the client to add block to a page AND post. What I don’t like about Carbon Fields is that the client still has all the default blocks to it’s disposal. So circling back a jear later the site looks like a warzone. A colleague in the field mentioned ACF Builder? But from what I remember before switching to Carbon Fields, is that I really don’t like adding the fields manually to the backend (dashboard). I want to do it in the theme (php or json), plus it clutters the dashboard with jet another menu item.

I mainly work with blocks as rows or regions on a page/post. Sometimes I nest blocks.

So, what’s your take on custom blocks on pages AND posts?

---

## Post 2 by @ben — 2025-11-10T16:40:09Z

I’d suggest [ACF Composer](https://github.com/Log1x/acf-composer) if you’re not wanting to write native React blocks

---

## Post 3 by @folbert — 2025-11-10T20:01:10Z

+1 on ACF Composer and use [allowed\_block\_types\_all – Hook | Developer.WordPress.org](https://developer.wordpress.org/reference/hooks/allowed_block_types_all/) to only allow the blocks you want.

I also use [https://www.advancedcustomfields.com/resources/how-to-hide-acf-menu-from-clients/](https://www.advancedcustomfields.com/resources/how-to-hide-acf-menu-from-clients/) to hide the ACF admin menu item in non-development environments. In development, it is sometimes helpful to be able to use the fields GUI to find what features each field type supports.

---

## Post 4 by @Tim — 2025-11-11T18:51:20Z

A really? What makes it more useful than carbon fields?

---

## Post 5 by @ben — 2025-11-11T19:03:38Z

Did you take a look at ACF Composer? It has the best DX for working with ACF on Acorn/Sage-powered sites, and it’s the most heavily used package in this community

> But from what I remember before switching to Carbon Fields, is that I really don’t like adding the fields manually to the backend (dashboard). I want to do it in the theme (php or json), plus it clutters the dashboard with jet another menu item.

This is not a concern if you use ACF Composer

---

## Post 6 by @Tim — 2025-11-11T19:06:14Z

Thanks, I’ll try it out in the project for tomorrow. Good to hear it’s widely used.

---

## Post 7 by @Tim — 2025-11-14T05:31:35Z

update, I will use it for the upcoming projects. It’s slightly more work that Carbon Fields to get a block running, but more compatible with components that CF. Since ACF exposes the fields directly instead of an `$fields` array.

Also, most breaking changes during updates came from CF in the last few years (don’t ask me what they where).

So yeah, I will switch back for ACF with composer. Now, I’ll see for DB migration of the custom fields when existing site upgrades come up.