Breaks Exposed Filters in Views 2

I was wondering if it's the way the session variable is being stored?

When BetterSelect isn't enabled:[session] => views|a:1:{s:6:"guides";a:1:{s:6:"page_1";a:1:{s:3:"tid";a:1:{i:164;s:3:"164";}}}}

When BetterSelect is enabled: [session] => views|a:1:{s:6:"guides";a:1:{s:6:"page_1";a:1:{s:3:"tid";a:4:{i:164;i:164;i:0;i:0;i:162;i:0;i:137;i:0;}}}}

Although it does work for me if I only have two options. :)

Can you confirm this is still happening with the latest Drupal 6 -dev release? I can't reproduce. Taxonomy exposed filter works perfectly with better select in my testing.

Hi Mark, Taxonomy Filter does work well, but I found that node type for example doesn't work.

I've got exactly the same problem : with exposed filters, the operators "is all of" and "is none of" just don't work anymore... (returning no results).

I would be reaaaaaally awesome if it worked, this is so practical ! Really good idea.

I am having a similar issue. When using better select with exposed filters the default content that should be displayed on initial page view does show up. The view returns 0 results. After pressing the apply button in the filter all the content is loaded.

When I disable Better Select the view works as it should, displaying all the available unfiltered content on the initial page view.

Great module by the way, thanks for your hard work!

I can confirm this issue too. My setup is with two exposed filters:

* One multi value CCK text field as filter
* And one exposed taxonomy terms filter

I'll try to digg some deeper in to this issue later this evening.

Ok I can confirm the bug exists. I've spent about an hour doing all the proper integration, but it hasn't helped.

I strongly suspect that this issue with supporting Views exposed filters is the same as Wim Leers and merlinofchaos have tackled trying to get Hierarchical Select to work. See the following:

http://drupal.org/node/342991#comment-1410606

If anyone wants to try fix it, I would suggest looking through that code too, but I can't really spend any more time at the moment.

subscribing

Any update on this? This bug has bitten me really hard today (as in, I had the module enabled in production for some time before I realized it was happening).

I may have a chance to look into it today, depending on what my other priorities are. If not, I may just have to disable the module, which is sad, because I love it.

Ok, so I looked at that issue. It looks like the problem there is that people want to actually *use* Hierarchical Select on Views, and the uniqueness of the Views Form API makes that an impossibility.

I actually don't need to use Better Select on Views, either in the Views admin UI or in Exposed Filters. Thus, I would be happy with a solution in which Better Select only operated on the multi-selects in node edit forms. Would that be easier to code? If so, at least that would provide a stopgap for people such as myself who want to use both Views and Better Select, but are OK with not using Better Select *in* Views.

I would agree that breaking views is a pretty big issue, so it would be great if someone does fix it.

@EvanDonovan I may be missing something but isn't there a setting under admin/settings/betterselect to just enable better select for node edit forms? I'm using that on my two sites and it's working fine.

Of course, if I could use it on exposed views filters, the world would be a better place.

@bohemicus: Oh, you are right! Thank you. This is what happens when I don't look at module configuration pages.

This bug should probably be noted in a "Known Issues" section of the README though, since it can be worked around, but there's no easy fix.

Patches welcome. ;)

I have the same problems with the exposed filter in views 2 ... looks great, but still not working ...
(subscribing)

I looked in to this problem yesterday and ended up making some changes to Better Select in order for this to work. I have only tried my changes with Exposed Filters in Views 6.x-2.6 using Taxonomy. The problems occur if you use the "Is all of" or "Is none of" settings.
I searched high and low for someone who had already solved it, but couldn't find anything so I ended up solving it myself.

It's a rather ugly patch, but it works ;)

I only needed to make changes to betterselect.module...
First I added the following directly after the first if-clause in function betterselect_process

// To handle deselection of checkboxes in exposed Views-filters we need this
if ((substr($complete_form['#id'],0,18) == 'views-exposed-form') && isset($element['#value'][0])) {
	$element['#value'] = array();
}

Then I added this to the very beginning of function betterselect_form_alter

// Add this to handle checkboxes in exposed Views-filters
if (substr($form['#id'],0,18) == 'views-exposed-form') {
	$form['#submit'][] = 'betterselect_views_filter_from_checkboxes';
}

Then I added this function:

/**
 * Additional submit handler for the views filter form.
 */
