Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#30 | Field_group.png | 8.75 KB | gable |
#25 | Undefined_in_field_ui_reduce_order_fix-1348948-25.patch | 494 bytes | energee |
#10 | Screen Shot 2012-02-27 at 19.46.02.png | 27.66 KB | Stalski |
#1 | Drupal_org_IssueID_#1348948.patch | 457 bytes | euginewm |
Comments
Comment #1
euginewm CreditAttribution: euginewm commentedPlease, see this solution.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedHi,
The link for the page seems to be broken...
Comment #3
damien_vancouver CreditAttribution: damien_vancouver commented@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.
Comment #4
damien_vancouver CreditAttribution: damien_vancouver commentedI 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.
Comment #5
arne_hortell CreditAttribution: arne_hortell commentedShort 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'];
}
Comment #6
loopy1492 CreditAttribution: loopy1492 commentedApplying the patch worked for me.
Comment #7
Stalski CreditAttribution: Stalski commented@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.
Comment #8
Stalski CreditAttribution: Stalski commentedI 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.
Comment #9
Stalski CreditAttribution: Stalski commentedI 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?
Comment #10
Stalski CreditAttribution: Stalski commentedthe screenshot, / doh
Comment #11
Stalski CreditAttribution: Stalski commentedExtra 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.
Comment #12
damien_vancouver CreditAttribution: damien_vancouver commentedHi 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.
Comment #13
damien_vancouver CreditAttribution: damien_vancouver commentedHm 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.
Comment #14
damien_vancouver CreditAttribution: damien_vancouver commentedOK 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!
... 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.
Comment #15
nils.destoop CreditAttribution: nils.destoop commentedI 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...
Comment #16
damien_vancouver CreditAttribution: damien_vancouver commentedI 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)
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!
Comment #17
Ivan Simonov CreditAttribution: Ivan Simonov commentedI 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.
Comment #18
nils.destoop CreditAttribution: nils.destoop commentedI 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.
Comment #20
loopy1492 CreditAttribution: loopy1492 commentedI 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?
Comment #21
deanflory CreditAttribution: deanflory commentedI just got it when editing the Manage Fields for Image file type in Display Suite.
Comment #22
Richard Moger CreditAttribution: Richard Moger commentedpatch #3 worked for me. thx.
Comment #23
tregismoreira CreditAttribution: tregismoreira commented#3 worked for me too! Thanks ;)
Comment #24
mraichelson CreditAttribution: mraichelson commentedLinks to patches above all lead to a 404 for me, can anyone point to where they actually live?
Comment #25
energee CreditAttribution: energee commentedComment #26
energee CreditAttribution: energee commentedComment #27
bleen CreditAttribution: bleen commented#25 works for me
Comment #29
arne_hortell CreditAttribution: arne_hortell commented// 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
Comment #30
gable CreditAttribution: gable commentedWe'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.
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.
Comment #31
deanflory CreditAttribution: deanflory commentedWhat is the status of this issue? Seems to have dropped.
Comment #32
PQ CreditAttribution: PQ commentedActually,
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.Comment #35
giupenni CreditAttribution: giupenni commentedvery annoying bug, I'm frustrated.
I can't use correctly Field Group and Displya Suite
Comment #36
joelpittet#25 is a drupal core patch, should this be moved?
Comment #37
odegard CreditAttribution: odegard commentedI 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.
Comment #38
Christian DeLoach CreditAttribution: Christian DeLoach commentedMaybe 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?
Comment #39
joelpittetComment #40
sime7.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.