Hi,

I installed the latest 6.x dev version on my site. The selection of of taxonomy terms with the widget works as it should be most of the time, however, seemingly random the selection of an item seems to crash.

While most of the times adding a term works as it should, sometimes (can't really pinpoint a specific event that would trigger it), the loading seems to take forever. All buttons are disabled, and I just see a waiting cursor.

I checked with Firebug and a post is being made to path 'hierarchical_select_json'. When i watch the response value, i see the following:

<br />
<b>Fatal error</b>:  Unsupported operand types in <b>/home/svc/public_html/timd/includes/common.inc</b> on line <b>2827</b><br />

Then when I do a hard page refresh (because nothing else on the page is working), i get the following errors:

    * warning: Missing argument 2 for drupal_retrieve_form() in /home/svc/public_html/timd/includes/form.inc on line 320.
    * warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in /home/svc/public_html/timd/includes/form.inc on line 366.
    * warning: uasort() [function.uasort]: The argument should be an array in /home/svc/public_html/timd/includes/common.inc on line 2825.

I tried to find what specific event triggers the errors, but it seems pretty random from my tests.
I'm not sure if this error is related to the HS module specifically, or if something in my setup is breaking things.

If you need more info on the particular settings i configured for the widget, let me know.

Do you have an idea what could be the cause of this?

Kind regards,
Sven

Comments

Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Active » Postponed (maintainer needs more info)

Do these problems still exist with the latest version?

Wim Leers’s picture

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

Closing while cleaning up the issue queue. Feel free to reopen.

skizzo’s picture

Title: Unsupported operand types in common.inc » Unsupported operand types in common.inc on line 2831
Status: Closed (fixed) » Active

I am seeing this error with 6.x-3.x-dev 2009-04-07. I am using a Hierarchical Select form element (Save term lineage, Force the user to choose a term from a deepest level, Disabled, Disabled; Multiple select, Required) for a 3 levels selection (Region/County/City) in a content type to be used by Content Profile. The error is triggered, so far consistently, when a user tries to select the Region while registering. I have found http://drupal.org/node/362799, but having no programming skill I could not make much sense of it. Note that if I create the node (by making the taxonomy not required) and then edit the HS elements, then the hierarchical selection works nicely. Thank you.

PHP Fatal error:  Unsupported operand types in /var/www/drupal/includes/common.inc on line 2831

And in watchdog, from Location: /hierarchical_select_json

uasort() [<a href='function.uasort'>function.uasort</a>]: The argument should be an array in /var/www/drupal/includes/common.inc on line 2829
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 /var/www/drupal/includes/form.inc on line 366.
Missing argument 2 for drupal_retrieve_form() in /var/www/drupal/includes/form.inc on line 320.
Wim Leers’s picture

Obviously, Content Profile is the cause. The page you reference is unfortunately irrelevant, as the error is not around line 1300, but at 2829.

I won't have time to debug this for at least the next six weeks (exams). So if you want a quick solution, you'll have to find it yourself or pay somebody to do it for you. Sorry.

skizzo’s picture

If I understand your response correctly, the error follows Content Profile usage, but lies within Hierarchical Select. So I don'have to move this issue to Content Profile queue. Right? Will wait patiently. Meanwhile I wish you the top score with your exam :-)

Wim Leers’s picture

Title: Unsupported operand types in common.inc on line 2831 » Content Profile + HS: Unsupported operand types in common.inc on line 2831
Project: Hierarchical Select » Content Profile
Version: 6.x-3.x-dev » 6.x-1.x-dev
Component: Code - common.inc » Base module
Assigned: Wim Leers » Unassigned

It's not sure which one is to blame as Content Profile performs a lot of Forms API trickery, that at least challenges HS' own trickery in complexity.

Either HS has a tiny bug or Content Profile makes it impossible for HS to work correctly. I know that we fixed this in Drupal 5 before. But it seems we'll have to repeat it for Drupal 6. Moving to the Content Profile issue queue to get feedback from fago. (Hi fago! :))

fago’s picture

Component: Base module » User registration module
Status: Active » Postponed (maintainer needs more info)

(Hi Wim :))

@skizzo: Are you using the latest dev-snapshot of cp? If not, please test it first as it incorporated quite some changes to the registration process. Try it with and without including all form fields.

skizzo’s picture

