$options['group'] defaulted to 1 instead of 0 in views_handler_filter.inc [#1427084]

In the latest release of 7.x-3.1, is there a reason why $options['group'] is defaulted to 1 instead of 0 in handlers/views_handler_filter.inc as was before?

The code in question is in line 92.

  function option_definition() {
    $options = parent::option_definition();

    $options['operator'] = array('default' => '=');
    $options['value'] = array('default' => '');
    $options['group'] = array('default' => '1'); // <-- default changed to 1 from 0 in 7.x-3.1
    $options['exposed'] = array('default' => FALSE);
    $options['expose'] = array(
      'contains' => array(
        'operator_id' => array('default' => FALSE),
        'label' => array('default' => '', 'translatable' => TRUE),
        'use_operator' => array('default' => 0),
        'operator' => array('default' => ''),
        'identifier' => array('default' => ''),
        'required' => array('default' => 0),
        'remember' => array('default' => 0),
        'multiple' => array('default' => 0),
      ),
    );

    return $options;
  }

function add_where($group, $field, $value = NULL, $operator = NULL) in plugins/views_plugin_query_default.inc expects default $group to be 0 and also sets it to 0 if its empty. However, we are passing 1 as the default now from views_handler_filter.inc in

function query() {
    $this->ensure_my_table();
    $this->query->add_where($this->options['group'], "$this->table_alias.$this->real_field", $this->value, $this->operator);
  }

What is the correct default? If the default is to be 1 from now, then backward compatibility will have to be given a better thought. This is also causing some of my views that were created by an older version of views to fail when I upgraded. Manually changing $options['group'] to default to 0 resolved it.

Comment	File	Size	Author
#13	1427084-no-results-views-cache.png	6.48 KB	girishmuraly
#9	views_3.1.zip	509.22 KB	skruf
#5	1427084.patch	1.24 KB	dawehner
#5
#4	DebugOutput.tar_.gz	464.58 KB	girishmuraly
#2	1427084-views-export.txt	28.79 KB	girishmuraly
#1	filter_group_default-1427084-1.patch	581 bytes	girishmuraly
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

girishmuraly CreditAttribution: girishmuraly commented 3 February 2012 at 10:57

Status:

Active

» Needs review

File	Size
filter_group_default-1427084-1.patch	581 bytes

Attaching simple patch to reset the default back to 0.

Comment #2

girishmuraly CreditAttribution: girishmuraly commented 3 February 2012 at 11:55

File	Size
1427084-views-export.txt	28.79 KB

I also forgot to mention that my views were using a Time based cache. I was able to get the views working with 7.x-3.1 by also setting cache to 'none', and leaving $options['group'] as it is to '1'. Note that this does not mean I was getting cached results. I was getting no results at all. All this was working as it is before upgrading to 7.x-3.1. So basically two options as workarounds work for me:

a) Hack $options['group'] and set its default to 0 as in 7.x-3.0, or,
b) Remove views caching from my views.

Having $options['group'] set to 1 as default *and* having time based caching on my previous view gave no results, which suggests some interoperability problems between the two settings. However, the live preview worked fine.

I'm attaching my view for reference.

Comment #3

dawehner

German

CreditAttribution: dawehner commented 4 February 2012 at 23:12

Mh this change was definitive intended and set back to 0 would remove the bug fix which was actually in here

   * As views has to wrap the conditions from arguments with AND, a special
   * group is wrapped around all conditions. This special group has the ID 0.
   * There is other code in filters which makes sure that the group IDs are
   * higher than zero.
   *

It would be cool if you would have a query generated by views before 3.1 and after 3.1, so it's possible to see some difference.

Comment #4

girishmuraly CreditAttribution: girishmuraly commented 6 February 2012 at 13:35

File	Size
DebugOutput.tar_.gz	464.58 KB

Certainly. I am attaching two txt files containing debug output using 3.0 and 3.1. Each txt file contains the SQL query shown during Auto preview on the view edit screen, and also a print_r($view) done in a hook_views_pre_render() for the same view on the actual view display page. HTH

I noticed some differences in $view->query->where. I shall leave it to your better interpretation :)

Comment #5

dawehner

German

CreditAttribution: dawehner commented 6 February 2012 at 17:26

File	Size
1427084.patch	1.24 KB

Oh thanks for this! This really helped to track down the issue.

As always taxonomy is the root all problem :)

Comment #6

girishmuraly CreditAttribution: girishmuraly commented 7 February 2012 at 10:25

Status:

Needs review

» Fixed

Brilliant, thanks for that! Tested, and your patch resolves the issue for me. Marking as fixed..

Comment #7

rickvug CreditAttribution: rickvug commented 7 February 2012 at 10:28

Status:

Fixed

» Reviewed & tested by the community

Has the patch been committed? I don't see any reference to 1427084 in the commit log. Setting to RTBC instead - dereine can mark as fixed.

Comment #8

dawehner

German

CreditAttribution: dawehner commented 7 February 2012 at 11:50

Version:	7.x-3.x-dev	» 6.x-3.x-dev
Status:	Reviewed & tested by the community	» Patch (to be ported)

Thanks for updating the patch, it could have indeed happened that the patch get lost.

This patch is maybe worth to backport to 6.x-3.x

Comment #9

skruf CreditAttribution: skruf commented 16 February 2012 at 12:30

Version:	6.x-3.x-dev	» 7.x-3.1
Status:	Patch (to be ported)	» Needs work

File	Size
views_3.1.zip	509.22 KB

Im getting the same issue despite the patch being applied. Turning off cache or changing:

$options['group'] = array('default' => '1');
to
$options['group'] = array('default' => '0');

fixes it as before. Attaching debug and export.

Comment #10

dawehner

German

CreditAttribution: dawehner commented 16 February 2012 at 13:13

How does the query looks like if you have attached the patch from above?

Comment #11

skruf CreditAttribution: skruf commented 16 February 2012 at 16:40

The patch had already been applied to 3.1 when I output the query and debug.

Comment #12

dawehner

German

CreditAttribution: dawehner commented 16 February 2012 at 17:22

Well the query just has AND conditions, actually there shouldn't be any difference.

Comment #13

girishmuraly CreditAttribution: girishmuraly commented 17 February 2012 at 11:10

File	Size
1427084-no-results-views-cache.png	6.48 KB

Hi @dereine, I work with @skruf and I must add that this view also uses time based caching. When the cache is turned off, the view works in 3.1, however caching causes some trouble - the results are not displayed but the pager is (screenshot attached).

I have also noticed changes to the $view->query->where in #9 (similar to that in #4). Would it be related?

Comment #14

dawehner

German

CreditAttribution: dawehner commented 17 February 2012 at 11:16

Status:

Needs work

» Closed (duplicate)

I did some debugging on this issue and what should i say, this is not easy.

See http://drupal.org/node/1430650#comment-5567728 for a short comment. The query is there converted to a string, so views can generate a caching key, though this seems to produce bad things.

So basically #1430650: Taxonomy filter with depth, Drupal 7.12, and views query caching failure is the same issue.
I bet the right fix is maybe one line of code, though hard to find. Such issues fill a total evening/night to get into it.