Jump to:
| Project: | Views |
| Version: | 5.x-1.6-beta5 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
It is possible to use two filters to filter a range of nodes. For example, if our product has a length field, we can choose:
Filter, decimal field: length, greater than or equal "100"
and then
Filter, decimal field: length, less than or equal "200"
Save the view, then look at the page and results are limited correctly to products with 100 <= length <= 200. All is well.
Exposing these filters so the site visitor can change the parameters does not work as expected.
Firstly, (configuration) in order to expose both filters, one must add the filters, save the view, then expose the second filter, wait for refresh and expose the first filter. Then save the view. Both views will appear in the page as expected.
Secondly, (operation) while the filters are exposed and they display as expected, they do not operate as expected. Only one filter works, so results will be length >= 100, _or_ length <= 200 rather than the desired / expected 100 <= length <= 200.
Help us Obi-Wan Bug Crusher! You're our last and only hope!
Comments
#1
Some more details. Setting upper and lower bounds for a search range works,
/*** a portion of the exported view
*/
$view->filter = array (
array (
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
array (
'tablename' => 'node_data_field_fl_min',
'field' => 'field_fl_min_value_default',
'operator' => '>=',
'options' => '',
'value' => '8',
),
array (
'tablename' => 'node_data_field_fl_min',
'field' => 'field_fl_min_value_default',
'operator' => '<=',
'options' => '',
'value' => '49',
),
);
$view->exposed_filter = array (
array (
'tablename' => 'node_data_field_fl_min',
'field' => 'field_fl_min_value_default',
'label' => 'upper bound',
'optional' => '0',
'is_default' => '1',
'operator' => '1',
'single' => '0',
),
array (
'tablename' => 'node_data_field_fl_min',
'field' => 'field_fl_min_value_default',
'label' => 'lower bound',
'optional' => '0',
'is_default' => '1',
'operator' => '1',
'single' => '0',
),
);
Save the view and then view the page and the filter range works as expected. The sql initially generated by the view includes this WHERE clause:
/*** a portion of the WHERE clause initially generated by this view
*/
AND (node_data_field_fl_min.field_fl_min_value >= '8')
AND (node_data_field_fl_min.field_fl_min_value <= '49')
Even though this sql is correct, there appears to be a problem because the two textfields for upperbound and lowerbound have the same parameter displayed, in this case, the lower bound value, "8".
Let's correct the filter values so lowerbound remains at 8 and upperbound is corrected to read "49" as in our default. Here, things break.
/**
* the addressbar displays the correct filter range values
*/
http://www.example.com/testview?filter0=49&filter1=8
/**
* but the sql generated is wrong. Here's the pertinent portion of the
* WHERE clause from views_build_view
*/
AND (node_data_field_fl_min.field_fl_min_value >= '8')
AND (node_data_field_fl_min.field_fl_min_value <= '8')
Is this a problem with views_get_filter_values retrieving the values, or something else? I don't know where to start for a patch.
#2
To be clear (and perhaps I should have tried this in the comment above) any parameter values for upperbound and lowerbound are shown correctly in the address bar parameters.
The search range fails because the sql generated incorrectly duplicates the lowerbound value and ignores the upperbound value.
#3
The problem is that when you have two input fields referencing the same field, the one overrides the other.
Another approach would be to define a new operator, say "range", and when that's selected a user can put '100-200' in the text field. You'd need to define special handling syntax to properly translate that into a query clause, but I would tend to think that would be an easier way to implement what you're trying to achieve.
#4
I don't think they are referencing the same field. The html generated calls them filter0 and filter1 .
The range works when first accessing the view by menu.
-- while the first look works, the two text fields only show one value, duplicated in the second field
The range works when the filters are not exposed.
The two parameters appear correctly in the url http://example.com/testproducts?filter0=8&filter1=15
The two parameters appear correctly in the text fields in the re-loaded page.
It looks like only the sql is being generated incorrectly. In the sql filter0 is used correctly with op0, but then filter0 also appears as the value for op1. It should be filter1 that is used with op1.
Here is the WHERE clause when we submit the page:
WHERE (node.status = '1') AND (node_data_field_fl_min.field_fl_min_value >= '8') AND (node_data_field_fl_min.field_fl_min_value <= '8')
Is the function that builds the sql from exposed filters using exposed filter values as an array, or always using filter0 rather than filtern ?
It would be wonderful to have a range operator as you describe. I believe that it is beyond my current abilities to create that operator.
The existing views filters appears to support ranges until we expose them and try to update the values.
#5
This isn't technically a bug, this is an unfortunate limitation in the design of exposed filters.
What's the difference, you ask? Bugs can be fixed easily. This can't.
I've been aware of this since shortly after exposed filters went live, and because of the way Views uses IDs to identify which filter to use, it turns out you can't have the same filter exposed twice, which makes it impossible to use ranges with exposed filters.
There is only one thing you can do: Duplicate the filter you're using so that you have two different filters. Then they'll not be the same filter.
#6
This isn't technically a bug, this is an unfortunate limitation in the design of exposed filters.
What's the difference, you ask? Bugs can be fixed easily. This can't.
I've been aware of this since shortly after exposed filters went live, and because of the way Views uses IDs to identify which filter to use, it turns out you can't have the same filter exposed twice, which makes it impossible to use ranges with exposed filters.
There is only one thing you can do: Duplicate the filter you're using so that you have two different filters. Then they'll not be the same filter.
#7
I have the same issue with attempting to expose filters to achieve the range filtering.
merlinofchaos,
By "duplicate the filter" did you mean clicking "Add filter" a second time on the same field ? I added the same filter a second time and it appeared in addition to the first copy seemingly ok.
My problem now (besides the range not working) is that I cannot even delete either of the filter because the delete (operation) icon does not appear.
#8
Ok, I've managed to get back the delete icons (in the filter fieldgroup) by clearing all the exposed filters. (I must have missed saving the changes earlier).
Back to the issue - duplicating a field (adding the same field again) in Filter does not enable me to expose/add the field twice to Exposed Filters. Once the first field is exposed, the "expose" button disappears from the other field.
Can someone confirm the same behavior and that getting a filter range query is not possible with the current module version (5.x-1.6-beta5) ?
#9
Ok, I've managed to get back the delete icons (in the filter fieldgroup) by clearing all the exposed filters. (I must have missed saving the changes earlier).
Back to the issue - duplicating a field (adding the same field again) in Filter does not enable me to expose/add the field twice to Exposed Filters. Once the first field is exposed, the "expose" button disappears from the other field.
Can someone confirm the same behavior and that getting an exposed filter range query is not possible with the current module version (5.x-1.6-beta5) ?
#10
I've pretty much come to the conclusion, to answer my own question, that it isn't possible to currently expose the same field twice.
And I've gone ahead to make a patch (http://drupal.org/node/151989) to add a set of new 'range' operators that solves this limitation.
#11
Bug report is not resolvable.
Feature request in #151989: Adding a range filter operator.