I am using 6.x-1.x-dev, stamped 2009-04-22. Without including the form fields everything works nicely. Also, if I uncheck the "Use on Registration" flag, the user can register and later on edit the profile, picking Region/County/City via HS. Everything is ok. The problem arises as soon as I check the "Use on Registration" flag (or the " Use on administrative user creation form" flag). If the problem is not obvious to you, we may just wait for Wim, as it seems he already went through something similar for D5. Thanks.

skizzo’s picture

Upgraded to the newly released version (timestamped 2009-05-31) but the problem is still there.

fago’s picture

Status: Postponed (maintainer needs more info) » Active

>If the problem is not obvious to you, we may just wait for Wim, as it seems he already went through something similar for D5. Thanks.

We went through it together for d5 with nodeprofile.. ;)

>Upgraded to the newly released version (timestamped 2009-05-31) but the problem is still there.

Ok, so it looks like we need another debugging session..

@Wim:
Content Profile Integration now works without a subform, it just pulls fields from the node form and puts it directly into $form from the user registration form - so AHAH callbacks find their form elements at the usual place. But perhaps, is there any form element else in $form or $form_state your stuff relies on?

WildKitten’s picture

@fago, @Wim:

Hi guys,
any news about this problem?

Maybe you could check out http://drupal.org/node/518830#comment-1819846. As Ryan Palmer said, the problem is in this part of hierarchical_select_after_build($form, &$form_state) { function, in hierarchical_select.module

  if (!isset($_POST['hs_form_build_id']) && count($names)) {
	
    $parameters = (isset($form['#parameters'])) ? $form['#parameters'] : array();
    $menu_item = menu_get_item();

    // Collect information in this array, which will be used in dynamic form
    // updates, to …
    $storage = array(
      // … retrieve $form.
      'parameters' => $parameters,
      // … determine which part of $form should be rendered.
      '#names'     => $names,
      // … include the file in which the form function lives.
      'file'       => $menu_item['file'],
    );

    // 6 hours cache life time for forms should be plenty.
    $expire = 21600;

    // Store the information needed for dynamic form updates in the cache, so
    // we can retrieve this in our JSON callbacks (to be able to rebuild and
    // render part of the form).
    $hs_form_build_id = 'hs_form_'. md5(mt_rand());
	
    cache_set($hs_form_build_id, $storage, 'cache', time() + $expire);
  }
zmove’s picture

Hi,

I have the same problem here is the details and how I fixes it :

I use content profile in conbination with Auto Assign Roles, to have different content profile for different roles.

So, I have different urls for different content profile as content profile and auto assign roles are friends.

The problem is that I disabled "Content profile on registration" as I checked to embed content profile on the auto assign role specific path for each roles.

With content profile on registration disabled, it bring the error with hierarchical select you mention.

So, my solution was to check this "content profile on registration", and to implement an hook_form_alter, to not display the content profile form on the "general user" registration page, but only on the auto assign role specific path

zmove’s picture

Hi again,

My solution finally don't work.

By checking the option to put the profile on content registration and then altering it as I did, it will break something in the registration integration.

In my custom user/register/my_role page set up with Auto Assign Role, I get my core profile fields, my content_profile node form and hierarchical select work, but the form don't validate correctly.

I have the content_profile form submit buttons + the create account button : first problem

In addition, the validation function for the form stopped working, if I don't fill required fields, I don't get the errors "field is required" anymore. If I disable the option to put content_profile on registration, it works again but Hierarchical select stopped working.

So I think there are no tricky solution, it need a content_profile or a hierarchical select patch, but it need a patch.

WildKitten’s picture

I needed to make HS fields work ok on user/register/my_role page, so i made 2 select fields with ahah, instead of HS fields. You can check it here. I even make those kind of fields for cck content multigroup (also insted of hs fileds)

zmove’s picture

nothing to say

crea’s picture

I've found that HS relies on $form['#parameters'] to store form builder function name and it's parameters and it's not set in my case. Does anyone have an idea on this ?

crea’s picture

This is probably very ugly. I've tried the following in my form (which is basically analogous to 'user_register' one) and it removed the error!

$form['#parameters'] = array(
    0 => 'profile_node_form',
    1 => $form_state,
    2 => $form['#node'],
  );

Should this stuff be processed by the Content Profile ? Or is it HS fault to rely on $form['#parameters'] which may not be always available ?

wizonesolutions’s picture

I'm experiencing this error still. Was a solution ever found? I can't really track down the problem even though I've dug in for a while. Seems to have to do with CP's $form array structure vs. what HS expects...

Summit’s picture

Hi, Having this error still also when I want to enable caching..anyone found a correct method please?
Greetings, Martijn