After adding a 'Horizontal Tabs' and re-ordering the fields, this message appears randomly in the administration pages:

Notice : Undefined index: name dans _field_ui_reduce_order() (ligne 81 dans /homez.154/innovatit/boiteD/modules/field_ui/field_ui.admin.inc).

I know that a similar issue was reported a year ago but it was caused by a development version of D7 and I'm using 7.9.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

euginewm’s picture

Status: Active » Reviewed & tested by the community
FileSize
457 bytes

Please, see this solution.

Anonymous’s picture

Hi,
The link for the page seems to be broken...

damien_vancouver’s picture

Status: Reviewed & tested by the community » Needs work

@Takeo, Drupal.org is not correctly URL encoding the link above, try: http://drupal.org/files/Drupal_org_IssueID_%231348948.patch

However... field_ui is not the problem here. field_group is creating fields without a 'name' it looks like, and also performing some kind of terrible recursion that's exhausting a huge amount of memory.

I hit this error repeatedly doing the following:
1) Create a horizontal tabs field group and some tab item field groups on a content type's Manage Fields screen.
2) Go to the Manage Display and try and clone from the form
3) You may run out of memory (I had to turn my PHP memory_limit up from 512M to 2048M to get it to even run the last time the error occurred)
4) The resulting page is loading very slowly and fires the error:

Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /home/www/modules/field_ui/field_ui.admin.inc).

The Manage Display screen will not load properly after the error occurs, until you find the bad field_group and delete it (it varies which one is the problem). It will load, but it will be extremely slow, fire the error above, and consume lots of memory. It's not good for your server performance!

For the time being, I recommend not cloning any groups with horizontal tabs (or even maybe any cloning at all). If you do, make a backup of your database first. I just rolled back to my backup and it felt great!

I will be able to spare some more time to look into the cause of this problem next month.

damien_vancouver’s picture

I just set this error off again, this time without cloning.

I created a new Field Group type Horizontal Tab Item called "Basics", which had the same name as a field group on my form named "Basics". I recall when this happened yesterday and I deleted the groups by trial and error, one named Basics was my problem too.

I've concluded that groups should have unique namespaces across your displays, when possible. Don't have group_foo and group_bar in edit, then in manage dipslay etc. This is of course what clone does, and how the error is popping up there I think.

arne_hortell’s picture

Short fix.

function _field_ui_reduce_order($array, $a) {
$array = !isset($array) ? array() : $array;
if (array_key_exists('name',$a)) // This line is added, prevents error message if $a['name'] dont have key 'name'
if ($a['name']) {
$array[] = $a['name'];
}

loopy1492’s picture

Applying the patch worked for me.

Stalski’s picture

Assigned: Unassigned » Stalski

@damien_vancouver: The memory you are talking about is normal when the bug is there. I once had it too.

I don't think it has to do with the same name in "form" or "display" but with the name that still exists somewhere. A while ago, I tried to debug this when I had it after creating "groupA" , then delete it, and then recreate it with the same name. The strange part is that it should be fixed a long time ago. So I'll look into that again, maybe it is fixed in dev but not yet in 7.x-1.1.

The "terrible recursion" you are talking about is refactored by someone a long time ago to speed things up. If you have a proposition to improve this kind of recursion, I 'd be very glad and happy to review.
So I think I'll wait for you answer.

Stalski’s picture

I little remark. If you need to go to 512M or even 1024M, then there is a big problem. I don't think that incrementing this is the best solution. Ofcourse that said, you need to find out first what the problem is. Now we know it's most of the time a name collision between some new added field_group and one that still exists somewhere, and I did not find out yet where that is.

Stalski’s picture

Status: Needs work » Postponed (maintainer needs more info)

I tried the cloning as well and indeed I get the error now as well.

I added a horizontal wrapper with basic and advanced horizontal tabs in the form. The fields inside where body, image and tags
I cloned this to the full display, however DS had already taken care of the fields as they were placed in regions.

With this approach, the horizontal tabs ended up in the disabled region where the fields that where nested in the form were left where they were. When grabbing the outer horizontal wrapper into a region, the fields suddenly moved towards the way they are configured in the form. But not all ! Only the fields that are in that region. See attached screenshot.
When saving this page, I get the error as well (Note that the error is always seen the second time the page refreshes, so you'll often see it in other pages that have nothing to do with it).
I think it can be reproduced in other ways too as I the fieldgroup itself still "knows" it's children, where Display suite also knows where they need to go.

Can anyone help me to tell the other ways to reproduce this?
Did anyone or maybe everyone enable display suite as well (currently I don't know what is causing the problem, but I'll investigate) ?
How many people are working with dev version instead of this 1.1 release?

Stalski’s picture

the screenshot, / doh

Stalski’s picture

Status: Postponed (maintainer needs more info) » Active

Extra information:
1) the name collision bug is traceable to the 1.1 version and should be fixed in dev.
2) the other issues with _field_ui_reduce_order due to the cloning has another cause. The fieldgroup is copied with its children from one view mode to another, that's basically it.
However this does not account of the fact that the fields (children) are set in another region (hidden, enabled or by Display suite regions).

