"Invalid Response from Server", possible causes and solution

same problem here, i create node form on different path and i got this same error

i fix this problem by put below code at line 290 on hierarchical_select.module

require_once(drupal_get_path('module','node').'/node.pages.inc');

it works now
i hope it will help other who may have same problem

thanks
Rizqi

Hierarchical Select compatibility: gotcha's
-------------------------------------------
- "Invalid response from server"
  This typically means that some functions could not be found when
  Hierarchical Select does an AHAH callback to the server, which in turn means
  that some code (some PHP file) has not been included, while it should have
  been.
  Hierarchical Select supports the same system to define files that should be
  included as CTools:
    $form_state['form_load_files']
  Hence you should do something like this in your form code:
    $form_state['form_load_files'] = array(drupal_get_path('module', 'node') . '/pages.inc');
  Which could look like this in your case:
    $form_state['form_load_files'] = array(drupal_get_path('module', 'mymodule') . '/something.inc');

This has just been added to API.txt — issue: #640534: Document CTools' $form_state['form_load_files'] compatibility.

Hi guys, thanks for getting to the bottom of this, it's been driving me crazy for some time. Sorry about bumping this issue, but I was just seeking some clarification on the fix you described in API.txt. I'm writing a function that clones a CCK content type which has HS/Content Taxonomy fields. The code looks like this:

function clone_job($nid) {
  global $user;
	
  $node = node_load($nid);
  $node->nid = NULL;
  $node->vid = NULL;
  $node->name = $user->name;
  $node->uid = $user->uid;
  $node->created = NULL;
	 
  module_load_include('inc', 'node', 'node.pages');  
  $form = drupal_get_form('job_node_form', $node);
  return $form;
}

Would your suggested fix be added to $form here, or would I have to implement the fix in hook_form_alter()?

It should be added there, in the piece of code you're quoting. It's of course still possible to do it through a hook_form_alter() until it's implemented there.

I use a view plugin to display node forms for each node in the view. The same error popped up until I added the snippet to the plugin:

  $form_state['form_load_files'] = array(drupal_get_path('module', 'mymodule') . '/something.inc');

This seemed to fix the issue in the sublevels of a multi-level taxonomy select. The top level selection still broke until I added:

  module_load_include('inc', 'node', 'node.pages');

on line 291 of hierarchical_select.module

@scheepers: just also add node.pages.inc to the form_load_files array and you should be good — without a HS hack :)

