After installing module I get notice mentioned in title

CommentFileSizeAuthor
#8 efq_views-undefined_index-1958106-8-D7.patch855 bytesmac51
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Stephen Rockwell’s picture

Issue summary: View changes

I know you said open up a new bug report, but I also don't want to repeat. I'm getting almost the same error message upon enabling the module.

Notice: Undefined offset: 1 in _efq_views_get_field_handlers() (line 194 of /sites/all/modules/efq_views/efq_views.views.inc).

chx’s picture

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

Then you are filing for the wrong version, I am afraid cos in 7.x-1.x-dev this line is empty but the code just moved so I don't think just moving to 7.x-1.x-dev solves the problem. Now, can someone do a cache clear and tell me what this

  if (isset($views_data['real field'])) {
    if (strpos($views_data['real field'], ':') === FALSE) drupal_set_message($views_data['real field']);
    list($field_name, $column) = explode(':', $views_data['real field']);
  }

prints?

chx’s picture

Title: Undefined offset: 1 in _efq_views_get_field_handlers() (line 194 of .../sites/all/modules/efq » Undefined offset: 1 in _efq_views_get_field_handlers() (line 194 of .../sites/all/modules/efq/efq.views.inc

bsandor, thanks for the bug report but in the future please be more careful and include the file name in the bug report.

mac51’s picture

After adding the code in comment #2, I received the following output. Disabling the Organic Groups module seems to have resolved the error message.

og_membership__1
og_membership__2
og_membership__3
og_group_ref__og_membership
og_group_ref__og_membership__1
og_group_ref__og_membership__2
og_group_ref__og_membership__3
members__1
members__2
members__3
og_membership__1
og_membership__2
og_membership__3
og_user_node__og_membership
og_user_node__og_membership__1
og_user_node__og_membership__2
og_user_node__og_membership__3

chx’s picture

Title: Undefined offset: 1 in _efq_views_get_field_handlers() (line 194 of .../sites/all/modules/efq/efq.views.inc » og membership views integration causes a notice
Version: 7.x-1.0-alpha5 » 7.x-1.x-dev

Thanks! I will install og and see what's up.

amitaibu’s picture

og_membership__1
og_membership__2
og_membership__3
og_group_ref__og_membership
og_group_ref__og_membership__1
og_group_ref__og_membership__2
og_group_ref__og_membership__3
members__1
members__2
members__3
og_membership__1
og_membership__2
og_membership__3
og_user_node__og_membership
og_user_node__og_membership__1
og_user_node__og_membership__2
og_user_node__og_membership__3

These items are provided by OG in hook_entity_property_info(), and they are "dummy" properties in the sense they have no schema field (i.e. they have no column in the DB that is mapped to them).

maybe EntityFieldQuery Views Backend is looking at all the properties defined by entity metadata wrapper, including the computed ones?

chx’s picture

I believe the colon comes from here (heavily edited):

  foreach (entity_get_info() as $type => $info) {
    foreach (entity_get_all_property_info($type) as $key => $property) {
        entity_views_field_definition($key, $property, $data['views_entity_' . $type]
// ...
function entity_views_field_definition($field, array $property_info, array &$table, $title_prefix = '') {
  // Create a valid Views field identifier (no colons, etc.). Keep the original
  // data selector as real field though.
  $key = _entity_views_field_identifier($field, $table);
  if ($key != $field) {
    $additional['real field'] = $field;
  }

So, as far as I can see entity_get_all_property_info($entity_type)[$views_data['real field']] would contain the property info. Now hook_entity_property_info docs contain computed but og doesn't define that. Just checking for entity_property_verbatim_get won't fly either cos for eg entity/modules/user.info.inc doesn't use that.

So we should get the property info as described and definite use when the schema field is defined or the getter callback is entity_property_verbatim_get and use it. Definitely skip when computed is set. If neither then watchdog error if there is no colon.

mac51’s picture

Separated the one-liner causing the issue into multiple lines with appropriate checks. It seems this way is a bit safer, as the number of results returned by explode() is determined dynamically.

scotwith1t’s picture

+1 for this patch. same issue with OG integration and this solved it. there may be something OG is doing wrong, but haven't explored that option. this works for us though.