Motivation

When you have some kind of numeric like filter, for example node: nid, field: field_name or some kind of date field
having just a pure textfield isn't enough.

At the moment people would have to write custom code to be able to do something like "4 or more" as a select option.

Proposed resolution

The solution to the problem is to provide the users to configure the options of the exposed filters.

With this patch you have an additional checkbox "grouped filters" which opens you a total new interface of allowed options.
Instead of a "single filter" you can configure each group item to use a certain operator and value.

You have several things in the userinterface you can do:

  • Configure the operator of the group item, for example "between" or "greater"
  • Configure the values of the group item
  • Add a new group item
  • Select the default group item

Fitler UI for a string filter

Configure string filter

Filter UI for a number filter

Configure numeric filter

Exposed Filter for the number filter

Show numeric exposed filter

Remaining tasks

Tests from more users.

User interface changes

TODO

API changes

TODO

Original report by [dagmar]

I would like to implement a new kind a exposed filters into views.

I'm thinking in a combo box with like this:

Select Number Rooms:
1
2
3
4 or more

Of course this can be easily implemented into a custom module, and I know how code it.

However maybe this could be a more abstract feature in views 3, allowing filters to merge into a single form a combination of a filter and a operator.

User could define something like this in a UI

Operator              Value           Display
=                        1                1
=                        2                2
=                        3                3
=>                       4                4 or more

I understand that specially "Value" is a complex thing to define. But, maybe it is possible to implement without destroy all the filters handlers, what do you think? dereine? merlinofchaos?

I think exposed form plugins are not the better way to configure this, probably a redefinition of views_handler_filter can make this possible.

What do you think, is a very crazy idea, or not?

CommentFileSizeAuthor
#160 views-731662-160.patch82.34 KBtim.plunkett
#158 views-731662-158.patch81.37 KBtim.plunkett
#155 interdiff.txt488 bytestim.plunkett
#155 views-731662-155.patch81.75 KBtim.plunkett
#153 views-731662-153.patch81.78 KBtim.plunkett
#150 731662.views_.142-new-tests.patch79.9 KBdagmar
#150 731662.views_.150.patch83.38 KBdagmar
#144 hybrid_filters.png37.54 KBdawehner
#144 hybrid_filters1.png36.75 KBdawehner
#144 hybrid_filters2.png15.12 KBdawehner
#142 731662.views_.142.patch76.02 KBdagmar
#140 731662.views_.140.patch76.96 KBdagmar
#137 731662.views_.137.patch48.04 KBdagmar
#136 731662.views_.136.patch47.47 KBdagmar
#132 Snap4.jpg70.74 KBdgastudio
#129 731662-hybrid-filters.129.patch41.9 KBdagmar
#129 hybrid-checkboxes.png34.14 KBdagmar
#127 interdiff.txt4.09 KBtim.plunkett
#127 views-731662-127.patch38.55 KBtim.plunkett
#124 interdiff.patch2.33 KBtim.plunkett
#124 views-731662-124.patch37.2 KBtim.plunkett
#120 7731662-hybrid-filters.120.patch37.45 KBdawehner
#118 zero.png36.13 KBdawehner
#118 731662-hybrid-filters.114.patch37.29 KBdawehner
#114 731662-hybrid-filters.114.patch37.91 KBdagmar
#110 Snap1.jpg100.84 KBdgastudio
#109 731662-hybrid-filters.109.patch36.83 KBdagmar
#107 731662-hybrid-filters.107.patch35.82 KBdagmar
#106 2.png22.75 KBMarc-Antoine
#106 1.png88.94 KBMarc-Antoine
#103 01.png70.74 KBMarc-Antoine
#103 02.png87 KBMarc-Antoine
#103 03.png65.86 KBMarc-Antoine
#103 04.png55.49 KBMarc-Antoine
#103 05.png32.1 KBMarc-Antoine
#97 1.png80.43 KBdagmar
#97 2.png73.8 KBdagmar
#97 3.png85.53 KBdagmar
#97 4.png75.37 KBdagmar
#97 5.png65.58 KBdagmar
#97 731662-hybrid-filters.97.patch35.4 KBdagmar
#95 731662-hybrid-filters.95.patch35.23 KBdagmar
#92 views-7.x.731662.92.patch32.85 KBdagmar
#64 hybrid_filter_output.jpg50.67 KBBWPanda
#60 views_731662_60.patch20.43 KBBWPanda
#53 view_export.txt4.76 KBSuperXren
#51 1.JPG33.7 KBSuperXren
#47 view_bug.png24.64 KBSuperXren
#45 731662.patch20.15 KBbojanz
#45 interdiff.patch8.78 KBbojanz
#43 views-731662.43-hybrid-filters.patch20.05 KBdawehner
#40 screenshot.jpg94.72 KBwebadpro
#39 views-731662.40-hybrid-filters.patch19.09 KBdagmar
#30 views-731662-hybrid-filters_1.patch17.15 KBdawehner
#26 views-731662-hybrid-filters_2.patch18.02 KBdawehner
#23 views-731662-hybrid-filters_1.patch17.15 KBdagmar
#22 views-731662-hybrid-filters.patch16.64 KBdawehner
#20 views-731662-hybrid-filters.patch14.76 KBdagmar
#7 pic1.png15.98 KBdagmar
#7 pic2.png46.51 KBdagmar
#7 pic3.png10.07 KBdagmar
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dagmar’s picture

The last line into the <code> tag is:

>=                 4                4 or more
Manuel Garcia’s picture

I think its a great idea, though it sounds like quite a challenge to implement... just how you can build your query, build your exposed filter. Sounds definitely interesting!

dawehner’s picture

This is definitive a very very cool feature. There are many people requestion this feature:

I would also like to see, for example: between 0 and 10, between 10 and 20, greater 20.

I think this will be hard to implement, definitive.

dagmar’s picture

An approach to achieve this task could be this:

In views_handler_filter add a new variable similar to "exposed", maybe "hybrid" is not the best word, but it doesn't matter now.

Alter views_plugin_query_default to call to hybrid_query() instead of query() for filters marked as hybrid.

In the filter UI provide a new button like exposed to generate hybrid filters, we could display something like a table with three columns.

Display | Operator | Value

Display can be a simple textfield, but operator and value have to be filled with the same forms that views displays in exposed forms. This allow us to insert a valid item for operator and value. As dereine said in #3 to get between 10 and 20, users should be able to select Between operator and fill the min and max value.

Ok, there is a lot more to consider, like the render form part, and well, a lot of other things, for now only ideas....

YK85’s picture

+1 subscribing - this sounds like a great new feature!

Bilmar’s picture

subscribing

dagmar’s picture

FileSize
10.07 KB
46.51 KB
15.98 KB

Ok, here are some screenshots of the ui. @dereine are we thinking in the same thing?

dawehner’s picture

This looks fine! Does this form only appear when you click "expose in group"?

This will be awesome, damn, i have to present views3 again :)

Did you implemented anything already? I would like to help, as always :)

merlinofchaos’s picture

This is really interesting! I think the proposed UI seems workable.

webadpro’s picture

Hi,

I'm just wondering if this has been released yet?

dagmar’s picture

@webadpro: No it isn't have been released. It is a complex patch and I'm working on it in my free time. Please be patient.

dawehner’s picture

@dagmar

I suggest we chat a bit about it. I also coded quite a bit on this patch.

webadpro’s picture

Thanks for the quick reply. I can't wait to see it, because I'm actually in need of it for a projet for a client.

dawehner’s picture

This will definitive be stable soon. You can still achive this with your own filter handler, which needs custom code.

webadpro’s picture

That's great news; If there's anything I can help with let me know!

dawehner’s picture

I wanted to write that this will definitive not be stable soon :)

webadpro’s picture

I see alright. Well lets see what could I get done on my own.

Thanks

dagmar’s picture

Issue tags: +views 3.x roadmap

Lets try to include this is views 3 soon. Tagging.

TC44’s picture

that looks great, this would be amazing to have.

dagmar’s picture

Status: Active » Needs review
FileSize
14.76 KB

Ladies and Gentlemen, Start Your Engines :)

Here is the first version of this patch, I just tried it out using Node: Nid, as you can see in this video: http://vimeo.com/14533078

There are still a lot of things to fix, here is a list of TODO's:

  • Allow to add and remove items of the group using ajax (at this moment add group doesn't work, and remove item either).
  • Allow to 'remember' the selection of a value
  • Ensure that options like 'use operator', 'indentifier' and 'operator identifier' are properly defined, due they are a requirement to hybrid filters works
  • Provide a method like can_make_groups() (like can_expose()) to determine if a filter can create groups, if a filter doens't have operators, it cannot create groups.
  • Maybe, define a key for each item in the group. At this moment a numeric id is used, but probably this will be a complication when items are added or removed
  • Maybe, allow to re-order items
  • Test. Test. Test!
  • and write tests :)

