A field group must be assigned to a post type/taxonomy/page template/whatever. Now, when we have a new clone field feature then leaving a field group unassigned might have a sense. One might want to define a field group, leave it unassigned and use as a source for a clone field (like a trait or a mixin in OOP).
You can do this by setting the field “Active” setting to No.
This basically solves the same problem.
Thanks. This is a good workaround, a much more elegant workaround than I used to use (I used to set conditions that could never be met in order not to show a field group on any page, like assigning a field group to a widget), but it’s still a workaround and it might be confusing because it makes a field group marked inactive on the list, when in fact, it’s not inactive.
So it would be great if a field group could be left unassigned.
When E added the clone field he posted a comment that I remember about setting a group to inactive for exactly this purpose and he built the clone field to not ignore inactive groups on purpose so that this could be done. So basically, this is the way it was designed to work. I don’t think you’ll see another way to do this.
If you want you could create a custom location rule that you could set so that a group appeared nowhere. I’ve actually done this in the past before the active/inactive setting was added. I find that a group set to inactive helps me fine the ones that are meant to be cloned.
