Error "Invalid response from server" with Hierarchical select in panels (Broken)

Tidying up the issue queue. The 6.x version is no longer supported. Only reopen this if it also applies to the 7.x.

Bug is reproducable in 7.x like described in the OT. Disabling panels for this edit view brings back hierarchical select functionality.

2 possible ways to discuss before writing patches:

• A fast work around: checkbox to disable HS for panels (yes/no) to still keep the field usable in panels.
• The long road: tackling down where panels or maybe ctools gets in the way of HS to fix it. Maybe it needs a cooperated patch for panels or ctools too. Let me catch some panels guys for this on IRC.

I would rather see the underlying issue fixed than add a checkbox

Thanks for your fast reply, @stefan.r
Agreed. Just wanted to make sure, that no time is wasted in walking down dead roads.

Well, it seems, there will be no guidance in this issue from any panels involded folks anytime soon yet. Tackling it down allone as somebody not involved in panels code much, would take much time and would be very inefficient while there are some who may know where to start. FIrst I would like to see more people chimging in being interested in a fix and some hints where to look at before I would start to get my fingers dirty on it.

To reproduce this issue:

• Install latest Drupal 7 with panels ctools views devel and hierarchical select.
• Extend your default content type article with the hierarchical select widget, e.g. for the tag field.
• Create some tags and content with devel_generate.
• Activate the default panel node/edit form panel variant and start layouting your article node form.
• Try to edit a node and try to add some new or given tags represented by the hierarchical select widget.
• The Error "Invalid response from server" pops up immediately in a little browser error message popup.
• The tag has not been choosen.
• But you can still go on with editing and saving your node. But no tags.

One of the very first things to make clear first would be the question if this is rather a HS or a Panels issue from the bottom.

Interesting is the fact that it does not work in node edit panel pages but it does in node view panels pages with editable fields and hierachical select :-P

Thanks for the detailed instructions diqidoq. They were sufficient to replicate the issue.

Discovery: I set the variant up so that it only triggered on Articles. I also added the HS widget to the Basic Page so I could test with and without panels in the same instance.

Initial discovery is that form_id is not being sent in the POST from the form on the panels based form. This prevents ajax_get_form() from finding the form at all and it bails early with a drupal_exit() that returns a zero length 200 OK response. The zero length is what HS reacts to in this case.

I will continue to dig into this and see if I can work out why the form_id isn't part of the form POST.

Hmm... This isn't an issue with HS. It is just floated to the surface due to it.

All of the standard hidden form fields are absent in the form in a panel variant. The changed, form_build_id, form_token and form_id are all absent regardless of the use of the HS form widget.

I'm seeing 2 ways around this.

1. Throw it at Panels (but I would expect that to have been a thing already and can't find any references to it in the issue queue.)
2. Strip out the requirement in the AJAX call to use the full form and just rebuild the bit we want from the state we have available.

Thoughts?

For what it's worth this is also an issue with Views Megarows when you are editing a node. It returns back the same error message and I would imagine that it is associated to the lack of id not being sent.