I’m gearing up to start work on a new Sage project that will rely heavily on custom fields. As part of the planning phase I’m considering the pros/cons of the (many) custom field solutions out there, and I’ve been struck by how overwhelming the Roots community seems to be in its consensus around Advanced Custom Fields. Importantly, most if not all of the Sage documentation and community contributions around custom fields seems to assume ACF. Normally I would just take the hint and go with ACF myself, but I find myself wishing for a more developer-forward tool like Meta Box or Carbon Fields rather than a GUI-centric tool like ACF.
I can’t speak for anybody else, but I use ACF because it’s well made, works great, and provides a lot of handy stuff out of the box. Its popularity also makes it easier and more pleaseant to work with because it’s easier to find answers to problems or cool tools people have built on top of it.
I also used to be frustrated with with what I perceived to be its lack of focus on the developer experience, but it provides tools to make your field building more “developer-y,” like generating fields using PHP, or storing them in your repo as JSON. Lately I’ve been using ACF Builder for all my projects, and now all my field definitions are authoritatively defined in my code, and I barely ever see the field creation UI any more.
That said, if you want to use something else, why not just go for it? I’ve built several projects with Carbon Fields, and several with good old CMB2. You might find something you like better, or it might help you realize why ACF is the tool for you after all.
As a newbie, trying to teach myself and learning from code examples, I started with Pods. It was really easy to create CPTs and fields, but recently I found it incredibly frustrating that I couldn’t get the fields defined in code and version controlled. For the main site I work on we’ve come unstuck a few times because someone forgot to ask for the latest JSON export and upload it to their environment.
Next I tried MetaBox, and it looked great. This was at the stage I started using Sage and creating templates rather than using BeaverBuilder. However once I tried ACF it just made sense, and I can’t see me switching away now. The docs are great, there are loads of supporting resources, and ACF-Builder is the bomb!!
I used Custom Field Suite for years before moving to ACF. I’ve also used Carbon Fields. ACF is the most polished of these options, but the others are fine, and they do their job.
Thank you everyone for sharing your thoughts. As a solo dev, second opinions are invaluable to me.
I do agree that there’s no substitute for hands-on experience. I’ve used CMB2 in the past, and while I love that it is fully open-source I eventually ran up against limitations with it, notably around the lack of complex content groups. I’m leaning towards taking the plunge with ACF - the community contributions around ACF + Sage integration are a big part of the equation for me (and the social proof from fellow devs does ease my mind ).
I’ve used carbon fields, and I would use it again. It also supports gutenberg blocks, if you’re interested in that (sage 9 example here).
I think carbon fields really fits the roots workflow, but acf + acf builder would also work if you’re in need of more advanced layouts and fields.
@Xilonz Gutenberg support will end up being necessary I imagine. Nice to hear a rec for Carbon Fields; I’ve looked that one over but haven’t tried it out yet. Thanks for that gist!
Been using Carbon Fields (CF) since version 1.4, tried ACF before it, but had to turn it down because it is not as dev/code share friendly as CF. It is our go to tool now for all things custom fields, hands down.
Rolled out a couple big projects with Carbon Fields and Sage since last fall and was REALLY happy with the results. They played well together and it’s great to have my fields defined in code rather than in the DB.