HS doesn't work inside subforms

Version 2 is no longer supported. Please install the current 3.x-dev tarball. The current tarball has been given a lot of testing and should be very stable. IIRC, we also tested if the required field validation works, and it does.

I'm not sure what kind of manipulations the nodeprofile module does, so it's possible that your taxonomy data is not being saved. But that doesn't mean HS is not working properly, it's an indication that nodeprofile makes changes to the taxonomy part of the form (since it works fine for all other node types).

Because you didn't install the jquery_form module HS 3 depends on… :) You have to use HEAD of jquery_form too. Either use CVS or this .zip: http://drupal.org/files/issues/jquery_form%20HEAD.zip.

HS 3 no longer depends on jquery_form, which should simplify your testing. Please let me know something!

More than 2 week without no response. Closing. Feel free to reopen!

I' m experiencing the same problem with 5.x-3.0 RC2.

The problem is a strange interaction between hierarchical_select and nodeprofile. The user_register page is built using _user_forms and not just drupal_get_form(), and thus when hierarchical_select tries to recreate the form from within JSON, it doesn't rebuild properly. To further complicate things, if I try to forcefully build the form from within form_alter, nodeprofile uses the subform_element module, and thus doesn't really create the form until it is rendered, and _hierarchical_select_get_form_item() never finds the element.

Very interesting. The issue I'm having with exposed filters, HS, and SavedSearches is with a filter on a node-profile CCK Content Taxonomy field. I wonder if there's any link...

Does this mean CivicActions is looking into using Hierarchical Select? :)

