ACF Group Field – I wish it had been implemented a touch differently

• rslater

• September 29, 2017 at 10:49 pm

I know it’s likely way too late for the ACF devs to consider this as a feature request, since the Group field/feature is already out the barn door (and thus why I am not posting this in the feature requests forum), but I really wish the ACF group field had been implemented as an attribute of a field instead of changing the data structure (and WP post_meta key name). Why? Because if it was just an attribute, adding the Group field to existing ACF fields would have been a trivial act, simply allowing you to offer your users a cleaner display of data in logical groupings on the wp-admin side of things– it’s intent, since it has no effect anywhere else, save for this next bit of whinging. The problem with implementing it by making it (behave as) a child object/array is that any existing references you have (in templates or custom functions that modify behavior, like dynamic population of fields based on other field values, cleanup/special handling of data on save, etc.) must all be updated with new references. Had the parent group been implemented as an attribute of a field, all existing field references could have been retained, making porting existing ACF fields into a Group field a truly breezy process, instead of a chore. This would have added some extra work on the devs, I know, implementing some extra logic so fields would could be parsed to determine where they should show up in the ACF Edit Field Group screen so they’d show up nicely nested there, but weighing those few dozen hours of work by them against the potentially thousands of hours of ACF users having to remediate their own templates/functions for adding group functionality to existing ACF field groups… well, it would have been nice.

Rant over. And, just a quick n.b.—I really do love ACF. It frees up a ton of time I would otherwise have to invest in creating data input/management interfaces to actually do cool, fun things with that data, so good on you, guys. This is just a bit of (hopefully) constructive criticism. Have a good Friday and great weekend, folks!

• John Huebner

• October 2, 2017 at 4:37 am

I know this isn’t going to help, but, I for one will never go back an rebuild an admin based on the availability of new field types. There wasn’t a field for grouping when I built the site and I probably designed the admin as well as I could given what I had to work with. It could be that you don’t do the kind of work that I do. I build many many sites and the client pays me to build them. I then maintain the site, but extra hours to rebuild the admin are not usually in the budget. Once the site is built, that’s it unless the client wants to pay me to make additions or changes of some kind. At that time I’d look at it and determine if it would be more cost effective to make changes based on new fields or stay with what it was. Constant restructuring of data is not something that I want to do.

There was recently a similar discussion that had to do with converting a repeater into a flex field, something else that can be done but not easily. Again, can I do it? Yes. Will I? Not very likely, simply because rebuilding the data to use the new field is not cost effective.

I’m not the developer, so I can’t say why they went with the implementation they did, but I do know quite a bit about the way ACF works. I can guess that it had mostly to do with using structures that already existed. The group field is nothing more than a repeater field that always has exactly 1 row. Using an existing structure rather than implementing a totally new one not only reduces the work to build it in the first place, it also reduces the work of maintenance. I think there may be 2 developers now so I think that maintenance time is always going to be something that is considered. I know that it’s something that I seriously consider when someone asks me to add a new feature to one of my plugins and one of the reasons that I purposefully keep the scope of any plugin extremely narrow.