I am reporting this as a new issue as I have no ctools and I can reproduce the problem consistently with both Firefox and Opera. I defined a new content type: 1 regular vocabulary, 1 HS vocabulary, 3 unrelated CCK fields, everything marked as "required". When adding a node the HS selection seems to work fine, however if I first attempt to preview or save the form without filling any field (just for the sake of testing) then subsequent HS selection attempts will result in Received an invalid response from the server. Please change status as required. Thank you.

Message: uasort() [<a href='function.uasort'>function.uasort</a>]: The argument should be an array in /var/www/drupal/includes/common.inc on line 2843

Comments

Status:Active» Postponed (maintainer needs more info)

Can you reproduce this on a vanilla Drupal installation *without* the CCK fields? I.e. just Drupal core with Taxonomy enabled for the "Page" content type (or any other built-in content type)?

I managed to reproduce it right away on a no-CCK content type (stock Page with assigned HS vocabulary), however it is not core Drupal, as I have a bunch of contributed modules with many dependencies. In few weeks I will install a core Drupal on localhost and try again. The problem is a minor nuisance, as it shows up only after trying to save an empty form, and reloading the page will clear it up.

Status:Postponed (maintainer needs more info)» Closed (fixed)

It's 99% likely that it's a contrib module that causes this. I'm closing this issue if you're only retrying this in a few weeks. Just reopen it when you've tried to reproduce it.

Hi Wim,

i have the same bug on a fresh Drupal installation after validation fails. My HS-version is from http://drupal.org/node/342992#comment-1880396

Category:support» bug
Priority:Normal» Critical

I have the same problem and not using ctools as it was mentioned in some other thread.
I justy tried it on Vanilla d6.13 installation and latest dev of HS.

- Taxonomy has two levels. Saving only deepest, choosing only deepest. Showing node numbers and rest is disabled, also its Required.

To way to replicate, build some taxonomy with 2 levels, make it HS, choose options as above, when creating node, dont choose anything, just go to preview and then try selecting HS, doesnt work. think this is rather big problem for module.

No response on this? I would say this is rather critical as with this bug HS is not so useable and altouth its DEV i guess many use it on live sites as i plan to do soon, as soon as i "solve" this and some other bugs. any chance on getting and pointing on some older DEV version of HS without this bug? I searched for other version but in there is only latest dev version, if someone has relase before this and its working please post/send it.

Status:Closed (fixed)» Active

Same here.

  • Drupal 6.13
  • Enabled core modules: Database logging, Menu, Taxonomy
  • Enabled contrib modules: HS, HS Taxonomy

Create a vocabulary. Add 2 hierarchical terms: 1st level term, 2nd level term. Make the vocabulary mandatory for a content type.

Enable HS on the vocabulary, leave all the settings at default.

Try to preview or submit the node without selecting a term from the mandatory vocab. The validator outputs an error message (however, the HS taxonomy dropdown is not marked with red) and sends back the node edit form for correction.

Now try to select the 1st level term in the HS widget, you should get this Javascript error: Received an invalid response from the server.

On the Firebug Response console:

http://domain.com/hierarchical_select_json 500 Internal Server Error jquery.js?p (line 13)

Very odd, will try to reproduce. Can't tell when, because DrupalCon Paris is coming. Will work on this on the train probably.

Same problem. Refreshing the page, than get this:

warning: uasort() [function.uasort]: The argument should be an array in /home/thamas/public_html/foldername/includes/common.inc on line 2843.

The HS is in a Content Profile node. There is no problem when logedd in user edit the node. Anonymous user (who want to register) can't use HS.

Hey Wim, any news on this? Seems very problematic, if u dont have time let me know and maybe give us some older dev version that doesnt have this so we could use it in meantime?

thanx

StatusFileSize
new109.98 KB

Hi deepm,

Yes, have same problem, but luckily had a backup of HS that works .. a previous version before 10 Sept.

find attached :)

Found it, tried it, has the same problem as new version. Are u sure u posted working ver.? I did try uninstalling module but there is no unistall option, so i guess i only need to put new files (or old ones) but as i said the problem is the same so guessing problem is going from back then?

StatusFileSize
new103.78 KB

This one is working so use it, its from 2009-04-07 but has no problem like mentioned here.

p.s.
why arent RAR's allowed?

Assigned:Unassigned» Wim Leers
Status:Active» Closed (fixed)

Well, if this was a problem, then it no longer is. I just did a fresh install of Drupal 6 and HEAD of Hierarchical Select. Works just fine.

Please update :)

Works great now in my test site!

Thanks Wim.

JP

I confirm it also, working fine now :-)

working fine here too (Firefox and Opera)

Sorry. Getting the same error on the Oct 3, Dev release.. When I click drop down to get to 2nd tier and select, I get Received and invalid response from server. I get this in ie and firefox.

Installed the Oct 3 Dev release on a copy of my operational 6.13 drupal site:

now I receive the 'invalid response from server' message directly (before previewing and/or saving a uncomplete page). The whole hierarchical select menu stopped working!

Anyone else experiencing this problem as well?

I get this error too. I don't know if its the same thing, but I can go levels deep, select etc a-ok, but as soon as I create a new item it comes back with this error and then everytime I select something it does the same. The only way to carry on is to save and come back. The item I tried to create is actually created.

fyi, this isnt vanilla and I am not in position to quickly install and test, but wanted to inform you just incase it was useful. (running latest dev + 6.14)

P.

I have D6.13 and I have the same problem too: "Received an invalid response from the server" when i user hs to select a deeper level.
What in hell is the matter?!
i'm a little desperate.

same here

need fix.

You are not alone ;-) sometimes got this, sometimes not, but got this everytime, when I enable user-register.tpl.php and

<?php
print drupal_render($form['taxonomy']);
?>

Status:Closed (fixed)» Active

same problem, updated to the 6.x-3.x-dev on 3rd Nov. 2009.

Priority:Critical» Normal
Status:Active» Postponed (maintainer needs more info)

Can you reproduce this on a vanilla Drupal site? If you cannot, keep on adding modules that you're using on your actual site until the problem is reproduced.

When you're able to reproduce this (on a vanilla Drupal site with the minimum number of modules to reproduce it), then please make a screencast of:

  1. your site configuration
  2. the problem being reproduced

That makes it easier for me to reproduce the problem. Thanks!

P.S.: don't have any screencast software yet? On Windows and Mac OS X, you can use the free Jing.

I'd try it.

Now there is an other error, and I sure, the origin is the same:

Type page not found
Date kedd, november 3, 2009 - 21:22
User Pál úr
URL http://mydomain.net/hu/hierarchical_select_json
URI http://mydomain.net/node/add/favor
Message hu/hierarchical_select_json
Level figyelmeztetés
Host 195.56.237.179

The enabled hungarian language makes something wrong....