function betterselect_views_filter_from_checkboxes($form, &$form_state) {
  	// Create a new and correct array, if we need to!
  	if (!array_key_exists(0, $form_state['values']['tid'])) {
  		$new_tid = array();
  		foreach ($form_state['values']['tid'] as $val) {
  			if($val != 0) {
  				$new_tid[$val] = $val;
  			}
  		}
  		// This is for the of chance that we actually selected something ;)
  		form_set_value($form['tid'], $new_tid, $form_state);
  		$form_state['values']['tid'] = $new_tid;
  		$form_state[view]->filter[tid]->validated_exposed_input = $new_tid;
  	}
}

In addition to this I added autosubmit using AJAX, but that is not really relevant here, is it?

That should be it! Please let me know if this doesn't work/does work for you as well!

Can you roll this as a patch so I can test? Thanks so much!

I made the changes, but it didn't work for me – maybe i made a mistake? Do you mind attaching your file "betterselect.module" for testing?
Thank you! :-)

@batchman_paradize: Try to make a patch out of your changes. http://drupal.org/patch

I'm out travelling at the moment, will get back to you with a patch and an attachment as soon as I'm back! Hope you can wait that long ;) I might get a chance to fix it tomorrow evening.

Here is my changed file as well as a patch, hope you can get it to work now :) If anyone find that there is something that still doesn't work with Exposed Filters and Better Select please report it here and I will see what I can do about it... I have just tested this with Taxonomy this far.

Due to restrictions on which file-extensions that are allowed you have to remove the ".txt" from the module-filename.

I copied your patched module-file, but it didn't work (for me). Instead it showed me the following errors:

warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /is/htdocs/wp1135829_MDTEF2JOND/www/sites/all/modules/betterselect/betterselect.module on line 222.
warning: Invalid argument supplied for foreach() in /is/htdocs/wp1135829_MDTEF2JOND/www/sites/all/modules/betterselect/betterselect.module on line 223.
warning: array_shift() [function.array-shift]: The argument should be an array in /is/htdocs/wp1135829_MDTEF2JOND/www/includes/form.inc on line 1326.

I'm sorry, but i'm not good enough to "read" the errors ...

I created a new patch that should take care of the above issue, though to make sure it really solves any problems I need to know exactly which settings you were testing in Exposed Filters. This goes for any problems reported, without detailed instructions on how to replicate the problem it will be hard to do anything about it.

Make sure to patch the latest release and not a previously patched file.

I tried your new patch (for beta2) and there are no warnings any more. But unfortunately it still doesn't work ...

I am using the following Views-filter:

$handler->override_option('filters', array(
  'tid_1' => array(
    'operator' => 'and',
    'value' => array(),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'tid_1_op',
      'identifier' => 's',
      'label' => 'Schwerpunkt auswählen',
      'optional' => 0,
      'single' => 0,
      'remember' => 0,
      'reduce' => 0,
    ),
    'type' => 'select',
    'limit' => TRUE,
    'vid' => '3',
    'id' => 'tid_1',
    'table' => 'term_node',
    'field' => 'tid',
    'hierarchy' => 0,
    'override' => array(
      'button' => 'Standard verwenden',
    ),
    'relationship' => 'none',
    'reduce_duplicates' => 1,
  ),
));

Is there anything wrong/special?

You can find the situation "live" (without betterselect) here: http://www.lecker-ohne.de/seite/alle-rezepte

Thanks for any help,

Tobias

tfranz: This should solve the issues you have...

In this patch I've added the possibility to exclude Better Select from all admin-pages (hopefully). Check the settings for the module. The code to detect if it's an admin-page is just something I came up with and is probably not the correct way to detect it... Anyone know how it should be done? Anyway, it works for me at the moment...

I've added support for multiple Taxonomy-filters as well as support for when you change "tid" to something else... (tfranz: These were the issues you had...)

Feel free to try it out and report back how it works for you ;)

I had some extra time to kill today and made some more changes. What I've done so far:

• Taxonomy-support now works in Views 2 (I think...)
• content_taxonomy-support added for Views 2
• support for multiple taxonomy-filters
• support for radiobuttons if singleselect is selected
• enable/disable radiobutton-support in Better Select admin
• enable/disable Better Select on all admin-pages (in case there are incompatibility-issues)
• some debug-functions which probably should be removed

Please note that there are still bugs when using multiple Taxonomy-filters in one View, these bugs have to be fixed outside of Better Select. They're there regardless if you use Better Select or not. To avoid some of the problems caused by these bugs consider to use content_taxonomy-fields instead...

The code is still a bit ugly and I've also been overzealous in my use of is_array, is_object and isset which are left there from when I traced myself down the variable-trees... But since it works I won't do anything about it at the moment...

