I'm using Profile 2 ver. 7.x-1.0. (using latest version of Drupal 7.8)

If there are more than 1 *required fields that need to be selected before submitting changes or creating a profile, when you go to select an option in HS list 1, there's an error message that appears stating that 'HS list 2 field is required'.

Please keep in mind that this message will appear multiple times as you go deeper into each level of HS list 1, repeating itself stating that 'HS list 2 field is required'.

Lists are created using Term Reference/taxonomy multiple levels deep.

I searched the forums, so my apologies if this was already posted.

Please advise.



having same issue in a content type (problem is not limited to profile2)

Title:error message when multiple *required fields are present in Profile 2 moduleHS error message when multiple HS instances are #required
Priority:Normal» Minor

This is a minor problem. Patches welcome.

Glad to hear it's minor, I figured as much, I look fwd to the fix...

I am also really anxious to have HS work in Views... http://drupal.org/node/1170192

This I am assuming is major issue and very important for a lot of people...?

Yes. But HS Taxonomy Views is also *very* hard.

I'm having this same issues, of error message notifying you that field is required. I may have a look at resolving this in the next few days, as it is an issue for my client. Any ideas on where to look?

Probably somewhere in HS' #process callback.

Getting this error message as well after selecting first term in hierarchy on a required field. Does not happen when there are no children terms.

I'm just getting into this, but I see the validation is being called at line 746 (and actually creating the error message at line 877) in form_hierarchical_select_process() in hierarchical_select.module, but it seems like it should only be validating on push of the Add button or saving the node. Does that mean changing when the callback fires?

It may be a minor problem but if your users are navigating to a term they want to select, they'll get an error on the page for every step of the way and it looks *really* bad ... and the average user is scared off by red message boxes.

I've got this http://drupal.org/node/1321242#comment-5234946 in my HS at the moment because it suppresses the messages but it doesn't stop the HS widget going red.

Subscribing hoping someone puts in a patch - this one is currently the only thing holding up release of a website I'm working on, although just suppressing the errors is technically enough.

Ok - had a look at the code PapaGrande mentioned that is at line 877

If you wrap this if

if ($form_state['submit_handlers'][0] !== 'hierarchical_select_ajax_update_submit') {

around the little block of code that generates the error then it won't trigger that annoying 'field required' error unless you've actually hit the submit button. I haven't tested it on preview. But it works for my usecase and I am very, very glad to see the back of 10-15 'field required' error messages every time I go grubbing around through my deeply-nested taxonomy looking for stuff.

Yep that works for me

Title:HS error message when multiple HS instances are #requirederror message on ajax update when the HS element is #required
Version:7.x-3.0-alpha4» 7.x-3.x-dev
Priority:Minor» Normal
Status:Active» Needs review
new968 bytes

I can reproduce this with a single HS element, provided it's required and the form has a submit button.

It's a minor fix, but it's not a minor bug: as pointed out above users will be scared off by big red boxes and the form looks like it's not usable.

Here's the fix outlined above as a patch.

Can I use this method to block warnings when I'm creating new terms? The other required fields are throwing errors.

#12 works well for me.

#12 works well for me too.

#12 fixes the Required field problem for me but it also introduces 2 new problems.

1) If I delete a taxonomy term I get an error
Notice: Undefined index: submit_handlers in _hierarchical_select_validate() (line 880 of /sites/all/modules/hierarchical_select/hierarchical_select.module).
2) If I create a new term through hierarchical select after selecting some existing terms all of the selected terms are removed from the selection.

I've found a workaround.

I require users to use HS on the user registration form. I've done the following changes in hierarchical_select.module at around lines 880.

= count($element['#config']['level_labels']['labels']);
$elcount == 1) {
    if (
$element['#required'] && (!count($element['#value']) || (is_string($element['#value']) && strlen(trim($element['#value'])) == 0))) {
form_error($element, t('!name field is required.', array('!name' => $element['#title'])));
  else {
    if ((
is_string($element['#value']) && strlen(trim($element['#value'])) == 0)) {
form_error($element, t('!name field is required.', array('!name' => $element['#title'])));

What happens here is that I check how many levels there are by counting level_labels. Don't know if this breaks down if you don't specify level labels.

If HS is a single list, then proceed as usual.
If HS is a hierarchy, then we remove the check for

['#required'] && (!count($element['#value']))

Now this would work, but it let you submit the form without selecting anything, which is wrong, because the field is required.

So to fix that, I added a validation function on my user registration form like this (using hook_form_alter in a custom module):

['#validate'][] = 'extra_hs_validate';

Then in the same module I've got the validation function itself

function extra_hs_validate($form, &$form_state) {
$form['field_that_is_required']['und']['#value'])) {
form_set_error('', t('You must select something!'));

It's not pretty, but I think it works atleast for my particular use case.

This solves the problem with deleting terms as #17 struggled with. I don't allow users to create new terms, so that I can't check, but I don't think that should be a problem either. Caveat emptor.

I think this might evolve into a general solution. I think we have to somehow count how many levels are required, and then check if that number is selected. What happens now is that validation fails after selecting one element, it doesn't take into account that you need to wait with the validation until a full hierarchy is selected.

Curious, did you get any solutions to your no.1 error? i.e. did #18 work for you?

Best regards,

Hello ccheu. The error only occurred if I used the patch from #12. After reverting back to the original code the error went away. I didn't try the method outlined in #18.

new1.02 KB

I have added a patch according to #12.
Please test it.

Patch #12 works for me. I can't reproduce either of the errors indicated in #17.

I have a interesting effect - If i create a new taxonomy term through the hierarchical select and add it to the page, when I go to save the page, it won't allow me to save. it tells me another user is working on the page. if I then refresh the apge, save it... now i have two nodes - duplicates!

Patch #21 works for me. Thanks!

#21 worked like a charm

#21 works for me. Thanks!

If use HS in forms with Captcha, #21 work only for one field :( when select second-third required fields get another problem:

  • CAPTCHA session reuse attack detected.

Have solution?

Status:Needs review» Reviewed & tested by the community
new956 bytes

I say RTBC (attaching a reroll from the module root). We're using this and it fixed all of the problems we were having.

cweagans this is a patch for 7.x-3.x-dev right? I can test it later tonight against my (admittedly limited) double-HS use case.

#28 worked for me with 7.x-3.0-alpha5 (patched applied with fuzz). i vote RTBC as well.


#28 solved the issue for me in the 2012-Jun-16 dev release

new956 bytes

Confirm RTBC!!! Re-roll for current 8.x

+1 for #28.

+1 for #28 as well. Will this be rolled into a 7.x DEV release soon?

Can also confirm #28 works for me !

Status:Reviewed & tested by the community» Fixed

Thanks, committed #28! (But credited joachim, who AFAICT was the original author of the patch.)


Status:Fixed» Closed (fixed)

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

Issue summary:View changes

This didnt work for me on 7.x-3.0-alpha5...checked the patch was applied in the code and it was...