On Drupal 7.22 and PHP 5.4, flag_handler_field_ops->query() function calls trigger a notice as the join field index is sometimes not defined but used.

Notice: Undefined index: join field in flag_handler_field_ops->query() (line 78 of /****/sites/all/modules/flag/includes/flag_handler_field_ops.inc).
Notice: Undefined index: join field in flag_handler_field_ops->query() (line 104 of /****/sites/all/modules/flag/includes/flag_handler_field_ops.inc).

CommentFileSizeAuthor
#1 flag-7.x-2.1-issue-1993578.patch623 bytesprston
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

prston’s picture

Please find the patch in attachment.
Evaluating $info['join field'] returns NULL at it is undefined. So my patch just set it to NULL manually, before it trigger the notice at lines 78 and 104.

Line 78:
As described at http://api.drupal.org/api/views/includes!handlers.inc/function/views_join%3A%3Aconstruct/7 the third parameter ($left_field = NULL) of the construct() method can be NULL.

$join->construct('flag_content', $info['views table'], $info['join field'], 'content_id');

Line 104:
But following http://api.drupal.org/api/views/plugins!views_plugin_query_default.inc/7 the second parameter $field of the add_field() method cannot be NULL as it's used later and not escaped. I wonder if it has some side effect somewhere.

$this->aliases['content_id'] = $this->query->add_field($left_table, $info['join field']);
joachim’s picture

Version: 7.x-2.1 » 7.x-3.x-dev

Thanks for reporting and figuring out the problem!

Could you try this on 3.x please? Bugs need to be fixed on the development branch, then backported.

Check the Drupal coding standards too -- if() blocks always need enclosing {}, even if a single line.

I'm also not sure when 'join field' can be undefined: the $info array is obtained from this:

  /**
   * Returns information for the Views integration.
   */
  function get_views_info() {
    $entity_info = entity_get_info($this->entity_type);

    if (!isset($entity_info['base table'])) {
      return NULL;
    }

    return array(
      'views table' => $entity_info['base table'],
      'join field' => $entity_info['entity keys']['id'],
      'title field' => isset($entity_info['entity keys']['label']) ? $entity_info['entity keys']['label'] : '',
      'title' => t('@entity_label flag', array('@entity_label' => $entity_info['label'])),
      'help' => t('Limit results to only those entity flagged by a certain flag; Or display information about the flag set on a entity.'),
      'counter title' => t('@entity_label flag counter', array('@entity_label' => $entity_info['label'])),
      'counter help' => t('Include this to gain access to the flag counter field.'),
    );
  }
}
sewhaa’s picture

I get this very same error but somehow the patch does not work for me. and i cant find any video to walk me through

joachim’s picture

Status: Active » Postponed (maintainer needs more info)

I'm going to need more information on how to reproduce this bug.

manumad40’s picture

These issues identify the origin of this problem and it seems they solve it:

#1647144: Default "like" flag can conflict with existing flags named "like"
#1689502: Error when enabling flag submodules for status module

So, I'm closing this. To avoid duplicates, this issue can continue here it the problem presists:

#1782910: How to deal with multiple modules providing a default flag with the same name?

manumad40’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (works as designed)
Issue tags: +Flag, +flags, +statuses, +like, +flag modules, +flag submodules