I can imagine a work-around is possible for the _user_forms thing. But if the subform_element module only creates the form at render time (I'd guess that's an #after_build callback), then that becomes … hard, not to say virtually impossible.
These problems (HS and subform_element needing #after_build) are indirectly being caused by some limitations (or even design issues?) FAPI has, so it's possible that the only way to fix this in a sensible way, is by improving FAPI.

I absolutely don't have the time to develop a solution/work-around for this, so I'm afraid you'll have to do that yourself. What I can do, is answer possible questions regarding HS or a possible solution.

sdsheridan: let's focus on getting it to work for nodeprofile first!

Well,interestingly enough, for data entry, it does work on my node profile. Not sure what that means...

shawn

CivicActions is using HS on a couple sites.

I was hoping that you would know the fix for this easily. I spent a couple hours diagnosing it. For now, I've just removed the taxonomy from the user/register page (using form_alter), and leaving it on the user/$uid/edit page (where it works).

If you have some suggestions on how to fix it, it's possible that I'll have time to work on, but no guarantees.

A BIG thank you to fago – whom is by the way a really nice guy – because he didn't mind sitting together to find the cause. We're both using the Forms API in very tricky ways, so it's really hard to find out on your own where it's going wrong. Sitting together looking at each other's code really did speed this up a lot.

Yes, the positive tone in this post does mean that this has been fixed!

Awesome! Is the fix in HS or nodeprofile? And is the fix in dev or rc3?

The fix is in HS, in 3.x-dev.

I read this and got very excited to use 3.x-dev... and the problem seems to have come back in the latest dev release (released on 9/21).

To reiterate - I've attached a Hierarchal Select field to a custom content type being used as a Node Profile. Everything works fine if I go to the Create Content page, however on the User Register form (which is included via Node Profile and Subform), the Hierarchal Select widget fails to show me the second level of my taxonomy. Firebug is reporting no Javascript errors. I've gone back to the rc3 version for now. Any idea what has changed from when this was fixed before? Or, better yet (at least for me), any hope for a patch to the rc3 release that fixes the Subform issue?

It doesn't appear fixed for me in rc2 or in rc3, yet I have the exact situation reported by phacts. No javascript errors. The first level hierarchy is displayed. But when I select it, it grays out, then ungrays out, and nothing else happens, the second level hierarchy is not displayed.

Get the dev release, this was fixed 12 hours or so after the RC3 release.

Ok, now I have the dev release. It's almost working in the dev release. I can select the first level hierarchy. I can select the second level hierarchy. But the third level hierarchy never displays and even more odd, the third level hierarchy terms have now replaced the second level hierarchy terms. When I select a third level term (from the second level select), nothing happens.

You don't get any JS errors I assume?

I've got what appears to be similar behavior to douggreen - I can select the first level, but then I can't select the second level. The difference may be that I've set the maximum depth to 2, so maybe its failing on that last level.

Also, no JS errors.

Ok, a little more diagnosis and information, ... I don't think that my HS issue is related to this at all. The second level HS term doesn't work. I think that something is wrong with the CSS. Attached are three screenshots. In the first screenshot, I've selected the first level term and the first and second level terms are properly displayed. In the second screenshot, I've selected a third level term but it isn't displayed. In the third screenshot, I grabbed the resize tool, and the third level term is shown, but positioned improperly.

Interesting! You can disable the "resizable" setting to see if that makes a difference.

I never noticed this problem in neither Safari 3 or FF 2.

Hi Wim, This works perfect on FF2, FF3 and Safari but it has issues on IE6 and IE7.

After selecting the first term in IE there's a javascript error on the page. It displays the second list but that list is not functional and it will not go any deeper.

I'm not sure if this is helpful but here is the error message:

Line: 127, Char: 3, Error: Invalid argument, Code 0, URL: http://[mysite]/en/node/1725/edit

wmostrey: And this happens only in nodeprofile or also elsewhere? If elsewhere, please start a separate issue.

That error message is … really vague. You seem to have forgotten to mention which line this is (line 127 may vary greatly depending on the version).

Finally, did you try my advice in #22?

I did follow your advise in #22 but that didn't resolve the issue. To be honest it didn't seem to be doing anything really, I still got the resize bar in FF3 even though the setting was disabled).

Here is line 127 with the 2 lines above and 2 lines below it:

125    preformatted : false,
126    convert_fonts_to_spans : true,
127    remove_linebreaks : true,
128    apply_source_formatting : true,
129    theme_advanced_resize_horizontal : false,

That's not from HS' source code, probably from a WYSIWYG editor.

Reproduced. This is indeed an IE-only problem. To make this even more vague, this indeed only happens on nodeprofiles…

Oh Firefox, why haven't you killed IE yet?!

I've set up a IE + Visual Studio debugging environment. This allowed me to narrow it down further.

- It's similar to http://www.nabble.com/Internet-Explorer-7-throws-jQuery-error-td19657233...
- It only happens when resizable is enabled.

THe above helped me to track it down very quickly.

Thanks, this solves it for me too!

I'm encountering the same issue with the latest version of the code - have tried both 5.x-3.0-rc7 and 5.x-3.x-dev. When using HS on a nodeprofile form, I can select the first item from the drop down. However, it then becomes greyed out and no second level appears. Using firebug I was able to track the problem to the response returned by hierarchical_select_json() - it always returns:

{ "cache": [  ], "output": null, "log": null }

It appears that $hs_form_build_id = $_POST['hs_form_build_id']; isn't being set. Instead the hs_form_build_id is stored in $_POST['profile_node_form']['hs_form_build_id'] (where 'profile' is the name of my content type). This is causing the following three errors to appear in the watchdog logs every time I select an item:

Missing argument 1 for drupal_retrieve_form() in /Users/stella/workspace/drupal/includes/form.inc on line 179.

call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, '' was given in /Users/stella/workspace/drupal/includes/form.inc on line 218.

uasort() [<a href='function.uasort'>function.uasort</a>]: The argument should be an array in /Users/stella/workspace/drupal/includes/common.inc on line 2145.

I'm using nodeprofile 5.x-1.4

Let me know if you need any more info.

Cheers,
Stella

The attached patch fixes the issue for me, though there may be a better alternative.

Cheers,
Stella

Committed: http://drupal.org/cvs?commit=239144. Thanks stella! I just added some documentation to _hierarchical_select_get_hs_form_build_id().

We should investigate if this needs to be ported to Drupal 6.

Hm, I guess subform_element never was ported to Drupal 6 completely, see http://drupal.org/node/293836 and http://more.zites.net/embed-a-node-form-with-drupal-6.

Wim, I would like to bring up stella's patch again. I was experiencing similar problems like in #518830: Content Profile causes error in hierarchical_select_json() and applying the patch from #34 to the latest 6.x-dev seems to have solved the problems. Not sure about the form_state part though, should it be an array?

Index: hierarchical_select.module
===================================================================
--- hierarchical_select.module  (revision 747)
+++ hierarchical_select.module  (working copy)
@@ -288,7 +288,7 @@
   // drupal_json() function.
   drupal_set_header('Content-Type: text/javascript; charset=utf-8');

-  $hs_form_build_id = $_POST['hs_form_build_id'];
+  $hs_form_build_id = _hierarchical_select_get_hs_form_build_id();

   // Collect all necessary variables.
   $cached = cache_get($hs_form_build_id, 'cache');
@@ -701,7 +701,8 @@

   $names = _hierarchical_select_store_name(NULL, NULL, TRUE);

-  if (!isset($_POST['hs_form_build_id']) && count($names)) {
+  $post_hs_form_build_id = _hierarchical_select_get_hs_form_build_id();
+  if (!isset($post_hs_form_build_id) && count($names)) {
     $parameters = (isset($form['#parameters'])) ? $form['#parameters'] : array();
     $menu_item = menu_get_item();

@@ -725,10 +726,10 @@
     $hs_form_build_id = 'hs_form_'. md5(mt_rand());
     cache_set($hs_form_build_id, $storage, 'cache', time() + $expire);
   }
-  elseif (isset($_POST['hs_form_build_id'])) {
+  elseif (isset($post_hs_form_build_id)) {
     // Don't generate a new hs_form_build_id if this is a re-rendering of the
     // same form!
-    $hs_form_build_id = $_POST['hs_form_build_id'];
+    $hs_form_build_id = $post_hs_form_build_id;
   }

   // Store the hs_form_build_id in a hidden value, so that it gets POSTed.
@@ -746,7 +747,8 @@
   // the associated values from the cache. The _hierarchical_select_submit()
   // must be the first submit callback to ensure that it's executed: if a
   // submit callback before it performs a drupal_goto(), it won't be called!
-  $form_state['hs_form_build_id'] = $_POST['hs_form_build_id'];
+  $form_state['hs_form_build_id'] = $post_hs_form_build_id;
+
   $form['#submit'] = (is_array($form['#submit'])) ? $form['#submit'] : array();
   $form['#submit'] = array_merge(array('_hierarchical_select_submit'), $form['#submit']);

@@ -2287,3 +2289,15 @@
     drupal_add_js($settings, 'setting');
   }
 }
+function _hierarchical_select_get_hs_form_build_id() {
+  $hs_form_build_id = $_POST['hs_form_build_id'];
+  if (empty($hs_form_build_id)) {
+    foreach ($_POST as $key => $value) {
+      if (is_array($_POST[$key]) && !empty($_POST[$key]['hs_form_build_id'])) {
+        return $_POST[$key]['hs_form_build_id'];
+      }
+    }
+  }
+  return $hs_form_build_id;
+}
+

drupal24: excellent! But let's continue in #518830: Content Profile causes error in hierarchical_select_json() :)