Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#3 | drag_group_row.png | 9.4 KB | yched |
Comments
Comment #1
swentel CreditAttribution: swentel commentedAs 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.
Comment #2
swentel CreditAttribution: swentel commentedCross referenced to #1016144: Undefined index: name in _field_ui_reduce_order() ..
Comment #3
yched CreditAttribution: yched commentedTried 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 ?
Comment #4
Stalski CreditAttribution: Stalski commentedI 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.
Comment #5
swentel CreditAttribution: swentel commentedOk, 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.
Comment #6
swentel CreditAttribution: swentel commentedBetter title
Comment #7
yched CreditAttribution: yched commentedMarked #1205974: Manage display of node: cannot move field group including fields in a column as duplicate.
Comment #8
Stalski CreditAttribution: Stalski commentedOk 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.
Comment #9
gbernier CreditAttribution: gbernier commentedHey Stalski, will the fix require DS to be added or will it address this within just the field_group module?
Comment #10
Stalski CreditAttribution: Stalski commentedI 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:
This is also the solution for the Display suite approach. The changes there will be simple:
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.
Comment #11
swentel CreditAttribution: swentel commentedI'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.
Comment #13
greta_drupal CreditAttribution: greta_drupal commentedI'm getting tons of this error. See http://drupal.org/node/1525684
Using latest build of DS and FG. Latest D7.
Comment #14
yoroy CreditAttribution: yoroy commentedI 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.
Comment #15
Stalski CreditAttribution: Stalski commentedUpgrading this then. This seems a bug that needs to be checked asap.
Comment #16
yoroy CreditAttribution: yoroy commentedHmm, 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.
Comment #17
yoroy CreditAttribution: yoroy commentedOops. 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?)
Comment #18
Stalski CreditAttribution: Stalski commentedFor 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"
Comment #19
yoroy CreditAttribution: yoroy commentedI 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.
Comment #20
nils.destoop CreditAttribution: nils.destoop commented