Moving fieldsets into another region leaves children behind

Tried to reproduce the 1st case (with latest field_group 7.x-1.x).
Dragging the group (with 1 field in it) to the 'hidden' region doesn't bring an error, but ends up with the field nested alone in the 'hidden' section, with the group row stuck at the bottom of the main ('visible') region (see screenshot).

That's most likely because the 'Format' dropdown for the group row doesn't seem to have any 'Hidden' option available ?

I can only say from a quick peak at this issue that I recognize the bug in the screenshot in latest reply. Usually refreshing the page manually would have lead to "Undefined index: name in _field_ui_reduce_order".

The fix for this will be to detect the hidden and reset the properties where parent is involved. I 'll look for this asap.

Marked #1205974: Manage display of node: cannot move field group including fields in a column as duplicate.

Ok started looking for this one.
I have the same as in #3 and the reason is indeed since there is no hidden region possible within fieldgroup at the moment.
With DS enabled, it works better since it takes the regions as it should.

More on this later tonight.

Hey Stalski, will the fix require DS to be added or will it address this within just the field_group module?

I think this issue comes in two versions.

1/ Field_group did not have any [Hidden] format type.
2/ With Display Suite layout enabled, the field-group AND it's children should be warned to move into the region concept.

The first issue is fixed.
The second issue will be taken up in Display suite as the javascript there should warn the children they can move to. To ease things a bit and cleanup the code in field_group, I moved the logic for the recursive children moving to another region to a separate function:

    if (recurse) {
      this.regionChangeFields(region, this, refreshRows);
    }

This is also the solution for the Display suite approach. The changes there will be simple:

  regionChange: function (region) {
     ...    
     // If a row is handled by field_group module, loop through the children.
     if ($(this.row).hasClass('field-group')) {
       Drupal.fieldUIDisplayOverview.group.prototype.regionChangeFields(region, this, refreshRows);
     }
    
     return refreshRows;
  }

The only thing I need to check now, is when fields are in fieldgroups that are in fieldgroups. My guess is that at the moment, with this field_group commit and the additional code in Display Suite, only first level fieldgroups will handle their children.

I'm getting tons of this error. See http://drupal.org/node/1525684

Using latest build of DS and FG. Latest D7.

I get this notice when saving after cloning a field group on the manage display tab of a content type, cloning the fieldgroup I made on the 'manage fields' tab to there (form to display). Using Fieldgroup 7.x-1.1, no Display Suite involved, just regular Field UI. Switching to the latest -dev release does not make it go away, I'll check if deleting and recreating the group with the dev release works better.

Upgrading this then. This seems a bug that needs to be checked asap.

Hmm, works better in the sense that no notices shows up. The fields that were added to the group on the 'manage fields' tab are not automatically added to that group on the 'manage display' tab though.

Oops. To recap:

Getting the notice using the 1.1 release
No notice using the dev release, but group item hierarchy not kept intact (different bug?)

For me it's the same bug, only checked
This certainly needs some love, but I already know it's not that easy since you need to take some assumptions, which is not good.

Do you have any idea's on how this functionality should exist? A couple of possible things to look at:
- When no fieldgroups exist at the destination, it's just copy, look for same fields and nest them in it.
- When the same fieldgroup exist there, leave it all together? Most of the time I had that, I actually wanted to override the behavior.
- With DS enabled, even the fields go be totally different. So only moving what we "know"

I tried to reproduce on another content type, making a new group in 'manage', cloning it to 'display'. Worked fine using 1.1, so it's probably a bit more subtle than just that.

My initial expectation was that a group defined in 'manage' would automatically be available in 'display' too. I was really surprised to not see it there, wondering if I had to re-create it again here or something. It took me a couple of trips between the node/add/x screen and viewing the actual node/x, wondering why there was no fieldset to be seen in the front-end view, while it was clearly there in the node/add form!

Only then did I care to notice the vertical tab with the fieldgroups blabla :)
The description "Clone fieldgroups from selected view mode to the current display" explained it for me.

…and now that I'm typing all this I realise and see that groups *can* be added from the 'manage display' tab. My mind was hard-wired to 'define stuff' in 'manage fields', so I added the group there, expecting it to become immediately available in 'manage display' as well.

I'm only talking from the very simple use case where I want to use the same grouping on node/add as on node/x view. Now I see it's (of course) a bit more complex than that.

Rambling myself into understanding here :) Silly Field UI…

No concrete suggestions but at least I understand the problem better now, I'll think about this a bit more. I guess this is the kind of stuff #1770720: [META] Gradual changes to Field UI was opened for.