im seeing the same issues when using Firefox, opera, safari and chrome with this module. if i am in the wrong thread (there is another at http://drupal.org/node/538022) pls advise.

based on a clean install (drupal 6.16), with no modules other than the core modules, Hierarchical Select (6.x.3.1), and the example module (hs_taxonomy_filter_block) as posted as a block from the drupal site. caching has also been disabled. i have 2 levels of hierarchy.

testing (all windows) ..
everything works fine in IE6/7/8
when searching 1 level - ok in IE7/8 + Firefox
2 levels - ok in IE7/8 + FF for the 1st time.

the prob occurs when the back button is pressed in FF, its more apparent in safari, as the form (1st tier is highlighted without the 2nd tier) doesn't get cleared. the "Invalid response received from server" errors occurs, obviously this wont work as the browser expected an entry for the 2nd tier. refreshing the screen at this point, brings up the 3 errors as listed at the beginning of the thread, Missing argument 2 etc. refresh the screen a second time and the form is reset, the cycle begins again.

ive tried to fix the issue with the 3 suggestions above, but to no avail. im no programmer, but i can see where the issue is, i just cant fix it. the nearest line i can see to your suggested fix is 'if (isset($form_state['form_load_files'] ))' - but this is an if statement which produces an error. but this thread is based on the dev version not the version im currently using.

i have also looked at the online demo (http://verenigingen.nieuwsblad.be/verenigingen_start) in Firefox - their site deliberately disables the search form if a user hits the back button. is there an overall browser issue?

i do like this module and i want to implement it successfully, but browser support is the top most priority for me.

also a lot of coverage here - http://drupal.org/node/538022#comment-1881220

ill take a look and see what develops around here.

I solved this issue by choosing 'none' on "Minimum cache lifetime" - /admin/settings/performance (DRUPAL 6.16)

why this cause the HIERARCHY SELECT module?

I have received this message quite a couple of times - "Received an invalid response from server".

I am also running the "Backup & Migrate" module which gives me "Restore Points".
What I used to do is to do a "Restore" and test "Hierarchical Select" to see if I can add new taxonomy terms from the "Create a new page" page, and then "Restore" to an earlier date, until I eventually found a "Restore Point" which allowed me to create new taxonomy terms without giving me the error.

Today I realized my site was giving the exact same error again.
As you can imagine; I do not know when the error started appearing - so this is a pain in my heart.
This time I have too much content which I added - thus I did not want to do a "Restore".

So I did some research and after reading seemas' post #10 I decided this seems so simple I am going to give it a try.
You won’t believe it; it actually worked.
My site's cache settings - before I fiddled with it:
Caching mode: Normal
Minimum cache lifetime: 3hours
Page compression: Disabled
Block cache: Enabled

I then changed my settings to:
Caching mode: Disabled
Minimum cache lifetime: none
Page compression: Disabled
Block cache: Disabled

Clicked on "Clear cached data"
Ran a cron

Tested to see if I can create a new taxonomy term using "Hierarchical Select"; and it worked

Switched my settings back to:
Caching mode: Normal
Minimum cache lifetime: none - take note that I tested this a couple of times and it has to be "none"
Page compression: Disabled
Block cache: Enabled

Tested to see if I can create a new taxonomy term using "Hierarchical Select"; and it still worked

I am no guru; thus I am not going to try and figure out why it works - but what I can tell you is that I am truly relieved

@entendu Thank you so much. This fixed the issue I had with displaying the HS on a custom form.

Wim, marking this as critical to get your attention and probably solve all these 'invalid response' issue once and for all - or at least have a good pointer to solve :) Most likely when this error occurs, the 'hs_form_build_id' cache entry in the cache table dissapeared. The use case I had is pretty simple:

• On my home page, I have a simple hs select form - all goes well as long as you don't submit. My submit function takes me to another page which starts a search based on the selection.
• Now, when I come back to my home page after a submit and start selecting again, I got that annoying error. Why, simple, my home page was still in the cache because I was surfing anonymous. The hs form was gone because the _hierarchical_select_submit removes the cached entry of the form from the cache table, so it couldn't get it back from the cache.

Quick solution: in my own form, I added '$form_state['view'] = TRUE;' because that's what you are looking for in your submit function to decide if you want to remove it from the cache and all was fine again - took me a lot of watchdogs and dsm's to find this out - while it was pretty simple to fix in fact heh :)

Possible solutions:

• Reflect this at least in documentation :)
• Maybe add another property you check on in $form_state, like 'hs_do_not_clear_cache' so developers can add this to their form_state ?
• Maybe check current $user and page_cache variable ?

For you to decide, the $form_state['view'] = true is a quick work around and safe for me.

Conclusion: anonymous browsing and page cache is 99% of the time the cause of this problem. It's typical that this error pops up when preparing to go live and turning on caching (especially page caching) while it was perfectly working before.

Edit

It can be even more funny: colleague A was testing the HS select, without submitting, at the same time colleague B, who's doing some last CSS updates, flushes all caches, so the entry in the cache table is wiped. At that moment colleague A gets the popup error again. Very fun to debug :) So I think you should add another solution - although not sure - and that's a fallback, because you are now always assuming that cache_get($hs_form_id) will always be set.

The same thing happened to me; though it was happening due to the form being rebuilt on an AHAH call. How did you manage to set that in the $form_state? I couldn't get it to pass through, I had to set it in the $form and then hack the HS module a little bit. The strange thing is this AHAH did not affect the part of the form where the HS fields were.

I have another AHAH field that updates the form (hides/shows the HS forms) and found that while I could initialize the new fields by passing the Drupal.setting, they would not work because the form was POSTing the new hsid's, but getting the cache that had the old ones.

I suspect these mixed results have something to do with the fact I used ahah_helper for the first AHAH and a more traditional AHAH for the second one.

Hi Wim!

There's the same issue with "Invalid Response..." irritating error occuring @ my website (HS 6.x-3.1).
As paulgrimshaw have already said in the other thread:

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.

Spot on Paul!