I'm changing the status to 'needs review' to give a change to review things that are working at this moment. Enjoy :)

dawehner’s picture

Just for later

+    // TODO: Make this more flexible
+    for ($x = 1; $x <= 10; $x++) {

This should be less my default if add group works.

dawehner’s picture

# Provide a method like can_make_groups() (like can_expose()) to determine if a filter can create groups, if a filter doens't have operators, it cannot create groups.

i called it can_expose_groups

# Allow to add and remove items of the group using ajax (at this moment add group doesn't work, and remove item either).

This is possible now.

# Allow to 'remember' the selection of a value

What do you mean with this?

dagmar’s picture

From previous list:

  • Allow to add and remove items of the group using ajax (at this moment add group doesn't work, and remove item either).
  • Allow to 'remember' the selection of a value
  • Ensure that options like 'use operator', 'indentifier' and 'operator identifier' are properly defined, due they are a requirement to hybrid filters works
  • Provide a method like can_make_groups() (like can_expose()) to determine if a filter can create groups, if a filter doens't have operators, it cannot create groups.
  • Maybe, define a key for each item in the group. At this moment a numeric id is used, but probably this will be a complication when items are added or removed
  • Maybe, allow to re-order items
  • Test. Test. Test!
  • and write tests :)

New items:

  • Beside add group and remove groups is working, there is a problem when an item is deleted and a new group is added, the deletion is restored, and two groups are added instead of one.
  • Exposed filter template is not prepared to work with this kind of widget, labels are rendered for a non existen widget, and the group of filters is rendered outside the div.
  • I changed the way that can_expose_groups() is defined.
  • Added a row to define -Any- as the selected item by default.
# Allow to 'remember' the selection of a value

What do you mean with this?

I mean use $_SESSION to storage the value of the group. We can postpone this part, is pretty complex.

Mmm, I'm comfortable with this way of working, like a ping pong of patches, there a lot of things to do, and code a bit each one will make this task easier. Other users of this thread are invited to participate too :)

TC44’s picture

This looks fantastic, thanks for all your hard work! I'll hopefully get a chance to test later this week.

Manuel Garcia’s picture

First of all, WOW.

Second, are you guys aware of this brand new project? http://drupal.org/project/views_dynamic_fields fork? should we hunt the author down?

[EDIT] OK, that module doesn't have much to do with this patch, [offtopic] still, perhaps they should provide a new patch for views3?[/offtopic]

dawehner’s picture

# Allow to 'remember' the selection of a value

Thanks for the explanation. So what have to be done is in filter::store_exposed_input
I'm wondering wether it would make sense to create a store_exposed_input_group and a store_exposed_input_basic

This would make it easier

# Ensure that options like 'use operator', 'indentifier' and 'operator identifier' are properly defined, due they are a requirement to hybrid filters works

This is already done by

  // If necessary, set new defaults:
  if ($item['build_group']) {
    $form_state['handler']->expose_options();
  }

No that's wrong i added the code which does this:

  function exposed_form(&$form, &$form_state) {
    if (empty($this->options['exposed'])) {
      return;
    }

    // If this filter use a group of operator | values
    if (!empty($this->options['build_group'])) {
      // Set the flags to be used later.
      $value = $this->options['expose']['identifier'] = $this->options['group_info']['identifier'];
      $this->options['expose']['use_operator'] = TRUE;
      $this->options['expose']['operator'] = $this->options['group_info']['operator'];

I tryed to add the reordering but it does not work yet. No idea why.

# Exposed filter template is not prepared to work with this kind of widget, labels are rendered for a non existen widget, and the group of filters is rendered outside the div.

This looks better now.

# Beside add group and remove groups is working, there is a problem when an item is deleted and a new group is added, the deletion is restored, and two groups are added instead of one.

I don't have a clue about this one. The problem is that in the submit handler both the form_state and the handler->options has still the removed item.

dawehner’s picture

#25

I think in views3 this should be a exposed form plugin. I think there is none yet but it would be also possible as contrib module. The module is somehow a hack with hooks.

TC44’s picture

Hi, will #26 patch the Sept. 15 Dev version, or is it better to patch alpha 3?

I tried to patch and test with the latest dev, but was getting an error.

Thanks!

dawehner’s picture

Always test again the latest dev.

dawehner’s picture

Yeaaaaaah Tabledrag works now. At least when you add a new tab for the filter settings. *sigh*

I understand why items doesn't get removed

This is frustrating.

dawehner’s picture

What's missing

* Bug when you remove items. See above
* Allow to 'remember' the selection of a value
* Maybe, define a key for each item in the group. At this moment a numeric id is used, but probably this will be a complication when items are added or removed

That's basically it.

webadpro’s picture

Hi,

Just curious, if I want to implement this custom code in my views module do I use the version of #30 OR #26?

Thanks

webadpro’s picture

I have just downloaded the lastest Dev copy and I get a hunk #2 succeeded at 3371 (offset 36 lines) when trying to apply either 30 or 26 patch.

dawehner’s picture

#33

Okay this patch still appears, that's what we expect :)

webadpro’s picture

Do you know when will you have a new patch that will work with the latest Views Dev copy?

dagmar’s picture

@webadpro "hunk #2 succeeded" means, I was successfully applied but the original file has been modified since the creation of the patch. (And the patch has been applied 36 lines below the original position)

webadpro’s picture

@dagmar well thank you very much for the information. Its always good to know and I greatly appreciate it.

TC44’s picture

I updated the latest dev and patched with #30, and was able to get it working!

Just want to give a big thanks, this for me is an enormously helpful breakthrough. I've been struggling with this issue for months trying to get something workable for exposed filters. It also worked on computed fields, which I was a bit concerned about. This seems to be the ticket.. thanks again!

dagmar’s picture

Remember now works.

Related to "Bug when you remove items." I think this can go as is, I know, it is a problem of usability, but I think is not "so bad".

@dereine, $form_state contains the info to determine if there are group items to be removed, I tried to use this information to skip removed items, but it creates more problems that it fixes. Maybe you can found a better solution.

Maybe, define a key for each item in the group. At this moment a numeric id is used, but probably this will be a complication when items are added or removed

Mmm, I don't think this is a good idea, the current form is already complex to introduce another textfield to complete with and id. But If you code it, I will not complain :)

I didn't test this stuff using group by in a view, I'm afraid this will not work.

webadpro’s picture

FileSize
94.72 KB

Hello I was wondering if I was the only one or not, but when I apply the patch (without any errors) the layout seems all weird. Please view the attachment and if anyone could help I would really appreciate it. Also i'm using garland for the layout.

Thanks.

webadpro’s picture

My bad, this addon works great. I simply forgot to clear my cache. Thanks to all the developers!

dawehner’s picture

Is it just me that tabledrag doesn't work anymore?

dawehner’s picture

This is now a working verison of the tabledrag.

Regarding the remove/add-bug. I think this is fixed now.

dawehner’s picture

Issue tags: +alpha-4 blocker

Would be cool to get this in before alpha4/beta1.

bojanz’s picture

Status: Needs review » Needs work
FileSize
8.78 KB
20.15 KB

Attaching an updated patch, and an interdiff.
Mostly cosmetic changes (coding standard, english text).

Some explanations:

1.

-    $identifier = !empty($this->options['group_info']['identifier'])?$this->options['group_info']['identifier']:'group_' . $this->options['expose']['identifier'];
+    if (!empty($this->options['group_info']['identifier'])) {
+      $identifier = $this->options['group_info']['identifier'];
+    }
+    else {
+      $identifier = 'group_' . $this->options['expose']['identifier'];
+    }

When concatenation is present, then a ternary operator is avoided, so that we don't have to think about operator precedence and other ugly things. This is the drupal core way, I had a talk with people at #drupal-contribute (including merlinofchaos) about it a few months back.

2. In foreach() loops, $x is now $group_id. We don't really want a variable called $x, I have no idea what that means :)

3.

-    $form['expose']['#prefix'] .= '<div class = "group-populated">';
+    $form['expose']['#prefix'] = '<div class="group-populated">' . $form['expose']['#prefix'];
     $form['expose']['#suffix'] .= '</div>';

We need to take make sure the HTML tags open and close the right way, without intermixing with other elements. If we started our div before all other HTML, we need to close it after all HTML. If we started it after, we need to close it before all HTML.

Testing showed:

1.

warning: Invalid argument supplied for foreach() in sites/all/modules/views/theme/theme.inc on line 583.

2. Works for Node: Nid, but fails miserably for Node: Type.
When trying to use Node: type
a. Selecting "NULL" or "IS NOT NULL" as the operator doesn't hide the possible note types, the dependent code fails (this works with Node: Nid)
b. Submitting a hybrid Node:Type filter gives me:

warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in includes/database.mysqli.inc on line 323.

This happens because $this->value now has an additional level, so I have $this->value[0] and inside it another array with all the node types (not just the ones I selected, which is also wrong).
So, the code counts the elements of $this->value, and fails.

3. During filter edit; removing an item from the group, or rearranging items, or adding new items has no effect, I save the form but everything stays the same. Changing the items themselves (item name or value) works.
Also, reordering doesn't just fail when editing, it fails when adding the group for the first time too.

Based on these three points, setting status to "needs work".

Additional notes:

    $form['group_info']['group_items'][$item_id] = array(
        'title' => array(
          '#type' => 'textfield',
          '#size' => 20,
          '#default_value' => $this->options['group_info']['group_items'][$item_id]['title'],
        ),
        'operator' => $row['operator'],
        'value' => $row['value'],
        'removed' => array(
          '#type' => 'checkbox',
          '#id' => 'views-removed-' . $item_id,
          '#attributes' => array('class' => 'views-remove-checkbox'),
          '#default_value' => 0,
        ),
        'weight' => array(
          '#type' => 'weight',
          '#delta' => 10,
          '#default_value' => $this->options['group_info']['group_items'][$item_id]['weight'],
          '#attributes' => array('class' => 'weight'),
        ),
      );

I think that it's more in Views style to declare each one of these (title, operator, value, removed, weight) separately, instead of doing it inside the same array declaration. Doesn't matter much though.

j0e’s picture

This is a cool idea & I wish it worked but I'm getting the same problems as bojanz mentioned with regards to using it on a content filter for a cck field. warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in includes/database.mysqli.inc on line 323. Also, I wish there were some solution that would enable a between ____ to ____ exposed filter for allowed values with two select lists. that's pretty standard for ui, so it may be already out there for views exposed filters for allowed values lists that enable multiples, but i have yet to chance upon it in any of the issues i've read. It is more intuitive than holding ctrl, shift for pc or command for mac.

SuperXren’s picture

FileSize
24.64 KB

Hi guys.

Happy new year!.

Why after installed view 3 dev i can`t see "build group" button after clicked "expose" button ????
I saw http://vimeo.com/14533078 video - but it doesn`t help.

What`s wrong?
In attachment screenshort of my screen after clicked on "expose" button.

Thanks in advance.

dawehner’s picture

Did you applied the patch?

SuperXren’s picture

Why i should do this ?? i get the latest (today) dev version. Do i need to do this?

dawehner’s picture

You need this for this feature

SuperXren’s picture

FileSize
33.7 KB

guys, sorry for disturb, but when i apply patch (731662.patch) to 6.20 view i could not see combo box with my filters.

See attachment.

Thanks for help.

dawehner’s picture

#51
Can you please export your view?

SuperXren’s picture

FileSize
4.76 KB

Yes, sure. Sorry for my stupid question, i`m new in patching drupal.

You can see export of the view attachment. If you have any question - fill free to ask.

Thanks.

Teezi’s picture

Glorious solution! Thanks a whole bunch to all the developers!

Teezi’s picture

Is there any means to prevent the filter being printed in the form submit button's div?

Pasko’s picture

Hi, I'm quite new to Drupal. I tried to install the patch with both Netbeans and Eclipse, but it doesn't work for me, I can't see the group filter (Eclipse doesn't find a match with one of the files, Netbeans says he applied the patch partially - I think there is a problem with some of the files). I applied the patch to 6.x-3.xdev. Someone can help me? Thanks in advance.

j0e’s picture

perhaps the dev version of views was updated since this patch came out, and the patch would need to be updated to match. that's what it sounds like at least.

dawehner’s picture

The patch still applies clean here.

BWPanda’s picture

I just tried to apply the patch from #45 to the latest dev version of Views 3 and got the following:

patching file css/views-admin.css
patching file handlers/views_handler_filter.inc
Hunk #1 succeeded at 25 (offset 10 lines).
Hunk #2 succeeded at 37 (offset 10 lines).
Hunk #3 succeeded at 74 (offset 12 lines).
Hunk #4 succeeded at 102 (offset 12 lines).
Hunk #5 succeeded at 118 with fuzz 1 (offset 13 lines).
Hunk #6 succeeded at 128 (offset 13 lines).
Hunk #7 FAILED at 155.
Hunk #8 succeeded at 221 (offset 30 lines).
Hunk #9 succeeded at 270 (offset 30 lines).
Hunk #10 succeeded at 468 (offset 59 lines).
Hunk #11 succeeded at 521 (offset 59 lines).
Hunk #12 succeeded at 711 (offset 59 lines).
Hunk #13 succeeded at 769 (offset 59 lines).
Hunk #14 succeeded at 791 (offset 59 lines).
Hunk #15 succeeded at 809 (offset 59 lines).
Hunk #16 succeeded at 839 (offset 59 lines).
1 out of 16 hunks FAILED -- saving rejects to file handlers/views_handler_filter.inc.rej
patching file includes/admin.inc
Hunk #2 succeeded at 3420 (offset 46 lines).
patching file views_ui.module
Hunk #1 succeeded at 240 (offset 8 lines).
BWPanda’s picture

Status: Needs work » Needs review
FileSize
20.43 KB

Here's an updated patch of the changes from #45. I've tested and it works on my site.

dagmar’s picture

Just as reminder. Like #1052312: Pluggable Breadcrumbs we have to find a solution to integrate the translation plugin with the multiple items defined per hybrid filter.

BWPanda’s picture

Hmm, this patch doesn't seem to work with date fields... They just default to Jan 1st of this year.

AND (DATE_FORMAT(STR_TO_DATE(node_data_field_invoice_paid.field_invoice_paid_value, '%Y-%m-%dT%T'), '%Y-%m-%d') >= '2011-01-01' AND DATE_FORMAT(STR_TO_DATE(node_data_field_invoice_paid.field_invoice_paid_value, '%Y-%m-%dT%T'), '%Y-%m-%d') <= '2011-01-01')
dawehner’s picture

So in general the date module filter handler has to be changed, too. If you create a new version of a module it's not always impossible to not create some kind of api changes/additions.

BWPanda’s picture

Status: Needs review » Needs work
FileSize
50.67 KB

Another thing I've noticed, the exposed group filter is being added into the exposed form just before the Submit button HTML...

See screenshot:
1 - Is where the exposed filter should be output,
2 - Is where it is incorrectly output

Shadlington’s picture

Subscribing

Shadlington’s picture

I LOVE this patch... It works great.
Can't wait for it to get committed.

jmolinas’s picture

patch wont work on views 6.3.x-dev got the following:

patching file views-admin.css
Hunk #1 FAILED at 305.
Hunk #2 FAILED at 705.
2 out of 2 hunks FAILED -- saving rejects to file views-admin.css.rej
patching file views_handler_filter.inc
Hunk #1 FAILED at 15.
Hunk #2 FAILED at 26.
Hunk #3 FAILED at 60.
Hunk #4 FAILED at 77.
Hunk #5 FAILED at 85.
Hunk #6 FAILED at 92.
Hunk #7 FAILED at 116.
Hunk #8 FAILED at 164.
Hunk #9 FAILED at 174.
Hunk #10 FAILED at 308.
Hunk #11 FAILED at 349.
Hunk #12 FAILED at 413.
Hunk #13 FAILED at 459.
Hunk #14 FAILED at 481.
Hunk #15 FAILED at 495.
Hunk #16 FAILED at 521.
16 out of 16 hunks FAILED -- saving rejects to file views_handler_filter.inc.rej
Shadlington’s picture

#67: I patched #60 against a fresh 6.x-3.x-dev yesterday and it worked fine...

dawehner’s picture

This might not apply against 7.x-3.x

So take sure that you test it with drupal6.

klonos’s picture

...amazing feature! Just put it into good use ;) Thanx people!

Shadlington’s picture

In light of http://drupal.org/node/646284#comment-4381712 this may have to be reworked as a separate module.

jvdurme’s picture

What an amazing feature here. Just what I was looking for. Thanks a lot.

It however, does not seem to be compatible with sortable columns. When I select e.g. a custom "greater than" operator from the select list and filter, it works. But when I click then on a column header to sort that particular column, one of the filters jumps to "Any" and the message displayed is:

An illegal choice has been detected. Please contact the site administrator.

Otherwise, great tool!

EDIT: here is the fix for this! #1188828: Exposed filters mess up click sortable columns

jvdurme’s picture

Any chance this will become a separate module?
The patch works pretty fine, but upgrading views with security updates will become a hassle like this.

bojanz’s picture

If someone wants to work on it, then yes.
Right now the chances of it being committed to Views itself are slim.

jvdurme’s picture

Then I subscribe for the module ;-) Thx for the reply!

