Per-exposed filter settings

The HS settings for the exposed filters are inherited from the vocabulary's settings, only the #required and #multiple properties are inherited from the Exposed filter settings (from "Optional" and "Force single" respectively).

You can override this yourself manually for now by doing a hook_form_alter() on the form with id "views_filter". See the code in the hook_form_alter() of modules/taxonomy.inc.

Changing to a proper feature request.

When this feature will be developed?

Can't tell just yet. Very unlikely to happen in the first month or so, due to exams in a couple of weeks.

Patches are of course welcome, and features can be sponsored to speed it up.

(I'm comming from http://drupal.org/node/233894.)

The HS settings for the exposed filters are inherited from the vocabulary's settings,

I have a simple idea which is relatively easy to implement, because it involves no UI, and which can solve all problems, including famine and wars:

Let's use drupal_alter() to give (custom) modules a change to alter the vocabulary settings.

Right now there are random variable_get("hierarchical_select_something_{$vid}", something) thingies in the code whenever some setting needs to be consulted. First, let's use a central function to get all settings:

Next, let's change this function to do drupal_alter():

...the calling code may look like:

this way one can write a custom module to alter some vocabulary setting in a certain context.

If I get a green light I can give a shot at writing a patch.

(I had an error in my drupal_alter() call: I forgot to pass the $context parameter. I fixed that.)

Having said that, bburan's original request, I think, has its own merit and doesn't really belong in our new 'per-view settings' discussion. That's because his request is a common one. Perhaps an additional checkbox on the settings page, '[x] don't enforce deepest for exposed filters', would do.

1) drupal_alter() is D6-only. You should use hook_form_alter().
2) You already can use hook_form_alter(). Just make sure your custom module runs after Hierarchical Select. You can do this by setting a heavier weight (i.e. higher number) in the system table for this module (you can do this through hook_install() in your .install file).
This is also what I replied in my first comment:

You can override this yourself manually for now by doing a hook_form_alter() on the form with id "views_filter". See the code in the hook_form_alter() of modules/taxonomy.inc.

Just the "enforce deepest" setting is not enough. It's actually not even everything what bburan wanted to do, so… (he also wanted to add the "<all>" option)

There are several reasons why my proposed solution is cleaner than using form_alter().

First, our custom code won't have the problem of figuring out where in the $form is the selectbox; this won't be a trivial task for themers --see the $form['view']['#value']->exposed_filter loop in hook_form_alter you pointed me to.

Second, my solution can solve a wider range of problems. For example, the Putting exposed views filters in separate lines should be optional issue could be solved by the custom module inserting a pseudo setting (say 'dont_tabelize') that HS could see. If we had to communicate this pseudo setting via form_alter(), we'd have to chain our custom module _before_ HS or else it wouldn't see this setting. And we'd have a weights soup, because we'd want our module to customize other things in Drupal as well.

But ok, you're the judge here :-) I'm restoring this to 'postponed'.

1) drupal_alter() is D6-only.

That's a negligible implementaiton detail. I know it's D6's. I was talking about the concept.

I think you've got a good point here. You're of course also right that drupal_alter() is only an implementation detail. I have to admit I'm reading + replying to issue comments very quickly lately, due to my exams (one more week of them, yuk). It's either that, or no replies.

If this generic system is there, building a UI around it will be easier at least. So that's good. The only concern I have left, is that this will be only for one specific implementation: the taxonomy one. That's of course the most significant one so far (and will probably remain the most important one), but a more generic approach would be desired. One other important implementation that will be included for sure (like 200% sure), is the menu module.

So, for a more generic approach, you should rename $vid to $params and thus compare all parameters for that implementation automatically. In order to know which implementation you're working with, you'll need a $module (Perhaps this should be renamed to $implementation all over HS? This is negotiable, but stick with $module for consistency with the rest of the code.) You can then use hook_hierarchical_select_params() to get all parameters for the specific implementation.

Once you've got this ready, I could probably also make the configuration form (which is currently only available at admin/content/vocabulary/settings), available for other implementations more easily.

So, to summarize:
- you've got my "blessing". Your coding effort won't be in vain, it will be included in HS.
- a taxonomy-specific implementation is acceptable for a first patch
- I think I'll only commit a generic variant. But that shouldn't be too hard once you've got a taxonomy-specific one of which you're satisfied.

If you've got any more questions, just ask ;) And thanks for contributing! :)

The only concern I have left, is that this will be only for one specific implementation: the taxonomy one.

Yeah, I was aware of this glitch.

OK, I'll give it a shot next week. We'll be smarter after I show some code.

(And good luck with your exams! ;-)

OK, I'll give it a shot next week.

Thanks! Much appreciated ;)

We'll be smarter after I show some code.

Definitely.

(And good luck with your exams! ;-)

Thanks :)

Any news, mooffie? :)

Wim,

Sorry for dawdling with this. I'll tackle this _tomorrow_, and if I see I can't handle this I'll say it outright.