I was quite sure my issue related to cache not i18n/anon/views branches. I tried to disable cache on Performance page @ my test site and cleared site cache but with no luck. Anyway I noticed the entry DavidMcLaughlin left in the very same thread:

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.

So I tried again, chose "None" for "Minimum cache lifetime" and cleared site cache. Bingo! It worked.
But I'm not sure it's a great way to resolve the problem for my live website - without caching enabled it would be cracked by heavy load immediately so hopefully you'll find better solution. Thank you!

recently having the same issue of showing error message by jquery for hierarchical select on firefox
the message does not exist on google chrome
adding the module_load_include line to include node.pages.inc works

for those of you who can't wait for the patch to be include in release
and don't want to hack the code everytime, below is a little code i wrote to solve the problem on my site:

/**
 * Implementation of hook_init().
 */
function hierarchical_select_fix_init() {
  $menu = menu_get_item();
  if ($menu['href'] == 'hierarchical_select_json') {
    module_load_include('inc', 'node', 'node.pages');
  }
}

put this function into a module
it will load the node.pages.inc everytime on loading page at path 'hierarchical_select_json'
i.e. the json callback by hierarchical_select

#16 fix this error for me, thank you!

None of the above solutions worked for me. I've got another post at http://drupal.org/node/834596#comment-3241978, but I thought I'd follow up here.

I'm trying to use an HS widget for selecting taxonomy terms on a node/add form and was doing so just fine for a number of months. Obviously something changed which has caused the error, but I can't, for the life of me, seem to diagnose what that was.

Whenever I try to select the top term on a node/add form with an HS widget, I receive an "Invalid Response from Server" error. This is verified on the latest versions of Safari, Firefox, and Chrome on Mac.

I also receive errors such as these in my Watchdog logs:

Missing argument 2 for drupal_retrieve_form() in /mysite.com/public_html/includes/form.inc on line 326.

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 /mysite.com/public_html/includes/form.inc on line 372.

uasort() [<a href='function.uasort'>function.uasort</a>]: The argument should be an array in /mysite.com/public_html/includes/common.inc on line 2884.

I've disabled all modules that are not vital to the site, but have still had no luck. I've updated to the latest dev release of HS.

Any other suggestions?

using hierarchical select in registration form and as a result get :
warning: uasort() [function.uasort]: The argument should be an array in my site/public_html/includes/common.inc on line 2884.
Need help

    * warning: Missing argument 2 for drupal_retrieve_form() in /var/www/rvr/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/rvr/includes/form.inc on line 372.
    * warning: uasort() [function.uasort]: The argument should be an array in /var/www/rvr/includes/common.inc on line 2884.

Only happens when I'm an anonymous user. My site is using Boost. When I log in, issue disappears.

Subscribing.
Tried #16 with cache on and worked, just gotta note you have to clear your cache first to pick up the changes.

I'm now looking at the issue on #13, i have go the invalid cache on page backs.
When you submit the form you can no longer use that same form by pressing back in your browser.
If you don't submit the form it remains active.

Here's a few questions on it:

"_hierarchical_select_submit removes the cached entry of the form from the cache table, so it couldn't get it back from the cache."

1. can this be overriden?
2. or is a patch needed?
3. in that case, when can you remove the cache entries then? upon logout or some timeout?

"Quick solution: in my own form, I added '$form_state['view'] = TRUE;' because that's what you are looking for in your submit function to decide if you want to remove it from the cache"

4. But that was for a views forms isn't it? like for exposed filters? Won't have views for custom forms.
5. Do that stop _hierarchical_select_submit from removing the entries?
6. Do $form_state['view'] = TRUE; go on the $form function or on the submit function? (has $form_state)
7. Same goes for $form['cache'] = FALSE; would the submit detect this condition?

Now, if we are looking to do something on the submit function:
8. Is that _hierarchical_select_submit or your modulename_submit function?
9. Once there, is there a function you can call to not invalidate the cache?

thank you for your help

@inforeto
I added my own submit callback to the hs form and put it before the submit function of HS. You're right that my own form was not a view, but passing the $form_state['view'] = TRUE did the trick. It's not the purpose, but it works :)

Thanks for your fast response, saw the code that checks for view in _hierarchical_select_submit.

