And this gives the oh so mighty notice error: Notice: Undefined index: name in _field_ui_reduce_order() (line 72 of /opt/cvs/drupal/modules/field_ui/field_ui.admin.inc).

2 ways to reproduce:

1) - move a field nested under fieldset
- move the fieldset to hidden
-> this isn't possible from a UI point of view, ajax error pops up with that notice

2) - choose a layout with display suite
- move a field underneath a fieldset
- move fieldset to another region in ds
-> same ajax error pops up with that notice

Debugging now, hope I can find this.

CommentFileSizeAuthor
#3 drag_group_row.png9.4 KByched
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

swentel’s picture

As a side note, there is an annoying error with drag and drop also with DS, see #1175414: Issue with drag and dropping fields into regions (custom DS layout) - not related with this one, but it's helpfull if you have layouts which have underscores in their region names.

swentel’s picture

yched’s picture

FileSize
9.4 KB

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 ?

Stalski’s picture

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.

swentel’s picture

Category: bug » task

Ok, update, looks like I had an outdated version of drupal core, no notices in 7.2 anymore, but as yched said, the field doesn't come along, but that's a fieldgroup thing, let's see if we can fix that or not.

swentel’s picture

Title: Moving fieldsets into another region throws notice or ajax error » Moving fieldsets into another region leaves children behind

Better title

yched’s picture

Stalski’s picture

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.

gbernier’s picture

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

Stalski’s picture

Status: Active » Needs review

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.

swentel’s picture

Status: Needs review » Fixed

I've committed the code over at #1238048: Moving fieldsets into another region leaves children behind for ds and all seems to be working nicely at my setup, even multiple nested groups and fields, so marking fixed from my side.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

greta_drupal’s picture

Status: Closed (fixed) » Active

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

Using latest build of DS and FG. Latest D7.

yoroy’s picture

Category: task » bug

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.

Stalski’s picture

Priority: Normal » Major

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

yoroy’s picture

Category: bug » task
Priority: Major » Normal

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.

yoroy’s picture

Category: task » bug
Priority: Normal » Major

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?)

Stalski’s picture

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"

yoroy’s picture

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.

nils.destoop’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)