I don't know an easy way to fix that.

damien_vancouver’s picture

Status: Active » Postponed (maintainer needs more info)

Hi Stalski,

just to answer your questions about versions,

I'm using 7.x-1.x from Jan 10th, which is just one translation related commit back.

I do have Display Suite enabled, and it looks like my content type is set to a One Column DS layout. It was probably like that when I was cloning too, because I was using a DS layout before.

damien_vancouver’s picture

Status: Postponed (maintainer needs more info) » Active

Hm not sure why the status got changed there.. putting it back to active! Let me know if there's anything I can do to help test on my side. I'll try turning off DS and doing some cloning and see if I can make it not work vs. work based on that.

damien_vancouver’s picture

OK so I found a content type that didn't have a DS layout yet.

I set up a field group on the Display by accident, instead of the Form. So then I cloned the field group from Display -> Form, and it worked fine.

I then went to Teaser, and cloned from Form -> Teaser and it also seemed to work fine as well.

Then I went back to Default and now there are three of those errors there!

    Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /home/damien/www/modules/field_ui/field_ui.admin.inc).
    Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /home/damien/www/modules/field_ui/field_ui.admin.inc).
    Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /home/damien/www/modules/field_ui/field_ui.admin.inc).

... Except Default is the one I started on, where I built them by hand. Very weird!

Anyway, no Display Suite anywhere (other than it being enabled), and it's still happening in yet a new strange way.

nils.destoop’s picture

Status: Active » Needs review

I just committed some fixes around cloning. Did the same steps like you, but couldn't reproduce it.
Can you check if it's fixed with latest commit? Patch can be found at http://drupalcode.org/project/field_group.git/patch/7dbe890313b4d40c04ee...

damien_vancouver’s picture

I was adding some field groups to the form of a content type that has never had DS on it, so I used it for some cloning testing too.

I'm using the latest 7.x-1.x-dev, but still see the error. Here were my steps:

- edited an existing content type with no DS layout set and no existing field_groups
- added some groups to the form layout, saved it
- went to the default display mode and then cloned field groups from form
- got green messages that the four groups were cloned successfully and they were. Most of my fields were set to hidden so I dragged one over to one of the newly cloned groups
- Then I get the error message 4 times again (once for each of my 4 field_groups I guess)

Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /modules/field_ui/field_ui.admin.inc).

If you can't reproduce, I could step through in XDebug and see what's wrong with the data structure. Let me know if that'd be helpful! I've saved this database in before/after states for doing that.

Thanks for all your work on this problem!

Ivan Simonov’s picture

Version: 7.x-1.1 » 7.x-1.x-dev

I try to clone field groups on 7.x-1.1 and got error
Then I install 7.x-1.x-dev and clone field groups successfully

After this in both versions 7.x-1.1 and 7.x-1.x-dev I got:
Notice: Undefined index: name in _field_ui_reduce_order() (line 81 of /modules/field_ui/field_ui.admin.inc).

Update:
When I delete hidden groups (wich not shown on page) "Notice: Undefined index..." disappear.

nils.destoop’s picture

Status: Needs review » Fixed

I just committed a fix to the dev. The problem occurres because a child field is in a different region, then the group after cloning.
To fix this, the only way was resetting the children.
This means: after you clone the groups, all groups will be below eachother, and you'll need to place all groups / fields on the place you want.

