Grok 'Advanced Custom Fields Pro' for useful / viable features

[petecooper]

https://www.advancedcustomfields.com/pro/

The WP plugin above is often mentioned in discussion threads of WP 'must have' functionality over and above that included in core WP. Given the recent events at Automattic / WP Engine, ACF is mentioned more frequently.

As we approach the v5 era, it would be pertinent to look at ACF functionality with a view to replicating the useful stuff we don't already cover.

[bloatware]

It looks like a large part of 'must have' comes from its integration with WP Guttenberg editor. We don't/won't (?) have one, but looking at the functionality behind ACF is certainly pertinent. Some of it (like complex cf) seems still missing in our cf branch.

[Bloke]

There are probably a few things we can take from it, but as @bloatware says, most of the design and functionality of ACF is related to integration with the bloated block editor. And, presumably, admins define and build these on a per-post basis making long-term maintenance an absolute nightmare.

Ours is a more centralized approach. One thing I would like to do - and I don't know if this should be a core feature or we should allow plugins to take over - is to somehow group fields into 'content types'.

We have a freeform 'family' field (or whatever our current name is that doesn't clash with MySQL's increasing number of reserved words) that plugins could use to tie fields together in various ways. A plugin could allow you to maybe comma-separate values here to associate each field with one or more content types. Then, said plugin could be used to tie them to sections maybe so if you select a section, the fields alter according to which ones match the section in one of the entries in the 'family' list.

That brings with it all sorts of fun. Like, what happens to the existing field content if you have an article already published and you change its section so a new (sub)set of fields appear in the UI and you then save the article. Does the old stuff get wiped out? (I think it currently does delete the field content if your fields go out of scope, so this would be extended by inference if this was to become a feature).

Sections are only one way of grouping content. Categories are another. So I'm kind of loathe to define (and therefore limit) the scope of custom fields in one particular way (such as tying them to sections), not least because a) different content types might share fields in different configurations - e.g. a Location field might specify a physical site in one content view but also a position where something might be found in a warehouse - and, b) fields are not limited to content types but also meta (presentational) types like Sections and Categories and even Authors, etc.

Granted, the Location thing is a poor example because nobody in their right mind would use the same field for two different types of data; one would probably be a dropdown and the other a freeform text field. But there could be instances where fields do make sense to be shared across content types and it'd be annoying to have to define the same field multiple times vs defining it once and making it available to two or more types of content (cf. the ACF 'clone' and 'repeater' field types, which look like hacks to me).

We should define the scope of this kind of thing and come up with some reasonable conventions that enable 80% of people to take custom fields and do insanely cool - and efficient in terms of storage/maintenance - things with them out of the box, while leaving avenues open for plugins to twist them into even more useful tools for the remaining 20% of use cases.

[petecooper]

Thanks very much @bloatware & @Bloke, this is exactly what I was thinking, hence 'useful / viable' in the title.