Countzero’s picture

Does it really work in 6.x-3.x - users seem to obtain random results ?

If so what should be done to bring this into 7.x-3.x ? Is there a project started to provide it as a separate module ?

I tried to transform an interval filter (on integer values) into a select element with hook_form_alter, but I end up with the "Illegal choice detected" message each time, whatever I try in the submit function. Any hint on how to get rid of it (and the underlying problem, of course) would be welcome invaluable.

dawehner’s picture

Users seems to post random comments,

@countzero
This would be really hard to implement as seperate module, but feel free to waste development time.
As long this is not done in 6.x-3.x it will not land in 7.x-3.x either. Did you already tested it on 6.x-3.x, hopefully yet.
Your personal support issue is ignored on this issue.

Countzero’s picture

As I don't have the Views API knowledge level to help on the original issue, I was just suggesting another approach via form altering, but I understand this doesn't seem a good idea.

So as of now, one has to write a custom filter handler to achieve an interval based dropdown exposed filter. Right ?

dawehner’s picture

Yes you should write a custom handler.

tiw’s picture

Subscribing.

Countzero’s picture

Just in case anyone is interested with an example of an interval filter handler for 7.x, mine is mainly functional : http://drupal.org/node/1239866. You may ask questions in this issue if the maintainers agree, and I'll try to help. Maybe I'll write a doc page if there is demand and I manage to find the time.

