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

Comments

prston’s picture

prston commented
StatusFileSize
new flag-7.x-2.1-issue-1993578.patch623 bytes

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

joachim commented
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

sewhaa commented

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

joachim commented
Status: Active » Postponed (maintainer needs more info)

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

manumad40’s picture

manumad40 commented

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

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