New features from @kervi

I attached the module from kervi so that everybody can take a look and could create a patch.

Working features:

1. hide empty terms. (it becomes a little bit slow on huge taxonomies)
2. add a counter of related nodes to each term. (it becomes a little bit slow on huge taxonomies)
3. unique id for each widget

TODO: add settings to select a content to coun/filter.

please, review.

ehm. it's already in options..

+    $form['nodes_counter'] = array(
+      '#type' => 'checkbox',
+        '#title' => t('Add nodes counter to each term'),
+        '#default_value' => $this->options['nodes_counter'],
+    );
+
+
+    $form['empty_terms'] = array(
+      '#type' => 'checkbox',
+        '#title' => t('Hide empty terms'),
+        '#default_value' => $this->options['empty_terms'],
+    );

Please remove all the tabs in the patch...

Please remove all the tabs in the patch...

done

+++ b/views_hst_filter_handler_filter.incundefined
@@ -399,5 +447,59 @@ class views_hst_filter_handler_filter extends views_handler_filter {
+  if (!empty($children)){ ¶

There is a space.

+++ b/views_hst_filter_handler_filter.incundefined
@@ -199,9 +229,27 @@ class views_hst_filter_handler_filter extends views_handler_filter {
+        $nodes_counter = term_nc($term->tid);
+        if($empty_terms_option == '1'){

The coding standards say that you have to put a space after the "if".

+++ b/views_hst_filter_handler_filter.incundefined
@@ -112,6 +112,31 @@ class views_hst_filter_handler_filter extends views_handler_filter {
+    /*ToDo: filter by content type. ToDo: take content type filter from views*/

When you have a single line comment you should use // instead of /* */

Why need all these features?

1. hide empty terms.
Well, give to user ability select only terms having nodes it very good idea, I think.
But what will happen if hide empty terms option is enabled and all taxonomy terms in current vocabulary are empty? Or only one term has some nodes?

2. add a counter of related nodes to each term.
Only for visual effect?

3. unique id for each widget
Why need it?

4. Why need TODO: filter by content type?

When adding a "Content: Hierarchical Taxonomy Filter" exposed filter, sometimes I would just like to let the user filter the FIRST parent element of the term.

For example:

first test parent
-first test's first child
-first test's second child
second test parent
-second test's first child
-second test's second child
third test parent
-third test's first child
-third test's second child
fourth test parent
-fourth test's first child
-fourth test's second child

In this case, I would only like to let the user select from "first test parent", "second test parent", "third test parent", "fourth test parent", and that's all, I don't want to let users select (and see) any children terms.

Could you provide an opportunity in the filter settings to be able to limit the depth of search?
Thanks in advance!

===
EDIT: BTW, there's another built-in filter called "Content: Has taxonomy terms (with depth)", which can also be exposed, BUT in this case, unfortunately all the children elements get displayed in the select list too.

@Sk8erPeter:

So, it won't be "hierarchical select", won't it?

@ser_house: hmm, yes, in this case, the select procedure itself wouldn't be "hierarchical" - when for example disabling the display of the children elements (having this ability when exposing this filter), the user could just select the top/first element of the hierarchy.
Just like when you having the exposed filter of this module, but using the browser with JavaScript turned off. :) (This way there is no AJAX communication.)

Use-case: When categorizing stuffs on your site, the user would just be able to select the main category.

As a summary: having the ability to limit the maximum depth of the search (even if a term has children terms!).

Sk8erPeter, please, open the new issue for your request.

@ser_house, good point ;)
I created a feature request issue here: #1845802: Being able to limit the maximum depth of the hierarchical search (even if a term has children terms!).
Thanks in advance! :)

So, I did not get answers for my questions (#8) therefore I'm postponing this issue as "postponed (maintainer needs more info)".

OK, let me share some ideas until kervi answers.

1. The exposed filter could then be hidden if it's not needed, because these terms are not assigned to any nodes at all.
2. I don't understand the question. This way the user can see how many children does a category have.
3. Hmm, dunno.
I would rather encourage being able to add our own classes to these exposed filters for easier CSS-styling (not just the optional 'container-inline' class).
4. I didn't quite understand the original idea of kervi: "TODO: add settings to select a content to coun/filter. ".

@Sk8erPeter:

1. If we have only an own filter on form and we make it hidden what will be on the form? There will be only button?
Just I don't imagine as the hiding would look in some cases.

2. I mean that this is a matter of convenience, not necessity. On the other hand, if we won't hide empty terms then we could show to user that these terms are empty.

3. Each widget has own id now, as example: id=edit-terms3-wrapper, id=edit-terms4-wrapper

4. ...

Main question: What can do with the empty terms? It's not enought corny hide.

I'm suggest only show to user the count nodes.

1. hide empty terms.
Well, give to user ability select only terms having nodes it very good idea, I think.
But what will happen if hide empty terms option is enabled and all taxonomy terms in current vocabulary are empty? Or only one term has some nodes?

so, the effect is the same, after press submit, there are no result. And, i don't think that somebody is going to use terms without any content associated.

2. add a counter of related nodes to each term.
Only for visual effect?

why? hierarchical select have it and any big eshop have a counter of results.

3. unique id for each widget
Why need it?

Becouse there are problems if you use 2 HST of different views on same page.

4. Why need TODO: filter by content type?
becouse for now, the counter/empty terms filter it works for any kind of content type associated with the term. It will be great to use content type selected as filter in views. Or add a option to HST options panel.

@kervi: I absolutely agree with points 1-3.
But I don't really understand the 4th. Why is having the ability to filter for ALL the content types a problem?
There's already a built-in "Content: Type" filter in Views, which can also be exposed, so this shouldn't mean a problem.

1. I still doubt, but let's do it and see how it would. OK.
2. OK
3. Yeah, I didn't think about it. OK.
4. We postpone it until, I think.

So, I will test it as soon as have time.

Sk8erPeter and ser_house, about 4.

for now, the counter is a simply function that count all the nodes related with term. it not depends from View for now.

i mean, you can create a View of users, add HST, add counter, but it will count all NODES related to term.

so, this is becouse i want to add a simple function to count only nodes of selected content type.

@kervi: oh, OK, I understand now, this makes sense, and this would be a great feature.

@Sk8erPeter: I don't need more info.

@ser_house: oops, changing the status wasn't intentional.

that do you think?

I think main purpose the filter was solve one problem.

And now it acquires more and more code, more and more options.

I think it doesn't make the module better, only more knotty (I mean code, of course).

But adding the option for effects it's interesting. I think :)

1. Done.
2. Done.
3. Done.
4. I need more clarification.

did a test with the new stuff on my install, everything seems fine so far.

adding list of new features