To fix current notices, you have to delete wrong groups.

Status: Fixed » Closed (fixed)

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

loopy1492’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Closed (fixed) » Reviewed & tested by the community

I just noticed that I still have to apply this to the new Drupal patch 7.21. Why hasn't this been included in a release? Does anyone know how we go about doing that?

deanflory’s picture

I just got it when editing the Manage Fields for Image file type in Display Suite.

Richard Moger’s picture

patch #3 worked for me. thx.

tregismoreira’s picture

#3 worked for me too! Thanks ;)

mraichelson’s picture

Links to patches above all lead to a 404 for me, can anyone point to where they actually live?

energee’s picture

energee’s picture

Status: Reviewed & tested by the community » Needs review
bleen’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

#25 works for me

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 25: Undefined_in_field_ui_reduce_order_fix-1348948-25.patch, failed testing.

arne_hortell’s picture

// using
if (empty($a['name'])) // Will fail with error if $a['name'] is not defined.
// but
if (array_key_exists('name',$a)) // Will not fail

Therefore patch #25 will not solve the problem

gable’s picture

FileSize
8.75 KB

We've found, that there was problem in database table called 'field_group'. There was a loop in 'parent_name' column, as you can see in the attached picture. This is not a systematic solution, I think there should be some kind of vaidation to prevent such loops, but it helps to at least restore the display of a node.
Field group loop
I've also found out, that it's better to switch on the groups if you have them swiched off. At first I tried to drag them to the proper place, but it turned out that when I swich them on they land with fields that were previously attached to them - it seems that the fields had still connections to their groups in the database. Aha, and this situation occured for me with Accordeon groups, not with Vertical or Horizontal tabs.

deanflory’s picture

What is the status of this issue? Seems to have dropped.

PQ’s picture

// using
if (empty($a['name'])) // Will fail with error if $a['name'] is not defined.
// but
if (array_key_exists('name',$a)) // Will not fail

Therefore patch #25 will not solve the problem

Actually, empty($a['name']) works fine for this purpose. like isset(), empty() is a language construct, not a function. It evaluates the validity as well as the content of $a['name'] and returns true if the key 'name' is not set or if it is set but is considered an empty value ('', 0, FALSE, NULL, etc) rather than throwing an error.

The last submitted patch, 25: Undefined_in_field_ui_reduce_order_fix-1348948-25.patch, failed testing.

giupenni’s picture

very annoying bug, I'm frustrated.
I can't use correctly Field Group and Displya Suite

joelpittet’s picture

Assigned: Stalski » Unassigned

#25 is a drupal core patch, should this be moved?

odegard’s picture

I got this error too, but at least in my case the fix waas easy. I'm creating a distribution where I create fields and groups in code.

I had an array of fields that I put in a group with mode 'form', and then I put that same array of fields in the same group with view mode "default".. the problem is that some of the fields in that array are hidden when displayed. When I went to the display tab on the content type, I saw that the hidden fields were hidden, but they were still indented as they belonged to the group.

The solution for me is to not send the same array of fields for the two modes, but remove the hidden fields for the group when defining the view mode "default".

I don't see this as a bug really, but rather sloppy code on my part. If you need to fix without reinstalling anything, just drag the hidden fields to the root and the error will go away.

Christian DeLoach’s picture

Maybe it's just me but I feel like almost every time someone posts an issue related to an undefined value the first patch just wraps the variable in a isset() test which, while helping to hide the error message, typically covers up a bug.

Besides being from two different development release, is this issue not a duplicate of issue #1016144? Should we just link this issue to issue #1016144 and update issue #1016144 to 7.x-2.x-dev?

joelpittet’s picture

Title: Undefined index: name dans _field_ui_reduce_order() » Undefined index: name in _field_ui_reduce_order()
sime’s picture

Status: Needs work » Closed (outdated)

7.x-2.x branch hasn't been updated in 8 years and doesn't have a recommended release. I'm closing all 7.x-2.x issues that are over 2 years old.

Is there a patch for 7.1 in here? Feel free to reopen against 7.1 and note the patch I can review.