achton’s picture

Subscribe.

jvdurme’s picture

Hi there,

when this patch is applied, when I render the exposed form, it seems that the grouped items are squeezed inside the submit button div, like this (I omitted some html code for clarity):

...
<div class="views-exposed-widget views-submit-button">
   <div  class="form-item form-item-labeled" id="edit-group-DIF-TANGO-wrapper">
    <label  for="edit-group-DIF-TANGO">dTANGO: </label>
    <select name="group_DIF_TANGO" class="form-select" id="edit-group-DIF-TANGO" ><option ...</div>

    <div  class="form-item form-item-labeled" id="edit-group-DIF-WALTZ-wrapper">
    <label  for="edit-group-DIF-WALTZ">dWALTZ: </label>
    <select name="group_DIF_WALTZ" class="form-select" id="edit-group-DIF-WALTZ" ><option ... </div>
<input type="submit" id="edit-submit-sequences" value="Filter results"  class="form-submit" />
    </div>
      </div>
</div>
...

I believe this is resulting in some issues with form elements weights/order that can't be adjusted even in views-exposed-form.tpl.php.

Also noticed that when I omit the $button variable from views-exposed-form.tpl.php, the Hybrid Filters also dissappear. So somehow the hybrid filters are displayed together with the submit button?

Does anyone know how I can fix this?

Thanks!

chinita7’s picture

Subscribe

jvdurme’s picture

Just to confirm that the patch in #60 works flawless in Views 6.x-3.x-dev. Had to patch manually (copy/paste) due to some Views updates, but the hybrid exposed filters work.
As this works, can it be implemented in Views 6.x-3.x-dev?
What else has to be done in order to implement it? Can I help?

dawehner’s picture

Issue tags: -alpha-4 blocker

Oh that's good to hear. If you want to help here, please test it with the different kind of filters and see whether it works as expected.

jvdurme’s picture

Then that's what I will do then. :)
Gimme a couple of days to testdrive this and I'll get back here.

chinita7’s picture

I just tried the patch #60 on 6.x-3.0-rc1 and it works like a charm.
I was struggling to achieve this feature for weeks for my age filter which is computed cck field. I hope it will be implemented in the 6.3 version.
Thanks a lot !

jvdurme’s picture

So I've tested it a bit and the issues raised by previous posters, remain:

  • Cannot delete item from group
  • Rearranging group items does not stick on 'Update'
  • Node:Type does not work
    The error message I get is:
    warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /var/www/devel/includes/database.mysqli.inc on line 329.
    And the mysql code executed is:
    SELECT node.nid AS nid,
    node.title AS node_title,
    node.changed AS node_changed
     FROM node node 
     WHERE node.type in ('')
    
  • Node:Updated date does not work, it just shows everything all the time

Node:Id works
Node:Title works
Numeric filter works
String filter works

So I guess there's still a bit of work. If someone is willing to fix this. I'm not experienced enough to do this.

Becker-and-Becker’s picture

Hello,

I tried this patch on 6.x-3.0-rc3 and there seems to be an issue on the views_handler_filter.inc part. Everything else seems to patch fine according to netbeans. Is it possible to get a patch for the lates rc3 version of views 3. Thanks.

jvdurme’s picture

The patch will probably start failing upon newer rc and dev versions because of too many changes. Just do as I did, and manually copy paste the new lines from the patch into the correct location in the files to be patched. All file and line number info is in the patch. It's a bit more work, but it works.

dagmar’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Assigned: Unassigned » dagmar
Status: Needs work » Needs review
FileSize
32.85 KB

My last patch of 2011 :)

I have been working in this patch during all this week, after reading several comments and because Drupal 7 is out and established, I have decided to port this patch to Views 7.x-3.x and when it be ready back port it to Drupal 6.

Here are some good news:

First, this patch is ready for testing, I did some tests and seems to be working fine.
Second, I found a way to solve the problem @dereine wrote in #63. This means, we don't need anymore port contrib modules to get this stuff working.
Third, I spent a lot of time documenting how this patch works, I know, it its a lot of code and I tried to make this easy to understand for other developers. However, my english is not perfect would be nice to have a review from people that really knows speak english.
Also, I have solved some issues with the templates, In the D6 version, some empty fields were rendered in the form, now the group filter replaces in a fashion way the exposed filter.

There are a few items missing yet.

First we have the translation problem, due groups are saved in a nested array translations plugin is not able to "see" the strings that have to be translated, I didn't spent time trying to port the translation plugin that I wrote for pluggable breadcrumbs, but if someone found and elegant solution (and with less lines of code) would be really nice to have. If not, we could provide a drupal_alter to translate groups, anyway is not too hard to do.

