Undefined index: type in ctools_entity_form_field_content_type_admin_title()
(line 106 of ctools/plugins/content_types/form/entity_form_field.inc)
Clean install with only ctools and panels installed.

I'm attempting to use "Node edit form: node ID" as an argument on a custom panel page. When adding any form content to the panel page i get this error and the title of the form fields doesn't show on the Variants » Panel » Content page, instead all form fields show title as: "Node edit form: node ID form". When viewing the page all seems to be working as intended.
In an earlier version of ctools I encountered a similar issue on the panel system page: "Node edit" but i believe that was fixed in the latest version and the "Node edit" page is working without the error, however the error persists on the custom pages.

Attached an export of the custom panel page I use.

#29 undefined_index-1197582-29.patch907 bytesbangpound
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]
#20 bug.jpg162.81 KBfrikino
#5 ctools_custom_page_form_elements.txt8.32 KBpresleyd
custom panel page.txt2.76 KBmartinyde


Same here, got a panel with a "user : id" argument and get the exact same error.
Results in form elements shows as "Entity info." when viewing the page.

I'm on latest Panels, Entity & CTools dev. (July 20th 2011)

Edit : i've tested with other elements like standard user (from context) and it does not throws the error. Only form elements.

Can confirm #1

I've got the same problem as #1

Also having this problem. Attached is the variant export

new8.32 KB

Oops well it's attached now.

After saving the context a few times the error goes away and the $context object has the restrictions array with an index called type as it seems it should. I'm looking to see where this is populated. If I hard set the offending line 106 by replacing $context->restrictions['type'][0] with my content type and recreate the panel content, the error does not show up. However, the form element still never appears and 'Entity Info' is all that is rendered on the node display. This error does not seem to be the culprit behind the form elements not rendering.

Meh I'm confused, sorry this testing/troubleshooting is less effective than I'd like it to be.

I switched the selection rules to use entity bundle instead of entity node type and then re-added the form elements, making sure that I selected "node edit form from node" under the Node option for each. The error above showed up again but the form displayed. Thinking I had found something telling, I switched the selection rule back to node type and the same behavior resulted: error about line 106 for each form element when I save but the node renders as I would expect it to with form elements instead of 'Entity Info'.

Subscribng, same error, but with adding a Geofield Form to a panel.
greetings, Martijn

Same error when creating a new variant. Also won't display some of the forms in the panels.

Version:7.x-1.0-beta1» 7.x-1.x-dev

Same in the latest dev.

Being a squeaky wheel. Same here using the latest dev of ctools and panels.

Same issue in panels: #1365256: Undefined index: type in ctools_entity_form_field_content_type_admin_title() .

Get this same error whenever trying to add the node edit form elements. It displays "entity info" instead of the form element

Same thing... on a node edit form page, almost everything shows up as simply "node being edited form". Same hatful of errors.

Looks like someone forgot that a form page doesn't have to be limited to just one bundle... Here's some alternate code for the failing function that fixes both problems for me (both the pile of error notice messages, and the full titles for form elements failing to display).

I'm just dumping it here in text rather than as a patch since I'm not sure if the problem should be considered to be in this code or in field_info_instance(), and I'm not 100% sure there aren't other implications for this change. Someone with deeper knowledge of ctools, field instances, contexts etc should get on the case and take it from here.

So be warned to only apply this sticky-plaster fix at your own risk. Basically what it does is, if there's no bundle info in the context, it gets field data for all bundles, merges them together (overriding bundles in the order in which they are listed), and uses that merged data. So, it assumes two things:

  • that there are no crucial differences between field instances between bundles
  • that an unset $context->restrictions['type'] means "all types" and so we should get data for all bundles

These assumptions seem fine in my case, I don't know if it's possible they might not be fine in yours. To apply, replace the ctools_entity_form_field_content_type_admin_title() function code with this.

