❤️ FAQ: difference between extended-acf and acf-builder

[chrillep]

Just a friendly question whats the biggest difference between extended-acf and acf-builder

refs

• https://github.com/Log1x/acf-composer
• https://github.com/stoutlogic/acf-builder
• https://github.com/StoutLogic/acf-builder/issues/176

[vinkla]

The primary distinction between log1x/acf-composer and stoutlogic/acf-builder is that vinkla/extended-acf has divided each field into its own class. The advantage of placing each field into its own class is enhanced intellisense. I have placed emphasis on the developer experience, and the best case scenario if you are using an IDE is that you won't need to consult the documentation as long as you know the name of the field. Additionally, the benefit of putting fields into their own classes is that it is straightforward to create custom fields for third-party fields.

It's really up to your personal preference, but just so you know, @Log1x and @stevep are both really good at writing code. So whichever package you end up going with, you'll be in good hands either way.

[chrillep]

yeah thank u. vinkla/extended-acf seems more DX firendly! log1x/acf-composer is more specific to the Sage, Radicle and Acorn ecosystem, if i understand it correctly.

Thanks for taking the time to explain the differences! Would be nice if maybe we could get log1x/acf-composer to use `vinkla/extended-acf, not cause acf-composer looks bad in any way. Just that it seems unmaintained, or at least in halted development. :)

[vinkla]

The ACF PHP API has remained largely the same for the past decade, as @Log1x stated, and all of the related packages can be considered feature complete. However, there are some areas that I would like to improve in the vinkla/extended-acf package in the future:

• Introducing the ability to set custom keys, which could be beneficial when converting an exported PHP array from the ACF dashboard or when updating from an earlier version of the package (which I have done multiple times).
• Adding a method for setting the column width of a field, instead of requiring width to be passed to the wrapper method.
• Supporting the clone field, although I'm not sure this is necessary; I have never needed to use the field since I stopped registering fields from the dashboard.

[fatk]

On the topic of future features, I don't know if that's something that many people would use, but i would love to be able to work with objects in get_fields(). Instead of just getting an array of values, we would get the object corresponding to each type and even extend the base objects with our own. I use wordpress with a heavy layer of Laravel so that would make a lot of sense for me, but maybe that's just me....

[vinkla]

@fatk, that sounds like an interesting feature, allowing the ability to extend fields with custom methods that can be used in your templates. This can be accomplished through another package. If you ever develop something like this, please let me know.

[kupoback]

To add about the returning of data that's object based, I've worked on something like that, that works for multi-dimensional arrays, converting them to objects on your return. This uses Laravel's Collection, and Fluent to work, and all you need to do is pass in an array of field names.

This isn't an open package, and was something I wrote for my companies Boilerplate with Sage 10 + AC, so it may not be fully optimized. This allows to return an object of field data, or you can hook into the ->setupFields() if you want to manipulate any of the data, like Post Object, or if you have get_fields(), you can convert it all. You can also pass in a post_id for things like Options pages, or pulling in ACF from another Post ID.

https://gist.github.com/kupoback/20fec6bf325c594c358126ac8ef98fec

Note this is written for php 8.1

[chrillep]

The ACF PHP API has remained largely the same for the past decade, as @Log1x stated, and all of the related packages can be considered feature complete. However, there are some areas that I would like to improve in the vinkla/extended-acf package in the future:

• Introducing the ability to set custom keys, which could be beneficial when converting an exported PHP array from the ACF dashboard or when updating from an earlier version of the package (which I have done multiple times).
• Adding a method for setting the column width of a field, instead of requiring width to be passed to the wrapper method.
• Supporting the clone field, although I'm not sure this is necessary; I have never needed to use the field since I stopped registering fields from the dashboard.

perhaps add a feature to export to extended-acf from admin? or cli command that does the conversion from array to classes

NOT a small feature tho :)

[vinkla]

perhaps add a feature to export to extended-acf from admin?

That's a great feature idea, but I won't personally work on it because I rarely use the ACF dashboard interface, except for testing fields in this package. I will review any pull request you send my way.

remove_menu_page('edit.php?post_type=acf-field-group'); // 👀