Scalability improvements: stop using a normal select for graceful degradation

This is not preloading. This is for graceful degradation: when JS is disabled, that normal select is what you will see. Just give it a try ;)

And yes, that is a performance issue. But it's the default Drupal behavior, in both Drupal 5 and 6. I intend to fix this in version 3 of HS.

True!

If you would like to speed up Taxonomy *today*, then look at the http://drupal.org/project/advcache module. It has a Drupal core patch to add caching to taxonomy_get_tree(), which is what's used mostly to render this.

Also, if you would like to sponsor this feature, let me know. I'll have time to work on this in 4 weeks.

See http://drupal.org/node/191360.

Being worked on.

See http://drupal.org/node/226067, which has to be done first.

- it would allow me to use HS on 5.7

That's exactly what I'm working on.

- I could use db's of 10s or even 100s of thousands of items without jscript degradation causing pre-loading to happen in the source of the page: values to be taken only from db when required

Of course, that's exactly what the scalability issue is! :)

- there would be a usable way of importing these values into db without having to create them one by one in Taxonomy

Aha. Interesting question. That would actually be something completely independent from the scalability issue. And it would also be really easy to implement.
Please post a new issue (feature request) in which you explain this in more detail. I.e. do you want a UI to manage this, or just "generic code" to do this kind of thing, or specifically for a table layout of your own? In the latter case, you can send me an e-mail instead of posting a feature request, since it would be custom code just for you.

Timescale is difficult, since I'm actually on a vacation right now. But a couple of weeks would be the worst case timescale.

There's no written or unwritten protocol for attribution of sponsors. You can see how I do it at HS' project page: http://drupal.org/project/hierarchical_select; I list the sponsors chronologically, link to them and mention what feature they sponsored.
Only sponsors of major features are listed. So far, most sponsorships were for major features though, and this one would of course be a major feature too :)

As for the amount: I prefer payment by the hour. But let's deal with those details via e-mail :) You can contact me via http://wimleers.com/contact

Great news.

Subscribing

I've been working on this and it's working already. However, graceful degradation is *extremely* tricky. Or at least I have *no idea whatsoever* on how to do it. In Drupal 6, you have the #executes_submit_callback property for buttons, but in Drupal 5, there's no such thing.

I'm wondering if it would be acceptable to have no graceful degradation when JS is disabled?

I just talked to chx about this on IRC:

WimLeers: chx: is it possible to simulate the behavior of D6's #executes_submit_callback property for buttons in
Drupal 5? I'm working on the scalable parent select thing, but I need it in D5 too.
chx: WimLeers: that's xtremely hard
chx: WimLeers: you can do a #process on #type submit/button and then wiz from there
chx: WimLeers: instead of form_state['clicked_button'] you can use a global
chx: WimLeers: $form_submitted is a global
chx: WimLeers: so, #process on the buttons, and flip $form_submitted .... and another global.
chx: WimLeers: you need to pwn the #submit too
WimLeers: chx: ok, thank you very very much ;) :) Now let's see if I can get this rolling
chx: WimLeers: this is quite hard in D5
WimLeers: chx: and this won't require any core hacks, right?
chx: WimLeers: no this won't

Posting this for my own reference and to indicate the complexity.

No graceful degradation is fine with me because 94% of the browsers have JavaScript (JS) on by default. And each year it's increasing.

According to TheCounter & w3schools statistics 94% of the most popular browsers have JS on: http://www.thecounter.com/stats/2008/March/javas.php

http://www.w3schools.com/browsers/browsers_stats.asp

To solve the 6% JS off issue I simply added a free JS detection thingy to my webpage. If the JS is off a warning message offers 2 options:
1 – A link to a tutorial called “How to activate JS on your browser”. Google example: http://www.google.com/support/bin/answer.py?answer=23852
2 – A link to “Contact the webmaster for assistance” to do the above.

Please find attached screenshots.

I've been working a lot of this. The link esilou gave me was somewhat helpful, but not very. When I got going, #executes_submit_callback turned out to be the least of my worries.

I'm first focusing on getting everything to work nicely when JS is disabled, since that's what's needed for the scalability improvements anyway. So I'm rewriting the rendering system of Hierarchical Select completely from scratch. Everything will be done through Forms API now, instead of custom callbacks to the server, and the server responding with HTML. That's necessary if we want to have graceful degradation.
This also means the CSS is pretty much completely rewritten.

