Existing field groups disappear and Add Field Group UI is disabled when no fields are available

Because of the empty($form['#extra']) part of the conditional, you won't notice you're Doing It Wrong™ if you have a module enabled that adds extra fields (e.g., Redirect): field_group will happily let you create field groups all you want before adding "actual" fields. Having been doing this for a few months now, I haven't seen a single side effect from the fact that field groups are created before fields.

Additionally, after spending a couple of hours debugging the Field API after a simple unset in a hook_field_extra_fields_alter() implementation, there's a major WTF moment if you happen to disable the module that's providing that extra field: when you visit the Manage Fields page again, it'll appear as if there was data loss, because all of the existing field groups disappear.

However, there isn't: re-enable the module that was providing the extra field and everything shows up again.

So the fact that it's checking for existing fields or extra fields is more of a bug than anything: there doesn't seem to be a reason at all to stop people from creating field groups before fields.

Attached is a patch that removes this check.

This was actually by design. The check on extra was not there at first, however we got notices.
So that's when we started doing the same thing as fields do: only add "add new field/fieldgroup" when there is something to work with. As fieldgroups group (extra)fields, this makes sense ofcourse.

However there actually should not be a restriction to add fieldgroups. That said, note that fieldgroups are ment to group fields and only work in that case. So there is no reason to add a fieldgroup as a standalone data object.

So the way I see it, I would go for the text as suggested in the report rather than removing the check and thus doing altering while field is NOT doing any altering yet!

Opinions?

From a workflow perspective, it's been easier to create the field groups first, which defines the skeleton of the entity type, then add the fields afterwards. In other words, field groups effectively act as an outline for the content of the page.

But discounting that benefit, the current check is lacking: it lets field groups be added if there are any fields or extra fields, but they can go away at any time. If they do, the field group interface gets disabled entirely and all existing field groups are hidden. Re-enable any module that implements hook_field_extra_fields or add another field, and everything shows up again.

This is a weird in and of itself, but if a user unwittingly clicks "Save" on the field overview form during field group's hidden state, there's data loss as the form gets submitted without the field group data that does exist.

So if it's essential that this check still exists in some form, what about:

1. If there are already field groups present, don't restrict the UI: show all existing field groups as normal, and show the "add field group UI".
2. Add the notice per the OP when there are no fields or field groups present.

Attached is a patch that does this.

I was going through my local forks of contrib modules, checking to see if anything needs a reroll, and this patch still applies with latest HEAD. Is there anything else that's preventing this patch from being committed?

I committed following solution:
- on the form settings, create group is always shown, even when there are no fields or extra fields
- on the display settings, the return should stay. Because field ui does no theming on the form then. I don't show a message, because field ui already says you have to start by adding fields. People would see 2 times the same message, if field group also said that.

Works great: thanks, I appreciate it!