Not sure where or how to add the callback, trying with:

function custommodulename_hierarchical_select_submit($form, &$form_state) {
  $form_state['view'] = TRUE;
}

Then cleared chache, but didn't work right away, pending further debug.

Also checked module weights, both custommodulename and hierarchical_select are located in /sites/all/modules.
HS has weight of 16, HS taxonomy has weight of -1 and everything else on /sites/all/modules have weight of 0.

The actual custommodulename_form_submit (called when the form is submitted) has a drupal_goto which HS comments that would prevent calls to _hierarchical_select_submit.
Setting $form_state['view'] = TRUE; in this function didn't work either.

Pending further testing i tried commenting out the whole line in _hierarchical_select_submit and this made the 'invalid' stop.
(following the mention on _hierarchical_select_submit that the cache is still cleared after minimum cache times)

Post #11 is a saver for me! I can confirm that my HS starts working like a dream after i have made the changes according to JCB's post. Thanks so much JCB!!!

I also have the "invalid response". We had hierarchical select 3.3 without having this problem. Now we upgraded the module to version 3.5 and when selecting a taxonomy term instead of loading the children, we get the "Received an invalid response from the server." message....
I tried disabling backup and migrate module and even the solution in comment #11, but it is not helping me.

Same problem here, solution from #15 (setting to 'none' the minimum lifetime in cache) did it for me even though I'm using boost, not the internal cache.
Also, leaving the cache lifetime from boost to its default value didn't trigger the error.

    warning: Missing argument 2 for drupal_retrieve_form() in /home/u2911/domains/u2911.titan.vps-private.net/includes/form.inc on line 330.
    warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in /home/u2911/domains/u2911.titan.vps-private.net/includes/form.inc on line 376.
    warning: uasort() [function.uasort]: The argument should be an array in /home/u2911/domains/u2911.titan.vps-private.net/includes/common.inc on line 2935.

same problem

Now that HS cache was moved to a separate table as shown in http://drupal.org/node/851512, is there a chance to have this cache not erased on drupal's cache lifetime?

It could have it's own lifetime to use in _hierarchical_select_submit() so that we can keep drupal's minimum cache lifetime at values other than none.

Second, may not erase it on a global call to cache_clear_all but rather on a special button in the admin/settings/hierarchical_select.
(sometimes it happens on cron run and users suddenly find their HS forms invalid)
It'd be just like the button to clear the views cache in the views settings.
(which is a good example on how to add cache times larger or smaller than the global minimum lifetime)

Lastly, not erasing it on submit allows the user to press back in the browser to search again on a HS enabled form.
For using HS on custom forms the only workaround is to set $form_state['view'] as mentioned above.

Thanks For Help
I solved Same Problem with thelp from comment #10

also getting, "Missing argument 2 for drupal_retrieve_form()"

Nov 11 16:45:22 p2 drupal: PHP Stack trace:
Nov 11 16:45:22 p2 drupal: PHP 1. {main}() /var/www/vhost/testsite.com/drupal/index.php:0
Nov 11 16:45:22 p2 drupal: PHP 2. menu_execute_active_handler() /var/www/vhost/testsite.com/drupal/index.php:18
Nov 11 16:45:22 p2 drupal: PHP 3. call_user_func_array() /var/www/vhost/testsite.com/drupal/includes/menu.inc:348
Nov 11 16:45:22 p2 drupal: PHP 4. hierarchical_select_json() /var/www/vhost/testsite.com/drupal/includes/menu.inc:0
Nov 11 16:45:22 p2 drupal: PHP 5. drupal_render() /var/www/vhost/testsite.com/sites/all/modules/hierarchical_select/hierarchical_select.module:346

tried #10, and #16, no luck

any updates to this?

I can confirm that when I set
'Minimum cache lifetime' to 'none'
HS (on taxonomy) works as expected. The cache of a whole form is lost when 'Minimum cache lifetime' is set to something else.

FYI 'Caching mode' is set to normal.

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

I'm using HS for the menu system. None of the different cache settings or other fixes don't see to fix the JSON error. HS works for the first few clicks then stops responding, throwing up the pop-up JSON error message.

Should I just create a new ticket for this with the menu system?

Subscribe. Getting the following error:

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