What this effectively means, is that in my #process callback, I'm no longer *just* changing #type to 'select' and adding some JS, but I'm expanding the element to *a lot* of elements. This is necessary, because all selected values have to be available to Drupal via normal POSTs, not through values collected/maintained by the JS. E.g. for each selection in the dropbox, I have to add some kind of form element to pass the data back to the server. Otherwise, you'd lose all the selections in your dropbox after each update or each time you remove an item.

A nice result is that >80% of the effort of porting this module to Drupal 6 is also done while working on that. Drupal 6's improved Forms API is likely to make lots of things easier to do, although I'm not 100% sure. E.g. the selections in the dropbox could simply be stored in $form_store.

When multiple select is disabled, everything already works nicely with an "Update" button when JS is disabled.
However, when multiple select is enabled (thus the dropbox is enabled), then things get much trickier. I have to do some really tricky processing with the values in $element['#value] and check which button was clicked. Also, I can no longer use the "Remove" links for each of the selections in the dropbox, since links don't submit forms in plain HTML. So I have to make buttons out of it. But, I need unique button names to identify which one was clicked (also a Drupal 5 limitation). So I might have to turn to checkboxes in combination with a single "Remove" button.

Currently, I'm working on getting the "Add" button to work properly.

And when all of that is working nicely, I'll have to pretty much completely rewrite the JS, since the inner working is completely different. There used to be *one* select that was defined using Forms API, and everything happened on that single one item. Right now, I've got these Forms API elements:
- a separate select for each level of the current hierarchical select (n items)
- a separate hidden input for each selection in the dropbox (n items)
- several wrappers to simplify the CSS and JS
- a table for the dropbox (I still want to make it FAPI-rendered)

One of the other benefits of all this work is that lots of logic will be moved from the JS to the PHP code, thus from client-side to server-side. Previously that wasn't necessary, because the degradation was much dumber (a single multiple select appeared to the user).

Sorry for the extremely long post, but lots of things have happened:

>: diffstat get_stats.patch 
 hierarchical_select.css    |   46 ++--
 hierarchical_select.js     |   84 ++++++--
 hierarchical_select.module |  434 +++++++++++++++++++++++++++++----------------
 modules/taxonomy.inc       |    3 
 4 files changed, 383 insertions(+), 184 deletions(-)

The "Update" and "Add" buttons are both working perfectly. I've had to some Forms API trickery to get all of this working properly, but it's working, with no super ugly hacks (just tricks). Just the way we want it.

The server-side logic for all of this has become clean, too.

More updates to follow later.

About the "AJAX capable dropdown menus" I found the following for you Wim. With code source & some with demo. Hope this help.

• Ajax Triple Dropdown with States Cities Database
  • Demo 2 dropdown menus
  • Code source 2 dropdown menus
  • Code source 2 dropdown menus (mirror)
  • Code source 3 dropdown menus
  • Code source 3 dropdown menus (mirror)
  • Homepage

• Massive AJAX Country/Area Drop-down List
  • Demo
  • Code source
  • Homepage

• Populate triple drop down list from database using Ajax and PHP
  • Demo
  • Code source
  • Homepage

• Create AJAX Dynamic Drop Down List using PHP - xajax
  • Homepage Teaser
  • Homepage Full (Free registration)

• PHP - Dynamic Drop Down Menu
  • Homepage

About the "graceful degradation" (Dropdown menus working with or without javascript) I found the following.

• recordingjunkie [Nice AJAX capable dropdown menus working with or without javascript]
  • Demo (SELECT CLASS then click FILTER CLASS button)
  • Code source (Spread over a three pages post)
  • Post

• Drop Down Menu Without Javascript
  • Post

Thanks again, onopoc, but you really can stop providing these examples. I *know* what I have to do, and I'm working on it!

Wim: My intention was to help & contribute to your project. Are you saying that you DO NOT welcome help & contribution from the Drupal community?

Other question, if we found more similar projects working with and without javascript (dropdown menu with graceful degradation) such as this demo. Do you want me and esllou to stop providing them?

Onopoc: I appreciate that you're trying to help. However, you've posted essentially the same information as in the Location field issue queue. So it was redundant. Plus, I had already said that I understand what you're saying (*repeatedly*!), and I've said the same here again.

I do appreciate helpful comments. esilou's comment was relevant, somewhat helpful and to-the-point. Your post was relevant, not helpful (I told you many times by now that I already knew what you were saying) and extremely long (i.e. not to-the-point). These kinds of posts are con sidered "noise" by the community and thus are not welcomed with open arms. And trust me when I say that I've been answering very patiently.

So, again: thanks for your efforts, but they are in vain: I already know what you are trying to explain to me.




esilou, onopoc, others: major progress:
- the rendering is now 100% Forms API driven
- all previously available functionality is working when JS is disabled

To do: rewrite the JS. This will also be a complete rewrite, but luckily the JS will get a lot smaller, rather than bigger this time. This is because much logic that previously only existed when JS was enabled (and thus in the JS), now also works when JS is disabled (and thus in the PHP code). The only major trouble left is figuring out how to generate a part of the form (to render it, to answer requests to the server from the JS). That's probably for tomorrow.

To explain the amount of changes again through diffstat (this shows how much logic has been moved to server-side code):

>: diffstat get_stats.patch 
 hierarchical_select.css    |   86 +++--
 hierarchical_select.js     |   84 ++++-
 hierarchical_select.module |  695 +++++++++++++++++++++++++++++++++------------
 modules/taxonomy.inc       |    3 
 4 files changed, 640 insertions(+), 228 deletions(-)

Wim: Thanks about the “noise” definition. I learned a new term today. I’ll work on that. Next time I’m trying to clarify a misunderstanding I’ll keep it short and to-the-point. That answered my first question, thanks again.

I don’t understand the answer to my second question though, so I’ll take it as a YES: YES if we found more similar projects working with and without javascript (dropdown menu with graceful degradation) such as this demo stop providing them.

I think we have a communication problem. We both don’t understand each other.

Good luck with your project.

Kind regards,

In this case, the answer to your second question is indeed "yes", as in: "yes, please stop providing AJAX dropdown examples". However, that's just because I already know what I have to do.
In general, I would gladly welcome examples. As long as you keep the describing text short and to-the-point :)

