I don’t believe this can currently be done, but I wish it could. I just assume it would be pretty hard to implement.
I use the Clone field EXTENSIVELY. My approach involves creating a “defaults” field group (which is never used anywhere) containing all the fields I will ever use, and their particular/default settings.
I then create all the field groups I intend to use, made up of clones fields from the master/defaults group I first created. I do this to ensure that if I want to make a change to placeholder text or other default settings, these are automatically cascaded down to all the cloned fields in all the active field groups I’ve defined.
The problem here is that there is no exception: I can’t overrule a specific default setting in a given situation – say, the placeholder text.
So a feature request, or a conversation point would be this:
Would there be a way to be able to apply overrides to clones?
The logic here would be that you want 99% of everything in the clone, but you just want to change one setting (say, the placeholder text).
I know this would be untenable if the thing you’re cloning is a complex repeater field, say, but even then, there may be some high-level settings you’d like exposed and accessible for overruling.
Thoughts? Anyone working on a concept here?
Well @alicam, I guess you’re not alone — but maybe both of us are.
I face this situation frequently, and it seems our uses of clone field are pretty close, when I need two (or more) fields groups that are visually and semantically the same (let’s say a basic Text/Textarea/link group) but the names need to be different depending on context (like Title/Content/Link for the first and Name/Bio/Contact for the second).
I start trying to find words that can serve for both titles, but that’s not practical and I end up creating two field groups that are *exactly the same*.
That’s not very smart, but sadly it seems that is what it is.
Hope some of staff members reach out this thread 🙂
I don’t know if this will help anyone, but I also use clone fields extensively. As an example I will use the example @pedrorivera gave. By reading it I am guessing that there is a title, a link and a block of text.
I would first create a field group, this group would have these three fields
Then when I cloned this field group I would create a “Group” field if only one can be entered, or a “Repeater” if multiple entries can be made. This group of fields would have a label and instructions that pertain to the use of the first field group in that specific instance. This could be “Links”, “Bios” or whatever other thing could use this setup.
More than likely these “Group” fields would also be a field group that could be cloned and then I would clone each of these were I need to use them.
I have many, many field groups. I start with the basics of what I am doing today and when I find a new use for a specific set of fields I break them out into a new clonable group. The other thing I always keep in mind when creating fields is “Could there be a different use for them?” if the answer to this is yes then I plan ahead by building the fields so that I can, if I choose, break them out into their own group to be cloned later on.
John, still not the best scenario, right? This kind of solution is more like a workaround than a real solution — we call it “gambiarra” here in Brazil, there’s no english word to express this kind of trick to get to a state that is not exactly a solution and might cover some cases, some not.
It says to literally confuse the end user with a not-so-accurate label so they must pay attention that you might insert the Linkedin profile where you read Link, or a person Name were it’s read Title. Not very good, I guess.
A simple toggle on clone field that allows the new cloned fields to be renamed would be simply amazing.
Thanks to ACF integration with Gutenberg, this use case has decreased a lot on last months, but when I need this, I keep creating two (or more) visually and semantically identical field groups :/
I don’t think so.
If there is a “Group” with the label “Bio” and this group has a title, text and link.
How does that confuse anyone if you then have a group called “Link” and this can also have a title, text and link?
You are assuming that the user will not understand that the fields pertain to the main label or the instructions of that group.
There is a toggle that allows fields in a group to be renamed, you turn on field name prefixing.
I don’t think so.
You’re also assuming people should understand that when they might not, depending on their instruction level. I tend to deal with people with low to medium tech education — sorry if here in Brazil things don’t go as fast as people on north might be used to, and not everyone is comfortable with a computer, we can blame a lot of factors for it, but I think this is not the point here, right?
UX embraces a lot of fields and demographics is one of the most important because it impacts on user behaviour, education and feelings. A computer interface is not usual for every person and feels different for each one. I had to deal with a 80+ y.o. clients more than once and sorry to disappoint you, they don’t get things so easily.
I won’t extend this discussion, as I said, ACF blocks for Gutenberg has made this process a bit less necessary.
Hope sometime it’ll be easier to make things easier.
Thanks for your attention.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!