Same problem, but with some differents.
* Drupal 6.13-6.14
* Enabled core modules: Database logging, Menu, Taxonomy
* Enabled contrib modules: HS, HS Taxonomy
Anonymous can create nodes.
When nodes created by registered user its OK.
But when it created by Anonimus, on checking any category in the HS field, get "invalid response from the server".
Same problem when enabled my module, that adding required HS field in the user register form. Users can't register...
If HS field is not required, and user leave it clear, user register normally and can edit this field when login.

This problem is on some computers (not on all) (no firewalls and anti-viruses).
Interesting, that if we get error on the computer, this error will be in all browsers. In FireBug on net folder we can see that there no POST data sending on server, and no response data from server.
But if we login from computers with that error, HS works correctly. This error only for Anonymous:)

I did some more tests and found that it wasn't because of the permissions but from where I have clicked to edit the Content.

If I click to edit the content from our own created link I get this in the url: ?q=node/800/edit&destination=home

But if I click to edit the content from the adminstration menu I get this in the url: ?q=node/800/edit

And if I delete the "&destination=home" in the url it works.

Does this help Wim, to reproduce the scenario?

Anyone know something more? this thread is stopped?

Same error here, works fine in node/add but fails for content profile register page

Could u please post the code changes u did on #14 to get it fixed?

I had this problem again when using HS modul with caching enabled. But it happend every now and then to more ppl when using my site. When i turned caching off for that particual page where HS is used its ok again. Talking about standard drupal cache.

I have caching disabled in a dev site and still this problem appears on content profile registration pages, but works on node creation (node/add) pages

Hi, i had the same problem ("Received an invalid response from the server" message).

In my case i have a spanish site. I saw in the watchdog a message like this:
"page not found 23/12/2009 - 12:35 es/hierarchical_select_json"

Note that the problem is the language path prefix. I solved the problem deleting the path prefix for the spanish language. (and for english, i put 'en' prefix)

I think this is a problem for multilingual sites.

I open a new issue (http://drupal.org/node/666498)

I've got this error when I make a node add form page using drupal_get_form()
This is my patch

//Module hierarchical_select 6.x-3.0
//Path: sites/all/modules/hierarchical_select/hierarchical_select.module
// Line 293
// Error : "Received an invalid response from the server"

//#### Path
module_load_include('inc', 'node', 'node.pages');
//####Path ///

hi, that would be cool, just to place this in hierarchical_select.module? cant see line numbers os standart patch signs.. thanx a lot

I am also getting this error, and in my case it is a cache issue. The problem is that the HS module sets the HS form cache expiration to 6 hours completely disregarding the general drupal cache settings. And then, here is what happens

1. The HS form is cached and the cache expiration is set to 6 hours.
2. The page displaying the HS form is also cached as a page, but for a much longer period
3. After 6 hours the HS form cache expires, but the page delivered to a user from cache still contains the old expired hsid
4. The AJAX callback tries to get the HS form from the cache using the expired hsid and fails.
5. JS parsing of the response fails and you receive the "invalid response" error

Temporarily, I have fixed the problem by replacing

cache_set($hs_form_build_id, $storage, 'cache', time() + $expire);

with

cache_set($hs_form_build_id, $storage, 'cache', CACHE_PERMANENT);

in the hierarchical_select_after_build function. (Do NOT forget to clear the cache at admin/settings/performance after this modification!!)

That would keep the HS form in the cache indefinitely. But the final solution should somehow take into account the general drupal cache settings and set the HS form cache expiration accordingly.

I have the same problem in view not in page or taxonomy

http://drupal.org/node/674528

I install this module in a vanilla drupal but this error persist again :(
any body have no solution?
is it possible that it refer to server setting?

This is too bad. I have had this bug through 3 versions. I just tried #38's solution and I still get the dreaded Received an invalid response from server. I have literally not been able to use this module for about a year. Tomorrow I am going to sit down and start with a fresh install and see if it works there. This bug has been around far too long. Time to help out.

Try to disable cache at admin/settings/performance, are you still getting this error?

No clearing cache does not solve the problem nor does selecting disabled cache. I did discover that the hierarchical select works just fine when editing a node but I get the same error when trying to create a new one. I am going to now to try and recreate on a fresh setup. I'll add modules as I go and see if the problem arises.

Version:6.x-3.x-dev» 6.x-3.0

Installed CCK, HS, Content Taxonomy on fresh Drupal 6.15. Activated Content module, Content Taxonomy, and HS.

Proceeded to vocabulary page to add vocabulary and received this error.

* notice: Undefined index: vid in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/sites/all/modules/hierarchical_select/modules/hs_taxonomy.module on line 17.
* notice: Trying to get property of non-object in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/sites/all/modules/hierarchical_select/modules/hs_taxonomy.module on line 65.
* notice: Trying to get property of non-object in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/sites/all/modules/hierarchical_select/modules/hs_taxonomy.module on line 80.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes/form.inc on line 892.
* notice: Undefined index: labels in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/sites/all/modules/hierarchical_select/includes/theme.inc on line 230.
* notice: Undefined index: item_types in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/sites/all/modules/hierarchical_select/includes/theme.inc on line 271.

Moving on, I create an object. It appears that HS is working for Taxonomy, but when I attempt to use it to select a term in the content taxonomy field, I am presented with only one option, <None> . I cannot select any terms.

I once again receive the error.

notice: Undefined index: #post in /mnt/stor2-wc1-dfw1/409706/mysite.com/web/content/includes
/form.inc on line 892.

I dont see any reason to continue further with adding modules at this point.

I'm getting the same error. It appears to be associated (at least in my setup) with the use of a Views 2 attachment that has the Inherit exposed filters option set to yes. Disabling the attachment cures the problem, re-enabling it causes the problem to return. 100% consistent.

I surmise that something in either the PHP or JavaScript logic doesn't like being called twice, although the API.txt file does say something about module weight that I can't grok.

In addition, once that alert pops up the next page load from the site - regardless of path! - yields three additional PHP errors, displayed in the message area:

  • warning: Missing argument 2 for drupal_retrieve_form() in /var/www/includes/form.inc on line 326.
  • warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in /var/www/includes/form.inc on line 372.
  • warning: uasort() [function.uasort]: The argument should be an array in /var/www/includes/common.inc on line 2874.

I faced this today While I'm using the hs API anyway I'm working on FF under ubuntu when I changed to chrome it works fine, I tried it on another machine FF ubuntu it worked.
I think this might help

Same problem with any add page with any prepopulate fields.

Sorry for the enormous in delay in getting this fixed. Last semester was crazy at the university. And the mess in this issue and the many duplicate issues did not help either.
Trust me when I say that you'll start to hate Drupal severely and be disappointed in its poor technical design when you're building advanced form elements such as Hierarchical Select. This problem is a strong indicator of where Drupal falls short.

So, in summary, these are the setups that trigger this problem:
- i18n: a language prefix; e.g. hu/hierarchical_select_json
- anonymous users; the typical situation is a HS form item on a content_profile form (which itself is again a hack and has caused nothing but trouble in combination with HS, which is again an indicator of Drupal's poor design)
- page caching: HS caching period < page caching period => cached page's HS relies on cache entries that no longer exist. Very clearly explained in #38 by mkassets. (I had to introduce a custom caching layer because Forms API was not flexible enough in D5 and still isn't in D6.) The solution is simple: forms that include HS should never ever be cached. The explanation: each visitor that interacts with HS, can have a unique interaction pattern (I'm sure you'll agree with that), hence the data cached for it should also be unique (this is why each HS gets a unique "HSID" that differs on each page load), hence forms with HS may not be cached! Yes, that can be a scalability issue. That's something to tackle in HS 4 though, when hopefully less hacks will be required to get HS to work.
- Views 2 attachment that inherits exposed filters. Lowest priority.
- custom form that does a manual include of a file instead of using $form_state['form_load_files']. This is a bug in *your* code, and can easily be fixed! See #697172: "Invalid Response from Server", possible causes and solution if you want a longer explanation.

That leaves me with 2 big cases to fix:
1) i18n
2) anon