There's only one problem in the communication between us: you suffer from a "disease" I like to call "feeling-forced-to-write-down-every-detail". I suffered from that too. But it's really important, especially these days, that you can get your message across in the shortest amount of text possible. That's why advertisers have short lines.

I just found these excellent guidelines on how to write e-mails, and I think they apply here and everywhere else, too: http://webworkerdaily.com/2007/10/05/7-rules-for-communicating-clearly-a.... I will refer others to these guidelines in the future, too. Because you're not the only one :)

Thanks for the guidelines Wim. Excellent guidelines indeed. I have to work on the 2 first points and the third: “Write about only one thing”, “stick to one subject, with one request. Once that’s done, send a second one, to not overwhelm the recipient.”

You misunderstood my second question. My question isn’t about “AJAX dropdown examples” but about “projects working with and without javascript (dropdown menu with graceful degradation)”.

Sorry about that I should have asked only one question in this post. Once that’s done, send the second question, to not overwhelm the recipient.

Onopoc: you're welcome! :)




esilou, onopoc: everything is done, including 70-80% of the JS rewrite, except the AJAX refreshing (that's the remainder of the JS). I have to rebuild the form in case of an AJAX request to the server, and that's … problematic. It's simply not supported in Drupal 5. It's easy in Drupal 6. I probably need to simulate the #multistep feature in such a way that I can rebuild the form only when a hierarchical select occurs in that form. I'm trying to get some advice from Forms API experts right now.

As soon as I know how to rebuild the form, it's about an hour of work.

I've been advised to contact quicksketch about this. He's the one who did the most work (correct me if I'm wrong, but he at least helped a lot) in bringing the #ahah property to Drupal 6.

While awaiting his response, I've decided its' better to post a patch of what I currently have, so you can already start testing. A couple of notes:
- hierarchical_select_json() in hierarchical_select.module is the only function on the server side that still needs work.
- this means *none* of the AJAX updates works currently.
- and that means that for testing of the functionality, you should disable JS for now. This way, you can also verify that the graceful degradation works as it should.

So I'm marking it as CNR. I *don't* expect code reviews (you of course may do that), only functionality testing.

I've attached both the patch and a .zip of the new module.

I've attached 2 screenshots: one in which JS is disabled, one in which it's enabled.

I’ll do functionality beta testing and let you know when it’s done.

Wim: we spoke via email. I would like to sponsor a small part of those new features.

Drupal community: If others want to do a joint sponsorship you’re welcome. Wim can be contacted via his contact form at: http://drupal.org/user/99777/contact

I forgot to mention that you have to install the jQuery Form module, Hierarchical Select now depends on it. See http://drupal.org/project/jquery_form.

Wim: Here are the functionality beta testing results:

PASSED: Firefox 2.0.0.13
PASSED: Safari 3.1
PASSED: Opera 9.22
PASSED: Internet Explorer 7.0.5730.11
PASSED: 10 levels deep taxonomy with all the above browsers

All with JS deactivated and Windows XP. See attached screenshots (PASSED_3_levels.jpg & PASSED_10_levels.jpg).

The 2 fallowing aren’t bugs but proposed functionality improvement. To reproduce set:
Home › Administer › Content management › Categories › Edit vocabulary > under "Hierarchical Select settings" > "Save lineage" > "save only the deepest term".

1. If user select: "BMW > 7 series > 714i" (See “imp1_step_1.jpg”). But change is mind and select: "BMW > 3 series" He doesn’t touch the “714i” who was already selected. Then click “Update” button (See “imp1_step_2.jpg”). The level 2 change for “7 series” but it should reads “3 series” (See “imp1_step_3.jpg”).
2. If user select: "BMW > 3 series > 325i" (See “imp2_step_1.jpg”) But change is mind and select: "BMW > 3 series > BLANK" (See “imp2_step_2.jpg”). Then click “Update” button (See “imp2_step_2.jpg”). All selected items disappear (like a reset). It should reads “BMW > 3 series” (See “imp2_step_3.jpg”).

Reproduced both. Both are indeed problematic. Thank you very much for the testing. I'll work on improving these.

I think I've already fixed it. The problem was that I was just taking the value of the last select. But I didn't validate the hierarchy these selects represented: I should pick the value of the last select up until which the hierarchy is valid.
I've also added the jquery_form dependency to the .info file.

Please try the new version.

Great Wim both improvements are working will all 4 browsers. You're welcome for the testing.

I've currently got a vocabulary that is 5 levels deep and contains roughly 10,500 terms. I'm obviously not using it on a prod site, but I'd really like to... which is why I'm interested in this thread. I run into critical javascript performance issues when using Hierarchical Select due to it loading every single term in the taxonomy into the page, regardless of which level you are currently browsing. The same issue occurs with Wim's patched version. I was under the impression the issue was to change that behavior - did I misread that?

I'm not sure what you're doing, but unless your *root level* (i.e. the first level of your vocabulary, the one that has no parents) is enormous, this simply cannot happen. As long as you keep the first level at a reasonable size, say a couple hundred maximum, and each child level also (i.e. the level below the term "foo" and below the term "foo>bar", and so on), you should no longer face any scalability issues.

Note that the JS is not yet working. You should disable JS for testing. Otherwise you'll be waiting forever for an update to happen :)

Ah - this was my mistake. I hadn't correctly removed my release-version of the module before using your patched version. Sorry for the bother! This looks great, Wim, and definitely solves our use case.

Due to lack of reply of the Forms API masters, I started doing it my own way, and it's working. I'm pretty sure it's as clean and good as it gets in Drupal 5. It will involve installing an extra DB table, but only for storing temporary values.

The updated patch will probably land tomorrow night.

For completeness, several other issues have been solved/simplified by this patch as well:
- The option prevents scalability (http://drupal.org/node/239452): fixed
- Scrolling Select box option. (http://drupal.org/node/212014): will be super easy now
- Ability to set start value of the hierarchical select (http://drupal.org/node/229586): will be easier

Slightly later than planned, but here it is: the new patch. Dynamic updates are fully working, the value returned by hierarchical_select form elements are valid now and the JS code has been polished up and was tested in Safari, Firefox and Internet Explorer.

The patch is truly massive now. 92.71 KB. That's the same size as the Registry patch!

>: diffstat scalability.patch 
 hierarchical_select-rtl.css |   86 ++
 hierarchical_select.css     |   86 ++
 hierarchical_select.info    |    2 
 hierarchical_select.js      |  513 ++++-------------
 hierarchical_select.module  | 1275 +++++++++++++++++++++++++++++---------------
 modules/taxonomy.inc        |   24 
 6 files changed, 1112 insertions(+), 874 deletions(-)

I need people to:
- verify that it works with node taxonomy forms as expected (i.e. with various settings)
- test the CSS cross-browser. It seems it works pretty well in Opera now, but now there are problems in IE: the selects don't always float to the left properly. And the dropbox table's border is absent (but that issue already existed in the previous version of HS). I'm no CSS expert, so help from cross-browser CSS wizards is most definitely welcome.
- test the JS cross-browser. I tested a lot in Safari, there it works flawlessly. Basic testing in FF and IE seem to be working as well.

I expect that there's still the necessary heap of cross-browser JS issues. Hopefully it'll be easy to fix.

Almost forgot: this new patch requires HEAD of the jQuery Form module. You can either check that out via CVS yourself, or use the .zip I attached here.

For both you can just use the attachment (the .zip's). I'm providing patched versions because that means less work for you guys! :)

Wim, thanks for the massive update.

In my testing environment (18,000 terms) this works great except for three things:

1) after choosing another term -- the items fade out but do not fade back in. After a few choices the options are completely hidden.

2) when editing a node tagged with a term from the top level of the taxonomy this error is reported:
warning: end() [function.end]: Passed variable is not an array or object in /Applications/MAMP/htdocs/devsite/sites/all/modules/hierarchical_select/hierarchical_select.module on line 280.

3) when saving a node (with a change in taxonomy or not) these errors are reported:

    * user warning: Duplicate entry '1-10289' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (10289, 1) in /Applications/MAMP/htdocs/devsite/includes/database.mysql.inc on line 172.
    * user warning: Duplicate entry '9897-0' for key 1 query: INSERT INTO term_hierarchy (tid, parent) VALUES (9897, 0) in /Applications/MAMP/htdocs/devsite/includes/database.mysql.inc on line 172.

This was tested using Mac Firefox 2.0.0.13

Thanks again for an awesome module and thank you for posting the patched version of the module - this does save a lot of time.

1) Can you go to http://wimleers.com/demo/hierarchical-select and tell me if this happens there as well? This does not happen in Safari, Opera and IE 6.

2) Ok, should be an easy fix.

