Comments

Version:7.x-3.0-alpha1» 7.x-3.0-alpha2

I was just wondering the same thing :)

subscribe

subscribe

subscribe

subscribe

Component:Code - Content Taxonomy Views» Code - Taxonomy Views

This has indeed not yet been done: TODO.txt.

This is now the official issue for tracking Views support in D7.

+1

I'm going to try and get something working over the next few days. There is a lot here that I haven't dealt with before so I'm not sure how far I'll get.

Wim, are there any pointers you could give me. What to look at first?

I'd look first at how Views' exposed filters system works in 7.x.

Title:Hierarchical Select for exposed filters in ViewsPort Hierarchical Select Taxonomy Views (for exposed filters in Views) to Drupal 7

Status:Active» Postponed

+1

Suscribe

+1

Status:Postponed» Needs work
StatusFileSize
new8.61 KB

I started porting the hs views module to D7. The patch attached is a first attempt. So far, it took me a day of poking things around, toiling, cursing, drinking coffee, more hacking, more cursing,... to get it to work.

There are a few issues with this patch:

1.

It incorporates the patch for #1160694: Received an Invalid Response from Server Looks like that isn't already committed over there. Even so, the other issue probably needs a formal review, so consider it a temporary fix.

2.

Most of the day I spend getting the HS to work with hierarchical taxonomy fields on the front end side. The JS threw me a very weird error: "TypeError: Object has no method getEffect" After a few hours of hitting walls, I finally found the root of the problem.

Exposed filters in Views are forms. As such, they should be rendered through the Form API. Views does it slightly different. The core logic for exposed forms can be found in Views in the includes/views_plugin_exposed_form.inc file. Yep, it's a Views plugin class. The render_exposed_form() method renders the form. It reuses bits and pieces of the FAPI logic:

    $form = drupal_build_form('views_exposed_form', $form_state);
    $output = drupal_render($form);

Rendering a form this way, excludes the hidden form builder fields. So the rendered form does not return a form id nor extra form information the FAPI would need to execute. Yet, exposed forms are submitted through a $_GET rather then a $_POST.

Omitting the form_id causes HS to bork. In the hierarchical_select_ajax() function, we find this piece of code:

  if (empty($_POST['form_build_id']) || $form_build_id != $_POST['form_build_id']) {
    // Invalid request.
    drupal_set_message(t('An unrecoverable error occurred.'), 'error');
    $commands = array();
    $commands[] = ajax_command_replace(NULL, theme('status_messages'));
    return array('#type' => 'ajax', '#commands' => $commands);
  }

Without the form_build_id key, it will trigger an unrecoverable error.

So, why would Views do this? You can find the answer and the solution in #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback You can form_alter the exposed form through Views hook called hook_form_views_exposed_form_alter and reset the form_id back. The problem is that Views has a really low module weight and has its' own implementation: views_form_views_exposed_form_alter. So, what the HS Views module actually needs to do, is to get a module weight that's lower then Views just to work.

For now, I haven't implemented the solution in the patch yet. I'll do that tommorow. Just wanted to hear your thoughts about this first since changing module weights and altering an exposed form in this way might break things for others.

3.

When you add a new taxonomy filter to a view, you can choose between "dropdown, autocomplete or hierarchical select". If you choose the latter, you'll get a boatload of errors. Why? because the filter hasn't been set to be exposed. Yes, the HS Views module contains logic for hierarchical select integration in the Views filter settings form. To get it to work: a/ first add a filter. b/ set it to be exposed c/ click on "settings" and choose HS. d/ Now click on "configure HS"

So far, I can add a HS exposed form item and configure it. With a few modifications, I can get the HS form element to work on the front end. I haven't yet tested how the filter reacts to this (lineage, deepest value,...) that still needs to be tested.

1. I just committed #1160694: Received an Invalid Response from Server. (As well as fixes for pretty much all other remaining issues in D7.)
2. a) Are you sure you're using alpha 4 or the latest dev snapshot? I've seen that JS error happen somewhere between alpha 1 and alpha 4 and fixed it.
2. b) You're aware of render_flat_select? This is how HS worked with Views' GET forms in Drupal 6.
3. Why do you only get a boatload of errors when choosing HS and not when you choose any of the other widgets?

Thanks for stepping up and working on this! :)

1. Thanks :-)
2. a) Yep. I've git cloned the HS 7x-3.x branch. So, I've been developing since this morning from the latest dev.
b) No. :-) I'll check it out and get back to you. If I can avoid another form_alter, that would be awesome!
3. HS assumes the properties of the $filter object are always there (exposed, required form field,...) These properties only get set when the filter is configured through the regular widgets. When you add a filter and go straight into configuring HS, those properties aren't there. Apparently, a new filter widget needs to set them explicitly. The object is stored in the Views' cache and retrieved as is. That's how the properties get passed on from one widget to another. I also noticed that the 'configure HS filter' form is set through a ctools_dependent_process. So, the form is rendered and assumes values while the base object isn't ready yet.

I'll check these out tommorow! :-)

Suscribe

2. b) Definitely take a look at hs_views_taxonomy + views in D6 then. You'll see how they work together. You could also look up the original D6 issue in which this was done, there should be a goldmine of information for you there!
3. I don't mind you changing HS' assumptions or using some sensible defaults until the filter has been configured.

StatusFileSize
new12.7 KB

Okay.

1.

I got the configuration forms working a bit better. The configuration info hook is now functional too.

2.

I didn't got round to fix the _form_alter() thing. I checked render_flat_select. That should work. It's set as a boolean TRUE for Views exposed form fields with HS. So that should trigger stuff. It doesn't.

3.

Which brings me to the actual GET handling. I created a view fetching nodes with 1 taxonomy field, set it as an exposed filter with HS. Now, when I click on "apply", it returns me this URL:

http://localhost//boeken?field_genres_tid%5Bhsid%5D=0&field_genres_tid%5...

So, this is definitely not what Views expects. A regular dropdown exposed filter passes something like this: http://localhost//boeken?field_genres_tid=5 and that works. In Views 3, the exposed form plugin I talked about still triggers the FAPI. Every exposed form is processed through three form functions in views: views_exposed_form(), views_exposed_form_validate() and views_exposed_form_submit(). A regular dropdown widget triggers these and each function gets executed. When HS is active, none of these gets executed when theres' a GET parameter like the one above present.

There are two D6 functions that got ommitted in D7 yet seem to be necessary for hs_taxonomy_views to work:

hierarchical_select_common_add_views_js()

I ported this one to include the views.js file which should simplify the GET parameter. The JS code is included, but doesn't get triggered. Can't see why.

_hierarchical_select_setup_js(&$form_state = NULL)

Contains a boatload of code to include all kinds of JS files (effects) and stuff. These lines look important: _hierarchical_select_add_js_settings(array('HierarchicalSelect' => array('basePath' => $url, 'getArguments' => drupal_query_string_encode($_GET, array('q')))), $form_state); They seem to do something to the URL and $form_state but I'm clueless what they exactly are all about. I could port it, but the _hierarchical_select_add_js_settings() function isn't in HS D7 either.

Feels a bit like tumbling down the rabbit hole of dependent code without knowing where I'll end up. :-)

I think that solving 3 might also solve 2...

Any ideas?

I'm afraid I don't have the time to dive deeper into this. I know it's frustrating. I know it's poorly documented. But that's only because Forms API + Views' custom Forms API stuff are also poorly documented. I'm afraid you'll just have to try and make sense of Views' quirky form handling.

I agree. This is hard stuff. I just spent the sunday afternoon stepping through form.inc with xdebug. By default, if you would create a form builder which passes stuff through the GET method, the form validation/submit handlers won't fire. Only a POST would trigger those. This works as designed.

Rather then calling drupal_get_form, Views does some weird things with to trigger these handlers while using a GET handler.

What I did notice is this: Views expects the exposed form to have only one button: the 'apply' button to submit the form. HS adds a hidden 'update' button through _hs_process_render_nojs which comes with its' own hierarchical_select_ajax_update_submit callback. When a user disables JS, the browser will render the form button as a graceful degradation.

On line 1814 in form.inc we find this piece of code: $form_state['triggering_element'] = $form_state['buttons'][0]; So the FAPI assums the first element in the button array to be the button that submits the entire form. However, xdebug tells me that element '0' is the hidden 'update' button for HS to work. The FAPI won't trigger the default _submit and _validate functions but rather - erroneously - the callback associated with the update button.

When I comment out the 'update' button element, the views_exposed_form_submit and views_exposed_form_validate handlers *do* get called. As they should.

Still, somehow, the View isn't returning the adjusted result based on the update filter value. :-( So, that still needs to be checked out. First, we need to get this thing moving through the FAPI.

subscribe

Good luck. This is why I knew I wouldn't have the time to get this in, even if it were sponsored. Thanks for working on this!

subscribe!

As soon as you've posted the patch that adds HS Taxonomy Views support in D7, netsensei, I'll tag the first beta. Soon after that, I'll move to an RC. And you'll definitely get major credit.

+1

I thought hook_module_implements_alter() would do the trick, but alas no, there is another cute bug in core which prevents this, so yeah, module weights are the only way to implement that hook_exposed_view_form_alter() :/ See #765860: drupal_alter() fails to order modules correctly in some cases

+1

subscribe!

Subscribe

Subscribe!

Subscribe!

I am really looking forward to see this feature ported to Drupal 7.
I am willing to help you if you need some testing or coding to be done, so don't hesitate to contact me.

Subscribing! Really looking forward to views exposed filters feature for hierarchical select in Drupal 7. If any testing needs to be done, please let me know as I would be more than happy to help.

+ 1 for Hierarchical Select in Views exposed filters. Any status on this? Looking forward to testing.

Subscribe!

subscribe

subscribe

subscribe

subscribe

Is it ready? I need it seriously.

not ready. :(

I'm not spending time on this right now. The HS Views module needs major, structural refactoring. Views does some weird things with the FAPI to get the exposed form with working with features like pagination, ajax,...

If you *really* have to have HS in your views, you'll need to resort to custom coding atm. You could do something dirty like this:

* Create a page/block with the view and a separate custom form where you add a HS form element.
* Create a submit callback which passes the value coming from the form element to the view as a views argument and stores it in a session for later use.

The latest patch doesn't work. I have debugged the patch for a whole day.
However, the form_build_id is not sent to the server somehow, and the server responses error.

Thanks. I will try: )

Just as netsensei's advice, I created a separate form and stored the selection in a session. Then I passed the selection as context to views. It works. Thank you, netsensei!

hello robin_jx,

I'm a newbie in Drupal. Could you explain more exactly how you made your separate form with HS, and then passed the selection to view ?

Thanks a lot.

Hi, I really need this, too! Please could you explain in steps how to do it??!! It sounds easy but I have no idea what I'm supposed to do! Thanks!

Subscribing.

subscribe

+1 subscribe

subscribe

Should we press the follow button on top of this page
instead of post a "subscribe" message?

subscribe !!! I'm willing to help, don't hesitate to contact !

I did it!!! :-)) It's working! I made a module (my first one) with a block and a hs form element!! I'm willing to help, too! If sombody needs this, probably best thing is to open a new issue, 'cause I think it doesn't belong here as it's only about a workaround! Wow, I cannot believe I did that!! I'm completely new to all this stuff here!!

Please Desica, could you explain us step by step how you did it? Thanks in advance