function ctools_entity_form_field_content_type_admin_title($subtype, $conf, $context) {
  list($entity_type, $field_name) = explode(':', $subtype, 2);
    $field = field_info_instance($entity_type, $field_name, $context->restrictions['type'][0]);
  } else {
    $merged_bundles = array();
    $info = _field_info_collate_fields();
    foreach ($info['instances'][$entity_type] as $bundle_data) {
      $merged_bundles = array_merge($merged_bundles, $bundle_data);
    $field = $merged_bundles[$field_name];
  return t('"@s" @field form', array('@s' => $context->identifier, '@field' => $field['label']));

Same issue here,I also take this message when trying to add to the user_view page a location map(form).It only appear on the user_view page,not on the node_view.Any suggestions?How you solved this one?

The code above isn't specific to one entity type (e.g. node or user) so should work for users too. If I've read the code right, the problem will appear any time you have something with an admin UI built on CTools plugins system (e.g. in my case a page manager page) which doesn't specify bundle types and which includes content-type-panes that don't define their own titles and the same change will fix it (e.g. in my case a node edit form for all node content types).

(this is assuming there are no problems or implications of my code above that I'm not aware of... it seems disconcertingly odd that a central essential module like CTools can have a bug sitting in its issues queue unfixed for 9 months that, seemingly, can be fixed in 30 minutes by someone like me who is more of a front end guy than php developer and who works in drupal only occassionally... I'm sure I must have missed something and that there must be more to it than this... hopefully this will kickstart a proper fix)

I hope someone create a patch soon

Old bug but no solution till now..Ctools 7.x-1.0

I'm getting the same exact problem as the OP. Except the error message is for line 105 now in version 7.x-1.0.

new162.81 KB

Same here , after i add content/form field :
Notice : Undefined index: type dans ctools_entity_form_field_content_type_admin_title() (ligne 105 dans /homez.194/ikino/www/sites/all/modules/ctools/plugins/content_types/form/entity_form_field.inc).

I am using http://ftp.drupal.org/files/projects/ctools-7.x-1.0.tar.gz version.

Please read the tag usage guidelines.

Error with Dev Ctools 7.x-1.x-dev and Dev Panels 7.x.3.x-dev

Status:Active» Postponed (maintainer needs more info)

In order to assist you we need additional information. Please review the drupal.org/node/571990 'Submission Checklist' for the type of information we are looking for. If we cannot duplicate your problem we cannot fix it, so tell us the steps necessary to recreate the problem. When you post information, please change the status back to active. Thanks.

Status:Postponed (maintainer needs more info)» Active

In my case, I'm using Panels in Drupal 7. In the Node/Edit panel page, under "Content" I chose to "Add New Content" and then under "Form" I added the Form Fields associated with the Node/Edit page (Field Form: Body, etc). Each Form pane that I add has no unique name and simply displays this: "Node being edited" form.

Under the title of the page, I get this error message:

Notice: Undefined index: type in ctools_entity_form_field_content_type_admin_title() (line 105 of /home/tekals6/public_html/inmyradius/sites/all/modules/ctools/plugins/content_types/form/entity_form_field.inc).

I don't think this is affecting the ability to edit the node at all, which is good. Seems like it's specific to the actual form's title.

... The problem is that ctools_entity_form_field_content_type_admin_title() has no fallback option for when no bundle name is passed in. So, this error will occur on panel and Page Manager forms that are for all bundles of an entity type (because no one bundle is specified) where there is an item(s) that get title from ctools_entity_form_field_content_type_admin_title() (field widgets, for example). These admin titles will fail to load.

In more detail: The error is Undefined index: type in ctools_entity_form_field_content_type_admin_title(), and the error causes the administrative titles not to be displayed. The type index referred to in the error is used to pass bundle name to field_info_instance().

So, the error will occur when no bundle name is passed in to ctools_entity_form_field_content_type_admin_title(). The examples that people have quoted here are form panels or Page Manager pages for entities where bundle is not specified (i.e. forms that are for all bundles of the entity type).

The example code that I posted in March in #14, which fixes the problem, works by offering a fallback option to get the field data which doesn't require a specific bundle, and uses this fallback for cases where no bundle is specified.

I'm no ctools expert so I can't say for sure that this is the best way to fix it - but, the best way to fix it will be one of these options:

  • Use a fallback if there is no specified bundle (like my code does). This seems to work fine.
  • ...or, maybe $context->restrictions['type'][0] shouldn't be blank when no bundle is specified? If so, make sure a value that is usable by field_info_instance() is passed in to $context->restrictions['type'][0] in cases where no bundle is specified
  • ...or, maybe, field_info_instance() should be able to cope with being passed parameters that don't include a bundle name? Probably not since it is about instances, after all... but if so, patch field_info_instance() so that it can work without a specified bundle and wrap if() logic around $context->restrictions['type'][0] to avoid the warnings

It's a simple, simple bug (but a simple bug in a really complex module). The example fix I posted in #14 took me 30 minutes to debug, diagnose and code - and I know nothing about how ctools works under the hood (which is the reason why I'm not putting the code forward as a patch).

@ananomaly Have you considered contributing to CTools? MelinofChaos is spread thin and would welcome some assistance. If so you can contact him on IRC @ #drupal-panels. He is holding CTools support office hours @ #drupal every other Thursday at non NYC time (is that 5 or 6 hours from GMT?), or you can leave a message here and I'll make sure he gets it.

@Ashlar thanks, and I would contribute more if I could, but I really don't have enough ctools knowledge, time, or access to ctools documentation to be able to contribute anything of value beyond that draft code above. I'm not even primarily a server-side developer, I'm more of a design/UI guy. I've contributed what I can here and I'm not the right person to take this further.

I understand that Merl can't be expected to do everything, but surely there are hundreds of people in the Drupal community who know ctools under the hood well enough to simply eyeball that code and judge whether it's worth making into a patch, or whether it's attacking the problem in the wrong place?

(...If there aren't people who know ctools well enough to do things like this, then we (meaning the Drupal community) have a problem...)

There is never enough people or time to do everything:( All Help is appreciated, even if its just a patch...

Status:Active» Needs review
new907 bytes
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]

All we need is the label from the field, so if we don't have a type, we can just use the subtype (the field name) as the label.

This is made against 7.x-1.0, but it applies to 7.x-1.x-dev too.

If it helps, this error on line 105 just appear for me today. I did not update Drupal nor any modules nor instal any new modules. I had been happily been building a variety of node_edit variants over the last week or so then suddenly today, I can no longer add any Form Fields. I add them, but they do not appear on the user side node_edit form.

D7.14 and Ctools 7.x-1.0

Bug still exists in cTools 7.1.2....

Bangpound's patch worked for me.

Both it and my code from several months ago fix the problem, the only differences I can see are, mine might have tiny performance overheads (it calls _field_info_collate_fields() ) but gives the full correct labels, Bangpound's has zero performance overheads but gives a less human-readable version of the label (for example, "node:field_some_machine_name" where mine gives "Some Field Name").

But it fixes the problem, and that's what matters.

Status:Needs review» Reviewed & tested by the community

I have this same issue and the patch fixed my troubles.

Hi, yes patch fixed it, please commit.
Greetings, Martijn

Status:Reviewed & tested by the community» Fixed

I committed bangpound's patch. While I like the idea of having better labels, I also need actual patches I can look at rather than snippets of code I would have to cut & paste. :)

Fixed after 14 months. Go team.

Had the same problem.
7.x-1.2+6-dev fixed it.

Status:Fixed» Closed (fixed)

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

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

welp, this bug has reared its ugly head. am on 7.x-1.2 which has the patch on #29. it happened all of a sudden on panels nodeform page am working on. fwiw am also on 7.x-3.5.

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

@liza: The latest dev release already has this patch included. Please go check out the 7.x-1.x-dev release and try again.

i posted this by mistake, can I still delete it?

i actually had the dev version installed, but just in case, i re-installed it. i don't see any problems... yet. so maybe there was a change missing in one of my latest updates. but now am not able to attach views to panes. gotta go fish for that issue now :P