Posted by schvili on November 5, 2009 at 5:49pm
Jump to:
| Project: | Hierarchical Select |
| Version: | 6.x-3.x-dev |
| Component: | Code - Content Taxonomy |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Hi Win.
Thank you for a great module! I got the same error as several others. Could it be connected to permissions?
Step by step:
Role: Admin
1. Install the needed modules
2. Create a new Content Type
3. Add a field in CCK that uses the Hierarchy Select widget.
4. Create new content
5. Select a term in the first level.
6. Next level expands (it works!)
7. Logout
8. Login as a 'authenticated' user, not admin
9. Create new content
10. Select a term in the first level of the hierarchy
11. Get the error message 'Received an invalid response from the server.'
Would be very grateful for support on this. We are planning to go live next week and would really like to have include you great module.
Matti
Comments
#1
I have the same problem, but with all users, include admin.
#2
Please provide a list of your modules an information of your enviroment.
there must be an incompatiblity with other taxonomy modules or with modules relatedt to sessions.
#3
same here when i use the default implementation of the hiearchy param of hs_smallhierarchy.module
$hierarchy = array('win' => array(
'label' => 'Windows',
'children' => array(
'xp' => array('label' => 'XP'),
'vista' => array(
'label' => 'Vista',
'children' => array(
'x86' => array('label' => '32-bits'),
'x64' => array('label' => '64-bits'),
),
),
),
),
);
and the firebug console message:
Fatal error: Unsupported operand types in drupal-6.14/includes/common.inc on line 2877
this is the drupal_render() function
#4
I get the same error, but only in nodes that have been newly created via the link that nodereference_url places in the referenced node. When I create the node via the "Create content" link (without preselecting the nodereference) everything works ok, the same when I open an existing node (where the nodereference field is not write-protected). Looking at the firebug output, all that I can see (I'm not a developer) is that in the defunct case, the "Params" tab shows just "q" while in the working case it shows "q hierarchical_select_json".
Hope that helps
#5
I had the same error.
I noticed that the path that was queried is [lang-code]/hierarchical_select_json that gave a 404.
i redirected that to hierarchical_select_json and we are up and running.
Something totdo with the language selections?
#6
#7
@VDMi.Frans: It's very well this is connected to using i18n. Can somebody please research that?
Also, can somebody reproduce the problem by following the steps posted by schvili?
#8
Indeed!
It has todo with language selection other then english as default on admin/settings/language
Set the default language to dutch and it will do its request on nl/hierarchical_select_json. Set the default language to english and it will do the request on hierarchical_select_json.
I don't know enough of i18n to point you to code where the path is expanded. But i use this modules (and their dependencies) regarding internationalization and paths.
i18n
path_redirect
pathauto
transliteration
uploadpath
filefield_paths
Hope that helps.
#9
I don't have the time to test those combinations. I know that just i18n works fine — because several people have posted patches to fix translation of terms in HS in Drupal 6 (it worked fine in 5, but changed in 6).
So, if you want to see this fixed, you're going to have track down which of those modules causes the problem. I can tell you with 99% certainty that pathauto, uploadpath and filefield_paths are not the causes, so I'd start with the other three modules.
#10
I don't think this is caused by i18n (because I'm not using it).
I get the error not only with nodereference_url, but also with og -- to me it looks (in my ignorance) like the widget is defunct whenever a node is created with arguments:
e.g. http://localhost/drupal/?q=node/add/association works,
http://localhost/drupal/?q=node/add/association&gids[]=61 gives the error
#11
@Wim Leers #7: The pb is with the hierarchical_select.module around line 1331 where the module would like to handle the i18n module. I commented out the prefix and it works:
<?php// Prefix URL with language path when i18n is enabled and when path-based
// negotiation is being used.
if (module_exists('i18n') && ($language->prefix != '') && variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE) != "3") {
//$url .= $language->prefix . '/';
}
?>
#12
Well, that was necessary to get i18n support working (search the issue queue and I'm sure you'll find the corresponding issue), so I'm definitely not going to commit your proposed change as-is. It looks like your proposed change is most definitely going to break i18n support.
Are *you* using the i18n module? You *must* be because otherwise it wouldn't be breaking for you. How come then that it doesn't work for you and that it did work for the 2-3 people that tested the patch that went in? I'm sorry, but more research is needed before I can commit this, otherwise it'll just break for more people.
Or: how Drupal i18n is a mess.
#13
I would not describe i18n as a mess. It is one of the more nifty modules available in D6, although from what I've gathered the early D5 implementations must have been traumatizing.
The issue is related to i18n. It only occurs with specific configurations, which i regard as incorrect, but may serve some purpose.
As far as I understand it, with the settings in step 5, only the path prefix of the default language can be set to nothing.
After selecting one of the options at step 5, one might forget at step 6 to change the default path prefix for English from nothing to en. I also like to set my default language's path prefix to nothing instead.
With these settings the current issue will not occur.
NB
This is not just an interface glitch in i18n. It is the lack of multistep form interfaces throughout Drupal's administration interface where subsequent configuration steps are concerned. This is an altogether different issue related to usability and Drupal's until recently lacking form api. I do not know if it has been tackled in D7.
Edit: changed "#" to "step" to avoid confusion with comment numbers. This comment is in reply to 11 & 12 and is supported by the code shown in 11.
#14
I have the same issue when trying to create a new node from a form in a block.
When I create node from same form in content it works fine.
Happens in hierarchy as soon as I select the first parent.
Using admin account.
#15
This happens to me, using core 6.15, HS 6.x-3.x-dev, the admin account, not using a language other than English. It happens when I try to change a vocabulary term in my taxonomy, using the "Add" button to give it a new parent.
I am also unable to save a new term with a parent. The term saves to the vocabulary, but without a parent. I'm going to have to uninstall this module so I can update my vocabulary. I'd be happy to install and test with a new dev release, but I am unable to "patch" - sorry.
I noticed that the module disables HS Book and HS Content Taxonomy Views as:
"This version is incompatible with the 6.15 version of Drupal core."
#16
More info for prev post, this is in my recent log entries when it happens:
Home › Administer › Reports
Details
Type page not found
Date Wednesday, January 13, 2010 - 08:59
User **
Location http://***/index.php?q=hierarchical_select_json?destination=admin%2Fcont...
Referrer http://***/index.php?q=admin/content/taxonomy/edit/term/15&destination=a...
Message hierarchical_select_json?destination=admin/content/taxonomy/3
Severity warning
#17
Following the comments 15-16 below, my comment in response to 11-12 seems to deal with a separate issue from the original. Apologies for the inconvenience. Still, I hope it may solve things for people with a similar setup.
#18
I also get the error when I am editing the terms from a freshly-cloned unsaved node.
When I click on the hierarchy it immediately gives the error.
When I save the cloned node with the wrong terms and then edit that exact node later, it works.
#19
Hello.
Same happened to me and I solved changing config to clean URLs. Seams that it has to do with how the HS module handles the params in the url when param q is present with others like destination.
Hope this is usefull for others. And sorry for my english. I have tried my best.
Alessandro Mascherpa.
#20
Not that for me - I already have clean URLs enabled.
#21
This is also happening for me and seems to be connected to urls, but I already have clean urls enabled.
As an anonymous user with permissions, if I go to ...node/add/student my cck hs select works perfectly.
If I attempt to go to the url /student - which is the content profile for user registration, I get the "Received an invalid response from the server" error and the hs selector does not work.
Reference:
http://domain/hierarchical_select_json
uasort() [function.uasort]: The argument should be an array in /var/www/vhosts/domain/subdomains/gp/httpdocs/includes/common.inc on line 2874.
#22
This is in fact a duplicate of #538022: JS alert: "Received an invalid response from the server.". I've posted a reply to the most useful comments in this issue over there, in this comment: http://drupal.org/node/538022#comment-2658954.
Please continue there!