(I hope your exams went well.)

Here it is. Of course, you're the judge here, and you're free to scrap it :-)

The code is only a handful of lines. The bulk of this patch is the documentation, so skip it till you reach the code.

Note that I deviated somewhat from the plan I described previously. I got smart and realized I can call the $settings altering hook from a low level: from the #process hook. This makes things simpler.

My intended audience is the administrator, or themer, so I'm not sure this code meets the high hopes you had in comment #10. But, I think, it'd serve well its intended audience.

Thank you very much. :) I'm about to leave on vacation, but I'll nevertheless try to give a look at it ASAP. In worst case, that will be in about 2 weeks from now. In the best case tomorrow.

You can leave it assigned to yourself, since you're doing the actual work here ;)

I'm afraid my review will end up being close to the worst case… I've been rewriting the rendering system of Hierarchical Select (not yet in CVS, see http://drupal.org/node/226067).
This means that the patch won't apply, but your changes to hierarchical_select.module are very small, so it won't matter much.

Just posting this to let you know I didn't forget about you ;)

And now, finally, exposed filters are working again in version 3. Time to work on this baby!

In HS3 there is an abstraction to get, set and apply a "config" (#config is the HS3 replacement for #hierarchical_select_settings), see includes/common.inc. *All* HS settings are now inside #config (see API.txt for details). There's also an abstracted way to generate form for any given implementation. This allows me to easily have a form just to configure the Hierarchical Select settings of an exposed filter.

However, HS3 does not yet support your proposed "context" parameter. And to be honest, I'm not sure it's a good idea. It seems to me like you're tackling the problem from the wrong side: why should a *form element* provide *context* to make *form alterations* easier? That really should happen in hook_form_alter().

So, HS3 will soon allow for per-exposed filter settings, but not for context-aware settings. So you won't be able to configure different settings based on the node type for example. At least not through an additional, custom hook.

I was wondering if that's a real use case for you, differentiating in settings depending on the node type? Or is it just a demonstration of what's possible? I think that's a pretty rare use case?

Your feedback is still very welcome!

(Sorry for the delay in my reply.)

Wim, you're doing a most important, and remarkable, work on HS3. It's going to be a milestone for Drupal, and you haven't yet heard half the praise ;-)

I was wondering if that's a real use case for you, differentiating in settings depending on the node type?

(No, it isn't a real use-case for me. It was a demonstration --but it was inspired by a support question I found in this issue queue.)

I suggest we leave this issue, this patch, to rest. If need arises, in the future, we can always revisit things. I don't see a demand for this so I'm accepting your judgment that it isn't that important.

mooffie, thanks for getting back to me. And thanks for your kind words.

I hope it will have the impact you are mentioning :) As far as I know, this widget is a unicum. Nothing like it exists. It will gain more traction, and I hope people will love it :) I like how it works, or even "feels" right now. For the next major iteration, it will have to be refactored significantly though. There's too much Forms API tricks going on: it's *very* hard to grok the code flow at the moment.

I *am* going to provide per-exposed filter settings, I'm just going to put the context and altering stuff aside. I don't think many people would use it. But this has helped me to gain more insight. So, thanks for contributing, it was not in vain ;) :) It has helped me to see that http://drupal.org/node/258056 is a good idea.

Marking as active and assigning to me to write the per-exposed filter settings stuff.

bookmark

Done! It'll need more thorough testing, but it's working flawlessly here.

esilou: don't forget to enable the Hierarchical Select Views Taxonomy module, or you'll be disappointed ;) :)

Wim,

just gave it a test. The exposed filters part seems to be working but I'm noticing 2 odd things:

1. The other issue I wrote about today (terms data not being saved in node/edit when Term Lineage option chosen) has worsened! I save a node as UK >> England >> London and when I go into the same node to edit it, the terms are showing as:

Angola >> London

which is not even a parent/child relationship that exists!

2. When I use HS for exposed filters, I'm getting a option which, when selected, allows the creation of new terms. I have never used this option and have that setting switched off for that vocabulary so I have no idea where it's suddenly coming from.

Please stay on-topic. #1 is completely unrelated to this.

#2 is impossible. Views Taxonomy exposed filters (or rather, that specific HS implementation) does NOT support the creation of new terms. The normal Taxonomy implementation however, does support this.

check out the video. I don't know if it's actually possible to create new terms because I haven't gone ahead and tried it, but the option is suddenly appearing as you can see. It wasn't there before. New Term Creation is not enabled in that vocabulary.

I've just fixed another bug that I think might be related to this. Please download the latest tarball and try again!

I was just coming here to say it wasn't happening anymore since I downloaded 1.80, which I grabbed in an effort to resolve the other issue #259903: When using "Save Term Lineage", term data not saved on node/edit. I thought I was going crazy. So that's one thing resolved anyway. Will do some more extensive testing tomorrow on exposed filters.

Heh :) Glad it's solved!

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

subscribing