Also, we need some tests, specially with some weird filters (I'm sure a lot of testers can find ways to break this new feature, so please do it)

To people that wants to test this patch, just download views using the git instructions

git clone --branch 7.x-3.x http://git.drupal.org/project/views.git
cd views

Download the patch and apply with

patch -p1 < views-7.x.731662.92.patch

And Please! please! don't put +1 for this, we know this feature is pretty cool, but use the new green "Follow" button at the top of the page.

Happy new year for all.

dawehner’s picture

Status: Needs review » Needs work
+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // A group is a combination of a filter, an operator an a value

...and a value

+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // Operating like a single filter.

operating small, so it's clear that this is the current sentence

+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // User can choose from a select box which group want to apply

which group they want to apply. Views will filter the ... to the defined value.

+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // Because it acts as a standar filter, we have to define

*standard

+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // This settings are saved in other array to allow users to switch

in another ... between ... and a group

+++ b/includes/admin.incundefined
@@ -3496,6 +3497,72 @@ function theme_views_ui_expose_filter_form($variables) {
+      'remove' => drupal_render($form['group_items'][$group_id]['remove']) . l('<span>' . t('Remove') . '</span>', 'javascript:void()', array('attributes' => array('id' => 'views-remove-link-' . $group_id, 'class' => array('views-hidden', 'views-button-remove', 'views-groups-remove-link', 'views-remove-link'), 'alt' => t('Remove this item'), 'title' => t('Remove this item')), 'html' => true)),

Didn't we got rid of that in d7, maybe you should change it according to the other parts

+++ b/handlers/views_handler_filter.incundefined
@@ -86,6 +87,26 @@ class views_handler_filter extends views_handler {
+    // A group is a combination of a filter, an operator an a value

... and a value

klonos’s picture

The patch worked fine for me too. Thanx for your hard work and all the time spent on it Mariano ;)

I'd like to express a couple of ideas I had on improving the hybrid exposed filters (let me know if you think this is off topic and I'll start a new issue):

How about supporting letter ranges as well besides numbers? For example, one might want to split an alphabetically sorted list of names/states/whatever so that they are presented in sets like so:

a-g (lower than or equal to g/G)
h-k (between h/H and k/K)
l-p ...
q-v ...
w-z (greater than or equal to w/W)

The check (query) should be performed on the first letter(s) of the field in question. Things that come to mind as something we'll eventually have to address are capitalization (case sensitivity), i18n and the need to be able to split sets based on more than only the first letter.

- Capitalization could be taken care of by either providing a "case sensitive" checkbox or by allowing values to be entered like so:

aA-gG
hH-kK
...

or the opposite (Aa-Gg, Hh-Kk ...), or even with some kind of "wildcard" like a*-g*, ...

- i18n would definitely be a tricky one. Should we define different sets of filters per language? I honestly don't know.

- Lastly, one might need to split a certain starting letter into two or more sets (if their db has a lot of entries starting with that specific letter):

aa-am
an-az
...

That's why in my suggestion I state that the query should be against first letter(s) of the field entry.

Another idea I had is to make the filters "smart". Instead of simply providing the option for the user to define specific filter sets, how about we also allow them to simply define the number of sets they want the drop-down to have and let the sets be automagically/dynamically calculated. These calculations would be:

- count the total of records
- divide the total by the number of desired value sets defined by the user
- split the records in sets based on the previous calculation
- dynamically populate the drop-down with these values

Do you think these improvements would be useful enough that they worth to spend time and effort on? Let me clearly state that I think that by no means should we postpone this feature request here on account of any of my ideas.

dagmar’s picture

Status: Needs work » Needs review
FileSize
35.23 KB

First to all, @klonos, it seems topic for a new issue.

Ok. Strings fixed. But I added some advanced help, so please take a look again.

The main change in this patch is the validation function. I modified it because it is not enough check !empty() for values that are arrays.

Also I did more tests and can confirm that this works properly with HAVING statments, (this came from the old #39 comment)

Didn't we got rid of that in d7, maybe you should change it according to the other parts

I just copied from another piece of code of admin.inc arround the line 3555, so I'm not sure if this can be done in a more Drupal 7 way.

Well, I'm quite conformable with this patch. Please do your own tests and provide feedback.

Marc-Antoine’s picture

First of, this thread is officially declared epic, be proud of yourselves ppl!

@dagmar

Sounds great so far, but it really needs some layout explanation (all I could see was some text inputs, I had to guess how to work things out)

Also, it looks like the 'null' label is gone from the radio widget type, leaving only the radio button on top of my list.

Tested using an integer field, and it runs smoothly.

dagmar’s picture

FileSize
35.4 KB
65.58 KB
75.37 KB
85.53 KB
73.8 KB
80.43 KB

@Marc-Antoine thanks for you comment.

I'm not really sure what do you mean with "layout explanation", maybe a better description of how to configure the hybrid filters?

I cannot replicate the 'null' stuff for radios, probably is a bug but I need a step by step explanation to replicate the problem.

I'm attaching a set of images that illustrates how to use this patch. In my opinion the new "Build group" is not enough visible and probably advanced users of views will not see the new feature due it is hidden all behind a simple checkbox.

I have also rerolled the patch since it didn't apply cleanly anymore.

imclean’s picture

This is a great feature and the patch in #95 works well for me. Thanks for all the work!

I can imagine there could be a few of these, but I have a particular use case which isn't quite working as expected. Using the values from a grouped filter I'm trying to populate the equivalent non-exposed filters of a different view using the session variables Views uses.

e.g. Minimum Price field using a select list

Title: 100
Operator: greater than or equal to
Value: 100

Title: 200
Operator: greater than or equal to
Value: 200

The value of the select option isn't actually the value specified, it's an internal value which I suspect is auto-incremented for the field (1,2,3 etc.). It's this value which Views stores in the session variable when "remember" is set. Presumably this is by design, but could there be an option to use the value specified in the config instead?

dagmar’s picture

@imclean: I'm not sure if what you are saying is that you found a bug, or something that you suspects that doesn't works as you probably expects.

The 1, 2, 3 that hybrid filters save in sessions is required because there is not a easy way to save something like:

Title: Starts With A. 
Operator: Starts with
Value: A

Views uses an 1 to represents the 3 things (title, operator and value) and this is what is saved into sessions. But when the 1 is loaded from SESSIONS it is converted again to the original set of operator|value.

Maybe a solution for your use case is use a hook, like hook_views_pre_execute, to load the values of the session and set the values for your non exposed filter.

Another solution could be make hybrid filters non exposed filters too, but I don't see a good reason to do this beyond the possibility to reduce a set of operator|value into a single number.

imclean’s picture

@dagmar, yes I suspected that would be the case. Non-exposed hybrid filters wouldn't solve my problem as the indexing would need to be the same. This can't be guaranteed as options can be added and removed.

Maybe a solution for your use case is use a hook, like hook_views_pre_execute, to load the values of the session and set the values for your non exposed filter.

Good suggestion, thanks, I'll give this a go.

punges24’s picture

Does anyone have the hybrid-filters patch already patched into views that I can download? I tried to patch it myself but it did not work for some reason.

Thanks

tim.plunkett’s picture

Status: Needs review » Needs work
+++ b/handlers/views_handler_filter.incundefined
@@ -104,6 +105,26 @@ class views_handler_filter extends views_handler {
+    $options['is_grouped'] = array('default' => FALSE);

All defaults that are booleans should be:

array(
  'default' => FALSE,
  'bool' => TRUE,
);

This makes sure it exports correctly.

+++ b/handlers/views_handler_filter.incundefined
@@ -104,6 +105,26 @@ class views_handler_filter extends views_handler {
+        'optional' => array('default' => TRUE),

See above.

+++ b/handlers/views_handler_filter.incundefined
@@ -120,6 +141,14 @@ class views_handler_filter extends views_handler {
+  function can_build_group() { return $this->is_exposed() && (count($this->operator_options()) > 0); }
+
+  function is_a_group() { return !empty($this->options['is_grouped']); }

Split these onto multiple lines.

+++ b/handlers/views_handler_filter.incundefined
@@ -248,6 +302,94 @@ class views_handler_filter extends views_handler {
+  function show_expose_form(&$form, &$form_state) {

Maybe renamed this to show_exposed_form?

+++ b/handlers/views_handler_filter.incundefined
@@ -248,6 +302,94 @@ class views_handler_filter extends views_handler {
+      '#prefix' => '<div class="views-expose clearfix">',
+      '#suffix' => '</div>',

Why not use container with attributes instead?

+++ b/handlers/views_handler_filter.incundefined
@@ -405,6 +547,55 @@ class views_handler_filter extends views_handler {
+        // Check if the title is defined but value wasn't defined

Missing a full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -405,6 +547,55 @@ class views_handler_filter extends views_handler {
+        // Check if the value is defined but title wasn't defined

Missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -405,6 +547,55 @@ class views_handler_filter extends views_handler {
+  function build_group_submit($form, &$form_state) {

Needs a doc block

+++ b/handlers/views_handler_filter.incundefined
@@ -405,6 +547,55 @@ class views_handler_filter extends views_handler {
+    $new_id = 1;

This is because of the new reserved group 0 for contextual filters? Perhaps there should be a constant for this instead of hardcoding 1 throughout views.

+++ b/handlers/views_handler_filter.incundefined
@@ -405,6 +547,55 @@ class views_handler_filter extends views_handler {
+        // Don't store this

Missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -420,6 +611,50 @@ class views_handler_filter extends views_handler {
+        'label' => '',
+        'identifier' => $this->options['id'],
+        'optional' => TRUE,
+        'widget' => 'select',
+        'remember' => FALSE,
+        'default_group' => 'All',
+        'group_items' => array(),

Shouldn't these still be arrays with 'default' as a key? And 'bool' => TRUE like above if the default is a boolean.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+    // Provide 3 options to start when we are in a new group

Missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+    // After the general settings, comes a table with all the existent groups

Missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+      // In each row, we have to display the operator form and the value form
+      // $row acts as a fake form to render each widget in a row

"value form $row" should be "value from $row", also missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+      // Fix the dependencies to update value forms when operators changes.
+      // This is needed because forms are inside a new form and their ids changes
+      // Dependencies are used when operator changes from to 'Between', 'Not Between', etc
+      // And two or more widgets are displayed

The sentences don't all need a line break, wrap it as a paragraph at 80 chars and end with a full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+      $without_childrens = TRUE;

Could just be $without_children, children is already plural.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+      // Per item group we have a title that identifies it

Comma after 'group', full stop at the end.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+    // From all groups, let chose which is the default

Missing full stop.

+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +706,187 @@ class views_handler_filter extends views_handler {
+    if (!empty($form_state['js settings']) && is_array($js)) {
+      $form_state['js settings'] = array_merge($form_state['js settings'], $js);
+    }
+    else {
+      $form_state['js settings'] = $js;

Could likely be a ternary, not important though.

+++ b/handlers/views_handler_filter.incundefined
@@ -529,6 +952,69 @@ class views_handler_filter extends views_handler {
+    // Here is where the conversion from grouped filters into standard
+    // filters ones occurs.

This should probably be rewritten as the docblock

+++ b/handlers/views_handler_filter.incundefined
@@ -529,6 +952,69 @@ class views_handler_filter extends views_handler {
+  function store_group_input($input, $status) {

Needs a doc block

+++ b/handlers/views_handler_filter.incundefined
@@ -529,6 +952,69 @@ class views_handler_filter extends views_handler {
+    if ($status === FALSE && isset($_SESSION['views'][$this->view->name][$display_id])) {
+      $session = &$_SESSION['views'][$this->view->name][$display_id];
+
+      if (isset($session[$this->options['group_info']['identifier']])) {
+        unset($session[$this->options['group_info']['identifier']]);
+      }
+    }
+
+    if ($status !== FALSE) {
+      if (!isset($_SESSION['views'][$this->view->name][$display_id])) {
+        $_SESSION['views'][$this->view->name][$display_id] = array();
+      }
+
+      $session = &$_SESSION['views'][$this->view->name][$display_id];
+
+      $session[$this->options['group_info']['identifier']] = $input[$this->options['group_info']['identifier']];

The duplicated checks for the $_SESSION variable, and the assignment by reference, are confusing. Could probably check once at the top and it would make the logic more obvious?

+++ b/includes/admin.incundefined
@@ -3508,6 +3509,72 @@ function theme_views_ui_expose_filter_form($variables) {
+      'remove' => drupal_render($form['group_items'][$group_id]['remove']) . l('<span>' . t('Remove') . '</span>', 'javascript:void()', array('attributes' => array('id' => 'views-remove-link-' . $group_id, 'class' => array('views-hidden', 'views-button-remove', 'views-groups-remove-link', 'views-remove-link'), 'alt' => t('Remove this item'), 'title' => t('Remove this item')), 'html' => true)),

Maybe build out the attributes into a variable, and do it over multiple lines? Or build out the common parts before the foreach and add to it within?

+++ b/includes/admin.incundefined
@@ -4468,6 +4535,44 @@ function views_ui_config_item_form_expose($form, &$form_state) {
+  // flip
+  $item['is_grouped'] = empty($item['is_grouped']);

Why flip? Needs a better comment

+++ b/includes/admin.incundefined
@@ -4468,6 +4535,44 @@ function views_ui_config_item_form_expose($form, &$form_state) {
+  $item =& $form_state['handler']->options;

Convention is now '$foo = &$bar', but is this even needed? It's a short string and only used twice.

+++ b/includes/handlers.incundefined
@@ -658,6 +658,8 @@ class views_handler extends views_object {
+  function is_a_group() { return FALSE; }

Split into multiple lines

+++ b/js/views-admin.jsundefined
@@ -818,6 +818,17 @@ Drupal.behaviors.viewsRemoveIconClass.attach = function (context, settings) {
+    var $ = jQuery;

Why not move this out a line and then use $ instead of jQuery for the .click?

+++ b/js/views-admin.jsundefined
@@ -818,6 +818,17 @@ Drupal.behaviors.viewsRemoveIconClass.attach = function (context, settings) {
+}

Missing semicolon

+++ b/views.moduleundefined
@@ -1886,7 +1886,18 @@ function views_exposed_form($form, &$form_state) {
+        // When an user choose an option the selected value is splitted

split, not splitted

+++ b/views.moduleundefined
@@ -1886,7 +1886,18 @@ function views_exposed_form($form, &$form_state) {
+        // into the operator and value that the item represents

Missing full stop.

+++ b/views_ui.moduleundefined
@@ -203,6 +203,12 @@ function views_ui_theme() {
+    // Group of filters

Missing full stop.

Marc-Antoine’s picture

FileSize
32.1 KB
55.49 KB
65.86 KB
87 KB
70.74 KB

Looking at your screenshots, I'm really surprised; your interface is way different from mine, so I decided to take some screenshots to help you understand the issues I was talking about.

Sorry for the french interface btw, I hope it doesn't bother you!

I used the current dev (7.x-3.x-dev) of views

EDIT: in the 4th screenshot I mention a possible label bug because there are some radio buttons at the end of my form, but I realized they where there to choose the 'default' state of the filter, so the real problem is only that Drupal doesn't seem to generate it's usual table display.

EDIT2: Also, it would be awesome to have a checkbox widget available, or a Better Exposed Filter compatibility?

dawehner’s picture

For the interface issue just clear the cache so the theme registry can be rebuild.

Marc-Antoine’s picture

You're absolutely right Dereine, I'm obviously still missing some Drupal mechanism knowledge.

And while I've got your attention, I just wanted to thank you for your work on this awesome module (I've seen your posts on most of the issue around here, impressive stuff o.o)

Back on our subject, the radio labels are still empty when I use the radio button widget, (please look at my new screenshots)

and I've noticed a bug when using the Better Exposed Filter module (which enable the checkboxes widget to my normal exposed filters), it says

Notice: Undefined index: filter-field_my_name_value in better_exposed_filters_exposed_form_plugin->exposed_form_alter() (line 467 of sites/all/modules/better_exposed_filters/better_exposed_filters_exposed_form_plugin.inc).

(these are the lines)
466 // Form element is designated by the element ID which is user-configurable
467 $field_id = $form['#info']["filter-$label"]['value'];

Here's the bug I created on their module's issue queue http://drupal.org/node/1431810

I hope this will help initiate a dialogue between developpers, because it would also be a great feature to have hybrid filters using checkboxes widget.

Marc-Antoine’s picture

FileSize
88.94 KB
22.75 KB

forgot about my screenshots, here they are:

This only occurs for the radio widget, but the select widget displays view's default label

I tried creating a new filter,
I tried creating a new view

dagmar’s picture

Status: Needs work » Needs review
FileSize
35.82 KB

@tim.plunkett: Thank you very much for you review. I applied most of your indications, a few things didn't changed. I'm listing the reasons here:

+++ b/handlers/views_handler_filter.incundefined
@@ -420,6 +611,50 @@ class views_handler_filter extends views_handler {
+        'label' => '',
+        'identifier' => $this->options['id'],
+        'optional' => TRUE,
+        'widget' => 'select',
+        'remember' => FALSE,
+        'default_group' => 'All',
+        'group_items' => array(),

Shouldn't these still be arrays with 'default' as a key? And 'bool' => TRUE like above if the default is a boolean.

No. This function is similar to expose_options().

+++ b/handlers/views_handler_filter.incundefined
@@ -248,6 +302,94 @@ class views_handler_filter extends views_handler {
+ function show_expose_form(&$form, &$form_state) {

Maybe renamed this to show_exposed_form?

Mmm, this is an override for the function defined in handlers.inc. I didn't created this function.

+++ b/handlers/views_handler_filter.incundefined
@@ -529,6 +952,69 @@ class views_handler_filter extends views_handler {
+    if ($status === FALSE && isset($_SESSION['views'][$this->view->name][$display_id])) {
+      $session = &$_SESSION['views'][$this->view->name][$display_id];
+
+      if (isset($session[$this->options['group_info']['identifier']])) {
+        unset($session[$this->options['group_info']['identifier']]);
+      }
+    }
+
+    if ($status !== FALSE) {
+      if (!isset($_SESSION['views'][$this->view->name][$display_id])) {
+        $_SESSION['views'][$this->view->name][$display_id] = array();
+      }
+
+      $session = &$_SESSION['views'][$this->view->name][$display_id];
+
+      $session[$this->options['group_info']['identifier']] = $input[$this->options['group_info']['identifier']];

The duplicated checks for the $_SESSION variable, and the assignment by reference, are confusing. Could probably check once at the top and it would make the logic more obvious?

Probably yes, but I didn't found a better way to do this, and it pretty similar to how store_exposed_input() works.

+++ b/includes/admin.incundefined
@@ -3508,6 +3509,72 @@ function theme_views_ui_expose_filter_form($variables) {
+      'remove' => drupal_render($form['group_items'][$group_id]['remove']) . l('<span>' . t('Remove') . '</span>', 'javascript:void()', array('attributes' => array('id' => 'views-remove-link-' . $group_id, 'class' => array('views-hidden', 'views-button-remove', 'views-groups-remove-link', 'views-remove-link'), 'alt' => t('Remove this item'), 'title' => t('Remove this item')), 'html' => true)),

Maybe build out the attributes into a variable, and do it over multiple lines? Or build out the common parts before the foreach and add to it within?

I just follow the same convention that used in theme_views_ui_rearrange_filter_form().

@Marc-Antoine: Sadly I cannot replicate the problem with the radios.

Attached the patch with almost all the modifications suggested in #102.

tim.plunkett’s picture

Status: Needs review » Needs work
+++ b/handlers/views_handler_filter.incundefined
@@ -471,6 +712,188 @@ class views_handler_filter extends views_handler {
+      // In each row, we have to display the operator from and the value form

The 'from' and 'form' should be switched.

Also, something weird is happening that I'm not sure is related to this patch.

If the views_exposed_filter_any_label variable is set to '', and the exposed type is set to radio and not select, theme_form_element_label runs filter_xss_admin and strips it out. I don't have time to see if that happens elsewhere in Views right now, but I thought I'd point it out.

Otherwise, it works wonderfully.

dagmar’s picture

Status: Needs work » Needs review
FileSize
36.83 KB

Well, guess what...? a new patch xD

Ok, the changes are this:

  • Changed the "The 'from' and 'form' should be switched." Thanks again @tim.plunkett.
  • @Marc-Antoine: I figure out your problem, tim.plunkett said that he was having troubles with the <Any> label. I fixed this too for hybrid filters, but like tim said in #108, I'm not sure if this is also affecting to another exposed filters that uses radios.
  • A new validation function was added for date filters. I think is properly documented the reason of this function.
  • I have removed the whole show_expose_form() it was exactly the same that the defined in handlers.inc, I think is old code that I didn't removed at time.
  • Also, there was a bug with the build_group_options() function. The 'contains' => array() is not necessary and don't updates the default values as expected. You can see how this is working now because the label of the widget not anymore in black when a new group is created

Ok, In my opinion, this is ready to go. I did a lot of tests, and all seems to be working fine, there is however a small change to the UI that could be done, by default the - Any - option is never selected, you have to click on it, and I defined the #default_value to 'All'. I'm really don't know what is going on here. But this is trivial and not a big deal.

I would like to see this in before March 3, 2012 (This feature is getting old, almost two years...) :-)

dgastudio’s picture

FileSize
100.84 KB

Error message
The value is required if title for this item is defined.

dagmar’s picture

@kervi thanks for the feedback.

Seeing your snapshot I think you didn't cleared the cache after applying the patch. Can you confirm that this behavior is present after clear the cache?

If this issue is still valid, please give a bit more of information about what kind of filter is causing this problem.

dgastudio’s picture

sorry, after clear cache everything seems working fine. thank u!

imclean’s picture

Better Exposed Filters support: #1431810: Better exposed filter displays an error when used with hybrid exposed filters

Edit: missed the link in #105. New patch anyway.

dagmar’s picture

+++ b/handlers/views_handler_filter.inc
@@ -420,6 +594,49 @@ class views_handler_filter extends views_handler {
+      $any_label = variable_get('views_exposed_filter_any_label', 'old_any') == 'old_any' ? $old_any : t('- Any -');

'old_any') was replaced by 'new_any')

+++ b/handlers/views_handler_filter.inc
@@ -405,6 +528,57 @@ class views_handler_filter extends views_handler {
+        if ($form_state['values']['options']['group_info']['default_group'] == $id) {

Operator replaced by ===. I found a bug here, now the first time the form is rendered and user selects '- Any -' this setting is remembered.

So, this is almost a re-roll, with a couple of fixes.

tim.plunkett’s picture

Status: Needs review » Needs work

I'm only noticing one real problem:

I click to add a filter, and check the box for both a field to make a hybrid group, as well as content type. In alphabetical order, the field config comes up first, and I check the box to make it a grouped filter. When I finish configuring, I'm NOT taken to the config for content type, and hitting save will throw an error.

Not clicking the group checkbox, it works normally. Maybe something crazy with the $form_state?

Also, minor nitpick for the reroll:

+++ b/includes/admin.incundefined
@@ -3516,6 +3517,73 @@ function theme_views_ui_expose_filter_form($variables) {
+      'data' => t('- Any -'),

This should be 'data' => variable_get('views_exposed_filter_any_label', 'new_any') == 'old_any' ? t('&lt;Any&gt;') : t('- Any -'), for consistency.

dagmar’s picture

@tim.plunkett thanks for the review.

I can replicate the problem. However I can replicate the problem in the current version of views 7.x. Just try to expose a filter and you will have the same problem. Then I think this is not a bug produced by this patch.

So the question is, Do I have to find a solution for this problem in this patch, or is a different issue?

tim.plunkett’s picture

You are 100% right, that's a pre-existing bug.

I've opened #1461904: Exposing a filter prevents subsequent filters from being configured to address that, if you reroll with the last tweak, I think it's ready to go!

dawehner’s picture

Status: Needs work » Needs review
FileSize
37.29 KB
36.13 KB

I just tryed to input 0 into the fields, but the required didn't allowed me to do that, see screenshot.
The change fixes it.

I corrected the small thing in #115

All my manual testing worked fine!

tim.plunkett’s picture

Status: Needs review » Needs work

I think there is a further problem on top of #1461904: Exposing a filter prevents subsequent filters from being configured, even though that fixed other bugs.

After picking out two filters, and clicking configure:

The first filter submit shows "Apply and continue": https://skitch.com/plnktt/8gy2b/exposed-hybrid-content-d7
After exposing it, it still says that: https://skitch.com/plnktt/8gy2c/exposed-hybrid-content-d7

Finally, when clicking "Build a group of filters", it switches to "Apply", and no longer goes to the second filter. Also, the first two show "1 of 2" in the top right, and this says "2 of 2": https://skitch.com/plnktt/8gy4r/exposed-hybrid-content-d7

So whatever magic with $view->stack was fixed in the other issue, this needs it too.

dawehner’s picture

Status: Needs work » Needs review
FileSize
37.45 KB

Applied the technique from the other patch to this patch. It worked for me fine.

tim.plunkett’s picture

Yep, that last patch works 100%. You mentioned you wanted merlinofchaos to look at this, I'll also have someone from zivtech who hasn't seen this try it out to see if it all makes sense to them.

klonos’s picture

I hate posting worthless comments, but seeing this getting so close to finally being committed makes me so excited! ...it's this issue's 2nd "birthday" in two days :P

tim.plunkett’s picture

Status: Needs review » Needs work

Okay, did some user testing with one of our themers, here's the feedback:

Instead of a checkbox "Build a group of filters", have two radio buttons:
"Single filter"
"Multiple filters"

"Single filter" being the current exposed filter, "Multiple filters" (or something similar) triggering the hybrid/grouping stuff like the checkbox does now.

In the table of settings, "Title" should be required, and renamed "Label".

In the default column, "Any" should be the default default.

tim.plunkett’s picture

FileSize
37.2 KB
2.33 KB

Okay, this addresses the default bug and changes the label. The required label is actually a bad idea, I think.

I also cleaned up some of the JS. I didn't yet switch to a radio button since there is Drupal.viewsUi.Checkboxifier but nothing for radios yet.

klonos’s picture

Status: Needs work » Needs review

...so, should we leave the switch from the checkbox to the radio button to a separate, followup issue? Please consider this because this feature really doesn't deserve to wait even more on this trivial UX thing.

dagmar’s picture

Status: Needs review » Needs work

I'm going to try to implement the radios on this weekend. We waited two years, we can wait a few more days.

tim.plunkett’s picture

FileSize
38.55 KB
4.09 KB

Alright, well I was really impatient so I went ahead and did it.

Discussed with a couple more people, I think the string changes make a lot of sense.

Attached is the whole patch as well as changes since #124.

tim.plunkett’s picture

Status: Needs work » Needs review
dagmar’s picture

Happy birthday issue!

Well, I think chx was right when he said that best ideas came up in the shower. I'm happy to announce a new feature in this patch, now is possible to use checkboxes for the widget, this means, yes I'm not kidding!, that you can apply different filters at the same time.

So this is how this works, by default, views manages multiple items at handler level. But doing some changes in th views::_build() function I found a way to submit several times the info of a exposed filter. Pretty simple, and seems to be working fine.

There area some problems with, how the view has to be configured to make this stuff work fine. For example, probably hybrid filters with checkboxes may go inside their own filter group and set the operator to OR in order to get mutually exclusive filters working together.

Also this addition needs a string review from, ejem, @tim.plunkett :P but I think this is a small change but powerful uses.

Oh, and probably find better way to define the 'default values' when the widget are checkboxes.

Attached the patch and an screenshot to illustrate the new addition.

monil-dupe’s picture

Thanks dagmar for this patch and fixes and features you did.

tim.plunkett’s picture

Status: Needs review » Needs work
+++ b/handlers/views_handler_filter.incundefined
@@ -553,6 +967,98 @@ class views_handler_filter extends views_handler {
+   * choosed in the checkboxes.

'choosed' should be 'chosen', use search and replace because there is more than one.

+++ b/handlers/views_handler_filter.incundefined
@@ -553,6 +967,98 @@ class views_handler_filter extends views_handler {
+      if (!empty($selected_group_id)) {
+        $selected_group = $selected_group_id;
+      }
+      else {
+        $selected_group = $input[$this->options['group_info']['identifier']];

This should be a ternary for clarity, and a line break after it.

+++ b/handlers/views_handler_filter.incundefined
@@ -553,6 +967,98 @@ class views_handler_filter extends views_handler {
+  function group_multiple_exposed_input($input) {
+    if (!empty($input[$this->options['group_info']['identifier']])) {
+      return array_filter($input[$this->options['group_info']['identifier']]);
+    }
+    return array();

I would probably start the function with $options = array();, assign the array_filter to it, and then return $options;

+++ b/includes/view.incundefined
@@ -1040,16 +1040,52 @@ class view extends views_db_object {
+        if ($handlers[$id]->is_a_group() && $handlers[$id]->options['group_info']['widget'] == 'checkboxes') {

This entire set of changes in includes/view.inc looks like it needs to be refactored, there is a lot of duplicated code between these conditionals.

dgastudio’s picture

FileSize
70.74 KB

i have applied the latest patch, but ui is totally not usable (cache cleaned).

1

JurriaanRoelofs’s picture

I'm trying to apply some of these latest patches to both latest stable and latest dev and all of the hunk are failing. Maybe someone can attach a zip with the patch properly applied?
These latest patches are for 7.x right?

dagmar’s picture

Yes, they are for 7.x. And probably you are right, the patch doesn't apply anymore.

I have been a bit busy past month, I will try to create a new patch in next days/weeks.

abtm’s picture

Any progress on this? I am building a property portal. Operators like >= and <= will make it possible for users to define their search criteria, e.g. "min bedroom" and "max bedroom". Thanks.

dagmar’s picture

Status: Needs work » Needs review
FileSize
47.47 KB

Rerolled. Re-Tested. Applied comments from @tim.plunkett in #131.

There is only one "TODO" besides the i18n stuff mentioned in #61.

The only problem I found is that default values for grouped filters with 'multiple items' option checked are not respected. So whatever you choose as default value in the checkboxes it is not applied.

If anybody can take care about this, I don't have more ideas to fix it. Or we can just remove the entire 'multiple items' feature and dealt with it in other issue.

dagmar’s picture

FileSize
48.04 KB

I figured out how to make the multiple items work. Also remove items was not working properly, this is fixed too.

Well, it seems to be working fine. Besides the i18n problem, I don't see nothing else to fix.

Please provide your feedback.

abtm’s picture

Thanks for the patch dagmar. It solved a big problem of mine. It's working well apart from three drawbacks:

1. In the Grouped filters, value "0" can not be saved. My first option's label is "Studio" and its value is "0". Every time I go back after saving the settings, the value "0" is gone, and if I select "Studio" in the form to filter the result, an error occurs.

2. There isn't a way to customize the default label value "- Any -". So I won't be able to set it to "No min", "No max" etc.

3. If the minimum value is greater than the maximum value, the form is still valid but no result is found. (I thought I would be able to use rules to throw a error msg but there doesn't seem to be a way even after installing "Rules Forms Support" module.

dgastudio’s picture

one more "bug".

after switch to "Grouped filters " there is no way to change exposed filter label.

dagmar’s picture

FileSize
76.96 KB

@abtm: Thanks for your feedback.

I have fixed the item 1, but I think that 2 is task for Better Exposed Filters module or maybe implementing a hook_form_alter. Sorry I know that I could provide this directly from my patch, but you know, It a lot of code to review and I really want to get this in.

Related to 3, well, maybe a follow up after this patch gets in.

@kervi: I cannot replicate your problem. After you enable the exposed group, you can set the Label for the widget using the 'Label' textfield in the UI.

------------

So, This patch is 25Kb bigger than my last patch because it includes tests.

I wrote tests for string, numeric, in_operator and equal handlers. Date and combine filters tests are missing but we can add they as a follow up.

Tests helped me to discover some failures in the patch, that are already fixed in this version of the patch.

Also, I found some problems with the exposed form caching and the testing framework. Therefore a new flag was added in views_exposed_form to allow to disable the caching system when tests are running.

That's all. Daniel, is your turn now.

abtm’s picture

@dagmar: Thanks for making such a long patch! Is it going to be committed or do we have to apply it every time after updating this module? It did take a long time for me to apply it. :)

dagmar’s picture

FileSize
76.02 KB

Re-rolled to reflect changes introduced by #1630136: Allow to clear the cache for exposed forms

dagmar’s picture

Assigned: dagmar » dawehner

Tests passed. Assigned to Daniel to final review.

dawehner’s picture

Added some screenshots used for the summary

dawehner’s picture

Issue summary: View changes

Added a proper summary

dawehner’s picture

Issue summary: View changes

added screenshots

dagmar’s picture

BTW, there is already included in the patch, docs for advanced help.

dagmar’s picture

Issue summary: View changes

added h4s above the screenshot

klonos’s picture

Thanx for the updated patch and screenshots+summary Mariano & Daniel!

...one thing though: I realize that though all of us following this issue got used to the term "hybrid", that's not so self explanatory when used in the UI. Though a lot better than "hybrid filters" I don't think that "grouped filters" does the job either. I think "filter ranges" describes it much better. What do you think?

tim.plunkett’s picture

Assigned: dawehner » tim.plunkett

I'm going to give this a final manual test and review, then it can go in.

yultyyev’s picture

I'm using #142 patch with filter "number rooms" (like in the issue), but I checked "allow multiple selection" (e.g. to filter the flats with 1 and 2 rooms) and I get view's query like this "myfield = 1 AND myfield = 2", so nothing is showing in view's results, the query should be like this "myfield = 1 OR myfield = 2". How can I get that?

dagmar’s picture

You should include the filter in its own group and set the operator of the group to OR (By clicking in the re-arrange option).

This is explained in the documentation of the patch.

dagmar’s picture

I have included some tests for the UI.

The first patch is essentially the patch provided in #142 plus the new tests.
The second patch includes the fixes for the fails that the new tests discovered.

There is not changes in the main functionality.

dawehner’s picture

Version: 7.x-3.x-dev » 8.x-3.x-dev
Status: Needs review » Patch (to be ported)

Let's get it in now, there are so many tests written for that, and many users tested this already.

@dagmar
Thanks for tons of your hours connected with this patch

tim.plunkett’s picture

Hahaha I was JUST testing this! Was about to RTBC :)

dagmar++!

tim.plunkett’s picture

Status: Patch (to be ported) » Needs review
FileSize
81.78 KB

Rerolled, all of the plugins were moved around.

Status: Needs review » Needs work

The last submitted patch, views-731662-153.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
81.75 KB
488 bytes

It was trying to manually include view.inc, which is gone and its replacement is autoloaded.

klonos’s picture

OMG!! Thank you, thank you, thank you. It's been so long that I've been patching my installations with this I can't believe it'll be in the next 7.x dev :D

Jackinloadup’s picture

Thank you dagmar, dawehner, tim.plunkett, bojanz, SuperXren, and BWPanda! Amazing results.

tim.plunkett’s picture

FileSize
81.37 KB

Rerolled for annotations.

Status: Needs review » Needs work

The last submitted patch, views-731662-158.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
82.34 KB

Ah, it needed protected $profile = 'standard';

tim.plunkett’s picture

Status: Needs review » Fixed

I tested this and it works, it was a pretty straightforward port.
So, I committed it: http://drupalcode.org/project/views.git/commit/8311f38

yultyyev’s picture

Some trouble with this part of module (in Views 7.x-3.4)

I make some hybrid filters with checkboxes (rooms: 1, 2, 3, 4+), when I submit exposed form all works fine, but when submit none of checkboxes selected in this filter all works only on first page: in url there are none of arguments of this filter, but pager produce url like this viewspage?rooms[1]=0&rooms[2]=0&rooms[3]=0&rooms[4]=0&myotherargs&page=1 the second page of view's result is empty with error (wrong choise in filter) and checkboxes are selected all. When I remove wrong part of query "rooms[1]=0&rooms[2]=0&rooms[3]=0&rooms[4]=0" from url, the view show normal result page.
---
update: i have create an issue #1750914: "An illegal choice has been detected" error when using hybrid exposed filters.

dawehner’s picture

@yultyyev
Please create a new issue for that. If not it will be incredible hard to be able to follow the issue.

Status: Fixed » Closed (fixed)
Issue tags: -views 3.x roadmap

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

no docs required.