i went to add a condition where specific cck content taxonomy terms would be used, but i'm using the hierarchical select (HS) module and it throws the following error when selecting the top layer item and when the next layer should be loaded.

"Received an invalid response from the server."

it seems that rules uses whatever widget cck uses, so the term selector is HS. i'm not sure whether rules needs modification so this works or HS needs modification or if there is a workaround. i really can't choose another widget in this case unfortunately. ideas?

Comments

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Possibly this form is fairly advanced and requires certain files to be included or its form definition function lives in a file separate from the menu callback's include? Then list it specifically using the same system CTools uses.

Details: http://drupalcode.org/viewvc/drupal/contributions/modules/hierarchical_s...

rconstantine’s picture

rconstantine commented

That's good to know. I'm looking at the code and the form builder in this module is so complex, I'm having trouble finding where the widget is called. I'll keep looking, but if a rules module guru can tell me which function(s) to look at, that would help in making a patch.

fago’s picture

fago
Primary language German
Location Vienna
commented

It's the rules integration shipping with CCK that creates the form, but the form itself is defined in the rules admin module - so yes it's complex. I think it writes the files to be included in $form['#includes'] or similar as $form_state is unusable for that form in d6 (form storage + ahah form caching makes it unreliable).

YK85’s picture

YK85 commented

subscribing

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

What solution do you propose then, fago?

rconstantine’s picture

rconstantine commented

So, fago's last comment would mean I should be looking at content.rules.inc, right? No wonder I couldn't find what I was looking for in the rules modules files. So is the function content_rules_action_populate_field_form in that file what needs modifying? I see that indeed $form_state is passed in. I can't imagine that all that is required is the addition of the following line of code, right?

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

The previous link provided by Wim doesn't specify what kinds of functions are expected to be found for this include, so I'm not sure which file - or maybe files - to include. In other words, in this case, what functions is HS not finding when it needs them? Is there a way to figure that out? I guess for now I can randomly try some suspects.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

@rconstantine: it really is that simple :)

The way you can figure this out, is by investigating in which files the code lives that Rules needs to be loaded, i.e. the functions that the form definition function calls.

rconstantine’s picture

rconstantine commented

I suppose I should find a module that is compatible with HS and see what they do. I'm still not clear on where that line of code should be placed and which functions are "missing" during the AHAH callback. I would have thought that HS functions would be missing, but now I'm not sure whether you mean that either Rules functions are missing or CCK functions. Like I said, content.node_form.inc gets included in the spot where the HS field element is built. I tried adding that file thus:

$form_state['form_load_files'] = array(drupal_get_path('module', 'content') . '/includes/content.node_form.inc');

with no effect. I believe HS is built when a function from that file is called - content_field_form. So am I in the wrong spot?

Like I said, I'll go look around at other HS-compatible modules, but meanwhile, further clarification on maybe how things flow would be great.

mitchell’s picture

mitchell commented

@rconstantine: No clarification on this end, but maybe these could help: http://drupal.org/project/hs_nodereference & http://drupal.org/project/hs_field_selector

rconstantine’s picture

rconstantine commented

So I haven't made much progress at all on this. Today I have had another thought. I am trying to use the hs_content_taxonomy module which has a function called _hs_content_taxonomy_parse_context_from_url in it. This might be a problem as the URL of the rules page will not resolve to either a content type or anything else it is looking for. Or maybe I'm way off.

I'm wondering if I should just choose a different CCK widget while I setup the rules, then switch back to HS once the rules are defined. That would probably work. Crap. I really wanted to get this to work but I'm being pulled in too many directions at work to spend the necessary time to figure this out. I hate leaving puzzles unsolved.

mayerwin’s picture

mayerwin commented

Hello,

Any update on this problem? I'm still having it with rules and HS, with the latest versions as of today...

rconstantine’s picture

rconstantine commented

i ended up running out of time that i could spend on this, so i switched to a different widget, made my rules, then switched back. seems to work. would be nice to figure this out though.

mitchell’s picture

mitchell commented

@rconstantine: Which widget did you switch to?

rconstantine’s picture

rconstantine commented

i was only looking for a single selection, so i think i chose the select box. it was about a month ago. definitely didn't do checkboxes. i noticed that the widget type gets set in the DB somewhere IIRC. in the rule itself? i seem to recall creating the rules with the HS widget in place, then changing the widget, then modifying the rule, then changing the widget back. this kept the DB entry matching the correct HS widget.

fago’s picture

fago
Primary language German
Location Vienna
commented

I think we need to figure out how we support special cases like this. Maybe we could use a "hook"/callback which allows field/widget providers to alter the CCK form?

mitchell’s picture

mitchell commented

@fago, @rconstantine: Have you seen Form Extended?

maximiliam’s picture

maximiliam commented
Component: Provided module integration » Rules Engine

The reason for that this error message is shown is that the hierarchical select module builds the form rules_admin_form_add, but it does not include the required rules_admin_rule_proxy class.

This issue can be solved by adding this autoload function to the rules_admin.module file:

spl_autoload_register('rules_admin_autoload');
function rules_admin_autoload($class) {
  if ($class == 'rules_admin_rule_proxy') {
    module_load_include('inc', 'rules_admin', 'rules_admin.rule_proxy');
  }
}
maximiliam’s picture

maximiliam commented
Component: Rules Engine » Provided Rules integration
moskito’s picture

moskito commented
Version: 6.x-1.1 » 6.x-1.x-dev
Category: support » bug
Status: Active » Needs work

maximiliam, #17 fix the exibition issue, but it doesn't save the value. When I tried to edit the same condition it doesn't show a default value.

mitchell’s picture

mitchell commented
Title: hierarchical select not compatible? » Add a hook to allow field/widget providers to alter the CCK form
Component: Provided Rules integration » Rules Core
Status: Needs work » Postponed

This is old, is it still needed?

tr’s picture

tr commented
Issue summary: View changes
Status: Postponed » Closed (outdated)

Drupal 6 end of life was 24 Feb 2016. Drupal 6 and Rules 6.x-1.x are no longer supported as of that date, and no bugs with those versions will be investigated or fixed.

If this issue is still a problem in the Drupal 7 or Drupal 8 version of Rules, please open a new issue with complete details of how to reproduce the bug.