Hi, I made a custom module with hook_block() and a hs form element in it. I applied some javascript to submit it on change (I have another - real exposed views filter form so I didn't want the submit buttom of the custom form). Then I have an if statement that's checking if the value is set (if(isset($_POST['formname'])) and stores the selected value in a session with $_SESSION['formname']. In views I added a contextual filter (Has taxonomy term ID) with custom php code:

$myvalue = $_SESSION['formname'];
return $myvalue;

Hope that helps! If you need more advice please open an issue and post the link here.

subs

Hello desica. Please, could you put your solution?

subsribe

Hi desica, would it be possible that you explain a bit more thoroughly or post some code?

Version:7.x-3.0-alpha2» 7.x-3.0-alpha5

Rather interested in this functionality on a number of projects.
Anything I can do to help with kicking it out? Funding, development, or otherwise?

Status:Needs work» Postponed

This issue keeps floating at the top of my queue. A durable solution relies on a lot of stuff that still needs to be flogged out elsewhere. Either in the HS module, Views or even core. (See our notes earlier in this topic)

I'm not saying it's undoable, but from my experience, a straight port isn't going to happen overnight. I can't speak for Wim, but at the moment, I don't have the time to invest, that this issue actually requires.

I'll try to put the alternate solution Desica worked out in a blogpost of sorts. Beware though: it's *very* hackish and won't cater everybody's use case. If you want to combine a HS enabled filter with other filters, you'll most likely end up writing extra code.

I'm setting this back to postponed. (sept 2011 > needs work)

subscribe

To all the "subscribers" here, see Stop subscribing, start following on subscribe comments. :)

What is being done to commumicate these issues to the maintainers of the other modules?

Is this the type of development that Drupal wants to be known for?

This obviously is a very important and much needed module.

I have to say that this is a let down and is most likely not good for the Drupal community.

Should I bail on Drupal altogether?

What is being done to communicate these issues to the maintainers of the other modules?

This is a let down.

This module is very important and much needed for Drupal to function normal.

Why is this not given priority?

EDITED: Found some ugly problems with IE8, now the code has been carefully tested and seems to work correctly.

Hi everybody!

I just had the time to create a temporary solution for a specific use case: dependant dropdowns for views exposed filter of 2 levels taxonomy vocabulary; a working example is at http://jsfiddle.net/aLyM8/17/

I'll also paste the code here:

Html sample:

<div id="edit-loc-wrapper" class="views-exposed-widget views-widget-filter-field_project_location_tid">
  <label for="edit-loc">City</label>
  <div class="views-widget">
    <div class="form-item form-type-select form-item-loc">
      <select id="edit-loc" name="loc" class="form-select">
        <option value="All" selected="selected">- ANY CITY/AREA -</option>
        <option value="1">BOGOTÁ</option>
        <option value="2">-SAN RAFAEL</option>
        <option value="5">ZIPAQUIRÁ</option>
        <option value="6">-MADELENA</option>
        <option value="7">-SANTA ANA</option>
        <option value="3">CALI</option>
        <option value="4">-CHIPICHAPE</option>
      </select>
    </div>
  </div>
</div>

JS:

/*
* Notes:
* - The fiddle does not use Drupal.t(), so you must do it when implementing it on your site.
*/
(function($) {
    $(document).ready(function() {
        var parents = {};
        var srcSelect = 'edit-loc'; // id of the select containing the original, flat list of options
        // Any option having this character(s) at least once will be considered child
        // It is assumed this "magic" word is found before the part of the option that
        // must be preserved when put into the level2 select
        var childChar = '-';
        var childCharLength = 1; // Length of childChar
        var level1Label = '- ANY CITY -'; // "all" values text for level 1 select
        var level2Label = '- ANY AREA -'; // "all" values text for level 2 select
        var level1Id = 'city'; // Id to use for the level1 select
        var level2Id = 'area'; // Id to use for the level2 select
        var allOptionValue = 'All'; // value of the "all" option in the srcSelect
        // Returns true if the text of the option has the childChar
        function isChildItem(opt) {
            var optText = $(opt).attr('text');
            return optText.indexOf(childChar) == -1 ? false: true;
        }
        // Stores the latest parent found
        var curParentVal = null;
        // Clones an option to the appropriate select in the hierarchy
        function addOption(parent, child, opt) {
            var optVal = $(opt).attr('value');
            var optText = $(opt).attr('text');
            var childCharPos = optText.indexOf(childChar);
            var cloneOpt = $(opt).clone();
            if (! isChildItem(opt)) {
                $('#' + parent).append(cloneOpt);
                curParentVal = optVal;
            } else {
                var childOptText = optText.slice(childCharPos+childCharLength);
                // Prepares the clone before appending it
                $(cloneOpt)
                    .addClass("sub_"+curParentVal)
                    .attr('text', childOptText);
                $('#' + child).append(cloneOpt);
                // Stores the child:parent relationship in the parents object
                parents[optVal] = curParentVal;
            }
        }
        // Turns on the selected attribute on the option whose value is optValue
        function setSelectValue(selectId, optValue) {
            return $('#'+selectId).attr('value', optValue);
        }
        // Clone only the .sub_X options from hidden select, X being current parent's value
        // and use it as new set of options for the child select
        function refreshChildOptions(parent, child, isSubselectOptional) {
            var parentValue = $('#'+parent).attr('value');
            // Hide to be nice with IE
            $('#' + child)
                .hide()
                .html($("#" + parent + child + " .sub_" + parentValue).clone());
            if (isSubselectOptional) {
                var cloneOpt = $('#'+srcSelect+' option[value='+allOptionValue+']').clone();
                $(cloneOpt)
                    .attr('value', parentValue)
                    .attr('text', level2Label);
                $('#' + child)
                    .prepend(cloneOpt);
            }
            // Show it again
            $('#' + child).show();
        }
        // Generate City - Area separated selects from original one. Initially hide them.
        $("#"+srcSelect+"-wrapper .form-item")
            .append("<select id='"+level1Id+"' class='form-select' style='display: none;'></select>")
            .append("<select id='"+level2Id+"' class='form-select' style='display: none;'></select>");
        // Iterate over the original options to add them to the dependant dropdowns
        $("#"+srcSelect+" option").each(function(index, item) {
            var optVal = $(item).attr('value');
            if (optVal != allOptionValue) {
                addOption(level1Id, level2Id, item);
            }
        });
        // Add the "all" option to the level1 select, do cloning just for convenience (also seems to be more compatible with IE)
        allOpt = $('#'+srcSelect+' option:first')
            .clone()
            .attr('text', level1Label);
        $("#"+level1Id).prepend(allOpt);
        // Original taken from: http://www.ajaxray.com/Examples/depend.html
        // Edits:
        // 19-Jan-2012: John Herreño (jedihe<a.t>gmail.com)
        function makeSublist(parent, child, isSubselectOptional, childVal) {
            // Add a hidden select to store the full possibilities for child, without filtering from parent's current value
            $("#"+srcSelect+"-wrapper .form-item").append("<select style='display:none' id='" + parent + child + "'></select>");
            // Get all the options from child and put them in hidden select
            $('#' + parent + child).html($("#" + child + " option"));
            // Read current parent's value
            var parentValue = $('#' + parent).attr('value');
            refreshChildOptions(parent, child, isSubselectOptional);
            // Select the default child option
            childVal = (typeof childVal == "undefined") ? "" : childVal;
            setSelectValue(child, childVal);
            // Bind to change event on parent select
            $('#' + parent).change(function() {
                var parentValue = $('#' + parent).attr('value');
                $('#'+srcSelect).attr('value', parentValue);
                refreshChildOptions(parent, child, isSubselectOptional);
                // Be nice to IE8
                $('#' + child + ' option:selected').removeAttr('selected');
                setSelectValue(child, parentValue);
                if (parentValue != allOptionValue) {
                    $('#' + child).focus();
                }
            });
            // Bind to change event on child select
            $('#' + child).change(function() {
                var childValue = $('#' + child).attr('value');
                $('#'+srcSelect).attr('value', childValue);
            });
        }
        makeSublist(level1Id, level2Id, true);
        // Ensure proper initialization of dependant dropdowns
        var initValue = $('#'+srcSelect).attr('value');
        var parentValue = parents[initValue];
        var level1Value = typeof parentValue == "undefined" ? initValue: parentValue;
        setSelectValue(level1Id, level1Value);
        refreshChildOptions(level1Id, level2Id, true);
        setSelectValue(level2Id, initValue);
        $('#'+srcSelect).hide(); // Comment to see the original select being driven by the new ones
        $('#'+level1Id).show(); // Only show the new selects at the very end, when we're sure it's all been set up correctly
        $('#'+level2Id).show();
    });
})(jQuery);

I would be glad to know if somebody found it useful :)

It would be even better if someone has the time to push it forward to get it working on arbitrary depth vocabularies.

I get the patch from netsensei at #22 against alpha5, and i get the "hierarchical select" option in a taxonomy_field, but, in the configuration page, following the link, I hadn't seen any term in the dropdown and I got some notice level errors. So I thought that the vocabulary was not loading propertly. So, in modules/hs_taxonomy_views.module file I changed the line 230 from:

<?php
   
'vid'         => $filter['vid'],
?>

to
<?php
   
'vid'         => taxonomy_vocabulary_machine_name_load($filter['vocabulary'])->vid,// $filter['vid'],
?>

and also the line 241 from

<?php
     
'max_levels' => _hs_taxonomy_hierarchical_select_get_depth($filter['vid']),
?>

to
<?php
     
'max_levels' => _hs_taxonomy_hierarchical_select_get_depth($params['vid']),
?>

Then, the error messages dissapear, and I could see the dropdown working propertly, but, in my preview and in my view page, the dropdown still empty... Any ideas?

Following the same logic, I also changed the file modules/hs_taxonomy_views_handler_filter_term_node_tid.inc in the line 44
from:

<?php
      $vocabulary
= taxonomy_term_load($this->options['vid']);
?>

to
<?php
      $vocabulary
= taxonomy_vocabulary_machine_name_load($this->options['vocabulary']);
?>

And now, my dropdown is full with the terms, but, when I select one of them to get deeper in the hierarchy, I get a javascript error, and the next dropdown never arrives. This is happening only in the exposed filter, not in the node edit form. This is the information of the ajax request:

request post parameters:

field_comarca[hierarchical_select][sleects][0] = 1
field_comarca[hsid] = 0
field_numero_habitaciones...
field_precio_value
field_tipo_inmueble_value = All
hsid = 0
keys
op = Actualizar

response:
[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"promogalicia","theme_token":"Ech4fZzGPnNus32zRVlQAfMha2pV0NuhkBfpH1g-bFc","css":[]},"getlocations_colorbox":{"enable":0},"overlay":{"paths":{"admin":"node\/*\/edit\nnode\/*\/delete\nnode\/*\/revisions\nnode\/*\/revisions\/*\/revert\nnode\/*\/revisions\/*\/delete\nnode\/add\nnode\/add\/*\noverlay\/dismiss-message\nuser\/*\/shortcuts\nadmin\nadmin\/*\nbatch\ntaxonomy\/term\/*\/edit\nuser\/*\/cancel\nuser\/*\/edit\nuser\/*\/edit\/*","non_admin":"admin\/structure\/block\/demo\/*\nadmin\/reports\/status\/php"},"ajaxCallback":"overlay-ajax"}},"merge":true},{"command":"insert","method":"replaceWith","selector":null,"data":"\u003cdiv class="messages error"\u003e\n\u003ch2 class="element-invisible"\u003eMensaje de error\u003c\/h2\u003e\nAn unrecoverable error occurred.\u003c\/div\u003e\n","settings":null}]

and the error

ajax.getEffect is not a function on...
var effect = ajax.getEffect(response); ( ajax.js?v=7.10  line 482)

I'm very sorry, I promised to help but I was working very hard on my project and had no time to look at this issue again. Here is my code for my custom module (I called it HS Views :-):

<?php
/**
* Implementation of hook_init().
*/
function hs_views_init() {
  drupal_add_js(drupal_get_path('module', 'hs_views') .'/hs_views.js');
}
function hs_views_block_info() {
  $blocks['hs_views_block'] = array(
    'info' => t('HS Views Block'),
    'status' => TRUE,
    'region' => 'sidebar_first',
  );
  return $blocks;
}
function hs_views_block_view($delta='')
{
  switch($delta) {
    case 'hs_views_block':
      $block['subject'] = null;
      $block['content'] = drupal_get_form('hs_views_my_form');
      break;
   }
   return $block;
}
// This function is called the "form builder". It builds the form.
// Notice, it takes one argument, the $form_state
function hs_views_my_form($form_state) {
$form['location'] = array(
    '#type' => 'hierarchical_select',
    '#title' => t('Location'),
    '#size' => 1,
    '#config' => array(
      'module' => 'hs_taxonomy',
      'params' => array(
        'vid' => 2,
      ),
      'save_lineage'    => 0,
      'enforce_deepest' => 0,
      'entity_count'    => 0,
      'require_entity'  => 0,
      'resizable'       => 0,
      'level_labels' => array(
        'status' => 1,
        'labels' => array(
          0 => t('Region'),
          1 => t('Subregion/Island'),
          2 => t('Town/City'),
        ),
      ),
      'dropbox' => array(
        'status'   => 0,
        'title'    => t('All selections'),
        'limit'    => 0,
        'reset_hs' => 1,
      ),
      'editability' => array(
        'status'           => 0,
        'item_types'       => array(),
        'allowed_levels'   => array(
          0 => 0,
          1 => 0,
          2 => 1,
        ),
        'allow_new_levels' => 0,
        'max_levels'       => 3,
      ),
      // These settings cannot be configured through the UI: they can only be
      // overridden through code.
      'animation_delay'    => 400,
      'special_items'      => array(
  'any' => array('none', 'exclusive'),
  ),
      'render_flat_select' => 1,
    ),
    '#default_value' => '-1',
  );
  // We need to hide the submit button with javascript, that way the user can save the location with the button if js is disabled.
  $form['submit'] = array(
    '#type' => 'submit',
'#name' => 'givelocation',
    '#value' => 'Save location!',
  );
  return $form;
}
if (isset($_POST['location'])) {
if ($_POST['location']['hierarchical_select']['selects']['0'] == 'label_0') {
$_SESSION['location'] = -1;
}
elseif ($_POST['location']['hierarchical_select']['selects']['1'] == 'label_1') {
$_SESSION['location'] = $_POST['location']['hierarchical_select']['selects']['0'];
}
elseif ($_POST['location']['hierarchical_select']['selects']['2'] == 'label_2') {
$_SESSION['location'] = $_POST['location']['hierarchical_select']['selects']['1'];
}
else {
$_SESSION['location'] = $_POST['location']['hierarchical_select']['selects']['2'];
}
// drupal_set_message(print_r($_SESSION['location'], true));
}