3) Now that's odd. This is one of the very things I tried to fix. Are you 100% sure that this occurred after testing with the new patch?

1) The fade problem does not happen at http://wimleers.com/demo/hierarchical-select
2) Thanks
3) I'll double check

My development environment has been punished with a lot of testing. If these errors do not resolve I'll create a fresh environment and test again.

Thanks.

1) Ok thanks. Then I know this problem was introduced in the new JS. Strangely, the part of the JS that handles this was left virtually unchanged (only the selector has changed, due to changes in the HTML structure).

I've installed a fresh copy of Drupal 5.7,jQuery Form Plugin (HEAD), JQuery Interface Library 5.x-1.0, JQuery Update 5.x-1.0, Hierarchical Select (v3)

Created a three level taxonomy.

Problem #1 - "fade in not working" appears for Mac Firefox 2.0.0.13 but does not have a problem with Mac Safari Version 3.1 (5525.13)

Problem #2 - you're on it

Problem #3 - add node, select a term, save node - this error is reported:

user warning: Duplicate entry '1-2' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (2, 1) in /Applications/MAMP/htdocs/drupal-5.7/includes/database.mysql.inc on line 172

3) Please post a screenshot of all the Hierarchical Select settings. I have been unable to reproduce this.

Thanks for taking the time to set up a new testing environment!