The Views 2 attachment issue would be extremely rare and is obviously due to the complexity of so many layers and APIs interacting with each other. Hopefully it will be fixed automatically by fixing the 2 big cases. And possibly it's even a case of a custom form (or form_alter()) that is manually including a file instead of using $form_state['form_load_files']. In any case, I'll ignore this problem for now and once the two big cases have been tackled, I'll accept feedback for that specific case again.

So now, I'll get started with fixing the "anon" case — I think it might be the key to solving it all.

Title:Received an invalid response from the serverJS alert: "Received an invalid response from the server."
Component:Code - Taxonomy» Code
Priority:Normal» Critical
Status:Postponed (maintainer needs more info)» Active

There was one more duplicate issue: #624502: 'Received an invalid response from the server.' connected to permissions?. I'm going to reply to some of the comments there over here, to consolidate the discussion. The comments numbers I'll be referring to in this comment are thus from that issue and not from this one!

@whatdoesitwant (#13): Thanks for the *excellent* explanation! Much appreciated! Unfortunately, your steps to reproduce didn't work for me.

  1. clean urls are enabled: yep
  2. i18n is enabled: yep
  3. Several languages are installed: yep, Dutch (nl) & English (en)
  4. The default language is set to non-English: yep, Dutch
  5. The i18n settings at http://example.com/admin/settings/language/configure is set to either path prefix or path prefix with language default: yep, the latter
  6. Under http://example.com/admin/settings/language/edit/en/ the path prefix is set to nothing: yep

This always works just fine for me, in all of these cases:

  • nl = default; nl/node/add/page
  • nl = default; node/add/page
  • en = default; nl/node/add/page
  • en = default; node/add/page

@almadeweb (#19): Thanks! That was indeed a problem! The problem was in HS' JS code, it was always appending the page's GET arguments by concatenating it with a question mark ("?") in between, instead of using an ampersand ("&") when clean URLs are disabled. I fixed that now, and that's at least one less cause for this vicious error! :)
http://drupal.org/cvs?commit=335230
http://drupal.org/cvs?commit=335232

So this means I'm effectively unable to reproduce one of the big cases: i18n. Can somebody please try to recreate the problem once more and post the exact steps to reproduce, since I'm unable to reproduce it? Thanks.

Next up: the anon case.

And again one more duplicate issue: #721280: Another 'Received an invalid response from the server.'. There, it was reported that Cache Router also triggers this problem.

Sorry, Wim. Why prepopulate fields are crashing HS?

I am experiencing the anon case - I am using HS node reference with Content Profile and autoassignroles.

If I try mydomain/node/add/student the HS works as anon user, no problem

If I try mydomain/student, as set up in CP/Autoassign roles, I get the "Received an invalid response from the server"

I have pored over these forums and tried some of the solution regarding cache and nothing changes.

This is critical for my project, so I would be happy to help test any potential solutions.

I am experiencing this same behavior from a different combination. I have a custom node type where I'm using the AHAH Helper module to add some AJAX behavior to a custom form widget. It works great and doesn't include any external files (so #48 is not a factor in this case). When I enable HS on some CCK Content Taxonomy fields they work great, until the form gets rebuilt via AHAH from the custom widget. If I don't make any AHAH requests on the loaded form HS works great, but just one form rebuild triggers the problem reported in this issue thread.

I am using the March 3rd nightly build 6.x-3.0-dev of HS on Drupal 6.15 with AHAH Helper version 6.x-2.0.

Unfortunately, I have no workaround for this, so the issue is a show-stopper. I'll do what I can to try and get more information on exactly what is going on under the hood.

I have had the "Received an invalid response from the server." error.

I debugged a vanilla install to my install until I found the "variable" database table was the culprit.

Then I traced it further, until I found that the variable (row in the db) "cache_lifetime" was the problem.

Sure enough, I had "Minimum cache lifetime" in the performance section selected in my production site.

I actually had looked at this a long time ago, but since my caching mode was set to "Disabled", I erroneously thought Drupal was not looking at Minimum cache lifetime.

I would be nice if the line "The following enabled modules are incompatible with aggressive mode caching and will not function properly" from the performance page was appended to include hierarchical_select.

I have page caching set to default 'disabled'. I reset to default to remove 'cache_lifetime' from the variable tables as suggested in #55. That did not help resolve my issue with AHAH Helper enabled form element requests on the same form.

Right now I'm looking into how '#parameters' and '#names' are being processed from within hierarchical_select_after_build(). There seems to be some resetting of the #names attribute going on and some other handling of #parameters. It is the missing #names and #parameters from the HS form cache that seems to be the root of my issue.

Is it assumed that the only AHAH requests that occur on a form with HS enabled are going to be those generated by HS module? Anyone else able to use HS on a form that has other AHAH enabled form elements? If so, is there some additional housekeeping I need to be doing to allow them to work together? I am using AHAH helper to manage paths and callbacks on my other elements.

subscribing

Hierarchical Select do not work, in registration form. Receive such exception *Received an invalid response from the server*

I have this problem too, when trying to parent taxonomy items - the taxonomy was flat, now moving items under parents. When I go to an item in the taxonomy list, hit edit, open advanced and select 'Africa' (I'm putting countries under continents) I get the error.

Caching has never been turned on. clean urls are off and no language stuff (it's a new devel site, everything up to date)

Let me know if this is a useful debug case and I can mess with it...

I've specifically received this response when opening two tabs in one browser of the same content type where I'm adding the taxonomy.

I've found a temporary solution to the problem.
I installed cacheexclude and excluded the node forms where I enter the taxonomy. This has a very slight performance impact in our case and should be evaluated by each individual.

Hope this helps.

Hi Wim,

I also have the problem with Internationalization i18n (as explained on #49: http://drupal.org/node/538022#comment-2658954).
What may be is missing in your installation, is the use of internationalization in contenttype setup?

EDIT: Version in http://drupal.org/node/538022#comment-2039602 is working somewhat with i18n, may be that is off some help?
I can;t give the vocabulary a internationalization option, than it is not working: only working option: "None. No multilingual options for this vocabulary."
and I got his error using that version when saving a node:

    * warning: preg_match() expects parameter 2 to be string, array given in includes/bootstrap.inc on line 777.
    * warning: preg_match() expects parameter 2 to be string, array given in includes/bootstrap.inc on line 777.

Thanks for going into this still!
Greetings, Martijn

Subscribing.

subscribing

Subscribe.

I got the message right after I enabled Internationalization from the i18n section. Everything was going well up until that point... :(((

Version:6.x-3.0» 6.x-3.1

Dear Wim and HS users, I have this problem and I believe it has something to do with the Form Block module.

I receive an invalid response and then some warnings :

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in /srv/d_lce/www/***/htdocs/includes/form.inc on line 372.
warning: uasort() [function.uasort]: The argument should be an array in /srv/d_lce/www/***/htdocs/includes/common.inc on line 2884.

I use Hierarchical Select for a CCK taxonomy field on a content type that can be created by any users (including anonymous but the problem occurs for any role) on the site. The node form is included in a quicktab block.

The standard node creation form in the admin section works with no problem with the same CCK field.

I hope it will be possible to use HS for this field as it is one the coolest field I've seen. ;)
Keep up the good work ! If you need any details I'm here.

Hi,
I suggest using this thread for looking at Internationalization bug with HS and use other/new thread for other modules.
Otherwise to much in this one thread. Right?
Sorry if my suggestion is not appropriate.

greetings, Martijn

I agree with #66. In my setup there is no Content Taxonomy module. As I wrote in #64, HS worked fine just until enabling i18n. Perhaps the title of the thread could be changed?

Let me add that I don't use the formblock module mentioned in #65, but I do have i18n enabled. I haven't actually noticed if this error happens only after i18n is enabled though and I cannot test since I am on a live site. I'll see if I can get a testing environment up-n-running soon so I can test and report back (if time permits).

What I am trying to say is that I doubt it has anything to do with formblock, but I cannot be 100% sure that it is i18n related either.

I think it is i18n related. If I set off the taxonomy support of i18n, the HS taxonomy object works fine,
if I choose any i18n taxonomy options, I got the invalid response message.
Greetings, Martijn

I know formblock didn't cause the problem you experienced but maybe it can help Wim to find the bug to know that it can be triggered this way too.

I can trigger it by checking the Remember checkbox on the exposed views filter form. Without Remember, the HS works.

Can it be that the "Received invalid..."-message disappears by installing the new 3.1 version of HS?

For me this is the case.

Sure mitroku, look in the changelog :

[…]
Fixed one case of #538022: JS alert: "Received an invalid response from the server." — when clean URLs are disabled and GET arguments are present
[…]
Follow-up patch for #605110 by pacproduct: i18n compatibility: POST request is prefixed with language code, not actual language prefix
[…]

My setup: HS + Content Taxonomy, 2 languages (main is russian and english with a prefix), *no i18n*, but there's cacherouter in APC mode on one PC and Memcache API on another. Note that on both PCs this error shows only after playing with the widget for some time by selecting different parents, not on during initial form loading. So I guess something bad happens in the process of returning children.

UPDATE: I need to correct myself, on PC with Cacherouter-APC caching the error doesn't happen. Pure guessing - could HS use wildcard cache flushes in the process of returning children ? Cause wildcard flush processing differs on my 2 setups: APC uses registry which keeps track of keys, and Memcache API version I have simply flushes whole bin/table. Wildcard mis-flushes often bring problems cause you may lose cache accidentally.

Hi,
It seems that HS 3.1 fixed the i18n issue!! Please others having problems, respond :)
And it looks like HS dev newer that 3.1 have still the same bug..is this possible?

greetings, Martijn

I understand that we have to deal with missing cache problem in the cache engine itself, and that is exactly what is happening: new version of Memcache API has registry to deal with wildcard flushes too. But OTOH I also think that cache is *by design* an "unreliable storage" so HS should be capable atleast to fail gracefully, not miserably, i.e. HS should verify it's storage and if it's missing, return a meaningful message to the user, something like "Error happened. Please contact the administrator". Currently HS cache_gets blindly assuming cache is always there. Maybe look at how core deals with missing form cache ? Another idea would be to not rely on cache, and use more reliable storage, e.g. DB.
Maybe it was a bad idea (in the core!) to use cache for storing form data from start. As I said, cache is unreliable storage by design and honestly I can't accept to have broken forms because of a cache flush. Note, that generally cache flushes should be harmless, because on cache miss you should be able to reconstruct missing data, and when form cache is missing you can't do that. Should we open a core issue related to this, or does it exist somewhere already ?

The only "proper" solution atm for me seems to be using Cacherouter with DB engine used for "cache_form" and different (faster) engines for other tables. But also maybe HS should move it's cache to 'cache_form' too ?

My problem has disappeared with last release! Thanks!

I got this error too but I haven't activated blockforms or i18n. 2 days ago I added a new language und I changed the cache settings and now I've got this error. But I can't reproduce exactly the steps and the exact time when this error appeared.

But I have content taxonomy activated.

Hope it helps a little.

Minutes ago I updated HS and Content Taxonomy to the latest dev releases but didn't help.

Repeating the same test as described in #2 (no CCK) I don't see the problem any longer.
I am running HS 6.x-3.1 and a bunch of contributed modules (no i18n, no formblock)

Okay, so it appears to be working with i18n for everybody (#72,#77, #79) again now! Great! :)

@crea: You're absolutely right in every regard. I followed core because core usually does it right and because I didn't want to create yet another database table. I guess I shouldn't have. The alternative is of course #528156: Performance: Remove Hierarchical Select's form cache and don't reconstruct the entire form anymore. Please either continue there or create a new issue! Thanks.

@Vote_Sizing_Steve (#71): that appears to be another instance of this error. Please create a new issue! Thanks.

I've added a new troubleshooting entry to the README based on this issue: when you get the JS alert: "Received an invalid response from the server.", you should make sure that the page the form is on is not being cached.

http://drupal.org/cvs?commit=357082
http://drupal.org/cvs?commit=357084

If it's still not working in combination with other AHAH/AJAX-powered stuff on the page or with content_profile, or something else: please create new issues. I'm gonna mark this one as fixed to prevent a further mix of the different causes.

Status:Active» Fixed

Hi, I got the "received invalid response from the server" when I tried to use the HS field value to trigger a rule!!! HS works normaly with nodes and the cache is disabled. Any support ?
Thanks.

Read #80 please.

Hello, same problem as #81 with adding rules. I tried to clear all caches but the problem persist when trying to select "field has value" in rules module.

Read #80 please.

Status:Fixed» Active

The Alert is displayed on 6.x-3.1 version, How can i do for work wiht HS and don't to show this Alert.
After the alert is displayed this message is showed too:

user warning: Can't create/write to file 'C:\WINDOWS\TEMP\#sql_150_0.MYI' (Errcode: 13) query: SELECT t.tid, t.* FROM term_data t INNER JOIN term_hierarchy h ON h.parent = t.tid WHERE h.tid = 1 ORDER BY weight, name in C:\AppServ\www\colombiaramica2\modules\taxonomy\taxonomy.module on line 755.

I am also getting the alert on the 6.x-3.1 version, with all caching disabled.

I am also using the hs_nodereference module, but it doesn't appear anyone else using that module has had this issue. I do get the error when I try to select something in the hierarchical select nodereference field, however.

Is there anything I can do at this point?

I get this error consistently when I try to use it with rules.

I am using a hierarchical_select as a taxnonomy. And want to set up a rule based on the value in the taxonomy. So when I try to select it, during the rule setup I get the error... Its part of an AND section of the "content's field xxx has value" rule.

So I have abandoned it for the rule setup.

It works well for just as a selection option in the application though.

I am using hierarchical_select 6.x-3.1 with drupal 6.16 + latest rules 6.x-1.x-dev.

Activate your Drupal cache, put at least 5 or 10 minutes minimum cache.
If possible, use cache enable HTML5 client-side, that should help.

Sorry for my English!!

What I would like to know is what are the set of functions that need to run if the cache is cleared and there is no cache entry to reference by hierarchical select? There may be a performance hitch but at the very least it would fix a bug and ultimately not require another table (only another query to set the cache entry for that particular form id once again). I don't mind trying to write up a patch regarding this.

Status:Active» Needs review
StatusFileSize
new1.23 KB

I started working with the possible issue and as a possible failback, what I did was create a form element that holds the values from storage. If there is no cache to retrieve storage, it will look at the form element. Attaching the patch. I don't necessarily think it is the best solution, but it works even after the cache is cleared (and will look at the cache if it is available though we may want to change that?) It could possibly work as a stopgap until a better solution from the issues Wim has pointed out are in place.

Status:Needs review» Needs work

Tried it with a view on a large number of hierarchical items and the views died - so still an issue :/ The patch would definetly need to be done without the use of hidden variables. Other possible solution is via sessional variables (which could get pretty nasty in terms of size of the session).

StatusFileSize
new1013 bytes

This is the patch with a sessional variable (only setting it to a specific variable whereby the assumption is made the user is only browsing one page at a time. Could work since its used as a fallback to the cache for now?

Thanks. This patch works.

I confirm the patch in #92 works

Which version of Drupal and Hierachical Select do you have, @files32 @domidc?

Still the same problem for me after applying the patc. I'm using Drupal 6.17 and HS 6.x-3.3.

+1

I am using Drupal 6.19 (Pressflow) and HS 6.x-3.3

Subscribing to #95.
The patch at #92 seems to be not working on Drupal 6.17 and HS 6.x-3.3.

StatusFileSize
new1.23 KB

Reroll of the patch in #92 against HEAD. I don't support it though.

I've not applied the patch yet but I am able to resolve the issue by configuring memcache API.

@gkap can you explain how you did that?

Basically, what I figured from above thread is that HS doesn't work well when server side (at Drupal core level) caching is enabled, but in most of the cases we need caching to be enabled. In order for both of them to work together, I disabled core caching and externalize using Memcahce API. It does require some setup at OS level and depending upon your hosting server OS, the installation steps may vary.

The above means, if I understood everything right, that HS doesn't work for anonymous when cache is on. Right?

@gkap I had memcached on when encountering this problem. I still had to apply the patch. What is your bin configuration? Perhaps the answer lies there.

I followed the steps as per this instruction. Also, I am using Pressflow instead of core from Drupal.org, if that makes any difference.

@OnkelTem, this may be true. I have a HS field in the content profile and when I exposed that field in the registration form, I was getting the same error.

Drupal 6.19
Hierarchical Select 6.x-3.3

After update this patch doesn't work.

Version:6.x-3.1» 6.x-3.x-dev

Please leave this to dev version.

Subscribing

Please follow this link. http://drupal.org/node/697172#comment-3501210 Post #11 fixes the problem for me.

Subscribing

HS is known to work with the cache disabled, please let's keep looking for a solution that lets HS works with cache enabled.

#13 worked like a charm. Thanx

In order to help issues move on we need to test latest patches available Eyitayo. Please test #98 and report back.

Nice job! Thanks for the patch, it works good for the HT ver 6.x-3.6.

I had the problem same as #24: using drupal_render for HS-taxonomy field in user-register.tpl.php. It is solved now!

Just for the record Vadim, it is patch #98 that worked for you. Right?

Hi Gregory,

Yes, this is exactly patch #98

Patch #98 also worked for me.

Status:Needs work» Needs review

This should have been set to 'needs review' since #98, so I am setting it to such.

I'm sure that our success stories here justify 'tested', but in order for this issue to be set to 'RTBC' I guess a professional/proper review is required. So, I will refrain from setting it to RTBC. Wim, do you still not support this?

StatusFileSize
new1.08 KB

Re-rolled #98 with last changes in dev

jcmarco: thank you very much for the re-roll! :) Much appreciated! However, this won't work in combination with the no_anon module. But that is an acceptable trade-off.

First, however, now that #697172: "Invalid Response from Server", possible causes and solution has been committed, please confirm that the problem still exists, and that this patch is thus still necessary.

@Wim Leers: I tested the patch from #697172: "Invalid Response from Server", possible causes and solution and I am afraid that #118 is still needed

For me the latest dev release clears the initial problem in this post with regards to the cache - thanks very much for your hard work Wim.

Cheers, Joe

This issue also affects HS forms compatibility with memcache API. Applying the patch at #92 solved this for me.

Assigned:Wim Leers» Unassigned
Status:Needs review» Needs work

So basically, the problem is that the entry in HS' own form cache corresponding to the form build id that was POSTed does not exist. By abusing $_SESSION, you can work around this.
But then again, this contradicts with the fact that you *do* need the form to be dynamically generated, because otherwise $_SESSION['hierarchical_select_js'] otherwise would not get populated.

I would commit this patch if it was at least clearly documented how this solves the problem, and how the problem itself is being caused exactly. For now, I'm going to release version 3.7 without this patch.

...at least we're getting somewhere. That's good news.

Version:6.x-3.x-dev» 6.x-3.7

I've disabled the multilanguage on a taxonomy, it did solved the "Received an invalid response..." message, but I've fallen in another trouble: after clicking on a term and the add button, it didn't adds to the dropbox and the dropdown becomes empty. The same vocabulary does works on another node type (a content profile). Tried the latest dev and the 3.7 version. Cache is disabled.

Version:6.x-3.7» 6.x-3.x-dev

@constantinus: DON'T hijack issues. Open a new one.

Enabling the cache solved, the issue. Sorry for bugging.

This works for me. Added missing including and cache enabled.
Don't beat too hard for my first patch, but You can try it.

Version:6.x-3.x-dev» 7.x-3.x-dev
Component:Code» Code - Taxonomy
Status:Needs work» Patch (to be ported)
Issue tags:+Hierarchical Select

Hey Artyom, wish you happy first-patch-in-d.o day! ;)

I haven't come across this issue for some time now (...doesn't mean it's been solve though), so I cannot comment as for the functionality of the patch. Perhaps others still having the issue can test it. As far as d.o coding standards go, this line:

-function _hs_process_attach_css_js($element, $hsid, $complete_form) {
+function _hs_process_attach_css_js($element, $hsid, $complete_form) {

...is unnecessary since it simply adds white space at the end of the line. And this line has white space at the end too:

+  $form_state['cache'] = TRUE;

Hi, Is this suddenly a Drupal 7 issue?
Greetings, Martijn

Efharisto! Thank You!
I will pay attention on damn whitespaces at future :)

I was following this as a 6.x issue. Why is it now 7.x?

Status:Patch (to be ported)» Needs review

Artyom was the one to change this in #128. I myself never had the issue in 7.x, but it seems that he did and he actually did something about it ;)

Well this got directly to "patch (to be ported)" ...that means if it works it will be ported in 6.x, but I honestly think that it needs to go through "needs review" first. Besides, there's already a 6.x patch in #118. That patch is the same as previous ones, but is/was rerolled against whatever version was current at that time. Wim did a reroll himself in #98, but he clearly states that he doesn't support that solution. Lets see what he thinks about this one, shall we?

I have this message, when i update the jquery from 1.2.6 (default in my drupal 6) to the newer 1.4.4.

problem is that i need newer jquery version for the .delay() functionality for something else.

i'm testing with anonymous on an exposed view with 2 levels. with jquery-1.2.6.js i can select 1st level and it shows 2nd level perfectly.

with 1.4.4 i have this error message every time i try to select a 1st level term.

I have the same problem (hierarchical_select-6.x-3.7)
I have only HS and HS Taxonomy enabled.
I'm using jquery-ui-1.7.3.custom as recommended for wysiwyg_image_upload.
Any caching is disabled.

Interesting that when form is refreshed, the message "'You don't have javascript enabled" appears, then it dissappears again.

So I see the list of top taxonomy terms, I click one of them and I get the error "Received an invalid response from the server".

So many users have this problem for such a long time, is it possible to fix it?

Is it possible that the problem is caused by duplicate jquery.ui?
I have another one in jquery_ui module, and the version is 1.7.3.custom

Version:7.x-3.x-dev» 7.x-3.0-alpha1
Status:Needs review» Active

I'm having this issue with a fresh install of 7.x-3.0-alpha1 on Drupal 7.0. I don't have any other jquery modules installed. And the patch in #128 did not work for me...

Status:Active» Needs work

Sorry, set the wrong status :)

Patch #118 worked for me.

Patch #118 didn't make any difference for me.

#118 worked for me too for Drupal 6 - thank you very much!!

Version:7.x-3.0-alpha1» 6.x-3.7

#118 is needed for me, and appears to solve the issue, certainly seems to still exist an issue with cache, i am running 6.x-3.7 and needed #118.to avoid a fatal.

StatusFileSize
new1.11 KB

Re-rolled #98 patch for 6.x-3.7. And it seems it works for me.

how to use this patch???

Actually #118 this seems to only work when I'm logged in. I have an exposed filter shown in block on my frontpage which creates the error only there.

#144's patch rocks, thanks folks!!!!

#144's patch didn't work for me, with HS 3.6.

I do not think that #143 is the way to go. The success people are seeing is a coincidence of different cache storage engines, which depend on the actual drupal install, but do not solve the underlying issue. Furthermore the cache should probably based on form ids and not on the whole session.

My idea was to recreate the missing cached data from $_POST['nodes']. $storage['#names'] now looks fine, but unfortunately something from the parameters/form_state still seems missing. The form created by drupal_retrieve_form does not have the part required by _hierarchical_select_get_form_item.

I'm having the same issue with 6.x-3.x dev. In fact, I'm having the same problem everyone else is having. BUT if I switch themes from my custom theme back to a default drupal theme (garland, blue marine, etc), the error goes away and everything workds fine. Does that shed any light on anything?

thanks,
blue

Category:bug» support

I am using a Content Taxonomy Field with Hierarchical Select widget in one of my cck's. Initially the field was working fine.

Then i enabled multistep module on this cck and this particular field was moved to the third step. Now when trying to select values in this field i get a JS alert: "Received an invalid response from the server."

Category:support» bug

...no need to be changing the issue's category though Ayush.

multistep or multiselect? (as in the link)

StatusFileSize
new107.54 KB

Hi Guys and Girls

I desperately need someone to help me figure out why I'm getting this error. I'm not clued up in JS or AJAX or PHP at all. I'm note sure where to start looking. I have been working on a site for months now, and all of the sudden getting this problem now. I've tried disabling most of the other modules on the site, but with no luck at all.

I don't use ctools.
I've tried different browsers, and pc. Happens on all.
When the issue just started, clearing the cache would normally fix it, but now its just stuck, nothing helps.

Hierarchical Select 6.x-3.7
Drupal 6.20

I'm willing to offer a reward to whoever helps me figure this out. I seriously cannot re-do this entire site, it will drive me crazy.

Please Please please help??

Try taxiselect module - I think it's not difficult to replace one with another

Quick Update on Post 154:

I went into phpMyAdmin and emptied every single cache table I could find, I also disabled all settings on the performance page, and rebuild the theme registry.

One of those seemed to have fixed the problem for the time being, until it happens again.
It does seem to be a cache issue though? At least it's working again, what a relief.

Please keep an eye on future changes on your site or test site, or anything that can help troubleshooting.
The invalid response is a cache issue in the sense that HS makes a cache entry and will throw the error if there's a mismatch.

You may have had cached pages trying to access HS entries that no longer existed, thus clearing the cache tables helped.
But if you have some special caching like views data cache you may keep running into invalid responses.

I have the same problem with D6.22 + HS 6-3.7 too.
It only append when cache is enable and cache lifetime isn't "none".
If I try to edit two pages at the same time, when the first is saved, the second can't use HS: the message "Received an invalid response from the server" appears. When page is refreshed, I have the drupal warning message :

warning: Missing argument 2 for drupal_retrieve_form() in /var/.../includes/form.inc on line 331.
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in /var/.../includes/form.inc on line 377.
warning: uasort() [function.uasort]: The argument should be an array in /var/.../includes/common.inc on line 2944.

Drupal core 6.22
Content Construction Kit (CCK) 6.x-2.9
Hierarchical Select 6.x-3.7 (HS + HS Flat List + HS Taxonomy)
jQuery UI 6.x-1.5

@Wim Leers who said #123 : For now, I'm going to release version 3.7 without this patch.
What about the next release?

"Received an invalid response from the server" can appear even if cache lifetime is "none".

same problem as in #45; attachments in views break HS when setting 'inherit exposed filters' to 'yes'
- not using ctools

StatusFileSize
new12.15 KB
new53.26 KB
new31.42 KB

Confirming this issue. We fixed this temporarily by disabling HS feature: "Require associated node" (step2.png).

Steps to reproduce issue
1. Edit your Views
2. Click on the settings icon to edit your "Taxonomy: Term filter". (step1.png)
3. Click on "Configure Hierarchical Select" link
4. Under "Require associated node" set to "Enabled" (step2.png)
5. Click on "Save" button
6. Save view
7. Test by selecting any term from HS. Then select another term.
8. Drupal will return the error: "Received an invalid response from the server." (step3.png). Expected result is no error.

With
* HS 6.x-3.7
* Views 6.x-2.12
* Views cache: Timebase: none
* Views filter "Taxonomy: Term". Exposed.
* CCK 6.x-2.8
* Drupal 6.22
* All Drupal caches activated

I'm using CTools, Content Profile, and HS on 6.22. If I create content like normal, HS works fine. If I'm trying to do it on the Content Profile form, it dies. One thing I notice too is that on the Content Profile form, the arrows for terms that have sub-terms is gone while on create content, the arrows are there.

I'm not using Content Taxonomy, but just the straight core Taxonomy field.

I had the same problem when I deactivate clean URL. After enable it again it starts working fine.

Also, make sure you run update.php / database update. I was experiencing this issue, and found that the following pending database update had not been run yet, which, after running it, resolved the issue:

Do you wish to run all pending updates? (y/n): y
Executing hierarchical_select_update_9 [success]
CREATE TABLE {cache_hierarchical_select} ( [success]
`cid` VARCHAR(255) NOT NULL DEFAULT '',
`data` LONGBLOB DEFAULT NULL,
`expire` INT NOT NULL DEFAULT 0,
`created` INT NOT NULL DEFAULT 0,
`headers` TEXT DEFAULT NULL,
`serialized` SMALLINT NOT NULL DEFAULT 0,
PRIMARY KEY (cid),
INDEX expire (expire)
) /*!40100 DEFAULT CHARACTER SET UTF8 */

I had been banging my head against a brick wall with this one for a LONG time... tried all these patches, changes to common.inc and to hierarchical_select.module... nothing worked.

I was only getting the error with non-admin users. Turns out it was down to a permissions issue. If authenticated users didnt have permission to edit the Content Taxonomy Fields CCK type, then they received the error.

Hope that helps someone out :-)

patch on #118 worked for me. thanks!

Version:6.x-3.7» 6.x-3.x-dev

#538022-143: JS alert: "Received an invalid response from the server." didn't work for me unfortunately. My problem seems to be related to Content Profile Registration and the $form array that Hierarchical Select checks not matching what it apparently expects even though the data is there. How frustrating. If anyone has any ideas, please advise!

Bumping to -dev because it happens there.

Turned off the cache module on a long shot. That didn't fix it either.

With data you refer to the entry (hs_form_build_id, etc.) that is added to the actual form?
Does the hs break on the first load or only when the form is submitted?

Do not know how content profile works, but since it's a problem with a module feel free to open a separate issue.
The patches here only cover the corresponding cases, the error would still happen when the entry goes missing in other ways.
(such as manually clearing the cache or if is lost during form alter, etc.)

StatusFileSize
new959.99 KB

Whoa, thanks for replying! With data i mean that the form structure is there. I've attached an output of the array passed to _hierarchical_select_get_form_item($form, $name); on line 371 of hierarchical_select.module. The value of $name is "taxonomy[4]". For some reason, this fails, and then of course the rest fails because $part_of_form winds up being set to FALSE.

I've tried permissions and patches without luck. I also updated to the latest Content Profile -dev version.

I'll open a new issue if you deem that better; I'm just not sure how to phrase it.

I thought that it was an error of hierarchical_select but the problem came from another module : node_clone
See this post.

I'm still encountering this, unfortunately. I have traced it down to what is different between where it works (Content Profile editing form) and where it does not (autoassignrole-generated role-specific registration page that also has Content Profile fields on it).

The problem is that no form elements seem to have #name set, which is what Hierarchical Select looks for.

No clue why those elements aren't set. What part of the code sets those up? I can debug it...if I can find it.

Problem finally solved. It was a strange situation, and I still don't know why the solution worked.

Basically, I use Auto Assign Role, which provides its own setting to show the Content Profile form (of which an HS field was a part) at registration. If both this and the "Use on Registration" settings of more than one Content Profile content type are selected, I guess the form generation gets messed up somehow (or it tries to add two different forms? I dunno) and HS fails.

So when using Auto Assign Role with specific paths, no need to check Use on Registration...the settings are separate.

Hope this helps someone, since I appear to be the first person who's had this problem and figured out the cause.

Hi,

I'm also getting this error when using a HS for taxonomy on a view, as a filter.

Using latest versions of HS & ctools, do not have node clone installed.

I've tried numerous patches from this issue and others, including #144. Issue sounds similar to http://drupal.org/node/538022#comment-4716518 (#158).

In watchdog after the error I'm seeing:

Missing argument 2 for drupal_retrieve_form() in /srv/www/xxxx/includes/form.inc on line 331.
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 /srv/www/xxxx/includes/form.inc on line 377.
uasort() [<a href='function.uasort'>function.uasort</a>]: The argument should be an array in /srv/www/xxxx/includes/common.inc on line 2944.

Here's an export of the view:

$view = new view;
$view->name = 'energyefficiencydatabase';
$view->description = 'Energy Efficiency Database';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Override',
    ),
  ),
  'tid_1' => array(
    'label' => 'Process group',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'type' => 'separator',
    'separator' => ', ',
    'link_to_taxonomy' => 0,
    'limit' => 1,
    'vids' => array(
      '8' => 8,
      '3' => 0,
      '4' => 0,
      '2' => 0,
      '5' => 0,
      '11' => 0,
      '7' => 0,
      '21' => 0,
      '6' => 0,
    ),
    'exclude' => 0,
    'id' => 'tid_1',
    'table' => 'term_node',
    'field' => 'tid',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'tid' => array(
    'label' => 'Unit process',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'type' => 'separator',
    'separator' => ', ',
    'link_to_taxonomy' => 0,
    'limit' => 1,
    'vids' => array(
      '6' => 6,
      '3' => 0,
      '4' => 0,
      '2' => 0,
      '5' => 0,
      '11' => 0,
      '8' => 0,
      '7' => 0,
      '21' => 0,
    ),
    'exclude' => 0,
    'id' => 'tid',
    'table' => 'term_node',
    'field' => 'tid',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'tid_2' => array(
    'label' => 'Sectors',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'type' => 'separator',
    'separator' => ', ',
    'link_to_taxonomy' => 0,
    'limit' => 1,
    'vids' => array(
      '7' => 7,
      '3' => 0,
      '4' => 0,
      '2' => 0,
      '5' => 0,
      '11' => 0,
      '8' => 0,
      '21' => 0,
      '6' => 0,
    ),
    'exclude' => 0,
    'id' => 'tid_2',
    'table' => 'term_node',
    'field' => 'tid',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'field_ee_introduction_value' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'label_type' => 'none',
    'format' => 'default',
    'multiple' => array(
      'group' => TRUE,
      'multiple_number' => '',
      'multiple_from' => '',
      'multiple_reversed' => FALSE,
    ),
    'exclude' => 0,
    'id' => 'field_ee_introduction_value',
    'table' => 'node_data_field_ee_introduction',
    'field' => 'field_ee_introduction_value',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('sorts', array(
  'created' => array(
    'order' => 'DESC',
    'granularity' => 'second',
    'id' => 'created',
    'table' => 'node',
    'field' => 'created',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'eedsolution' => 'eedsolution',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'status' => array(
    'operator' => '=',
    'value' => '1',
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
    'relationship' => 'none',
  ),
  'term_node_tid_depth_1' => array(
    'operator' => 'or',
    'value' => array(),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'operator' => 'term_node_tid_depth_1_op',
      'label' => 'Process Group/Unit Process',
      'use_operator' => 0,
      'identifier' => 'term_node_tid_depth_1',
      'bef_filter_description' => '',
      'bef_format' => 'default',
      'optional' => 1,
      'single' => 1,
      'remember' => 0,
      'reduce' => 0,
      'vfs_selective' => 0,
      'vfs_active' => 0,
      'bef_select_all_none' => 0,
    ),
    'type' => 'hierarchical_select',
    'limit' => TRUE,
    'vid' => '6',
    'depth' => '0',
    'id' => 'term_node_tid_depth_1',
    'table' => 'node',
    'field' => 'term_node_tid_depth',
    'hierarchy' => 1,
    'configure_hs' => '<a href="/admin/build/views/hs_config/energyefficiencydatabase/default/term_node_tid_depth_1">Configure Hierarchical Select</a>',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
    'reduce_duplicates' => 0,
  ),
  'tid_1' => array(
    'operator' => 'or',
    'value' => array(),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'tid_1_op',
      'identifier' => 'sectors',
      'label' => 'Sectors',
      'bef_filter_description' => '',
      'bef_format' => 'bef',
      'optional' => 1,
      'single' => 0,
      'remember' => 0,
      'reduce' => 0,
      'vfs_selective' => 0,
      'vfs_active' => 0,
      'bef_select_all_none' => 0,
    ),
    'type' => 'select',
    'limit' => TRUE,
    'vid' => '7',
    'id' => 'tid_1',
    'table' => 'term_node',
    'field' => 'tid',
    'hierarchy' => 1,
    'relationship' => 'none',
    'reduce_duplicates' => 1,
  ),
  'keys' => array(
    'operator' => 'optional',
    'value' => '',
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'keys_op',
      'identifier' => 'keywords',
      'label' => 'Contains keyword(s)',
      'optional' => 1,
      'remember' => 0,
    ),
    'id' => 'keys',
    'table' => 'search_index',
    'field' => 'keys',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'role',
  'role' => array(
    '2' => 2,
  ),
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('title', 'Energy Efficiency Database');
$handler->override_option('empty', '<p class="error">Sorry, there are no energy efficiency solutions to show at this time.</p>');
$handler->override_option('empty_format', '1');
$handler->override_option('use_pager', '1');
$handler->override_option('distinct', 0);
$handler->override_option('row_options', array(
  'inline' => array(),
  'separator' => '',
  'hide_empty' => 1,
));
$handler->override_option('exposed_block', TRUE);
$handler = $view->new_display('page', 'Page', 'page_1');
$handler->override_option('path', 'energyefficiency');
$handler->override_option('menu', array(
  'type' => 'normal',
  'title' => 'Energy Efficiency',
  'description' => '',
  'weight' => '0',
  'name' => 'menu-energyefficiencydatabase',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));

Please let me know if there's any other info that could help.

Hey Alli, I cannot help you with your issue, but could you please upload your exported view in a txt file and remove the huge code chunk from your last post. This issue is long enough as it is.

Thanx in advance for understanding ;)

I set 'Minimum cache lifetime' to 'none' but it still doesn't work for me. I'm using a custom template for the node type that has HS content taxonomy.
When I print the whole field group like this:
<?php print drupal_render($form['group_example]); ?>
HS works with other fields but it does work when I try to print only the individual field of the content taxonomy using HS like this:
<?php print drupal_render($form['group_example']['field_HS']); ?>
It also works when I disable the custom template and use the default one.
Any suggestion?

EDIT:

Sorry I was actually misunerstandng that it doesn't work also when I print <?php print drupal_render($form['group_example]); ?> but it works only when I print <?php print drupal_render($form); ?>

The patch from #143 fixed my issue, tnx!

Custom node form template, hierarchical select is rendered as drupal_render($form['taxonomy']['4']), got this error trying to "create new item".

StatusFileSize
new133.64 KB

I have the same issue and i found a solution to my case,
i have an Arabic website,
i set the default language to Arabic and disabled the English.
when i select any taxonomy i get the same error.
looking at the console in Firebug i found the error 404 path mysite/ar/hierarchical_select_json
the solution in my case is to enable the English language
it will works with the same path mysite/ar/hierarchical_select_json
may this will help you

Status:Needs work» Needs review

Same old issue here: no JS errors in the console, just the "Invalid response from server" error.

Setting Minimum Cache Time to solves the problem. Switching theme to Garland does not.

Patch #143 applies to 6.x-3.x-dev and solves definitely the problem, thanks!

(reverting to Needs review as seems status was accidentally changed)

I can confirm that patch #143 does fix this issue.

We also had immediate success with the patch from #143. We did not experiment with any other fixes (cache, etc.) so we can't attest to whether or not those are better options.

Also exists on 7.x-3.x, can reproduce by simply selecting a term which triggers the children to be loaded, then reselecting a new parent.

Edit: Have done some more testing and have figured out what's causing it. On a fresh drupal install using 7.x-3.0-alpha5 (dev version also does this), if you have "Save term lineage" AND " Allow the user to choose a term from any level" selected in your HS config you get this error when doing the actions above.

seems like patch @ #143 solved my problem

Another + on the patch @ #143. Works great for me.

unfortunately patch #143 isn't working for me

StatusFileSize
new1.58 KB

Patch #143 doesnt work.
I tried to expand it:
In function hierarchical_select_json:

<?php
$hsid
= $_POST['hsid'];
$name = $storage['#names'][key($storage['#names'])];
?>

That way it always set correct name from $storage.
In that array, form name is tied on key, which is $hsid. But $hsid is in $_POST for example 24 and in $SESSION 25.
After I select again in HS, $storage gets stuff from $SESSION which has $hsid key in #names $hsid_from_POST + 1. If we use $hsid form POST we d get nothing from $storage and that will throw error.

But while this fixed showing this annoying error and HS seemed to work, there was actually a problem with showing list in second depth in HS. Like for example, I select country in first level and should list me country's cities in second level. It does list them, but only part, not all. So I guess some problem is still lurking around which I still didnt locate.

#143 Patch upgrade in attach.

If you are having this problem and also care about caching for your anonymous users, the patch in #1620982: Don't store anything in $_SESSION - breaks caching for anonymous users also solves this issue.

Issue summary:View changes

#92 works like a charm for me, THANKS A LOT!! You saved me a lot of time!