#11 works for me - fixed both Hierarchical select, image upload (using imagefield) and textfield (Add another item etc) - so all the ajaxy stuff.

Side note, This doesn't seem to happen for me on PHP 5.2 servers? My site with the error is on php 5.3? Could this be signifcant? (But I could be wrong?)

My site with the error is php 5.2.9, afaik the php version do not affect caching.
Disabling cache as per #11 is a known workaround, but let's seek a solution that includes caching.

I have the exact same error message at stinky.

Subscribe.

This is all very confusing. When people say enter a line of code in hierarchical_select.module at line ###... it doesn't seem to match mine (3.6).

I have ctools, panels and hierarchical select going. I get the 'invalid response from server' error when trying to use HS with an exposed filter in block.

I've tried adding code. No changes... help?

:/

@tribe:
Lines around 290 to 310 belong to function hierarchical_select_json()
So you either add the fixing lines at very the beggining or after the first few lines that are mostly initialization code.

If it doesn't work remember that this issue can have other causes, see the other threads about the 'invalid response from server'.

subscribe

There appear to be separate threads here. Let me address them separately

Thread 1
#13 Thanks Kristof, very insightful. With recent changes to how HS handles caching, I can actually simply delete the _hierarchical_select_submit() function. If you theory applies to all of those whom still have this problem, then this would be one epically easy fix. I sure hope that you're right :)

Follow-ups include: #14, #15, #22, #23, #24, #29. Thank you, swentel and inforeto for your insightful comments. Thanks to Ingumsky for your helpful citation.

Thread 2
These are all others, starting with #16. In these cases, the cause is often a buggy other module that doesn't yet include node.pages.inc properly. This is documented in API.txt:

Hierarchical Select compatibility: gotcha's
-------------------------------------------
- "Invalid response from server"
This typically means that some functions could not be found when
Hierarchical Select does an AHAH callback to the server, which in turn means
that some code (some PHP file) has not been included, while it should have
been.
Hierarchical Select supports the same system to define files that should be
included as CTools:
$form_state['form_load_files']
Hence you should do something like this in your form code:
$form_state['form_load_files'] = array(drupal_get_path('module', 'node') . '/pages.inc');
Which could look like this in your case:
$form_state['form_load_files'] = array(drupal_get_path('module', 'mymodule') . '/something.inc');

Conclusion
I'm going to tentatively commit the fix suggested by swentel. I'm going to remove the #submit callback (_hierarchical_select_submit()). This is not a problem, since most cached items are being deleted on cron run anyway. So this can't break anything, it can merely slightly increase the size of the cache_hierarchical_select table.

See http://drupal.org/cvs?commit=495538.

Thus: install the dev tarball and if it still doesn't work, please continue in #538022: JS alert: "Received an invalid response from the server.".

Removing the submit callback is a good fix, will help with users that navigate back to a page that has already been submitted.
(causing an 'invalid response' error when trying to load a deleted entry)

I had taken out the function myself by commenting out the line to solve this issue on my site.
Nothing else breaks provided your cache clears on cron (fixed on newest version).

Excellent — and thanks for confirming :) And thank you very much, inforeto, for your continued help in this project's issue queue! :)

the #11 solution is OK!

I had the "Invalid Response from Server" using an exposed views filter, problem was that I made my filter only on a "Page" display which was not available on "default" display, upon deleting it and recreating the exposed filter on "default" tab the problem was resolved.

No solutions works for me, from above list

any update?

Try checking your themes template.php file for HTML comments or spaces before the opening php tags, if you find any remove them and recheck the functionality.

I had this issue and solved it by going through the standard debugging process. I first disabled the theme that I had made and checked if the issue still occurred. After my theme was disabled the Hierachical Select worked fine, I then disabled all JS files in the theme and re enabled it, Hierachial Select stooped working again, this meant that the issue was not to do with the JS in the theme.

I then thought that it might be caused by a function in the themes template.php file. I temporarily deleted this files from the theme on my test server and Hierachial Select started working again. After some time I realized that there was an HTML comment in the template.php that was causing the issue.

#48 seems to have saved the day for me... i'll come back and update if not... I'm using v3.8

The whole thing for me was about the cache. I put the exposed filter in a block and loaded it with ajax. Never seen the problem since.