One more thing: If things seems to be buggy, enable "Optional" in the filter and try again... If you think about it you should be able to come up with the answer to why ;)

Forgot to change the status... Please review my changes and get back to me...

The new patch seems to work, if i use only ONE Taxonomy-Filter. In the sample-page (see link above) there are two taxonomy-filters and i still don't get it to work ... (see attachment line 457 ff)

To say something positive: i like the feature "Node form only" – so i can use "Better Select" at other places ... and there it works perfect! :-)

Best regards,

Tobias

By the way: the content-filter (see attachment line 516) ignores Better Select permanently ... but that is an other issue ...

tfranz: I'm unable to reproduce your problems with multiple Taxonomy-filters at the moment, I will try to give it one more try this week but I'm very busy and will be away on 10-day trip from Friday...
I'm running this on a WIP-page (it's in Swedish):
http://masterveil.paradize.org/produkter

At the moment the main difference is that I use a CCK-Taxonomy-field and the normal Taxonomy-field instead of two Taxonomy-fields. I do this since If I run both filters as normal Taxonomy-fields it doesn't work regardless of whether I use Better Select or not.

Additional support for the field which is ignored has to be written, most probably it might work with just allowing the same functions which handle other Filter-fields using Better Select to handle that type of field as well. The structure for how to do that is in the current code I've submitted...

btw: If you want a more flexible exclude-function check out #540918: Exclude fields from conversion?.

PS. I changed the version of Better Select since I noticed that this thread was originally for beta1 and all code I've provided is based on beta2 (dev). DS.

I can confirm Better Select does in fact break views exposed taxonomy filter functionality. The empty text appears when initially loading the view page (which could be a symptom of the bigger problem) and checking known terms with associated nodes returns empty results.

subscribing

subscribing

I am also having issues with Exposed Filters in Views 2, but I think it's maybe different. For me, the module is simply not doing anything at all. The posts in this thread reference the fact that it looks good, but doesn't work. Mine still works, but it's still just the multi-select list. The module hasn't overwritten it to be checkboxes. I can't seem to find any other issues related to this, but will post here in case it's somehow related to this or maybe I'm just a moron. I'm not using any taxonomy or anything. It's honestly a very basic select list for picking the status of a job posting to filter on.

edit: it seems that my field returns a associative array, so my keys are not numeric. In this module, there is a check that aborts the process for this occurance:

foreach($element['#options'] as $key => $val) {
if (is_numeric($key) || !is_string($val)) {
return $element;
}
}

Since I don't really see the point in making sure keys are numeric, I am taking this check out. I don't know what in drupal causes my array to be different (CCK?) but there it is. Sorry if this post is in the wrong place. Hopefully it can be moved to a good spot or just deleted.

Thanks.

Hello, I was wondering if there has been any updates on a fix for this issue?
Many thanks!

If anyone is after a fix, try this module which is specific to Views Exposed filters and works a treat : http://drupal.org/project/better_exposed_filters

After enabling better select, exposed filter in views2 seems to be "required" (even if unchecked). That means, if nothing is selected, view displays no result. Exposed filter is based on taxonomy.

Man I was pulling my hair out over this one - it certainly does mess with Views' exposed filters. Much better to user http://drupal.org/project/better_exposed_filters instead of this module methinks - then just use CSS to control checkbox styling (scrolls etc)

q./

It can conflict with better_exposed_filters I made a small patch to fix that issue
basically if better_exposed_filters is installed it will prevent betterselect to be applied to exposed filters

The fact that betterselect breaks views exposed filters for taxonomy terms is pretty critical. I would suggest at the very least that this be documented on the project homepage if it can not be fixed in the code in a timely manner. I just about disabled the module and gave up on it when I realised that it was to blame for the hours of time lost to debugging this issue #979770: Taxonomy filter forcing terms to be selected.

@Bevan: It looks from the code of the patch in #39 that there is a "betterselect_node_form_only" variable that you can set. Possibly it should be documented that people are recommended to enable that if they are going to be using views exposed filters.

EvanDonovan; I agree that is a good solution.

In my case, the filter does not have to be exposed to be broken by betterselect. I think when filtered by taxonomy term and the operator is "is all of" or "is none of" it is broken. Waiting for a fix, thanks...

still broken. - any updates?

TimelessDomain; Enable the "Node form only" option in the BetterSelect module's options.

Perhaps also the default option for this setting should be "off"?

See: Issue #1407566: Better Select does not work on select elements without "-None-"/"-Select-" options

Will that issue/patch solve this? If so, we should close this as duplicate.