And in the javascript file goes this:

(function ($) {
  Drupal.behaviors.HsViews = {
    attach: function (context, settings) {
      $('#hs-views-my-form #hierarchical-select-0-wrapper').bind('change-hierarchical-select',function() {
        $("#hs-views-my-form").submit();
      });
    }
  };
}(jQuery));

As I already mentioned above, then you'll need this in your contextual filter code:

$myvalue = $_SESSION['location'];
return $myvalue;

Of course, anybody who is going to use this will have to customize a few things.

Thanks for posting your code desica. I've been waiting for a solution until this is one of the few issues left on my Drupal-study-website to solve. It is not clear to me if this feature is ever going to be added to the Hierarchical Select module and my website relies heavily on the ability to search thru long lists of organized terms. I feel I have no choice as attempting to recreate the module you are describing.

So I recreating your HS views module but since this is very new to me it's not very surprising I can not get it to work.

This is what I did:

  1. I created a folder in sites/all/modules/custom/ and called it "hs_views"
  2. In this folder I created the files "hs_views.info", "hs_views.js", "hs_views.module"
  3. I have put this in "hs_views.info":
    name = HS Views
    description = Shows Hierarchical select in views.
    core = 7.x
  4. Put your Javascript code in the file "hs_views.js".
  5. Put your php code in the file "hs_views.module".
  6. Activated the module.
  7. Added your php code to a contextual filter in my view at "When the filter value is NOT in the URL -> Provide default value".

Now I get a "page not found" with this notice:

Notice: Undefined index: formname in eval() (line 1 of PATH_TO_MY_WEBSITE/sites/all/modules/views/plugins/views_plugin_argument_default_php.inc(50) : eval()'d code).

I am assuming this is because I can not figure out what you mean by "Of course, anybody who is going to use this will have to customize a few things."

Could you or someone else shine a light on this? It would help me a lot (and maybe a lot of other noobs)

Thanks!

Update:

While looking over the php code I found some stuff that (probably) need customizing. Assuming 'location' is the machine name of your vocabulary I changed every instance of it to my vocabulary machine name.

  • On line 36: $form['location'] = array(
  • in the code starting from line 97: if (isset($_POST['location'])) { ------ and all below

I also changed the 'vid' on line 43 to my vocabulary's id number.

Now I have the hierarchical select on my view working with all the terms in my vocabulary but I still get the "page not found".

+1

Will this work for non-taxonomy queries?

Hi kwindo! Here goes some advice...
1.) in the contextual filter code, instead of 'formname' I have 'location', I changed it in the post above

2.) location is the name of my vocabulary but this has nothing to do with line 36, only the vid is reffering to the vocabulary. Here, location is just the name of the form element. (Have a look at the API text in the Hierarchical select module!) If you change it, change all other names below, too, and don't forget to change it in the contextual filter code as well.

3.) try to use drupal_set_message to find out what variables you need, ignore my if, elseif, else-stuff from line 97 to 112, instead to begin just put:

if (isset($_POST['location'])) {
$_SESSION['location'] = $_POST['location'];
drupal_set_message(print_r($_SESSION['location'], true));
}

Good luck!

Priority:Normal» Critical

Hi,

I'm a little confused over this 'location' reference?

What do i need to replace in the php code if the machine name for my vocabulary is 'tags' and the machine name for my view is 'advanced_search'?

Any help is greatly appreciated.

I understand you're confused, cause I named everything 'location'. You can name the form element how ever you want (I have $form['location']), the 'vid' is your vocabulary id and then in $_POST you put again the form name.
Neither the vocabulary machine name nor the view machine name is needed. The vid is reffering to the vocabulary and the code with the SESSION variable goes into the views context filter php code!

StatusFileSize
new3.61 KB
new24.79 KB

Apologies for so many questions as I'm still getting to grips with PHP in Drupal

'vid' - yours is set as 2, where do i find my vid?
form element/name - is this the path that the view outputs to in page settings or the page title?

I've attached a few pics to show my view and taxonomy setup

StatusFileSize
new6.36 KB

@desica

I think i may of misread your post and also i should have looked at the code fully. I don't really want a new block creating, all i really need is a new option in the views exposed filter settings menu.

Currently under selection type i have (see attached)

*Dropdown
*Autocomplete

I would like the 'Hierarchal Select' feature adding to that list, is this possible?

Obviously you misunderstood something here. I made a module which is a WORKAROUND (like suggested by netsensei above). It won't provide any new settings in views but it solves the issue of having a hierarchical select element for filtering content by a hierarchical vocabulary. It's far from perfect but at least I'm ok with waiting for a HS Taxonomy port to D7 (if ever).

Is it possible to put more fields in the module and make these search able? Sort of re-creating my view.

How do you mean... put more fields in the module? If you mean, have another hierarchical select element for a different vocabulary, I suppose it is possible, you would need to store the second value in another session. But first, try to get it working with just one...

And why would you need to recreate your view? The only thing you need to change in your view is to add the context filter code!

Thanks desica I got this to work with your code.

I needed the ability to remember what I selected on each page load, a reset option, and setting the taxonomy filter to all if nothing was selected. Instead of the block though I did a drupal_render on the form in the header of my view and moved the session setting to a form submit handler. I also wrote some session based code to remember the values on page loads so you don't need to go through the full HS boxes every time your view loads. Then I added a reset button with session unsets to reset the hierarchy.

Notes: I have a 4 level taxonomy (alter this to your taxonomy depth) and named it activities with a vid of 2, so make sure to change those.

js file:

(function ($) {
  Drupal.behaviors.HsViews = {
    attach: function (context, settings) {
$('#hs-views-my-form #hierarchical-select-0-wrapper').bind('change-hierarchical-select', function(hsid, updateType, settings) {
      var selectedTermTid = $('#' + settings.select_id).val();
      $.get('/activity-hs-session/' + settings.select_id + '/' + selectedTermTid, function(data) {
       //data
      });
    });
    }
  };
}(jQuery));

module info file:

name = "HS Views"
description = "Custom code for the HS Views integration"
core = 7.x
project = "hs_views"
version = 1.0
package = "HS Views"
dependencies[] = views
files[] = hs_views.module
scripts[] = hs_views.js

module file:

<?php
/**
* Implementation of hook_init().
*/
function hs_views_init() {
  drupal_add_js(drupal_get_path('module', 'hs_views') .'/hs_views.js');
}
function hs_views_menu() {
  // Callbacks for toggle active
  $menus['activity-hs-session/%/%'] = array(
      'page callback' => 'hs_views_activity_hs_session',
      'page arguments' => array(1,2), // 1 is nid, 2 is forwarded destination url
      'access callback' => true,
      'type' => MENU_CALLBACK,
  );
return $menus;
}
function hs_views_activity_hs_session($hs_id, $hs_term_id) {
  if(isset($_SESSION['as_hs_default_vals'][0])) {
    $hs_default_0 = $_SESSION['as_hs_default_vals'][0];
  } else {
    $hs_default_0 = -1;
  }
  if(isset($_SESSION['as_hs_default_vals'][1])) {
    $hs_default_1 = $_SESSION['as_hs_default_vals'][1];
  } else {
    $hs_default_1 = -1;
  }
  if(isset($_SESSION['as_hs_default_vals'][2])) {
    $hs_default_2 = $_SESSION['as_hs_default_vals'][2];
  } else {
    $hs_default_2 = -1;
  }
  if(isset($_SESSION['as_hs_default_vals'][3])) {
    $hs_default_3 = $_SESSION['as_hs_default_vals'][3];
  } else {
    $hs_default_3 = -1;
  }
  $as_hs_default_vals = array($hs_default_0, $hs_default_1, $hs_default_2, $hs_default_3);
  switch($hs_id) {
    case 'edit-activities-hierarchical-select-selects-0':
      $as_hs_default_vals[0] = $hs_term_id;
      break;
    case 'edit-activities-hierarchical-select-selects-1':
      $as_hs_default_vals[1] = $hs_term_id;
      break;
    case 'edit-activities-hierarchical-select-selects-2':
      $as_hs_default_vals[2] = $hs_term_id;
      break;
    case 'edit-activities-hierarchical-select-selects-3':
      $as_hs_default_vals[3] = $hs_term_id;
      break;
  }
  $_SESSION['as_hs_default_vals'] = $as_hs_default_vals;
}
function hs_views_unset_session() {
  unset($_SESSION['actvities']);
  unset($_SESSION['chosen_activity']);
  unset($_SESSION['as_hs_default_vals']);
}
// This function is called the "form builder". It builds the form.
// Notice, it takes one argument, the $form_state
function hs_views_my_form($form_state) {
if(isset($_SESSION['as_hs_default_vals'])) {
$default_tids = $_SESSION['as_hs_default_vals'];
} else {
$default_tids = '';
}
$form['activities'] = array(
    '#type' => 'hierarchical_select',
    '#title' => t('Category'),
    '#size' => 1,
    '#default_value' => $default_tids,
    '#config' => array(
      'module' => 'hs_taxonomy',
      'params' => array(
        'vid' => 2,
      ),
      'save_lineage'    => 1,
      'enforce_deepest' => 0,
      'entity_count'    => 1,
      'require_entity'  => 0,
      'resizable'       => 0,
      'level_labels' => array(
        'status' => 1,
        'labels' => array(
          0 => t('Select an Activity'),
          1 => t('Select an Activity'),
          2 => t('Select an Activity'),
          3 => t('Select an Activity'),
        ),
      ),
      'dropbox' => array(
        'status'   => 0,
        'title'    => t('All selections'),
        'limit'    => 0,
        'reset_hs' => 0,
      ),
      'editability' => array(
        'status'           => 0,
        'item_types'       => array(),
        'allowed_levels'   => array(
          0 => 0,
          1 => 0,
          2 => 1,
          3 => 2,
        ),
        'allow_new_levels' => 1,
        'max_levels'       => 4,
      ),
      // These settings cannot be configured through the UI: they can only be
      // overridden through code.
      'animation_delay'    => 400,
      'special_items'      => array(
          'any' => array('none', 'exclusive'),
          ),
      'render_flat_select' => 1,
    ),
  );
  // We need to hide the submit button with javascript, that way the user can save the activities with the button if js is disabled.
  $form['submit'] = array(
    '#type' => 'submit',
        '#name' => 'giveactivities',
    '#value' => 'Apply',
  );
  $form['reset'] = array(
    '#type' => 'submit',
    '#value' => 'Reset',
  );
  return $form;
}
function hs_views_my_form_submit($form, &$form_state) {
if(isset($form_state['values']['op'])) {
   if($form_state['values']['op'] == 'Reset') {
       unset($_SESSION['activities']);
       unset($_SESSION['as_hs_default_vals']);
   }
}
if(count($form_state['values']['activities']) > 0) {
   $last_val = count($form_state['values']['activities']) - 1;
   $_SESSION['activities'] = $form_state['values']['activities'][$last_val];
   if(strpos($_SESSION['activities'], 'label')) {
     $_SESSION['activities'] = 'all';
   }
} else {
   $_SESSION['activities'] = 'all';
}
}

subscribe

Depending on the complexity of your vocabulary, the Views Dependent Filters module can also be used as a workaround: create an exposed taxonomy filters for each level in your vocabulary and create a "Global: Dependent filter" to make each child level depend on its parent.

Well like you said - Views Dependent Filters can only be used with very basic taxonomies. For instance, i have a taxonomy with 2 levels, and more than one term has a couple of children. When i choose a parent term, the dependent list isn't limited to the children of the actual chosen parent. Just sayin'..; don't get your hopes up :)

Has anyone been able to find any alternatives for filtering large vocabularies, such as a tree-style taxonomy menu, that works with views and drupal 7?

please someone help me... i've this simple structure:

-Alfa romeo
---156
---147
-Mercedes
---Classe A
---Classe B
ecc...

only 2 leves of taxonomy...

i've tried the desica solution, i've created the modules and the form is appeared. I've modified this string in hs_views.module:

'#config' => array(
      'module' => 'hs_taxonomy',
      'params' => array(
        'vid' => 3,

where 3 is my vid vocabulary.

The form now render right all 2 leveles.
After this i've added a Contextual filter to my view as Taxonomy Term: ID, and i've set this default value for no results:

<?php
$myvalue
= $_SESSION['location'];
return
$myvalue;
?>

Now when i change the dropdown list it do nothing... what's wrong?

Hi, you'll have to analyze things step by step to see what's wrong, that's how I got it working. It seems that your form is ok, first thing to check would be if it gets submitted. I see you didn't change 'location' to 'cars' so I suppose you haven't changed anything else and you are submitting the form onchange like me. Check if #hierarchical-select-0-wrapper is the id of your hs element, if not correct it in the js file.

Second, uncomment my last line of code:
drupal_set_message(print_r($_SESSION['location'], true));
Select something in your form and check if the correct tid shows up in the message area.

This issue was opened to track the effort to get the actual module to support this functionality, but I'm afraid it's been overwhelmed with support requests for implementing separate workarounds. Should one or the other interest be spun off into a separate issue so as not to distract from the work of actually getting the module fixed?

@desica thanks for posting your code. I have been having trouble getting this going I keep getting this error: Notice: Undefined index: location in eval() (line 1 of /Applications/MAMP/htdocs/sites/all/modules/custom/views/plugins/views_plugin_argument_default_php.inc(50) : eval()'d code).

Along with a page not found for the view I am trying to display.

Where exactly does the location index in the $_SESSION get set?

Thanks again.

this module is abandoned Travis.

Is there any other module providing similar functionality?

no, :(

I went back to using Drupal 6 as this was a main feature

It is a petty that as D7 the module has no support for views... :(

So no more D7 migration until I find and alternative w/o having to code.

Hope someone pick up the module or a similar one comes up.

In any case, thanks for the D6 module. It si great!!! Thanks a lot for the work done ^^

I also moved back to Drupal 6 because of this hoping a descent alternative for Drupal 7 will pop up one day.

I also think go back to drupal 6 since it does not implemented.

Version:7.x-3.x-dev» 7.x-3.0-alpha5

ugh

Im thinking also to turn back to drupal 6, really sad situation..

Really disappointed.

I think a lot of people have worked really hard to get this working and I hope someone finds a solution soon.

Good luck,

CP

Status:Postponed» Closed (won't fix)

i really dont' understand why Wim is still working on his another module, CDN (last commit 2012-Mar-08) and ignore hierarchical select.

if he is very busy, he can't work on both modules, right?

Status:Closed (won't fix)» Postponed

Reverting status to postponed in case Wim can get back to HS sometime in future (or in case someone else can contribute a patch ;-)

Hi,
I need to use the Exposed filter hierarchical select on my new project.I want to use Drupal 7 not Drupal 6 for this.
Any news regarding this feature's port on D7?
Thanks

It's a pity this feature hasn't been already ported on D7 :(

Agree, trying to make this work at 2+ days and I'm stuck...

Seems like this is going no where...? I'm rethinking the whole "Hierarchical Select" feature and figuring out other ways my users can filter through terms. Disappointed to see such a good module die like this..

question: if I go back to drupal 6 in defeat, will I never be able to update to drupal 7 because this module will never get fixed? my site currently depends on this and it's launch is pending on it.

hi #111 @ drumnjo,
same here i m also using D7, wanted HS badly for my site,but HIGHLY loose hearten :( currently compromising and using "views exposed filters" as replacement(in a hope that mean while HS will hv a release) but wanted to ask one question that u r saying to degrade ur site from D7 to D6!! is it possible?? if yes how?? can u please share!! it will be great,coz i m also planning to backport from D7 to D6!! thanks..

i think you have to re-build it in drupal 6

ohh.. is that so!! not good idea for me :( hving 25732 data entries!! so, OBVIOUSLY not a wise decision to rebuild!! :-) what do u say?? :-D ha..ha.h.a

I can understand that the maintainers of this module have not enough time to add this functionality, but I can't understand a system like Drupal has no another option module for this. there are thousands of drupal site builders (using drupal 7) and if they are not a php guru!, they can't filter their views by taxonomy term in a hierarchical manner. Just pathetic!!

If a module developer Can't keep up with Drupal core, they shouldn't have created a module in the first place. Because it will be huge disappointment for Drupal newbies.

Let's be careful to avoid personal attacks here. I understand everyone's frustration—I want this module, too—but this is community software; let's try to solve this as a community. To that end, let's first of all try to keep this issue free of hostility and complaining. If we want this module to be more actively maintained, we should try to make that job a pleasure. Now here are some ways people could potentially help things along.

  1. Supply a patch. Obvious, I know, but it's still the most effective strategy if you have the ability to code. If you don't, you could still...
  2. Hire someone to work on the feature. The author states on the project page that he can be contacted for paid customizations of this module. You could also hire any other Drupal developer to work on it and supply a patch.
  3. Start a ChipIn. If you can't afford a bounty on your own, you could see if there's enough interest for a community pot.
  4. Organize a sprint. If none of us can write a patch for the feature and we don't have the money to pay someone to, we can at least try to get the interest of others who can. Take this to your local Drupal group and suggest it as a mentoring exercise.
  5. Find a JavaScript library we could integrate for the UI component. Cross-platform JavaScript is complicated. If we could just use an open source script that does what we need, we could focus on the Drupal-specific implementation and reduce the work involved in maintaining this module.
  6. Update the summary for this issue. This thread has grown long, and it would take a considerable effort for anyone to get up to speed on it. If you can fill out a simple template you can make it easier for new people to get in and help.
  7. Offer help in other HS issues. If we helped triage issues, answer questions, and test patches in the other issues filed against Hierarchical Select, the maintainers would have more time (and motivation) to help us with ours.
  8. Appeal to the maintainer. Consider writing the maintainer to thank him for his hard work on this module and express your interest in this feature. Be responsible, of course—don't spam him—but let him know he's appreciated. As they say, honey is often more persuasive than vinegar.

There should be something in there that everyone can do. Anyone who's not willing will probably help most by keeping their peace. :)

Version:7.x-3.0-alpha5» 7.x-3.x-dev

I agree with TravisCarden. People need to remember that the people who donate their time and effort to these modules have their own priorities, and if we want them to continue to support these modules, we need to do more than just complain. If someone can help find a developer that would be willing to take this on, I would be glad to contribute to a chipin-type system.

Thanks Travis.

Indeed, within the available timeframe, I've tried to port this to D7. Wim has been as supportive as he could be. A straight port which the Views integration part of HS is just not do-able. The D6/D7 changes made to the Views API and the form API just make it impossible to make the existing code work with minor changes.

I've shared my experiences over those days that I put into this here. I can only conclude that we're looking at a major rewrite of this module. I just don't have the time to engage in such a large project. That's why I don't go any further into this.

I agree with many of you that this is a major annoyance. If it worked in D6, it should d**n well work in D7 too.

Either a chip in or someone willing to step up to the plate, having a good understanding of the Form and Views API and enough time has a good shot at making this work.

Sorry to disappoint anyone if this is a hard requirement for you. I can only recommend that you have a solid technical analysis before you start developing.

What's the bottom line here, as far as how much money we are talking about for a 'community pot'?

I have tried to get the developer of views to look into this thread and try to help out. no response.

Where are the heavy hitters out there who got the bucks to pay for this as you potentially suggest? Don't these site developers need this important feature? I think it's more than an 'annoyance'... from my perspective it's a drupal failure.

Where is the teamwork in trying to make this work? I have tried to be productive in my communication efforts.

I don't have money, I'm lucky to hold down a job these days.

I agree, the negative feedback sucks, and I'd rather read that people are working towards solutions or that the issue has been resolved.

I think I've contributed the best that I can by trying to implement some communication from the developer of views, to be specific.

I don't have much money but I've learned in life that effective communication can solve problems.

Version:7.x-3.0-alpha5» 7.x-3.x-dev

yes,i also want this module BADLY and i know it is SURE frustrating!! it is surely DIFFICULT!! and yes it SURELY is a failure of drupal..!! and yes communication SURE PAYS excellent sometimes!!, good try #drumnjo, i'l also follow and post a reply as a support!! and i wish every one else should also do it so that people out there KNOW!! what the REAL ISSUE!!

ok apart from this my main motive of posting this is that....

i like the suggestion of TravisCarden and i m interested in raising some money or to bring in some HELP,so can anyone tell me...
1) how much money is EXPECTED to required??
2) a list of field of APPLICATION of this module!!(means it's importance)
3) skills required to do this (viz php, CSS, HTML, PEARL etc...)

i m asking this coz i m a electrical student (not IT or web so dnt hv technicel know how ) but i have got an idea..that as a student i can(planning to) convenience(hopefully) my professors/guide to take up this as a "PROJECT" and provide a funding for it(from govt. or college whatever)!! or else i can convenience other friends to take this as a curricular project in final year!! it would be GREAT isn't it??!! ;) but to do all this i need to have it's IMPORTANCE(properly documented)!!so.please share ur views regarding my idea.. thanks...

+1

Well, @rathin2j, the skills required to do this include PHP, Drupal API, jQuery, and a little CSS. @netsensei might be able to speak to the question of how much effort it would take, since he's worked on it. I don't understand your second question. Are you asking for use cases? how the feature might be used?

yes sir,i m talking about it's use, how this feature can be "crucial" (inevitable) in some sites...

I wish I could be of any help!! But as for my part, I'm a sexologist... not a web developer either! So first of, thx a lot for all your efforts and I can assure you many people will be grateful when it'll be available. I'm actually working on creating a platform for health & social services that will gather many resources (intervention programs, theses, etc.), so it will be very useful to browse within the publications, being able to select the type of publication, theme & more. If anyone does have an idea for an existing module in D7 meanwhile that could be useful, I'll be very welcome to hear your suggestions :) Good day, everyone!

i have found a "solution" to use hierarchical taxonomy in views.

if you want something like this

http://www.screenr.com/CK78

you have to:

1.buy this: http://codecanyon.net/item/finder-jquery-drilldown-plugin/1764847?ref=kervi (it's refferral link, :))
3. create a new taxonomy term field with your hierarchical vocabulary as source.
2. install jquery_update module, latest dev version. set jquery to 1.7 (/admin/config/development/jquery_update)
3. install global_filter module. in Global filter block options, set it to:
- field, content property, location proximity or search term(s)
- select previously created field.
- widget: Single choice drop-down
- move this block to any visible region.
4. create a new view and add new contextual filter with relationship to your global filter.
4. add jquery-ui.finder.min.js and finder.css to your theme.
5. run the magic:

jQuery('#your_field_id').finder({
indent: '-',
});

it's works!!!

i will talk with global filter module mantainer to include this as feature.

subscribe

@kervi

Thanks for the idea!

Do you have an example of this working on a Drupal site? The video you posted didn't seem to show it running with Drupal.

Thanks!

I followed @kervi's instructions (more or less) and got the Finder plugin working with Drupal. It's working very well for me.

I did 2 things differently: I didn't use the Views Global Filter module, and I added a preprocess page hook to template.php to enable jQuery UI widgets (required by Finder).

Here are the steps I followed:
1. Use the jQuery Update module to update jQuery to 1.7
2. Add a preprocess page hook to your theme to enabled jQuery UI widgets. You may not need to do this if you are already using a module that requires widgets. Add the following to template.php:

<?php
function YOUR_THEME_NAME_preprocess_page(&$variables) {
 
drupal_add_library('system', 'ui.widget');
}
?>

3. Buy the Finder jQuery UI plugin (it's only $5). Add jquery-ui.finder.min.js and finder.css to your theme. Also add select_arrow.gif, unless you plan to rewrite the css.
4. Use the following js to enable Finder for a field:
jQuery(function(){
  jQuery('#YOUR_FIELD_ID').finder({
    indent: '-'
  });
});

Does it work on Views 3 filter criteria - exposed filters? The Finder plugin, I mean.

Thanks in advance.

I'd like the discussion around implementing Finder to be able to continue without overwhelming this issue, so I've created a Finder jQuery Drilldown Plugin sandbox project where that can happen. Let's pick this conversation up in its issue queue at #1526734: Implement the Finder jQuery Drilldown Plugin , and this issue can go back to working on Hierarchical Select. Thanks!

Thanks Travis. Much appreciated!

I don't think many people are aware that I've invested many hundreds of hours of my free time in this module over the years…

I know I've neglected this module. The "getting a great job" part has been more difficult than anticipated — if I'd have taken the job offer at Facebook (I didn't because I don't want to move to the U.S.), it would've been easier, but then I wouldn't have had time to continue this module either.

As to why the CDN module has been kept up-to-date much better: it's easier to maintain. With all due respect, but I have to waste far less time holding newbie's hands there. There's far less incredibly basic questions there than in the HS issue queue. All that being said, the most significant reason is that Hierarchical Select is a far more complex beast. It supports so many possible configurations. But more importantly, it integrates with so many modules. Each of which can have problems, more often than not caused by *other* modules, not HS, but nevertheless people flock to the HS issue queue instead of to other modules. Notably the D5/D6 Content Taxonomy module integration has caused probably 30–40% of all support requests, because it was such unstable craptastic code. That's *very* demotivating. Even more importantly: Drupal's Form API really doesn't support AJAXy form elements/widgets properly. Go and look, there's only #type = autocomplete and that's pretty much it. To get HS to work *at all*, I've had to invent crazy work-arounds.
Overall, HS is a nightmare to maintain, because it's so flexible, because Drupal is so flexible and because FAPI doesn't support these extremely complex AJAXy form elements very well.

The most important way for you guys to help out and to help me get HS back on track, is by doing as much HS issue triage as possible. I've put in a few hours today, and again the same trends of the past are there: plenty of duplicate issues… The fact that several of you are so upset can be interpreted as annoying, but it also shows this module really is very important for many users (apparently some of you even *downgrade* to Drupal 6 for it!).

Let's do this :)

wim, i really appreciate your work.

Maybe a summary of #131 can be posted on top of node/add/project-issue/hierarchical_select,
or in HS project page at least. Thank you Wim, and all the best with your new job at Nascom!

hi
I am trying to use Hierarchical select with view, but doesn't manage to make it working.

I created a taxonomy and I use Hierarchical select for that , it help user to tag content with country and then city.
But i want to create a view of this content and allow user to search specific one (by searching country and then select city) with the same presentation of list that hierarchical select provide but in my view i don't manage to do it

Do you know if it posible? and how i could do that?

thanks in advance
ana

#135: don't post support requests here. Also: can't you read? It's stated on the project page and in this issue that this functionality has not yet been ported. Also: please use proper punctuation and English.

@all: #135 demonstrates how extremely frustrating it can be to maintain and support this module. Imagine getting hundreds of these requests, and answering them. In your spare time. ;)

#131: We can't thank you enough for all the work you have done for this module. So many people have used HS in their projects, and maybe HS has played very important role in their projects, and again maybe they've made their money from these sites just because you and other developers like you have spent most of their free times to develope great modules like HS.

So I think nobady here has right to complain about what you haven't done. But I also think the people who is following this issue, deserve to know if this functionality is going to be in D7 or not. If it is ... When ?

You could just say that you are not going to have time to do that. Everybody should understand that. Or you (or another developer) could say it will be ported "This" time later. So we can decide what to do more easily.

#137: please see #23, #24, #26, #28 and everything preceding #23.

It's simple: this is *extremely* hard stuff. It can easily take a full-time week to get this working. But it could take more. Hence nobody wants to sponsor it (so far at least). I don't want to spend >5 full days of my free time on it.
Conclusion: this specific functionality (Views integration) will not be ported to D7 until somebody contributes a patch that does it, or until somebody sponsors me to port it.

(The fact that this functionality has not yet been ported is also the reason I've still not tagged a beta or RC — see #28.)

1st off all my apologies to the community for the following post, but something must be said.

#138 Instead of been rude on answer to #135, as this is a international community and not everybody have English as native language you could already tell to EVERYONE the problem is you want money to fix the module.

From your words you point of view of Drupal is everybody must beginning charge for every single hour, right? More, This issue have more than 1 year, why you don't say before to the community you want money to develop the functions needed?

If the problem is the money give numbers, how much will cost that "week"?

It's a shame, if everybody thinks like you, Drupal won't exist. If you don't want to share your skills/knowledge with the community, and where everybody share code for free here, your place is not on Drupal, choose another CMS, mark this module as unsupported/abandoned but don't make the community waiting more one year to have something functional.

Once again, If the problem is money, why dont you insert a "This module need financial assistance to be completed" on module description and you wait more than 1 entire year? You already see several persons downgrade versions, others leaving drupal...

You already stop to think if a similar module doesn't exist yet is because this module exist and everyone are waiting to this be done?

If you cant understand the english I wrote I can also wrote on my native language but I doubt you speak that. Alternative you can also put the correct punctuation and correct the English or you will charge that also?

#139: You're wrong on so many counts that I don't even want to reply to it all — especially because I don't want this issue to turn into a flamewar.

But please read what you've written: you're saying that if everybody thought like me, Drupal would not exist. That I don't share my code freely. Did you even bother to read #131? I've put in hundreds of my free time (unpaid!) into this module. I provide upgrade paths all the way back to Drupal 5. I provide a 3.x version for Drupal 5, 6 and 7. I've added an insane amount of features that I didn't need, but people in the community needed, which I've added free of charge.

Where are your code contributions?

If it wasn't clear yet: it's these sorts of demands that are very demotivating.

Please apologize.

P.S.: my native tongue (one does not say "native language") is also not English — it's Dutch. It's not even my second language, that's French. It's a language I was barely taught in school. Also, punctuation is mostly language-independent.

Wim,

I'm not going to use this post to make some double edged comment followed by insisting you spend your free time on making this work. Your work on HS has been fantastic. Perhaps you could start a www.kickstarter.com campaign (or similar)?

Clearly the community rates your work... and it would be better that you are recompensed for your work than some guy on CodeCanyon.

Rustig aan!
Ĝis!
别着急

Choitz

I am ready to kick in some money !

Great work WIM - thank you for your efforts! I'll second joemoraco #142

@125
@kervi
I have been trying to get the Finder fix to work but I am a little confused, where exactly are you supposed to put this code in order to "run the magic" :)

jQuery('#your_field_id').finder({
indent: '-',
});

Hi!

you can add

<script type="text/javascript">
    jQuery(function() {
        jQuery('#your_field_id').finder({
indent: '-',
});
    });
</script>

to your page.tpl

or

http://drupal.org/node/304255

Sorry, I know this is off topic and don't feed the trolls etc, but... PedroMiguel who has made zero commits is accusing Wim Leers who has made 1138 commits to 20 Drupal projects of this:

It's a shame, if everybody thinks like you, Drupal won't exist. If you don't want to share your skills/knowledge with the community, and where everybody share code for free here, your place is not on Drupal, choose another CMS, mark this module as unsupported/abandoned but don't make the community waiting more one year to have something functional.

Wow, just wow...

@Wim, if some organization (like mine) was wiling to sponsor it would you even have the time right now to dig into this? Would you prefer a patch from an outside source or a sponsor?

@Wim - I'm going to be working on this over the next few weeks... but I know the high quality of your work, and this will be my first significant Views integration code... so I can say I'm not optimistic that I can do better than you here. Would you have time to give guidance on good directions to take, or what the problems are that you've encountered?

I'd love to get familiar enough with the internals of this module to help triage support requests, and to take this monster Views integration off your hands. If you've got time for a Skype call sometime in the next few weeks, I'm game. PM me if you like :)

@ohthehugemanatee: You might consider creating a sandbox where questions could be asked and guidance offered in the issue queue as you work on it.

@ohthehugemanatree I would suggest to read my comments in this issue between #16 and #26. I've tried to port this back in september last year. My notes should give you some insights to the showstoppers I encountered in my attempt.

Especially #24.

I agree. This is hard stuff. I just spent the sunday afternoon stepping through form.inc with xdebug. By default, if you would create a form builder which passes stuff through the GET method, the form validation/submit handlers won't fire. Only a POST would trigger those. This works as designed.

Rather then calling drupal_get_form, Views does some weird things with to trigger these handlers while using a GET handler.

What I did notice is this: Views expects the exposed form to have only one button: the 'apply' button to submit the form. HS adds a hidden 'update' button through _hs_process_render_nojs which comes with its' own hierarchical_select_ajax_update_submit callback. When a user disables JS, the browser will render the form button as a graceful degradation.

On line 1814 in form.inc we find this piece of code: $form_state['triggering_element'] = $form_state['buttons'][0]; So the FAPI assums the first element in the button array to be the button that submits the entire form. However, xdebug tells me that element '0' is the hidden 'update' button for HS to work. The FAPI won't trigger the default _submit and _validate functions but rather - erroneously - the callback associated with the update button.

When I comment out the 'update' button element, the views_exposed_form_submit and views_exposed_form_validate handlers *do* get called. As they should.

Still, somehow, the View isn't returning the adjusted result based on the update filter value. :-( So, that still needs to be checked out. First, we need to get this thing moving through the FAPI.

To me, the extra button added by HS conflicts with Views/FAPI. So, apart from building a new HS integration for Views, you'll probably going to have to patch the HS module itself too.

Even so, you'll also going to need to figure out how to integrate with Views exposed forms cleanly in order to make it return/print a valid (paged!!) result set.

Wim,
I really appreciate all you have done!
..But... Can you put some numbers on the table?

As #142 and #143 I'm willing to kick in some money. But as any paid project I think you have to quote the price and time estimate.
Also... there is always a question of future support for the module and views integration feature.

IMHO, you should at least let us know what would it take to kick start this.. if this is acceptable by this forum, setup paypal donate or something and lets see if we can raise the money.. if after lets say a month we are not close to the sum I wouldn't mind if you donate whatever collected to a better cause of your choice.

Udi

@ohthehugemanatree: i really appreciate your working on this and suppose you get much support from the family here if you report and ask!!
a sandbox would be fine sure.

Yep. I'm presently looking into a totally different approach to get the same functionality. Will sandbox shortly.

Subscribe

Any news?

heh - people are excited, eh?

The other approach I want to try came from user kervi (http://drupal.org/user/412147), and was demoed for me on a temporary site . Basically it's a pure Form API approach to hierarchical select form behavior, which might be easier to build into Views. The relevant code:

<?php
function custom_test_form($form, $form_state) {
 
// wrapper
 
$form['terms'] = array(
   
'#tree' => TRUE,
   
'#prefix' => '<div id="terms">',
   
'#suffix' => '</div>',
  );
 
$values = isset($form_state['values']['terms']) ? $form_state['values']['terms'] : array();
 
$values += array('term' . (count($values)+1) => 'none');
 
$parent = 0;
  foreach (
$values as $input_name => $tid) {
    if (
$parent === 'none' || !($terms = taxonomy_get_tree(1, $parent, 1))) { //<-- VID!!!
     
break;
    }
   
$options = array('none' => '<none>');
    foreach (
$terms as $term) {
     
$options[$term->tid] = $term->name;
    }
   
$form['terms'][$input_name] = array(
     
'#type' => 'select',
     
'#options' => $options,
     
'#default_value' => $tid,
     
'#ajax' => array(
       
'callback' => 'custom_test_form_ajax_',
       
'wrapper' => 'terms',
      ),
    );
   
$parent = isset($options[$tid]) ? $tid : 'none';
  }
 
$form['submit'] = array(
   
'#type' => 'submit',
   
'#value' => 'Submit',
  );
  return
$form;
}
/**
* AJAX callback
*/
function custom_test_form_ajax_callback($form, $form_state) {
  return
$form['terms'];
}
?>

I haven't gotten to play with it yet. The project that will require this is still there, but they had other, more urgent things break. Once I'm done taking care of those things, I will ultimately be getting to this. Maybe someone else wants to play with this approach in the meanwhile?

@ohthehugemanatee, excited is an understatement, we are holding our breath many projects depend on this. if you haven't replied now, some (at least me) might have collapsed.:), not able to decide whether it is going to be a horror movie or just suspense thriller, better be suspense thriller i hope.

can some body try to make this Chained Select/Dropdown using aJax & jQuery using Taxonomy work as temporary workaround please.

@ohthehugemanatee is there any success story?

I know this one is not related with HS module, but I found a JS solution that turns a hierarchical select dropdown to multi-step select form: https://github.com/AndrewIngram/jquery-select-hierarchy

One thing to do is to convert the select options on the views from:

Cat 1
-Subcat 11
-Subcat 12
Cat 2
-Subcat 21
-Subcat 22

to:

Cat 1
Cat 1 > Subcat 11
Cat 1 > Subcat 12
Cat 2
Cat 2 > Subcat 21
Cat 2 > Subcat 22

Does anyone knows how to do it?

I just combined the script on the #160 with some custom code, and now I have a working multi-step taxonomy select widget!

In order not to steal this issue any further, I created this documentation page: http://drupal.org/node/1669940

Thanks for that link....
I tried it and everything worked beautifuly but i needed it to work on 3 levels so i actually found a way to output my taxo as:

Cat 1
Cat 1 > Subcat 11
Cat 1 > Subcat 12 > Subcat 31
Cat 2
Cat 2 > Subcat 21
Cat 2 > Subcat 22

here is my function (probably badly written, i am no PHP ninja):

function city_select_filter_opts() {
        $vid = 14 // Your vocabulary id
$taxos = taxonomy_get_tree($vid); //array containing all terms
$taxoArray = array();
foreach($taxos as $taxo){
  $tid = $taxo->tid; //tid for each term
  $taxoParentArray = taxonomy_get_parents_all($tid); // array containing all terms and all the parent like (suburb - city - country) in my case
  $taxoParentArray = array_reverse($taxoParentArray); // I reverse the order to get (country - city - suburb)
  $count = count($taxoParentArray); // get total items
  $i = 0;
  $sep = ' > ';
  $parentsName = ''; //need to create the var in case there is no parent then you get an error (var undefined)
  foreach($taxoParentArray as $taxoParent){
    if(++$i === $count){
    $sep = '';
  }
  $parentsName .= $taxoParent->name . $sep; //loop thru and create our new values (country > city > suburb)
}
  $taxoArray['All'] = "-All-"; // add the first value to array
  $taxoArray[$tid] = $parentsName;// add all the other values
  }
  return $taxoArray;
  }
//unset my field added in views -> exposed filter
unset($form['term_node_tid_depth_1']);
// create the new option fiel with the new array
$form['term_node_tid_depth_1'] = array(
      '#type' => 'select',
      '#title' => t('Countries'),
      '#options' => city_select_filter_opts(),
    );

UPDATE

Well it was to good to be true, this code works only if the exposed filter form is on the view and not in a block (so useless for me)

@etcetera9 would you be able to tell me how i can modify your script to use on a 3 level taxonomy ??!
Thanks

FOLKS! this is not a forum...!
please do not hijack this issue.

Yes, for this I created a new page about my solution. Please continue under it.

I ported the most parts of hs_taxonomy_views to Drupal 7. Please review and commit it.
Thanks

Sorry i forgot the patch. Here is it.

Colorcode free file.

@florian.gosse, perhaps I patched the file(s) wrong, but I got this error and nothing else on my home page which has an exposed filter that is using Hierarchical Select:

Parse error: syntax error, unexpected $end in mysite/sites/all/modules/hierarchical_select/modules/hs_taxonomy_views.module on line 721

I also patched the file and it is applied cleanly. but There is no settings on the views exposed filter options for hierarchical select.

Where should I look to see if it is working ?

Sorry when I add a term relationship on a content views and add a Term ID filter, I found hierarchical select option. And it seems to work just fine.

but i have a 500 error and broken whole view with:
Fatal error: Call to undefined function _hierarchical_select_setup_js() in ...\sites\all\modules\hierarchical_select\modules\hs_taxonomy_views_handler_filter_term_node_tid.inc on line 26

After spending hours trying to port it to Views, I just gave up and wrote my own JavaScript function to do the same thing. Ignore the variable names, I am building a car website. Insert this snippet into the footer of your views and make sure you change listWithDepth("edit-field-vehicle-tid"); to the id of the select box you want to be converted. This ONLY works with a depth of two!! Note: Most of my time was spent making sure this worked for ALL browsers, so please let me know if you have any problems! And im not using ANY libraries. This is as light weight as it gets!!!

<script type="text/javascript">
listWithDepth("edit-field-vehicle-tid");
listWithDepth("edit-taxonomy-catalog-tid");
function disectList (nodes)
{
var parentCount = -1;
var childCount = 0
var carBrand=new Array();
for(i=1; i<nodes.length; i+=1) {
if (nodes[i].innerHTML.indexOf("-") != -1)
{
carBrand[parentCount][childCount+1] = nodes[i].innerHTML;
childCount += 1;
}
else
{
parentCount += 1;
carBrand[parentCount] = new Array();
childCount = 0;
carBrand[parentCount][0] = nodes[i].innerHTML;
isParent= true;
}
}
return carBrand;
}
function listWithDepth (list)
{
var listWithDepth =document.getElementById(list);
listWithDepth.style.display ="none";
var nodes = listWithDepth.getElementsByTagName('option');
var carBrand= disectList (nodes);
var brandList  = document.createElement("select");
var modelList = document.createElement("select");
brandList.id = "brand" + list;
modelList.id = "model" + list;
brandList.className = "form-select";
modelList.className = "form-select";
modelList.style.display = "none";
option = document.createElement("option");
option.innerHTML = ("- Any -");
brandList.appendChild(option);
for (x in carBrand)
{
option = document.createElement("option");
option.innerHTML = (carBrand[x][0]);
brandList.appendChild(option);
}
brandList.setAttribute("onchange", "brandChanged('" + list + "')");
modelList.setAttribute("onchange", "convertBackToList('" + list + "')");
listWithDepth.parentNode.appendChild(brandList);
listWithDepth.parentNode.appendChild(modelList);
}
function brandChanged (list)
{
var modelList = document.getElementById("model" + list);
var brandList = document.getElementById("brand" + list);
modelList.innerHTML ="";
var listWithDepth =document.getElementById(list);
var nodes = listWithDepth.getElementsByTagName('option');
var carBrand= disectList (nodes);
if (brandList.options[brandList.selectedIndex].text == "- Any -")
{
modelList.style.display = "none";
}
else
{
for (y in carBrand)
{
if(carBrand[y][0].indexOf(brandList.options[brandList.selectedIndex].text) != -1)
{
option = document.createElement("option");
option.innerHTML = ("- Any -");
modelList.appendChild(option);
for (z in carBrand[y])
{
if(z != 0)
{
option = document.createElement("option");
option.innerHTML = (carBrand[y][z].substr(1));
modelList.appendChild(option);
}
}
}
}
modelList.style.display = "block";
}
convertBackToList (list);
}
function convertBackToList (list)
{
var listWithDepth =document.getElementById(list);
var nodes = listWithDepth.getElementsByTagName('option');
var modelList = document.getElementById("model" + list);
var brandList = document.getElementById("brand" + list);
var selectedTag =  "";
if (modelList.selectedIndex >0)
{
selectedTag = modelList.options[modelList.selectedIndex].text;
}
else
{
selectedTag = brandList.options[brandList.selectedIndex].text;
}
for(i=0; i<nodes.length; i+=1)
{
if (listWithDepth.options[i].text.indexOf(selectedTag)>-1)
{
listWithDepth.selectedIndex = i;
}
}
}
</script>

Thanks you very much Florian for your patch. I have a probleme tough with it. In the hs_taxonomy_views file.

@@ -444,7 +472,7 @@ function hs_taxonomy_views_hierarchical_select_item_get_label($item, $params) {
function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
   static $count;
-  $current_view = views_get_current_view();
+/*  $current_view = views_get_current_view();  <----- HERE

Where do the block comment stop? Can we have (download) your patched module HS Views?

I have the same error (#172). i use dev version and apply #168 patch. and this work properly.

+1

@gmilonas,

Really thanks you so much for your flawless code (#173).
I'm having headache for this hierarchical selection and you save me.
Thanks again.

You're very welcome!!! I will be posting an updated code very soon that will fill in the listbox if the page reloads with a value already set =). Not a permanent solution but it works flawlessly.

<script type="text/javascript">
listWithDepth("edit-field-vehicle-tid-1");
listWithDepth("edit-taxonomy-catalog-tid");
function disectList(nodes) {
    var parentCount = -1;
    var childCount = 0
    var carBrand = new Array();
    for (i = 1; i < nodes.length; i += 1) {
        if (nodes[i].innerHTML.indexOf("-") != -1) {
            carBrand[parentCount][childCount + 1] = nodes[i].innerHTML;
            childCount += 1;
        } else {
            parentCount += 1;
            carBrand[parentCount] = new Array();
            childCount = 0;
            carBrand[parentCount][0] = nodes[i].innerHTML;
            isParent = true;
        }
    }
    return carBrand;
}
function listWithDepth(list) {
    var listWithDepth = document.getElementById(list);
    listWithDepth.style.display ="none";
    var nodes = listWithDepth.getElementsByTagName('option');
    var carBrand = disectList(nodes);
    var brandList = document.createElement("select");
    var modelList = document.createElement("select");
    brandList.id = "brand" + list;
    modelList.id = "model" + list;
    brandList.className = "form-select";
    modelList.className = "form-select";
    modelList.style.display = "none";
    modelList.style.marginTop = "7px";
    option = document.createElement("option");
    option.innerHTML = ("- Any -");
    brandList.appendChild(option);
    for (x in carBrand) {
        option = document.createElement("option");
        option.innerHTML = (carBrand[x][0]);
        brandList.appendChild(option);
    }
    brandList.setAttribute("onchange", "brandChanged('" + list + "')");
    modelList.setAttribute("onchange", "convertBackToList('" + list + "')");
    listWithDepth.parentNode.appendChild(brandList);
    listWithDepth.parentNode.appendChild(modelList);
var carBrandName;
var carModelName;
for (x in nodes) {
if (nodes[x].innerHTML.indexOf("-") != -1)
{
            carModelName = nodes[x].innerHTML;
if (nodes[x].getAttribute("selected") != null)
{
break;
}
        } else {
            carBrandName = nodes[x].innerHTML;
if (nodes[x].getAttribute("selected") != null)
{
carModelName = "- Any -";
break;
}
        }
}
nodes = brandList.getElementsByTagName('option');
for (i = 0; i < nodes.length; i += 1) {
        if (brandList.options[i].text.indexOf(carBrandName) > -1) {
            brandList.selectedIndex = i;
        }
    }
brandChanged(list);
modelList = document.getElementById("model" + list);
nodes = modelList.getElementsByTagName('option');
for (i = 0; i < nodes.length; i += 1) {
if (carModelName.indexOf(modelList.options[i].text) > -1) {
            modelList.selectedIndex = i;
        }
    }
}
function brandChanged(list) {
    var modelList = document.getElementById("model" + list);
    var brandList = document.getElementById("brand" + list);
    modelList.innerHTML = "";
    var listWithDepth = document.getElementById(list);
    var nodes = listWithDepth.getElementsByTagName('option');
    var carBrand = disectList(nodes);
    if (brandList.options[brandList.selectedIndex].text == "- Any -") {
        modelList.style.display = "none";
    } else {
        for (y in carBrand) {
            if (carBrand[y][0].indexOf(brandList.options[brandList.selectedIndex].text) != -1) {
                option = document.createElement("option");
                option.innerHTML = ("- Any -");
                modelList.appendChild(option);
                for (z in carBrand[y]) {
                    if (z != 0) {
                        option = document.createElement("option");
                        option.innerHTML = (carBrand[y][z].substr(1));
                        modelList.appendChild(option);
                    }
                }
            }
        }
        modelList.style.display = "block";
    }
    convertBackToList(list);
}
function convertBackToList(list) {
    var listWithDepth = document.getElementById(list);
    var nodes = listWithDepth.getElementsByTagName('option');
    var modelList = document.getElementById("model" + list);
    var brandList = document.getElementById("brand" + list);
    var selectedTag = "";
    if (modelList.selectedIndex > 0) {
        selectedTag = modelList.options[modelList.selectedIndex].text;
    } else {
        selectedTag = brandList.options[brandList.selectedIndex].text;
    }
    for (i = 0; i < nodes.length; i += 1) {
        if (listWithDepth.options[i].text.indexOf(selectedTag) > -1) {
            listWithDepth.selectedIndex = i;
        }
    }
}
</script>

I also had this, and found out that the patch forgot one bracket In hierarchical_select/modules/hs_taxonomy_views.module

Here is a copy of my code. Hope this helps

else {
//more commented stuff
//$count[$current_view->name][$item] = db_query($count_query, $args)->fetchField();
}
  //return $count[$current_view->name][$item];
  return 1;
} }
/**
* Implementation of hook_hierarchical_select_implementation_info().
*/
function hs_taxonomy_views_hierarchical_select_implementation_info() {
  return array(

StatusFileSize
new4.67 KB

Thanks to gmilonas for that script. My colleague Tim decided to re-write it in jQuery and added support for vocabularies of any depth. Also note that if including the script in the View footer as suggested, make sure you select "Display even if view has no result", else the script wont get included on pages without any results.

Thanks to gmilonas for that script. My colleague Tim decided to re-write it in jQuery and added support for vocabularies of any depth. Also note that if including the script in the View footer as suggested, make sure you select "Display even if view has no result", else the script wont get included on pages without any results.
Attachment Size
views-exp-filter-hierarch-select.js 4.67 KB

I can't get this to work, care to give more instructions?
would be much appreciated.

Hi Allmighty,
As gmilonas said, you just need to insert this into the footer of your view, and update the line convertSelectElement($('#edit-category')); to use the ID of your select element (mine was called edit-category). You can either put the code inline, by wrapping it in <script></script> tags, or you can just put the file somewhere in your project, and have the script tag link to it i.e. <script src="/sites/all/themes/YOUR_THEME/js/views-exp-filter-hierarch-select.js"></script> (note that the script file was renamed when I uploaded it to have _.txt at the end, which you will need to get rid of).

Hi Allmighty,
As gmilonas said, you just need to insert this into the footer of your view, and update the line convertSelectElement($('#edit-category')); to use the ID of your select element (mine was called edit-category). You can either put the code inline, by wrapping it in tags, or you can just put the file somewhere in your project, and have the script tag link to it i.e. (note that the script file was renamed when I uploaded it to have _.txt at the end, which you will need to get rid of).

Thank you, i was able to get it working with your explanation.
And thank you Jackocnr for posting the code it saved me a lot of work.

#gmilonas

nice try. But in my case, after form submit. the select is reseted to original style.

Has anyone styled this hierarhical selects by js plugins? JS in #181 post works perfect, but when I add styling js, everything is crashes. Any thoughts?

FOLKS,

i really appreciate every effort to come up with some solution for this problem.

That said, i MAY remind what this issue is about: Port Hierarchical Select Taxonomy Views (for exposed filters in Views) to Drupal 7

To me it seems that this issue is becoming a forum for workarounds. So if someone wants to care for the original issue, they will have to read tons of posts and filter aut what's to the point. (Everyone that once had to do that knows: It's a major PITA.)

So i created #1758844: Workarounds for Hierarchical Select Taxonomy Views and ask to post everything there that is not about solving the original issue.

Of course the line is sometimes different to draw, so if some stuff from the workaround issue can help here i suggest you to link it in this issue's description.

Thank you for your cooperation.

Could someone email me the complete PATCHED module. I have tried a million and one ways to apply a patch and just gave up. I'm 100% anti linux so I don't even bother. Someone should just make a module that talks with the server and runs patches for you. My email is george.s.milonas@gmail.com. Thanks Guys.

if someone send me complete PATCHED module also
my mail is harsharuwan@gmail.com

In response to post 169 where your site broke, I got this too. If you look at the function on line 472 (this one):

function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
static $count;

It's missing a closing {

I think it should be further down but I just stuck one in under the "static $count;" and it got my site working again.

Views Hierarchical Taxonomy Filter

Views Hierarchical Taxonomy Filter extends Views with an option of using hierarchical taxonomy select in a capacity of the exposed filter.

The module adds to Views a special filter that enables selecting taxonomy terms of the specified vocabulary consecutively.

The selection considers terms hierarchy and uses AJAX for set of “select” type fields, in which a value of each next depends on the value of the previous.

It works in combination with other taxonomy filters, including the same filter, used for the other vocabulary

Heh, I thought you couldn't sell drupal modules...

Great, can someone buy and then distribute the above module for the rest of us please? :)

Not that $20 is a lot but imho its rather disloyal to the entire drupal community to sell that module you wrote when you have been getting ALL modules you have ever been using for free before... don't shit where you eat, just saying.

@ibuildit: I totally agree.

I've bought modules before, but they were insanely complicated ones that dealt with credit cards. $20 for something that was most probably stolen from the original code is just disgusting.

1. the code of Views Hierarchical Taxonomy Filter is 100% original.
2. davey_b, ibuildit , as i understand you 2 are working for food, right? it's ok, i'll publish this module for free, but you will work with me.. for free.. why not? This is free world...
3. if you read CAREFULLY this post, you will see that wim says "Hence nobody wants to sponsor it (so far at least). I don't want to spend >5 full days of my free time on it." So, we have a problem, one of most needed modules for taxonomy doesnt work becouse matainer dont have time to finish it. And he want money. MONEY.

Ok, we have a problem, but i have a solution and i have spend my time to found this solution and my time = money.

If you need to solve the problem with taxonomy filters in views, buy the module. If you want it for free, no problem, write your own solution or wait until wim will back.

Sorry for my english.

Kervi,
Does the Views Hierarchical Taxonomy Filter work with Better Exposed Filters? In particular, I would like to avoid having to press the APPLY button to activate the selections.

it works via drupal ajax system, and it looks exactly like hierarchical select. you can check the demo http://hs.u5444.krypton.vps-private.net.

If you mean, autosubmit, no, it doesnt play well with it due to ajax restrictions.

kervi, I hear what you're saying. The question is where do you draw the line? I think that is what people find difficult. I know you need to work to make money as we all do but the VAST majority of drupal code is free including core code so I don't think it's difficult to understand that people who spend their time writing code and then giving it away might feel a bit aggrieved that others build on that base and then charge for things.

Fair play to you though although for doing the work and getting it working. It does seem a bit of a risk though as it would seem that anyone can buy it and then give it away for free.

@kervi: "as i understand you 2 are working for food, right? it's ok, i'll publish this module for free, but you will work with me.. for free.. why not? This is free world..."
Yes, this is how Drupal community principally works. One creates a module, publishes it for free to help others, and save some time for them; afterwards, the module's users report issues (bugs, requests, etc.), and help solving them (for free!) with publishing patches, writing suggestions, etc.
Without any sentimentality, I think freeness and the open source mentality is what moves the Drupal community forward - no offense!!
Everyone works for earning money, but I think for the majority of the Drupal developers, publishing modules is not the primary source for that. But that's only my own opinion, you don't have to agree. :)

Status:Postponed» Needs work

I just applied the patch from #168 and saw a strange behavior. You can see a screencast here. There were some fatal errors:

Notice: Undefined index: expose in _hs_taxonomy_views_get_filter_label() (Zeile 682 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Undefined index: expose in _hs_taxonomy_views_get_filter_label() (Zeile 682 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Undefined index: vocabulary in hs_taxonomy_views_config_form() (Zeile 309 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Undefined index: expose in hs_taxonomy_views_config_form() (Zeile 317 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Trying to get property of non-object in hs_taxonomy_views_config_form() (Zeile 319 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Trying to get property of non-object in hs_taxonomy_views_config_form() (Zeile 326 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Notice: Trying to get property of non-object in hs_taxonomy_views_config_form() (Zeile 328 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy_views.module).
Exception: vid should not be empty in _hs_taxonomy_hierarchical_select_get_depth() (Zeile 1115 von /sites/al/modules/contrib/hierarchical_select/modules/hs_taxonomy.module).

There are also lots of coding issues in the patch but we can fix that later.

+++ b/UPGRADE.txtundefined
@@ -10,7 +8,7 @@
+ - Taxonomy Views support has **not** yet been full ported

There are tabs, should be spaces.

+++ b/hierarchical_select.moduleundefined
@@ -402,7 +407,7 @@ function _hs_process_attach_css_js($element, $hsid, &$form_state, $complete_form
-             'animationDelay'   => ($config['animation_delay'] == 0) ? (int) variable_get('hierarchical_select_animation_delay', 400) : $config['animation_delay'],

Why did you change the animation delay from 400 to 0?

+++ b/modules/hs_taxonomy.moduleundefined
@@ -566,7 +566,7 @@ function hs_taxonomy_hierarchical_select_params() {
+  // TODO: support multiple parents, i.e. support "save lineage".#

There is an unnecessary sign at the end.

+++ b/modules/hs_taxonomy.moduleundefined
@@ -998,6 +997,9 @@ function theme_hs_taxonomy_formatter_lineage($variables) {
+    throw new Exception('vid should not be empty');

You should uppercase the first character.

+++ b/modules/hs_taxonomy.moduleundefined
@@ -1096,6 +1111,9 @@ function _hs_taxonomy_hierarchical_select_terms_to_options($terms) {
+    throw new Exception('vid should not be empty');

You should also uppercase the first character.

+++ b/modules/hs_taxonomy_views.moduleundefined
@@ -444,7 +472,7 @@ function hs_taxonomy_views_hierarchical_select_item_get_label($item, $params) {
-  $current_view = views_get_current_view();
+/*  $current_view = views_get_current_view();
   if (!isset($count[$current_view->name][$item])) {
     $temp_view = $current_view->clone_view();
@@ -467,6 +495,7 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
@@ -467,6 +495,7 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
     if ($item != HS_TAXONOMY_VIEWS_ANY_OPTION) {
       // Get an array with all tids: the tid of the currently selected term and
       // all child terms.
+//      print_r($item);
       $term = taxonomy_term_load($item);
       $tree = _hs_taxonomy_hierarchical_select_get_tree($term->vid, $term->tid);
       $tids = array($term->tid => $term->tid);
@@ -475,7 +504,7 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
@@ -475,7 +504,7 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
       }
       $id = 'tid_' . implode('-', $tids);
-      $temp_view->display[$display_id]->handler->override_option('filters', array(
+/*      $temp_view->display[$display_id]->handler->override_option('filters', array(
         $id => array(
           'operator' => 'or',
           'value' => $tids,
@@ -503,59 +532,61 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
@@ -503,59 +532,61 @@ function hs_taxonomy_views_hierarchical_select_entity_count($item, $params) {
     else {
       // Disable the default value, otherwise the <Any> option will actually
       // filter by the default value.
-      $filter_id = $params['filter_id'];
-      $temp_view->display[$display_id]->display_options['filters'][$filter_id]['value'] = array();
-      $temp_view->display[$display_id]->handler->options['filters'][$filter_id]['value'] = array();
-      $temp_view->display['default']->display_options['filters'][$filter_id]['value'] = array();
-      $temp_view->display['default']->handler->options['filters'][$filter_id]['value'] = array();
-    }
-
+    //   $filter_id = $params['filter_id'];
+    //   $temp_view->display[$display_id]->display_options['filters'][$filter_id]['value'] = array();
+    //   $temp_view->display[$display_id]->handler->options['filters'][$filter_id]['value'] = array();
+    //   $temp_view->display['default']->display_options['filters'][$filter_id]['value'] = array();
+    //   $temp_view->display['default']->handler->options['filters'][$filter_id]['value'] = array();
+    // }
+
+//print_r($display_id);
     // Build the queries and collect the arguments.
-    $temp_view->build($display_id);
+    // $temp_view->build($display_id);
     // We only need the count query. We don't care about the actual fields or
     // order of the View.
-    $count_query = !empty($temp_view->build_info['count_query']) ? $temp_view->build_info['count_query'] : $temp_view->query->count_query;
-    $args        = !empty($temp_view->build_info['query_args']) ? $temp_view->build_info['query_args'] : $temp_view->query->query_args;
+    // $count_query = !empty($temp_view->build_info['count_query']) ? $temp_view->build_info['count_query'] : $temp_view->query->count_query;
+    // $args        = !empty($temp_view->build_info['query_args']) ? $temp_view->build_info['query_args'] : $temp_view->query->query_args;
     // Regenerate the query after we set the distinct flag for the nid field.
     // This unfortunately doesn't work, because Views doesn't create an
     // optimized count query when any of the fields have the distinct flag set.
     //$temp_view->query->fields['nid']['distinct'] = TRUE;
-    //$count_query = $temp_view->query->query(TRUE);
+    $count_query = $temp_view->query->query(TRUE);
     // Due to the above: sneak DISTINCT() in through a string replace ...
-    $count_query = str_replace("SELECT node.nid AS nid", "SELECT DISTINCT(node.nid) AS nid", $count_query);
+    // $count_query = str_replace("SELECT node.nid AS nid", "SELECT DISTINCT(node.nid) AS nid", $count_query);
     // Filter by node type if such a filter is configured in the view.
-    if (isset($current_view->filter['type'])) {
-      $node_types = $current_view->filter['type']->value;
-      if (isset($node_types)) {
-        $values = '';
-        foreach ($node_types as $key => $value) {
-          if (empty($values)) {
-            $values = '\'' . $value . '\'';
-          }
-          else {
-            $values .= ', \'' . $value . '\'';
-          }
-        }
-
-        // Use the same sneaky string replace trick once more.
-        $count_query = str_replace("WHERE", 'WHERE node.type IN (' . $values . ') AND', $count_query);
-      }
-    }
+    // if (isset($current_view->filter['type'])) {
+    //   $node_types = $current_view->filter['type']->value;
+    //   if (isset($node_types)) {
+    //     $values = '';
+    //     foreach ($node_types as $key => $value) {
+    //       if (empty($values)) {
+    //         $values = '\'' . $value . '\'';
+    //       }
+    //       else {
+    //         $values .= ', \'' . $value . '\'';
+    //       }
+    //     }
+
+    //     // Use the same sneaky string replace trick once more.
+    //     $count_query = str_replace("WHERE", 'WHERE node.type IN (' . $values . ') AND', $count_query);
+    //   }
+    // }
     // Apply the same query transformations as view::execute() does.
-    $count_query = db_rewrite_sql($count_query, $temp_view->base_table, $temp_view->base_field, array('view' => &$temp_view));
-    $count_query = 'SELECT COUNT(*) FROM (' . $count_query . ') count_alias';
+    // $count_query = db_rewrite_sql($count_query, $temp_view->base_table, $temp_view->base_field, array('view' => &$temp_view));
+    // $count_query = 'SELECT COUNT(*) FROM (' . $count_query . ') count_alias';
     // Execute the count query.
     // TODO Please convert this statement to the D7 database API syntax.
-    $count[$current_view->name][$item] = db_query($count_query, $args)->fetchField();
+    // $count[$current_view->name][$item] = db_query($count_query, $args)->fetchField();
   }
-
-  return $count[$current_view->name][$item];
+}  */
+  return 1;
+  // return $count[$current_view->name][$item];

When you comment it out you can remove it.

+++ b/modules/hs_taxonomy_views_handler_filter_term_node_tid.incundefined
@@ -23,17 +41,37 @@ class hs_taxonomy_views_handler_filter_term_node_tid extends views_handler_filte
+    // @TODO uncomment

Same as above.

+++ b/modules/hs_taxonomy_views_handler_filter_term_node_tid.incundefined
@@ -23,17 +41,37 @@ class hs_taxonomy_views_handler_filter_term_node_tid extends views_handler_filte
+//     $vocabulary = taxonomy_vocabulary_machine_name_load($this->options['vocabulary']);

Tabs!

+++ b/modules/hs_taxonomy_views_handler_filter_term_node_tid.incundefined
@@ -43,29 +81,27 @@ class hs_taxonomy_views_handler_filter_term_node_tid extends views_handler_filte
-      }
-      else {
+    } else {

It's right to put the else in a new line.

Status:Needs work» Needs review
StatusFileSize
new33.87 KB

I fixed the coding issues from above and after clearing cache and test and test and test it seems to work. I also removed the modifications in includes/views.js I think that was only for testing reasons.

With this patch applied the exposed filter works but we absolutely improve that.

StatusFileSize
new33.96 KB

This is the correct version, sorry.
UPDATE: Just want to mention that the new file isn't included in the patch. Will do this later.

StatusFileSize
new37.54 KB

Here is the patch with the hs_taxonomy_views_handler_filter_term_node_tid_depth.inc included.

@yannickoo: is this patch supposed to make hierarchical selects work with views? Because it isn't working for me and I'm kinda lost in the 200+ comments on this issue, most of which are about why Drupal is Open Source. Could you summarize the current status?

The workaround mentioned in #187 works fine btw!

Just apply the patch from #206 and add a new Taxonomy term: Term ID (The taxonomy term ID.) field then you can select Hierachical Select.

StatusFileSize
new34.44 KB

Here is an updated patch which also replaces views_object_cache_clear with ctools_object_cache_clear.

Status:Needs review» Reviewed & tested by the community

Status:Reviewed & tested by the community» Needs review

You cannot mark it as RTBC because it has lot of bugs. I'm still debugging this module.

Status:Needs review» Needs work

Sorry but I cannot work on this issue anymore. It costs to many time. Finally I bought the Views Hierarchical Taxonomy Filter module for $20.

It works for me and I don't know how to help you. Maybe there will be a new standalone module which brings you the functionality and hasn't the Hierachical Select dependency.

Sorry...

You can checkout the module here. Feel free to post patches and let us bring that module forward :)

I have tried the patch at #209, but I get this error message (the module is not working the way it should, it simply displays no results):

Notice: Trying to get property of non-object in hs_taxonomy_views_handler_filter_term_node_tid->init() (line 22 of /home/me/public_html/my_site/sites/all/modules/hierarchical_select/modules/hs_taxonomy_views_handler_filter_term_node_tid.inc).

Any idea ?!

Did you clear your caches?

@gridbitlabs

Clearing the caches does not help, same problem

Did you add the Taxonomy term: Term ID (The taxonomy term ID.) field? Only works with that.

@yannickoo

If you mean to the fields to be displayed, yes I did. I also add the Taxonomy relationship and choose the exposed filter field to be Taxonomy term: Term ID. Not working...

When you need it now you can use the module from #213.

@yannickoo

Thanks for all the help so far and thanks for the module at #213. It works as it should. However I had to remove the line:

$is_alone = FALSE; (line nr. 9) from the file views_hst_filter_handler_filter.inc

with that line in place, views displayed an ajax error (in views display settings page)

@yannickoo, so, you have stolen my code from codecanyon and published it for free.. nice..

That is absolutely okay....

No real surprise it's ended this way. I feel for you kervi but I thought this would happen sooner or later.

Seems that kervi opened a sandbox here on d.o.

yes, i'll publish the module and will try to promote it to full project.

it's my first time, so give me so time.

thank you.

@kervi: http://drupal.org/node/1170192#comment-6567154

9: Is it permitted for me to sell Drupal or a Drupal module or a Drupal theme?
Yes. However, you must distribute it under the GPL version 2 or later, so those you sell it to must be allowed to modify and redistribute it as well. See questions 6 and 7 above.

This doesn't mean that anyone "steals" your code.

By the way, thanks for promoting your module to a full project for free, and thanks for your efforts!

Yeah, thanks from me too for taking this forward as a free project. If you have a paypal account can you give payment details (I think that'll be an email address) and if I install it and use it I'll put $20 your way.

Thanks

From reading this - http://drupal.org/node/1832378

Kervi's sandbox is gone but ser_house's sandbox is still here as he originally built the module that kervi used from how I read the thread link above. So would be good to get some more reviews and feedback to ser_house to help him get his project completed and live.

This is the sandbox from the original author: http://drupal.org/sandbox/ser_house/1832320

Don't buy this code from codecanyon you're just getting ripped off.

@Wim Leers: You know we (the whole Drupal community) love you and wish you well on your fantastic new job, don't listen to people that have no idea of the massive amount of work you've done for Drupal (from code to volunteering at DrupalCons).

Let's all try to get @ser_house's application approved (follow link from #228), and maybe with time he can even help Wim maintain HS.

The module at #213 (posted by yannickoo), causes large amounts of data to be inserted into cache_form table, is there a way to avoid that? Thanks.

@Geir19 use http://drupal.org/sandbox/ser_house/1832320

If you find the same issue open an issue on the issue queue so we can track it and solve it.

@ipwa

Tried the one by ser_house, same problem exists

I think this needs to be passed to the hst form:

$form_state['no_cache'] = TRUE;

@Geir19 don't have time to test right now, can you please test it and if that does solve it, I'll open an issue and write a patch

@ipwa

The idea to turn off cache for the exposed form breaks the functionality of the module. The hst exposed form is based on Ajax and thus requires form cache to be on. Have a look at this peace of information from the Drupal 7 API documentation:

By default, $form and $form_state are built from scratch during each of these page requests. Often, it is necessary or desired to persist the $form and $form_state variables from the initial page request to the one that processes the submission. 'cache' can be set to TRUE to do this. A prominent example is an Ajax-enabled form, in which ajax_process_form() enables form caching for all forms that include an element with the #ajax property. (The Ajax handler has no way to build the form itself, so must rely on the cached version.) Note that the persistence of $form and $form_state happens automatically for (multi-step) forms having the 'rebuild' flag set, regardless of the value for 'cache'.

Back to problem, the strange thing is that each page navigation within a view using hst exposed filter produces two new entries inside cache_form table, one of them has a data BLOB size of 410KiB while the other of 3KiB... Do not you think that is much data making its way into the DB ?! Do you think that can be avoided ?!

So do we have a patch or module now that gives us this functionality? Has Kervi managed to get a module produced?

Kervi is out.

Ser_house is in. Please contribute to his sandbox module. Read comment #232

Status:Needs work» Closed (won't fix)

I think we can close this issue and refer to the issue queue from ser_house's sandbox which is currently in the application review process.

Thanks to all who helped with patches.

Status:Closed (won't fix)» Active

Temporarily reopening.

I stumbled upon #1831160: my code is stolen today and was quite shocked: #1831160-18: my code is stolen. Somebody who wanted to sponsor Views support for HS in D7 pointed me to http://codecanyon.net/item/views-hierarchical-taxonomy-filter/3000280, which led me there.

Is #1832378: Views hst filter the latest & greatest, meaning that the progress that was made got stuck there?


As some of you know, I started working for Acquia in mid-May (http://wimleers.com/blog/working-at-acquia), in the office of the CTO, on http://sparkdrupal.com. The Spark team got the Drupal 8 toolbar in, helped with responsive tables, in-place editing, and much more.

Feature freeze is coming up at Feb 18. After that, it should be possible to put some time in to get Hierarchical Select for D7 in good shape again, instead of the current sorry state of affairs.

As you all have noticed by now, Hierarchical Select is a very, very hard to maintain module. Even if only for the fact that it touches less stable areas of Drupal, where many modules are overriding the same stuff, so there's many potential cases for conflicts. Hence there's an endless sea of support requests. If you guys could help out with that, that'd be great. It'd be super helpful if we could clean out the issue queue, so that duplicates are merged into a single issue, simple support requests have been answered, etc.

Now, I don't know how much work this will be. Something like Kickstarter would definitely help, because this is going to be a lot of work. I had hoped that somebody would step up to co-maintain Hierarchical Select, but that has not happened. Alternatively, I had hoped that somebody would have stepped up to maintain e.g. just the Taxonomy integration. Or just the Menu integration. If somebody is interested in doing that, please step up now :)

Thoughts?

Hey Wim, thank you for your answer, nice to hear something from the maintainer. I bought the module from kervi and published it so that he don't get more money because it is very uncool to sell Drupal modules. As you can see here, ser_house is the original author, not kervi that means that kervi stole the code from ser_house. That is so crazy.
I really like kervi's comment.

Really sorry for all this story. Never again.

Sandbox deleted.

Views hst filter is the project which should be published on d.o because it doesn't work in the current version of HS. I also invested lot of time to get the Views integration working but it is to much like you said "Hierarchical Select is a very, very hard to maintain module".

#240: I'm fine if it's in a separate module, then we can have the *really* thorny issues/bugs/support requests in that separate project's issue queue :)

HOWEVER, I'm wondering whether having it in a separate module would really make things easier? If it works in a separate module, it surely can also work in Hierarchical Select? Or is the code full of hacks (I haven't looked at the code yet)? And what do you mean by " it doesn't work in the current version of HS"?

Views exposed filters doesn't work with HS Taxonomy. It shouldn't be in a seperate module but this is the current workaround.

I bought the module from kervi and published it so that he don't get more money because it is very uncool to sell Drupal modules. As you can see here, ser_house is the original author, not kervi that means that kervi stole the code from ser_house. That is so crazy.

I totally agree with both of you. It seems like kervi doesn't understand the meaning of "open source". He's happy to use modules created with huge efforts and published here on drupal.org FOR FREE, but he SELLS his own. He ought to be ashamed of himself. I think he still isn't (despite that he says theatrically "Really sorry for all this story. Never again."): he still sells his own stuff...
This mentality pisses me off.

Let's stay on track with the issue, please.

Let's not continue the witch-hunt here. Although you may not like what kervi is doing, you can not force anybody to give anything free. There are rules for GPL license. As long as somebody obeys them, he can do whatever he wants. Giving free is a very nice and respected behavior, but I cannot go further and say that the opposite is "ashaming", "crazy" or disrespectful.

kervi may be a lot of value to the community in the future. So, instead of pushing him out, showing him the ways of Drupal would be far better, which I think he already started to understand.

@Sinan Erdem : you're right. :)

Good point Sinan!

Okay, a small update: ser_house does not want to publish his module on drupal.org anymore. Stefan created a module, it's called Simple hierarchical select, just for anybody you are searching for an alternative :)

StatusFileSize
new47.7 KB

Thank you so much

@yannickoo : thanks for recommending this, it's cool that there's already an alternative! :) I hope it will work just fine. :)

please tell me how to make the field of the child term always disclosed with title- any even parent term is any

@maked1sky : is your question related to Views hst filter module?
If yes, ser_house deleted his module:
http://drupal.org/node/1832378#comment-6978606
don't ask me why, I don't know: he got mad when he was told he has to wait for a long time to get a full release, and he can speed up the process with making reviews of other modules, but he didn't want to... :)
So you have to get in contact with him on his own site or via the contact form to possibly get some support.
If his module will remain deleted, his module will soon be forgotten, and "Simple hierarchical select" will be pushed forward that yannickoo recommended. :) (http://drupal.org/project/shs)

my question is related to Simple hierarchical select
maybe someone knows how to make child term field is visible with value=any when parent term field is also any

@maked1sky : if it's about shs, why don't you post your question in a forum (here on drupal.org or Drupal Answers, etc.) or in the issue queue of shs, marking the issue as "support request"?

ok thank you

Can we close this issue now? Everything seems to be resolved.

To say: I LOVED IT.
BUT...
I had to change my level tree to a 3 level.
To bad this doesn't work for 3 levels.

#256: the aim of this issue is not reached so it will stay open.
please do not make this a forum and post support requests and issues for simple-hierarchical-select in their corresponding places.

like wim noted in #241 the cleanest thing now is to port back the shs fix to hs.

subscribe

More than 2 years and this hasn't been fixed yet?

It is a complex module Tim. Check out the Simple hierarchical select module :)

I think the correct question us: which of these modules is still maintained... as SHS is developed by 1 maintainer which refuses to extend that module, but HS is getting alive (kind of) after some long time

Issue summary:View changes

Updated issue summary.

subscribe

Issue summary:View changes

So can anyone tell me whats the actuall state of this? Is there a working solution for views filter with hierarchical select integration?

@kitikonti You had better try simple hiearchical select https://drupal.org/project/shs