Patch updated. All problems have been solved!

I can confirm that in my setup all problems are solved for both Mac Firefox and Mac Safari.

Thanks Wim!

Esllou, it looks like your javascript is not getting loaded or is turned off. View the source of your html page - you should see this file in the list of .js files:

/sites/all/modules/hierarchical_select/hierarchical_select.js

Also, try refreshing your browser to flush out old cached javascript files.

Are you sure that you don't have a Javascript error of some sort?

Excellent. You've installed it properly then I think. But that doesn't help me find the solution :P

Perhaps it's only the Remove link and Add button, I've seen that happen here as well when I had firebug enabled. Do you have another computer where FF is "clean", i.e. no extensions installed? I'll have to solve it nevertheless, but that'd help narrow down the cause.

Which browser? FF with Firebug? Please verify that it's also failing in another browser, especially in Safari.

You can download Safari for Windows :) However you didn't try it in FF *without* Firebug either. Please test that as well, I'm sure you have some other computer somewhere.

I already suspected the problems only arise with the "Remove" link and "Add" button. I've seen that happen here as well.

It's by design that everything greys out when it's loading. That's to indicate that it's loading.

The oddity you describe, is perfectly normal. There are some pretty complex algorithms going on to construct the necessary hierarchies for the user to select. But it also validates hierarchies. So if you are changing the way the user can select a hierarchy, it's possible that terms saved with a previous configuration of HS will no longer be displayed/added, since they're no longer valid in the current settings.

esllou: Same thing happened to me it’s user error though. To solve this issue I type in anything in the fields “Title” & “Body”. Then I click the "Add" button.

Wim: AJAX works. It's awesome. Super fast loading with large taxonomy.

esllou: It's a great idea to record video. Much easier and faster than screenshots. I'm using a free one from camstudio.org

Wim: Here are the HS (from post #49) beta testing results:

1. NOT PASSED: Firefox 2.0.0.13

• When clicking "Add" button selection aren't display into dropbox. I confirm esllou issue #64

All with JS activated and Windows XP.

To reproduce please find attached videos & setting screenshots.

Testing with modules:

• hierarchical_select (from post #49)
• jquery_form (from post #40)
• jquery_interface 5.x-1.0
• jquery_update 5.x-1.0
• cck 5.x-1.6-1
• view 5.x-1.6
• content_taxonomy 5.x-1.x-dev

Ok, plenty of testing now. Thanks! I'll work on this ASAP, probably tomorrow.

I upgraded to the HS module from #49, installed the jquery form from #40, ran update.php, didn't do the patch (that's correct right)?

And now it's not working at all. It was reporting that I didn't have JS on, but I did but then I remembered in #36 that you said JS wasn't working....is that still correct?

I turned JS off in my browser, it removed the errors of coruse but now you can't select any sub-terms....so what's the point?

I was directed here by Wim from http://drupal.org/node/243748. So I followed these instructions in hopes of a fix to my problem (even tho it wasn't mentioned/addressed here).

What should I do? Go back to the other version? Or hold tight for the next update here...?

Many thanks - I was pumped after getting as far as I did with the previous version, I'm sure it'll only get better!

Wim. Can you please post an update to the API.txt? Specifically, the recommended structure of the form array for integrating with a taxonomy vocabulary:

This is the API suggestion

  $form['select_some_term'] = array(
    '#type' => 'hierarchical_select',
    '#title' => t('Select the tag you wish to use.'),
    '#options' => $options, // Contains an array of tid - term name pairs.
    '#hierarchical_select_settings' => array(
      'module' => 'taxonomy',
      'save_lineage' => FALSE,
      'enforce_deepest' => FALSE,
      'all_option' => FALSE,
      'level_labels' => array(
        0 => t('Main category'),
        1 => t('Subcategory'),
      ),
      'params' => array(
        'vid' => $vid,
      ),
      'animation_delay' => 400,
      'dropbox_title' => t('All selections:'),
      'dropbox_limit' => 0,
    ),
    '#default_value' => '83',
  ); 

This is the code I'm trying to get to work for a two level taxonomy
I noticed that the module is now named 'content_taxonomy' and the params has a depth value - are these correct changes? All I see is the "Submit" button but no options.

   $tree = taxonomy_get_tree(4,0,-1,2);
  foreach ($tree as $term) {
    $options[$term->tid] = $term->name;
  }

  $form['select_some_term'] = array(
    '#type' => 'hierarchical_select',
    '#title' => t('Select a Destination and then an Activity'),
    '#options' => $options, // Contains an array of tid - term name pairs.
    '#hierarchical_select_settings' => array(
      'module' => 'content_taxonomy',
      'save_lineage' => FALSE,
      'enforce_deepest' => FALSE,
      'all_option' => FALSE,
      'level_labels' => array(
        0 => t('Select a Destination'),
        1 => t('Select an Activity'),
      ),
      'params' => array(
        'vid' => 4,
        'depth' => 1,
      ),
      'animation_delay' => 400,
      'dropbox_title' => t('All selections:'),
      'dropbox_limit' => 0,
    ),
    '#default_value' => '38',
  ); 

  $form['submit'] = array(
    '#type' => 'submit', 
    '#value' => 'Submit',
    );
  
 return $form;

mdowsett: please see http://drupal.org/node/243748#comment-807078.

@jpsalter: funny enough, I just did that without reading your request :) Only 2 things have changed:

1. The all_option setting is gone.
2. You no longer have to set #options. Hierarchical Select now does this automatically. See "3)" in API.txt.




@esilou, onopoc: the issues in Firefox and Opera have been solved!



@esilou: your MySQL error that was being caused by Hierarchical Select has been fixed as well. It was because the array of term ids was not unique.



@all: I've fixed several other issues as well:

• If you would have tried to place multiple Hierarchical Selects on the same form or page, it would have failed. That's fixed now.
• When at least one item was added to the dropbox, the default selection in the hierarchical select was the root level label instead of "<none>".
• The #after_build callback was being added to every form instead of just the forms that contain a hierarchical_select form element.
• The RTL CSS was not yet updated with the LTR CSS' latest changes.
• Code documentation wasn't 100% up-to-date yet.

Only one problem is not yet fixed: the CSS issues in IE6 and Opera. However, that should change soon too: I've helped EclipseGc with some Drupal 6 AHAH forms issues, and in exchange he's going to give his best shot at fixing the CSS.

This will be the final testing round. You can ignore CSS issues in your testing, they will be tackled in a follow-up patch.

Wim: Here are the HS #71 beta testing results with SAVE ONLY THE DEEPEST TERM:

• Issue #66 with firefox is fixed. It's working fine now: When clicking "Add" button selection aren't display into dropbox.
• Firefox, Safari, Opera, Internet Explorer:
  • ISSUE: Required* setting isn't working. Warning message isn't showing. User should see "The field X is required"

To reproduce please find attached video & setting screenshots.

Tested with:

• hierarchical_select (from post #71)
• jquery_form (from post #40)
• jquery_interface 5.x-1.0
• jquery_update 5.x-1.0
• cck 5.x-1.6-1
• view 5.x-1.6
• content_taxonomy 5.x-1.x-dev
• JS activated & Windows XP

Testing results with SAVE TERM LINEAGE, Multiple values DEACTIVATED:

• Firefox, Safari, Opera, Internet Explorer:

• ISSUE: User select items, click SUBMIT then message "The field X is required".

To reproduce please find attached video & setting screenshots.

Tested with same as post #72.

Testing results with SAVE TERM LINEAGE, Multiple values ACTIVATED:

• Firefox, Safari, Opera, Internet Explorer:

• ISSUE: User click SUBMIT > EDIT content > Dropbox is empty.

To reproduce please find attached video & setting screenshots.

Tested with same as post #72.

Wow, thanks for the fast testing!

#72 & #73: nice find. Both are easy fixes.
#74: this is a non-issue, it only happens if you enable the dropbox for a vocabulary which had completely different settings (e.g. dropbox disabled and save lineage disabled). There's no sane way to "fix" that. You simply have to make sure you get your settings right the first time.

New patch soon.

Patch updated. #72 and #73 should be fixed.

Subscribing, greetings, Martijn

Wim: You're right #74 isn't a issue but user error. #72 & 73 are indeed fixed. Thanks Wim.

Here are the HS #76 beta testing results with SAVE THE TERM LINEAGE SAVE ONLY THE DEEPEST TERM, Multiple values ACTIVATED:

• Firefox, Safari, Opera, Internet Explorer:
• ISSUE: With 3 HS in the same page when user edit page saved items aren't all showing in dropboxes.

To reproduce please find attached video & setting screenshots. Video was to big so I split it in 4 parts. Files VideoSafariz01.zip, VideoSafariz02.zip, VideoSafariz03.zip must be unzip before unzipping file VideoSafari.zip.

Tested with same as post #72.

It was not when "save only the deepest term" was enabled, but when "save the term lineage" was enabled. The reason: a typo. Argh!

Other than that, only one comment has been updated. So, with only this final issue remaining, I decided to commit this. You guys have done excellent testing work, making it ready to be committed really fast. Thanks for your efforts!

For the sake of completeness, I've attached the final patch and .zip for your very final round of testing. All that's left are the CSS issues, then it's ready for consumption. This will be one of the major new changes in HS3. The others major feature will be the ability to create new items in the hierarchy. And several other, smaller things, of course.

Thanks!

Wim: That was a quick update. You're burning rubber (joke).

I have corrected the typo in #78. Thanks for pointing this out.

You're welcome for the beta testing.

Wow you guys are rockin...

Can't wait to try it out...

Hi Wim, Onopoc, Neil, thanks a lot for this great functionality!
I will implement it this week in my site used in Nepal to get rid of the performance issue.
Wim, great you are going to implement http://drupal.org/node/200285 soon after this.
This way the functionality I have right now, not performing, will be the same with HS hopefully performing!

greetings,
Martijn

O.k. So I've uploaded the newest release... And It's not working well for me in any browser... Firefox, Safari, or I.E. The problem is... It's only showing the terms for the root level... as soon as I choose a term from the root level it doesn't update to the 2nd level... If I click add... it seems to be acting as though I've chosen submit on the bottom of the node/add page... displaying an error that required fields must be filled out... I have all required modules installed and have run update.php... hope that helps

Daryl

I'm also getting this error on the pages that HS is being used as an exposed filter in the view...

warning: array_unique() [function.array-unique]: The argument should be an array in /home/content/m/r/b/mrbidster/html/sites/all/modules/hierarchical_select/hierarchical_select.module on line 567.
warning: Cannot use a scalar value as an array in /home/content/m/r/b/mrbidster/html/includes/form.inc on line 855.
warning: Cannot use a scalar value as an array in /home/content/m/r/b/mrbidster/html/includes/form.inc on line 859.
warning: Cannot use a scalar value as an array in /home/content/m/r/b/mrbidster/html/includes/form.inc on line 861.
warning: Cannot use a scalar value as an array in /home/content/m/r/b/mrbidster/html/includes/form.inc on line 859.
warning: Cannot use a scalar value as an array in /home/content/m/r/b/mrbidster/html/includes/form.inc on line 861.

and just for icing on the cake... Taxonomy subscriptions are displaying as a normal select instead of a HS Element... Hope I haven't given you a headache... Thanks for all of your fine work Wim...

Daryl

#83: are you sure you have installed HEAD of jquery_form? Download it here: http://drupal.org/files/issues/jquery_form%20HEAD.zip

#84: I'll fix tat

#85: Well, I didn't test that at all, so it's possible there are still problems with Taxonomy Subscriptions. However, it's impossible that there are normal selects there: normally there are checkboxes there, and the new HS never degrades to a normal select. So I think you haven't installed it properly. Also, please open a new issue for these problems. This issue is long enough as it is! Thanks.

Wim: The new HS from post #79 as indeed fixed the issue #78. It's working fine now. Thanks.

Below attachments are for comparison between posts #87 & #88.

Wim: Here are the HS #79 testing results with Firefox, Safari, Opera, Internet Explorer:

ISSUE: With 2 HS in the same page but using different vocabularies, when user click SUBMIT button warning message shows:

user warning: Duplicate entry '1-15' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (15, 1) in .../includes/database.mysql.inc on line 172.

user warning: Duplicate entry '2-15' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (15, 2) in .../includes/database.mysql.inc on line 172.

When 2 HS are in the same page and use the same vocabulary it's working fine (#87). But when 2 HS are in the same page but are using 2 different vocabularies the submitted page shows a warning message (#88). To reproduce please find videos & setting screenshots attached to posts #87 & #88.

Testing with:

• Drupal 5.7 fresh install
• hierarchical_select (from post #79)
• jquery_form (HEAD from post #86)
• jquery_interface 5.x-1.0
• jquery_update 5.x-1.0
• cck 5.x-1.6-1
• view 5.x-1.6
• content_taxonomy 5.x-1.x-dev
• JS activated & Windows XP

I've tested out a CVS checkout of HEAD, and it's working great. Are there plans to add the hierarchical select widget to the add / edit term select box for parent term? If not, shall I take a stab at it?

onopoc: I'll fix that as soon as I've got time.

jrbeeman: yes, those plans exist: http://drupal.org/node/200285!