Port HS support for Content Taxonomy to Drupal 6

Hello Wim,

comment on zip provided in comment #158

I have installed zip provided there of content taxonomy but it is giving me some errors on field configuration settings

1)
hs_content_taxonomy_common_config_form_submit() function has
drupal_execute('_content_admin_field', $form_state['values'], $field['type_name'], $field_name);
it is creating following error :-

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_content_admin_field' was given in /var/www/test/includes/form.inc on line 366.

2)
And after saving node i get ......

* warning: array_unshift() [function.array-unshift]: The first argument should be an array in /var/www/test/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 44.
* warning: array_unshift() [function.array-unshift]: The first argument should be an array in /var/www/test/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 45.
* warning: Illegal offset type in isset or empty in /var/www/test/matri/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /var/www/test/matri/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /var/www/test/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in isset or empty in /var/www/test/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /var/www/test/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /var/www/test/modules/taxonomy/taxonomy.module on line 1019.

Please help me fixing this error...

Chandu

I do say, the prospect of using HS with CCK is very exciting. So, I thought I would give it a try.

I am running the Dec 3 dev version along with the Zip for the CCK bit. I got what appears to be the same error as chandubhai's #2 - but the line numbers are different.

Also, the values are not saved. When I go to edit the node, I see that the selects do not have any values selected.

    * warning: array_unshift() [function.array-unshift]: The first argument should be an array in /home/medimar0/public_html/sites/all/modules/hierarchical_select/hs_content_taxonomy.module on line 42.
    * warning: array_unshift() [function.array-unshift]: The first argument should be an array in /home/medimar0/public_html/sites/all/modules/hierarchical_select/hs_content_taxonomy.module on line 43.
    * warning: Illegal offset type in /home/medimar0/public_html/sites/all/modules/content_taxonomy/content_taxonomy.module on line 170.
    * warning: Illegal offset type in isset or empty in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1016.
    * warning: Illegal offset type in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1019.
    * warning: Illegal offset type in isset or empty in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1016.
    * warning: Illegal offset type in /home/medimar0/public_html/modules/taxonomy/taxonomy.module on line 1019.
    * warning: mb_eregi_replace() expects parameter 3 to be string, array given in /home/medimar0/public_html/sites/all/modules/pathauto/pathauto.inc on line 184.

Hi,

Reporting exactly same errors:

    * warning: array_unshift() [function.array-unshift]: The first argument should be an array in /home/lilifilm/public_html/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 42.
    * warning: array_unshift() [function.array-unshift]: The first argument should be an array in /home/lilifilm/public_html/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 43.
    * warning: Illegal offset type in isset or empty in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1016.
    * warning: Illegal offset type in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1019.
    * warning: Illegal offset type in isset or empty in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1016.
    * warning: Illegal offset type in /home/lilifilm/public_html/modules/taxonomy/taxonomy.module on line 1019.
    * warning: mb_eregi_replace() expects parameter 3 to be string, array given in /home/lilifilm/public_html/sites/all/modules/pathauto/pathauto.inc on line 184.

Looking forward to making this work, and thank you.
Lilian

I needed this for my project, so I made some edits to the zip to get rid of those errors.
It seems to be working now

note: if you are using "save linage" the "Number of values" setting on admin/content/node-type/[type]/fields/[field-name]
should be set to "unlimited", I'm not sure if the module is supposed to detect this and adjust the setting itself.

the patch is against the 6.x-3.x-dev version

you may need this

I apologize for cluttering up this thread.
Here is the correct admin.inc you need

It did not patch the .info file correctly... I had to add ' core = 6.x ' to it to get it to work.

Installed fine. I added a couple of taxonomy terms like ford>focus ford>explorer

I got this error after I submited my new HS cck field (after setting all the settings):

warning: require_once(sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.admin.inc) [function.require-once]: failed to open stream: No such file or directory in /home/mysite/public_html/myothersite.com/includes/menu.inc on line 346.

Also, I get this error when I go here http://mysite.com/admin/content/node-type/testhsct/fields/field_makemode...

Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.admin.inc' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/mysite/public_html/myothersite.com/includes/menu.inc on line 346

EDIT!!! I copied your hierarchical_select.admin.inc.txt instead of hs_content_taxonomy.admin.inc.txt on accident the first time... after I got the right file, the above errors went away!

It seems to work great! I haven't checked views integration but I would think it would work just fine.

One thing I did find that doesn't work is setting the 'Parent term', but I don't think that worked in D5. Also 'depth of taxonomy tree' doesn't work also.

subscribing (and trying it out time permitting)

EDIT:It worked great after applying the patch and uploading the admin.inc file from #6 (thanks loze). It does all of the basic things fine. I did not test extensively but I did notice one bug: When you have multiple tags and delete one of the tags which is not the last one, and then try to add more tags (without saving first), it does not save the added tags. It would seem to be an issue with the way the array is handled it gets confused if you delete something from the middle.

One more bug is that when used when a field is configured with free-tagging, and insert new values into vocabulary AND the field is required, then content cannot be submitted because it will state that the field is required, I assume because it does not register the value as valid (because the term does not exist yet).

Hi,

I've tried to use this port today. When applying the patch, it mentioned a problem with the .info file. I guess it's the same thing that that0n3guy mentioned.

After installing and enabling the module, I also noticed an error message when creating either a Page or a Story:

warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\drupal\sites\all\modules\hierarchical_select\modules\hs_content_taxonomy.module on line 86.

Another thing I noticed is that the node title isn't being displayed on nodes containing a content taxonomy field with hierarchical select. Don't know if this has something to do with this module or not.

Osieke,

My node titles are showing up just fine. I think that problem might be something else. As for the warning you got... I have no idea.

I've been using it for a while and I havent really had many problems (besides what I stated earilier) with it.

The node title issue seems to be related to the viewfield module. There's an open issue there mentioning similar problems. When removing all viewfields from my content type the node title displays correctly.

As for the warning...it doesn't seem to harm any pages or stories...but the warning clearly mentions the content taxonomy module, so I guess there's a small glitch somewhere.

One other thing I noticed has to do with modifying the depth of hierarchical taxonomies. Let's say I have a taxonomy vocabulary with a number of root terms, each with a number of child terms. If I add a content taxonomy field using hierarchical select and make that field a required field. Then I limit the depth of the hierarchical taxonomy tree to 1, so I only get to select the root terms. If I try to submit a node, it comes up with a warning that the field is required. If I remove the depth parameter and show the full taxonomy, all is fine.

Then I limit the depth of the hierarchical taxonomy tree to 1, so I only get to select the root terms. If I try to submit a node, it comes up with a warning that the field is required. If I remove the depth parameter and show the full taxonomy, all is fine.

Yeah, this sounds like the same bug that I mentioned on #7 above "Also 'depth of taxonomy tree' doesn't work also."

I remember this bug being there in D5 also (but I haven't used the D5 version in a long time).

Not sure if it's related, but I created an issue at Content Taxonomy for the same problem.

http://drupal.org/node/372534

Installation/upgrade:

0. (Be sure to use 6.x-3.x-dev codebase)
1. Downloaded patch in #4
2. Moved it into sites/all/modules/hierarchical_select/modules
3. Applied it
4. Downloaded the file in #6
5. Renamed it to hs_content_taxonomy.admin.inc
6. Moved it to sites/all/modules/hierarchical_select/modules
7. Enabled it
8. Started using it.

(I provided the above in case other people don't read the whole thread)

Some bugs:

1. "Parent Term:" in the field configuration form is not enforced.
2. Terms are not rendred as links by default, have to change it in render settings. Not a big prob. But I am not allowed to select comma separated values, as for the text fields (using cck formatters). A formatter for comma separted text and links would be great. Added this as an issue: #390090: Display Formatters
3. The settings from the additional HS Content Taxonomy settings seems to be omitted in exports; and I assume isn't parsed on import.

Question:

1. If a "Parent Term:" enforcement is in place, how will the "Save lineage" function? I suggest that it should only include all subterms of Parent Term, and not the parent term itself, or parents above it.

First impression:

Very good, works well, saved my day!

subscribing

Several people have used the patch successfully. There are a number of small bugs (as reported), but all of the core functionality appears to be there and stable. Wim, perhaps you can commit this patch to dev and we can start systematically filing proper bug reports and fixes?

very much looking forward to this feature in 6.x - will test as soon as roled into cvs tarball

Subscribing

I'v done all acording #15 and got this when try to configure HS for contetnt taxonomy field

warning: call_user_func_array(): First argument is expected to be a valid callback, 'hs_content_taxonomy_config_form' was given in bla-bla-bla/includes/form.inc on line 366.

Actualy, all I want there is to make him remember all taxonomy hierarchy line, not only the last term.

AFAIK this is called save_lineage

Can I do this?

(sorry for my english)

I'v done all acording #15 and got this when try to create new forum thread at node/add/forum/12000

warning: Invalid argument supplied for foreach() in D:\Web\htdocs\sites\all\modules\hierarchical_select\modules\hs_content_taxonomy.module on line 86.

I'v solved this problem by adding one more condition to "hs_content_taxonomy_form_alter" function

Line 85:

before:
if (isset($form['type']) && $form['type']['#value'] .'_node_form' == $form_id){
after:
if (isset($form['#field_info']) && isset($form['type']) && $form['type']['#value'] .'_node_form' == $form_id){

But cause of such behaviour is still uknown for me.

subscribing

Subscribing too. Nice module!

All,

Has the patch from #4 been updated to work with the latest dev version that could be checked out as of today? After applying the patch I fail on both the .info and .module file. Most of the hunks succeed on the .module but a handful fail. I'm happy to debug it and retrofit this but I figure that someone would be tracking the code against the latest HS dev version and could save me the time by posting an updated patch. I would be happy to test and debug this as I need this functionality for my site.

I will also be testing this in conjunction with content taxonomy patches for content multigroup as well so the testing will hit a number of touchpoints.

Thanks!

OK, here's what I did to at least apply the patch from #4 and follow the directions from #15.

# Download
wget http://ftp.drupal.org/files/projects/hierarchical_select-6.x-3.x-dev.tar.gz
wget http://drupal.org/files/issues/hs_content_taxonmy.patch
wget http://drupal.org/files/issues/hs_content_taxonomy.admin_.inc_.txt
mv hs_content_taxonomy.admin_.inc_.txt hs_content_taxonomy.admin.inc

# Extract
tar zxf hierarchical_select-6.x-3.x-dev.tar.gz
mv hs_content_taxonmy.patch hierarchical_select/modules
mv hs_content_taxonomy.admin.inc hierarchical_select/modules
dos2unix hs_content_taxonmy.patch

At this point, I made only one change to hs_content_taxonmy.patch - removed the first 16 lines that patched the info file. The rest of the patch will apply correctly with a 'patch < hs_content_taxonmy.patch' command. I then edited the .info file manually to break out the dependencies to look like this:

dependencies[] = hierarchical_select
dependencies[] = content_taxonomy
dependencies[] = hs_taxonomy

At this point, after running update.php the module is able to be enabled. I switched the widget type for one of my content taxonomy fields to use the newly available Hierarchical Select option. This all worked fine until I hit this page:

http://mysite.com/admin/settings/hierarchical_select/configs

When I clicked "Edit" to configure the HS options, it pretty much blew up and threw up a ton of php code. Screenshot #1 shows the code at the top that appeared above all of the regions, and Screenshot #2 shows what it looks like in the main content area. I have not tried to debug it so I am just reporting that as of now, patch #4 isn't working so well for me.

(sorry for my english)

To use Hierarchical Select as Filter for View I have done following:
Hierarchical Select Content Taxonomy Views Module - is off
Hierarchical Select Taxonomy Views Module - is off (actually not available)

hierarchical_select.module : line 14, after define('HS_DEVELOPER_MODE', 0); insert:

//<overall>
///*
//drupal_load('module', 'views');
require_once('D:\Web\htdocs\sites\all\modules\views\includes\view.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\includes\base.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\includes\plugins.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\plugins\views_plugin_display.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\plugins\views_plugin_display_page.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\includes\handlers.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\handlers\views_handler_filter.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\handlers\views_handler_filter_in_operator.inc');
require_once('D:\Web\htdocs\sites\all\modules\views\handlers\views_handler_filter_many_to_one.inc');

require_once('D:\Web\htdocs\sites\all\modules\cck\includes\views\handlers\content_handler_filter_many_to_one.inc');

require_once('D:\Web\htdocs\sites\all\modules\content_taxonomy\includes\views\content_taxonomy_handler_filter_many_to_one.inc');
//*/
//</overall>

sites/all/modules/content_taxonomy/includes/views/content_taxonomy_handler_filter_many_to_one.inc : line 22, after

  function get_value_options() {
    $options = content_taxonomy_allowed_values($this->content_field);
    unset($options['']);
    $this->value_options = $options;
  }

insert:

//<overall>
  function value_form(&$form, &$form_state) {
    parent::value_form($form, $form_state);

///*
  $form['value'] = array(
    '#type' => 'hierarchical_select',
    '#title' => t('Select the tag you wish to use.'),
    '#size' => 1,
    '#config' => array(
      'module' => 'hs_content_taxonomy', //'hs_content_taxonomy_views', //'hs_content_taxonomy', //'hs_taxonomy',
      'params' => array(
        'vid' => 2, //1, //$vid,
        'tid' => 0, //2586,
        'depth' => 0, //1,
        'root_term' => FALSE,
        'exclude_tid' => NULL,
        'optional' => TRUE,
      ),
      'save_lineage'    => 0,
      'enforce_deepest' => 0,
      'entity_count'    => 0,
      'resizable'       => 0, //1,
      'level_labels' => array(
        'status' => 0,
        'labels' => array(
          0 => t('Main category'),
          1 => t('Subcategory'),
          2 => t('Third level category'),
        ),
      ),
      'dropbox' => array(
        'status'   => 0,
        'title'    => t('All selections'),
        'limit'    => 0,
        'reset_hs' => 1,
      ),
      'editability' => array(
        'status'           => 0,
        'item_types'       => array(),
        'allowed_levels'   => array(
          0 => 0,
          1 => 0,
          2 => 1,
        ),
        'allow_new_levels' => 0,
        'max_levels'       => 3,
      ),
      // These settings cannot be configured through the UI: they can only be
      // overridden through code.
      'animation_delay'    => 400,
      'exclusive_lineages' => array('**ALL**'),
      'render_flat_select' => 0,
    ),
    '#default_value' => '2588', //'83',
  ); 
//*/
  }
//</overall>

I know it's dirty, very dirty, but it works, and it is convenient for me.

This makes all Content Taxonomy widgets turn into Hierarchical Selects for Vocabulary specified in $form['value']['#config']['params']['vid'], which is coded as a constant...

I have not did this hack as patch, because, I think this would be better, because i don't know how make a patch and a new development snapshot can appear in any moment and I don't want to port it for new snapshot, also because I have got confused about to which snapshot apply this hack because I havt tested it on latest snapshot 6.x-3.x-dev (from 2009-Mar-28) patched with patch from #15.

I need a help to extend this patch to support proper vocabulary for corresponding Content Taxonomy Field.

Hi,

I haven't read the whole thread above. But, attached module, I wrote couple of weeks back for "Hierarchical Select Content Taxonomy" drupal 6 has been working for me quite well in quite a few projects, so this might be helpful to someone till somebody makes a proper release.

Thanks,
Sudeep

I was really excited to see this post and test this. It didn't work for me. I just want to share the following

1. When I select a term, I would get an error message. See attached Pic
2. I was unable to set the weight. I even tried moving its position about the node title.
3. Field is still resizable even after you disabled it.
4. When accessing the widget configuration page, I just get a WS.

(sorry for my english)

I have applyed the patch from #29 and get the next error (in /admin/content/node-type/%/fields/%/hs_config):

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_content_admin_field' was given in /home/david/Trabajo/dev/andaltec/trunk/drupal/includes/form.inc on line 369.

Any idee?

#29 works ok, not all the options work but its good enough for some begining. thanx hope it gets better in folllowing months.

p.s.
also in FF i get some strange blocking of dropdown if i refresh form for entering data for CCK node.

I tried module from #29 and get same error as #31

#29 doesn't save lineage and doesn't seem to load saved term on node edit.

tried patch from #4, its closer, but doesn't reload the terms into the field when i edit the node i just saved.

possibly part of the reason is that i have a cck_fieldgroup_tabs setup and this field is not in the default 1st tab - which is the reason i am trying to use content_taxonomy so i can move vocabs to other tabs.

I don't use tabs, but have the same situation:
when I edit node - It does not show saved selection in HS content taxonomy field.

Hello,
first of all i want to say, that i love this module absolutly and i cant wait until the content-taxonomy and views - modules of it will work fine.
I tried out #29. I dont know for sure if it is the same probleme as some people above me had, because of my bad english-knowledge.
I can create a content-taxonomy-field with hierachical select, this works. But when i want to create a node, i just can put in taxes in the first level, because the selection for level 2 doesent apear.
I allowed creation of new terms in all 3 levels and i allowed creation of new levels.

Edit

Ok, sorry it was my misstake. I just had to erase the settings in the depth of tax-tree in the cck-field. So, now it works, terms are added, and the hierarchy is working. But if i submit the node i got following error-message:

warning: array_unshift() [function.array-unshift]: The first argument should be an array in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 42.
warning: array_unshift() [function.array-unshift]: The first argument should be an array in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 43.
warning: Illegal offset type in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/sites/all/modules/content_taxonomy/content_taxonomy.module on line 165.
warning: Illegal offset type in isset or empty in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1014.
warning: Illegal offset type in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1015.
warning: Illegal offset type in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1018.
warning: Illegal offset type in isset or empty in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1014.
warning: Illegal offset type in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1015.
warning: Illegal offset type in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/modules/taxonomy/taxonomy.module on line 1018.
warning: mb_eregi_replace() expects parameter 3 to be string, array given in /var/www/vhosts/metaletics.com/subdomains/nexttest/httpdocs/sites/all/modules/pathauto/pathauto.inc on line 184

The submitted terms are in the database, but they are not submitted to the node.
Do i have to do any workaround or patch or do i have to wait until there is any?

Subscribing.

I have a patch to make it works with multiple options.

Could you please share the code of your patch #40?

By the way, patch #29 results as well for me in the following error:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_content_admin_field' was given in /usr/share/drupal6/includes/form.inc on line 366.

I reworked code presented in this issue: mostly it is code from #4 with minor fixes.
Also I ported HS CCK formatters from 5.x.
It works for me but I haven't done very deep testing.
Please do some more testing and report errors, I will try to fix em
This is all-in-one patch against latest 6.x dev
Please don't beat me hard if there is some error with the patch, im still learning git and stuff :-P

Updated patch: added another theming function. Now every piece of output of HS CT formatters can be themed (lots of classes added)

will test it out later today..

Going to test the last patch
thank you I really need it.

Please dont change status unless you find error

#43 is working great for me!!!

copy hs_content_taxonomy_6x_new.patch to /sites/all/modules/hierarchical_select/
patch -p0 < hs_content_taxonomy_6x_new.patch

Editing
http://examle.com/admin/build/views/edit/SomeView
and adding filter of content:location exposed at hierarchical select, then "Select the tag" and press update:
getting those warning messages

* warning: Illegal offset type in isset or empty in /home/moshe/projects/ofno/sites/all/modules/views/handlers/views_handler_filter_in_operator.inc on line 189.
* warning: Illegal offset type in isset or empty in /home/moshe/projects/ofno/sites/all/modules/views/handlers/views_handler_filter_in_operator.inc on line 189.
* warning: Illegal offset type in isset or empty in /home/moshe/projects/ofno/sites/all/modules/views/handlers/views_handler_filter_in_operator.inc on line 189.
* warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /home/moshe/projects/ofno/includes/database.mysqli.inc on line 323.
* warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /home/moshe/projects/ofno/includes/database.mysqli.inc on line 323.
* warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /home/moshe/projects/ofno/includes/database.mysqli.inc on line 323.

Just selecting expose and the preview works just great.
save the view.

Thanks

Moshe beeri.

I forgot to mention.
This patch does not touch Views integration. So please test only basic functionality. Views integration is under big question and as Wim asked, should be made (if it's possible) in another patch.

the way HS expose the information in the view should be just perfect.
I hope you will come out with a solution for that, I see it as basic or mast have.
Can you suggest other means to accomplish what I like other then HS?

moshebeeri, how hard is to understand that Views integration must be discussed in different place ? There is #342991: Port HS support for Taxonomy Views to Drupal 6 for that.
The point of HS without Views is to provide nice UI for entering field values with large hierarchies. Which is alone good enough.

subscribed

My code. I'm sorry, it's not a patch and it is horrible!!!
It works.

<?php

/**
 * @return List of fields that we used with HS Content Taxonomy
 */
function _fields_hierarchical_select() {
  // an example of fields that use with HS Content Taxonomy
  return array ('field_cnt_profile_poblacion', 'field_poblacion', 'field_sector',
                'field_cnt_profile_categoria', 'field_cnt_profile_tipo_producto',
                'field_otro_pruebas', 'field_casi_definitivo',
                'field_de_guia_para_mi_ejemplo',
               );
}

/**
 * hook form_alter: we add a validation function (no submit! exists another for taxonomy)
 * & we added values in form for fields (widget: HS Content Taxonomy): BUG of HS Content Taxonomy
 */
function autoselect_parents_taxonomy_form_alter(&$form, $form_state, $form_id) {

  // Si editamos un nodo...
  if (stripos($form_id, '_node_form') !== false) {
     // Incluimos una validacion para limitar el numero de elecciones
     $form['#validate'][] = 'autoselect_parents_taxonomy_validate';
  }

  $fields_hierarchical_select = _fields_hierarchical_select();

  foreach ($fields_hierarchical_select as $campo) {

    // Si esta en el formulario y es HS Content Taxonomy no tendra todos sus valores cargados.
    if (isset($form[$campo])) {
      $all_valuesof_node = $form['#node']->$campo;

      $form[$campo]['tids']['#default_value'] = array();

      // Incluyo uno a uno en el formulario todos los valores incluyendo el que si incluye por defecto.
      foreach($all_valuesof_node as $key => $value) {
        $form[$campo]['tids']['#default_value'][] = $value['value'];
      }
    }
  }
}


function autoselect_parents_taxonomy_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  // Para solucionar con un parche el problema que tiene Hierarchical Select Content Taxonomy
  $fields_hierarchical_select = _fields_hierarchical_select();

  // Actuamos justo antes de ser guardado un nodo
  if ($op == 'presave') {
    // Heredamos en algunos fields (no hierarchical_select) los padres a los hijos
    // $node = _hereder_terminos_progenitores_a_hijos($node);


    foreach ($fields_hierarchical_select as $campo) {
      if (isset($node->$campo)) {
        $all_values_packed = $node->$campo;
        foreach($all_values_packed[0]['value'] as $key => $value) {
          $all_values_packed[$key] = array('value' => $value);
        }
        $node->$campo = $all_values_packed;
      }
    }
  }
}

#54 jcdenton.dm

Please use English for comments unless you like me to Comment in Hebrew :-)
I could not feature out what your code should do?
Can you give me more details?

Thanks You,
Moshe Beeri.

I have tried out the patch at #43. Thank you. It worked fine. Still needed to download the admin.inc from #6 though.
Configuration was a bit clumsy, I had to switch back and forth from the content taxonomy field management and the HS widget management page, as HS widget management only gets the values of depth for example after you saved that in content taxonomy.
Otherwise it was working fine for me.

Thanks a lot.

#54 jcdenton.dm

> Please use English for comments unless you like me to Comment in Hebrew :-)

I'm sorry, now i use comment in english in my code.

> I could not feature out what your code should do?
> Can you give me more details?

Example: you create a field with "Content Taxonomy". This field works: Content taxonomy search an array of values in $form.
Hierarchical Select don't use this hierarchical in $form but Drupal search this organization of values in $form (Hierarchical Select Content Taxonomy is a widget of Content Taxonomy!).

I change the organization in $form[$field]: i make that be as was created by Content Taxonomy

You can see the changes easly: with dBug: http://dbug.ospinto.com/

insert this code at the beginnging of function autoselect_parents_taxonomy_form_alter:

require_once('dBug.php');
new dBug($form);

and this code at end of that function:

new dBug($form);

Subscribing

(sorry for my English in first)

When i save the Term on node by HS+CT - it's saved. It's ok.
But when i try to edit THIS node again this field contains: code! (see attach image)
And if AGAIN save the node (do not make changes in this field) - all terms is erase for this node!

It's a bug or my hands? :)
And if problem with my hands, what i'm doing wrong?

Please submit patched module as http://drupal.org/files/issues/hs_content_taxonomy_0.zip i cant patch in my *grebaniu* windows, but this module is very important for me. Work stay.

2 Jackinua: you can install "Eclipse PDT", create new project from existing directory (for whole drupal folder or for HS module only), then open "Navigator" (in Eclipse), right click on HS module folder, select "Team" -> "Apply patch".

Thank's it's a easer method. I did't know that Eclipse can to do that )

crea - I installed the patch from #43. It's most definitely an improvement but there's still some issues I'm encountering.

The biggest ones being

1) Users can't create new taxonomy terms from the CCK field using HS
2) Lineage does not appear to be saved
3) Term labels are not appearing

I'll dig around in the code and see if maybe I can figure something out to contribute back. Thanks for the patch, though; it's most definitely an improvement from where I was before!

@scorrales
1) Hmmm, I didn't verify creating new items, because I don't use it. Glad you checked this. I'll look into it.
2) Lineage is saving ok for me.
3) Term labels are also ok for me (by term label I mean term name). Did you mean level labels ?

After applying the patch file hs_content_taxonomy.admin.inc copied to the up level. Perhaps you have the same problem?

Hi,

could anyone help me? I don't get all of this discussion so would like to ask. I have a cck Content Taxonomy and HS and would like to have a taxonomy displayed to the user not just like that:
aaa
-s
--sdf

but nicely like HS can do it. So is it possible? if so, which patch should i use? Thanks.

Subscribing.

trying patch from #43 and seems to work same as posted earlier. Terms seem to apply and can be seen in view mode of node; but upon editting there are no terms visible - and if re-submitted without re-adding; the terms are wiped from the node.

adding: http://screencast.com/t/Sbh6nZl6US
viewing: http://screencast.com/t/HL2Jt2bzwX
edit: http://screencast.com/t/qN7UyZoGkT

i took 6.x-3.x-dev (2009-Apr-06) and patch from #43 above (which patched cleanly)

If anyone can confirm this behavior i can likely look at providing a patch - just don't want to fix it if it isn't really busted.

not exactly sure how this widget is supposed to work yet; but if i pick a 3 level tax term even though save term lineage is set; only the deepest level gets set in the field table - even though all 3 get added to the term_node table (since this was laso configed this way).

perhaps this ok if when the node is loaded for edit it builds the default values for the HS selector from the lowest level - but it isnt doing this...

re: #63/64 i think i agree that lineage is NOT being saved - i tried the case of adding only the top level and when i go to edit, sure enough it is still there.

@crea, yes, lineage is saved.. sort of. it is saved to tern_node and therefore shows on node view; but isn't saved to field so if not the lowest level (i.e. if more than 1 level is saved) this isn't able to be re-added when the node is edited.

how do we expect the field to save multiple values?? shouldn't there be a content_field table - i only have a column in my content_type table (which can't be correct)

for example when i save:

body -> head
body -> foot

in term_node i get node tagged with body, foot and head (which is correct)

but in field_fieldname_value in content_type table i only get foot. pretty sure that can't be correct for this to work.

again, since it is possible to determine lineage from lowest term; it is possible that we only need to store head and foot; but that isnt happening and i don't think any code to rebuild lineage from each lower term.

ok, this is an ugly hack; but not sure how else this can be done until it is sorted out how this field type stores multiple terms

this only works if you select option to also have the terms saved to term_node table (std taxonomy)

basically in the function: function hs_content_taxonomy_widget(&$form, &$form_state, $field, $items, $delta = 0) the only $item that is passed is the single item that gets stored in the field (which is wrong)

so i simply replace this with the array build from term_node values which do get stored correctly

i can provide a patch if anyone wants; but i didn't do it now since this really isn't the right way to do this.

in the function mentioned above under this code:

  $field_name = $field['field_name'];
  $vid        = $field['vid'];
  //$tid        = $field['tid'];
  $tid        = (empty($field['tid'])) ? 0 : $field['tid'];
  $depth      = (empty($field['depth'])) ? 0 : $field['depth'];
  require_once(drupal_get_path('module', 'hierarchical_select') .'/includes/common.inc');
  $node = &$form['#node'];
  //dsm($node);

add this code:

  // hack to get real list of items since we don't seem to save with the field anywhere
  $terms = taxonomy_node_get_terms($node);
  unset($items);
  foreach ($terms as $key => $term) {
    $items[] = array('value' => $key);
  } 

just did a couple quick tests but seems to work.

hmm.. not quite perfect yet.. but will need to look at it later.

when i edit even though lineages look correct and save correct if i resubmit; if i add one more chain the ones that were there before get duplicated: http://screencast.com/t/CPfen8U7yXH

when submitted the HS module does the right thing and cleans out the extras so not too big a deal; but needs to get fixed.

Subscribing...

@crea

You're right - level labels is what I was referring to.

perhaps just a glitch in my testing as it seems to work fine now (i.e. duplicates not appearing in lineage list)

i did realize that my code doesn;t need to do further db access as $node->taxonomy already has the terms that i need so the code i posted in #72 could be simplified as this:

  // hack to get real list of items since we don't seem to save with the field anywhere
  unset($items);
  foreach ($node->taxonomy as $key => $term) {
    if (is_object($term)) $items[] = array('value' => $key);
  }

I can confirm that this is happening to me also. Upon editing the node there's no value exposed. A patch with your findings would be great.

I can't clearly understand whether people here have now this working (saving and displaying correctly upon editing) using patch on #43. If it's somehow working, please inform.

EDIT: - Applied the hack in #76 and it appears to work nicely. All left now for it to make to "workable" status on my install would be to display the same table shown in the edit tab also in the "View" tab.
- For the people asking whether the problem might be because of groups, I can confirm that with this hack now it also works, as I have group tabs.

Cheers.

Subscribing

I was reading posts on this subject for few days, and I tried to apply all patches (included those that are mentioned above). I can create a content-taxonomy-field with hierachical select. But when I try to set field configuration settings, I keep getting the same error , over and over :
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'hs_content_taxonomy_config_form' was given in C:\wamp\www\jobnetworkfinal\includes\form.inc on line 366.
So I would really appreciate, if someone have solution for this problem. I keep looking at those posts, and noone said that has overcame this problem. So please, if someone has, write it here.

I have instal 6.x-3.x-dev HS on 6.13 drupal.

EDIT: Please guys, I tried every single thing that has been written here, and still can't set field configuration settings for a CCK field with HS. I even tried different versions of drupal. Did anyone of you solve that problem?

@scorrales #75 : As for level labels, please keep in mind HS itself sometimes hides them. IIRC level labels are hidden when "force deepest" is enabled for HS widget. So please make sure what you get is indeed bug with level labels and not feature of HS.

@ALL I reproduced bug with HS values not saving on clean site. It seems HS just doesn't switch "multiple values" feature of CCK so until I enable it manually terms are removed on second edit, indeed. I guess this won't be very hard to fix.. No need for hacks, guys!
EDIT: I'm stupid, loze was stating this clearly in #4.

Hmm found another bug, with previews printing taxonomy errors.

Still, if finally I choose this module, I would have to use two of them in the same page and in a quick test could not make the second one to record the data... Will update on this.

@oboskovic: check that you have file "hs_content_taxonomy.admin.inc" in the same directory as the module

I just fixed "multiple values" setting. Now in the process of fixing previews.

many thanks crea, your work is greatly appreciated. I look forward to testing the next patch.

It seems like previews are broken in Content Taxonomy, there are errors even if I use other widgets for CT field and disable hs_content_taxonomy.
See #391906: "Illegal offset type in" warnings on node preview.

There are probably small bugs still (like level limits or creating new terms) - just didn't have time to test it all. I'm more interested in fixing major bugs first.
Posting module archive as many people seem to have troubles with patches. Unzip to "modules" subdirectory of "hierarchical_select" module directory.

@crea yes I have hs_content_taxonomy.admin.inc" in the same directory as the module. In fact, half of that file is written (part of php code) on page when I try to set up configuration for field.

The same thing happened when I unpack and copy your latest .zip file in hierarchical_select/module/ folder.

Forgot to attach image

@oboskovic
you seem to have some problem with incuding that file - that error message is about function that resides there, is not found.
As noone else reported this, it's likely some specific problem with your installation and not with the module

@oboskovic check permissions and ownership of the files to make sure your system can access them.. i just switched to Vista and for some reason on occasion when i untar a module file into my modules folder; it doesn't get recognized by Drupal. I had cygwin installed and did an ls -la and saw that some of the files didn't appear with same owner - doing a chown -R and all of a sudden drupal could see module.

Code in #85 still has problems with "root term" feature of CT: I will try to fix it. Meanwhile, please test other features

nope, don't get it.. maybe i am missing something in the field setup but the module in #85 still doesn't work. i can add numerous chains, even preview seems to work (doesn't for my solution above) but when i save only one of the terms is saved in cck tables (all terms are saved in term_node table), so, sure enough.. when i edit - field shows as empty.

some screen shots:

field config: http://screencast.com/t/M2xREsjPNY
hs select config: http://screencast.com/t/A5OMjssHd
edit form: http://screencast.com/t/UVHZALHGAa
view after submit: http://screencast.com/t/ZJ9YIqRjIH
re-edit: http://screencast.com/t/e7G2uqHTdT

oops.. nvm.. i resaved field config and resaved hs config and now i have a content_field table.. whoo hoo!!

works like a charm.. even preview works (although i don't get matching tax terms in preview; but maybe a theming issue)

thanks a ton crea for your work here.

I fixed "root term" feature. Now going to try creating new terms.

Hm, after small amount of testing creating terms seem to work well. This is updated version, which has "root term" fixed.

@liquidcms #93: From what I understand, preview bug is triggered depending on if you have taxonomy vocabulary attached to the content type of CT field.

@liquidcms : Permissions are just fine, and drupal can see modules.

Well, I finaly manage to set up configuration for content-taxonomy field with HS. How I did it? I copy/paste function hs_content_taxonomy_config_form from hs_content_taxonomy.admin.inc, and commented line 'file' =>'hs_content_taxonomy.admin.inc', in hs_content_taxonomy.module. Still have that part of function writen on the top of page, but at least I can set up configuration now.

But now there is another problem. On user/register page, when I try to select data in that field, I get alert "Received an invalid response from the server.". And consola (in firebug, Mozzilla) says :

http://localhost/jobnetworkfinal/hierarchical_select_json ; 
response: <b>Fatal error</b>:  Unsupported operand types in <b>C:\wamp\www\jobnetworkfinal\includes\common.inc</b> on line <b>2845</b>

But when I edit users account, everything works perfect.

And I don't have CTools/Delegator installed.

@oboskovic Please don't spoil this issue. This is NOT support queue. Open different issue for your problem.

@crea : I did, just wanted to say where this problem took me

it works :)
but the field value doesn't save until the module weight is less than cck.
so .install file with hook_install function to set module weight on installing must be added

Applied #95. Have prob listed in #87. Have ctools, but not delegator installed. Windows environment. D6.13. No other issues where includes are involved and I have quite a number of modules installed that do the include thing. So there shouldn't be an issue with my environment.

Oops. just saw #97. Did another issue get opened for #87? I didn't see one.

[EDIT] I figured it out. the hs_content_taxonomy.admin.inc page didn't start with <?php, it started with <? so if your server is set to not accept the shorthand version, it won't work.

@rconstantine: thanks for catching this!

Other than Content Taxonomy Views integration, everything seems to work fine for me in this patch. You should commit this patch actually cause it's usable, and works for many people in this thread. And once we have Taxonomy Views integration, using it to make Content Taxonomy Views shouldn't be too hard. You are free of course to ask for sponsorship for Content Taxonomy Views, cause it's not available, but you could commit the code in this thread so people finally start to test it like official branch and not some code from random guy in the forums.
If you are refusing to review and commit this code, no problem, I will make standalone module for this, but you will then look silly.

BTW last commit has some sort of syntax error:

PHP Parse error: syntax error, unexpected '[', expecting ')' in /home/home/sites/all/modules/hierarchical_select/modules/hs_content_taxonomy.module on line 167

I can confirm that #95 works. Thanks crea.

+1 for committing this patch. I would be happy to contribute more testing.

Testing done with:
-Drupal 6.13 fresh install
-HS version 6.x-3.x-dev (2009-Jul-29)
-Ubuntu 8.04
-Firefox 3
-HS sub-modules:
--Hierarchical Select Content Taxonomy
--Hierarchical Select Taxonomy

@Wim: Thanks for this great module. I understand you develop Drupal modules for a living. But I can't afford a strong sponsorship. About a ChipIn? http://www.chipin.com

According to HS usage statistics there are currently 1,200+ websites using HS for Drupal 6.x. http://drupal.org/project/usage/hierarchical_select

Let say 120 people (10% of 1,200) would ChipIn US $10 or $20. Then you could get a strong sponsorship between $1,200 and $2,400.

In fact, most of the code was ready, provided by loze in #4. It's shame to admit but I used his code without deep understanding what's happening in some of its places.
I never did deep code cleanup because you were away, I needed it quick and dirty, so people start testing.
I'll fix code style problems you mentioned.
About Views changes: actually i'm not that experienced with Views but I'll take a look. If it will be too hard I will probably give up early cause I have more important stuff to do.

@Wim: I didn't understand you in "9) theme_hs_content_taxonomy_formatter_hierarchical(): $field_name is obsolete". I fixed everything besides it.
This patch is against latest dev

@crea: I'm trying to apply patch #110 but patch return errors. I tried the following command lines.

patch -p0 < /pathtodrupalroothere/hs_ct_fixed.patch
patch -p0 < /pathtodrupalroothere/sites/all/modules/hierarchical_select/hs_ct_fixed.patch
patch -p0 < /pathtodrupalroothere/sites/all/modules/hierarchical_select/modules/hs_ct_fixed.patch
patch < /pathtodrupalroothere/hs_ct_fixed.patch
patch < /pathtodrupalroothere/sites/all/modules/hierarchical_select/hs_ct_fixed.patch
patch < /pathtodrupalroothere/sites/all/modules/hierarchical_select/modules/hs_ct_fixed.patch

Error return:

can't find file to patch at input line 110

can't find file to patch at input line 130

Is the patch against HS 6.x-3.x-dev (2009-Jul-29)?

Should I place the 'hs_ct_fixed.patch' file in Drupal root folder? Or at HS root folder?

I'm on Ubuntu Server 8.04 LTS using TERMINAL command line. It's my first time applying a Drupal patch on a remote server. I tried everything at http://drupal.org/patch/apply

Is there an easier way to apply a patch?

General method for finding out proper place to apply patch from is the following: open patch file and look at the strings that describe path to files.
For this patch its following:

--- /dev/null
+++ modules/hs_content_taxonomy.admin.inc
and
--- modules/hs_content_taxonomy.module
+++ modules/hs_content_taxonomy.module

Then from file path you can guess right place: it has to be directory, for which file path would work, i.e. since we have "modules/hs_content_taxonomy.module" than proper directory is obvious: it has to be HS module directory which has "modules" subdirectory with .inc file and HS submodules in it. Then you put patch there, and apply:
patch -p0 < hs_ct_fixed.patch

Thanks crea. I'll try that.

After applying patch #110 to HS dev (2009-07-30) I still cannot enable HS Content Taxonomy
in modules list page (the red incompatibility mark keeps showing up in place of checkbox).
- if someone sets up a chipin widget I will be happy to throw in my contribution.

@crea: Patch in #110 failed against latest dev: hierarchical_select 6.x-3.x-dev (July 29, 2009 - 17:17). Find attached REJECTS file for details.

Could you remake the patch? Or post a .zip file containing the full HS module with patch already applied?

@skizzo Ofcourse you can't enable it. I removed line "core = 6.x" from info file so you can't enable it, because Wim asked me in #108 to remove lines added by packaging script. You can add this line manually if you wish to apply patch yourself and test it.

@Onopoc: I double checked that patch from #110 still applies without errors to latest (july 30) dev. You are doing something wrong.

$ patch -p0 < hs_ct_fixed.patch
patching file modules/hs_content_taxonomy.admin.inc
patching file modules/hs_content_taxonomy.info
patching file modules/hs_content_taxonomy.module

@crea: According to the release page the lastest dev version is July 29, 2009 - 17:17. http://drupal.org/node/172915/release

Where can we found the July 30, 2009 dev version?

@Onopoc Try hierarchical_select 6.x-3.x-dev. By "dev version" people usually mean development snapshots

@crea: Yup that's the one I used in comment #116. I mean the version on this page http://drupal.org/node/341008

I'll try again now. Then post result here.

@crea: I tried again but didn't work. PATCH command returns the following error message "can't find file to patch".

According to terminal log it seems that PATCH tries to patch the file 'modules/hs_content_taxonomy.admin.inc'. But it can't find this file because the file doesn't exist in the latest dev version (July 29, 2009) http://ftp.drupal.org/files/projects/hierarchical_select-6.x-3.x-dev.tar.gz. Find below attached terminal log to clarify.

You are applying patch in the wrong directory. why do you run "patch -p0 < /path_to_drupal_root_here/modules/hierarchical_select/modules/hs_ct_fixed.patch" while you are supposed to run "patch -p0 < hs_ct_fixed.patch" ? Run the following:

cd /path_to_hierarchical_select_module_directory_here/
wget http://drupal.org/files/issues/hs_ct_fixed.patch
patch -p0 < hs_ct_fixed.patch

Also you seem to have HS in the global "modules" directory which is wrong. Read documentation how and where to install modules first.

@crea: Got you. First I must CD to HS module folder. Then run the .patch. Thanks :) I learned something new.

It works :). PATCH command returns no error. Find below attached terminal log to clarify.

I'm testing the patched module now. I'll post result here.

As for the global "modules" directory that's normal because I have a Drupal multisites setup.
So my structure looks like the following
-/drupal_root/
--/sites/
---/my_domain_name_here.com/
----/modules/
-----/hierarchical_select/
------/modules/

The structure of HS module folder is the same though. So it should not affect the patching process.

@crea: I can confirm skizzo's result in #115. After applying patch #110 to HS latest dev I cannot enable HS 'Hierarchical Select Content Taxonomy'. The red incompatibility mark keeps showing up in place of checkbox. I tried both patches: #110 and via wget with same result. Find below attached screenshot to clarify.

@all: If someone else want to contribute testing I have attached patched module below. This is patch in #123 already applied to latest dev: hierarchical_select 6.x-3.x-dev (July 29, 2009 - 17:17).

Thanks Wim. I added line core = "6.x" to 'hs_content_taxonomy.info' file. And it works.

I'm testing now. Will post result here.

@all: Find attached working module.

@Wim Leers: actually I thought packaging script is smart about that, since branch name would be enough to figure out core compatibility and the patch was inteded for you to commit anyway :P

@Wim: I'm done with #128 testing. It works. I noticed a increase performance compare to Drupal 5.x module :). #128 testing done with same setup as #106.

@skizzo & all: Wim said he would like more than one person to test. Could you test #128 and post your result here?

@crea: I don't know how to create a patch yet. I'll read the handbook within the next days. In the meantime could you post a new patch for Wim? My .zip file is good for testing but not for committing.

@onopoc: I think that using patches (as opposed to tarballs) makes life easier for testers and developers. Patches can be reverted, will be there to remind me what I have or have not done to the dev version, and allow focused communication with developers.

@skizzo: Indeed patches make life easier for advanced testers and developers. But patches are a challenge for absolute beginner testers. I mean from an absolute beginner testers point of view, it's much easier to test a .zip or .tar file as oppose to a .patch file. Mostly because of the learning curve that comes with a .patch file.

Personally in future I'll try using .patch files during development and commit phases. And both .patch file and .zip/.tar file during testing phase. So testers can pick the file format that better matches their current skill level.

@crea: Thanks for the new patch. It works great.

@all: If someone else want to contribute testing I have attached below the latest dev version hierarchical_select 6.x-3.x-dev (July 29, 2009 - 17:17) with patch #131 already applied.

Just a quiestion. Is it enough if I only copy those three files from your "hierarchical_select-with-patch-131-already-applied.zip" to the latest Views-patched version of hierarchical_select - see http://drupal.org/node/342991#comment-1889368 , as they are the only ones mentioned in the patch:

hierarchical_select/modules/hs_content_taxonomy_views.info
hierarchical_select/modules/hs_content_taxonomy.admin.inc
hierarchical_select/modules/hs_content_taxonomy.module

The reason is that I want to use the Views-patched version of hierarchical_select and have the Content taxonomy enabled. I would then copy/overwrite the above mentioned 3 files into the Views-patched version of Wim?

@mitkoru: Yes those 3 files were changed plus another file 'hs_content_taxonomy.info'. Seems like a good idea to copy only those 4 files but I don't know if it would work though. I never tried the Views-patched version of hierarchical_select for Drupal 6. I suggest trying what you said on a test site instead of a production site. Because the Drupal 6 module is still in development phase and its structure might change before final release.

You're welcome to post your testing results here.

Tested the file in #134 http://drupal.org/node/342992#comment-1880396.

Got the "received invalid response from server" error that is said in closed issues to be related to modules that alter the node form.
(and content taxonomy does alter the form i assume)

The error happens when the form is submitted or previewed without all the required fields filled.

Still investigating about other modules interfering with this but if someone can reproduce this on a clean install will be great help.

The actual errors in the logs are:

Missing argument 2 for drupal_retrieve_form() in /home/testsite/public_html/includes/form.inc on line 320.

call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in /home/testsite/public_html/includes/form.inc on line 366.

uasort() [function.uasort]: The argument should be an array in /home/testsite/public_html/includes/common.inc on line 2843.

@inforeto: Re http://drupal.org/node/538022, could you please send me, via contact form, the list of your enabled modules? So that I can compare it against mine (124 modules) and shortlist potential sources of problem. Under Linux, if drush is installed, you can get the list running the following line command: drush statusmodules | grep Enabled | cut -d"(" -f1

Hi,

i have the same bug like in #137 on a vanilla Drupal installation after validation fails. My HS-version is from #134

I think I could discover, that the problem of #137 is in the HSID-session-variable.

After a validation-error a new HSID is generated in the SISSION and it looks like the HS-form-element do not realize it. And because of that the HS-form-element can not be found.

But this is only my opinion after one hour of debugging. It would be nice, if someone with more experience could approve it. The code I debugged is in the version of #134:

file:hierarchical_select.module -> function hierarchical_select_json()

I don't have problems with required field mentioned . Just tried this: I have "Regions and countries" CT field set to "required" and when I submit it not filled in, I simply get "Regions and countries field is required." error message as I should. Taking into account this is even not clean install, but development site loaded with lots of modules, and HS I have is even patched with Taxonomy Views patch, I tend to think problem is not in this patch.

If you insist there is problem with patch, post steps to reproduce. Also I won't comment problems in modules posted by other people, like the one in #134 cause I can't and won't check every piece of code posted here. I will only fix problems with patches posted by me. Get latest HS, get my latest patch, apply, and then it can be considered proper test.

ok, testing environment should be the following: preferably clean drupal install, latest CT (dev version), latest HS, my patch

Ok I reproduced this on clean site. Investigating...

There is problem with $hs_form_build_id values desyncing from $hsid number: during validation form is rebuilt with new hsid (+1) value, but hs_json function uses cached value where previous hsid is used, so it can't find correct #name of HS element. So I confirm #142.
However I can't understand how this can be connected to CT integration, since it only implements HS element and adds small submit callback, and other processing is done by HS.
I suspect it is HS bug: I'm going to try to reproduce it without Content Taxonomy integration.

I reproduced it with HS Menu integration. But i'm little late with bug reporting, cause there is alredy issue for it :D
See #541132: Hierarchical Select breaks with >1 Hierarchical Select form item on the page
Setting it to "needs review" because it was bug of HS, not HS CT integration.

When testing this patch, make sure you have latest Content Taxonomy. Preview errors are fixed only in dev version of it.

Direct link to latest 'Content Taxonomy' 6.x-1.x-dev (2009-Jul-15)
http://ftp.drupal.org/files/projects/content_taxonomy-6.x-1.x-dev.tar.gz
or
http://drupal.org/node/253900

yes I confirmed bug #142 when it loaded old cache lead to alert "Received an invalided ....
my site have 2 languages

Please post your experience of using this patch: it's needed so this patch finally will be committed. No need for confirming "invalid response" bug anymore cause it's already confirmed by Wim and there is different issue.

I've made the following setup:

1. Installation
- Install drupal 6.13 (http://ftp.drupal.org/files/projects/drupal-6.13.tar.gz)
- Install cck 6.x-2.5 (http://ftp.drupal.org/files/projects/cck-6.x-2.5.tar.gz)
--- enable Site Building->Modules->Content
- Install Content Taxonomy 6.x-1.x-dev (http://ftp.drupal.org/files/projects/content_taxonomy-6.x-1.x-dev.tar.gz)
--- enable Site Building->Modules->Content Taxonomy
- Install hierarchical_select-with-patch-131-already-applied (http://drupal.org/files/issues/hierarchical_select-with-patch-131-alread...)
--- enable Site Building->Modules->Hierarchical Select
--- enable Site Building->Modules->Hierarchical Select Taxonomy
--- enable Site Building->Modules->Hierarchical Select Content Taxonomy

2. Add Content Type: Name: "Cities", type: "cities"

3. Add vocabulary: Vocabulary name: "Cities of the world";
--- Use the Hierarchical Select form element for this vocabulary: "yes"
------ Save lineage: "Save only the deepest term"
------ Level choice: "Force the user to choose a term from a deepest level"
------ Dropbox settings: "Enable the dropbox"
------ leave all other settings as they are
--- Content types: "Cities"
--- Added some tags to this vocabulary, e.g. "Europe" -> "France" -> "Paris", "Lyon"; "Asia" -> "Japan" - "Tokyo"... etc.

4. Possible issue? When you add new content (Cities), e.g. "Berlin", HS jumps straight to the lowest level of the taxonomy, not making it a level-by-level (or step-by-step) choice. So as "France" is alphabetically before "Germany", as you choose "Europe" you are being brought straight to "Europe" -> "France" -> "Lyon" and you have to replace "France" with "Germany" and then choose "Berlin".

5. Install Content Profile 6.x-1.0-beta4 (http://ftp.drupal.org/files/projects/content_profile-6.x-1.0-beta4.tar.gz)
- enable Site Building->Modules->Content Profile
- enable Site Building->Modules->Content Profile User Registration

6. Edit Content Type: "Profile"
- enable "Use this content type as a content profile for users"
- Add new field:
--- Label: "Where I lived"
--- Field name: "where_i_lived"
--- Type of data to store: "Content Taxonomy Fields"
--- Form element to edit the data: "Hierarchical Select"
--- Global settings: "required", Vocabulary: "Cities of the world"
--- configure this Hierarchical Select widget's settings:
------ Level choice: "Force the user to choose a term from a deepest level"
------ Dropbox settings: "Enable the dropbox"

7. When you create/edit your profile everything goes ok, except for the problem described in 4.

One issue I have discovered though:

- enable Site Building->Modules->Content Permissions

- User management -> Permissions
--- enable "edit field_where_i_lived" for anonymous and authenticated users
--- enable "view field_where_i_lived" for authenticated users

- When you register a new user and make selections for "Where I lived" through HS the account and the profile is created. However the values for "Where I lived" are not saved in the profile, as this user signs in.

If you enable "Site Building->Modules->Option Widgets" and "Site Building->Modules->Content Taxonomy Options" and register a new account and make "Where I lived" selections through Options (change the Widget type to "Checkboxes/Radios") on the registration page the values are saved.

@mitkoru: What you described in #152 is not bug but feature of HS - it always expands itself to the deepest level when you set it to force to deepest level. #153 looks like bug though...

@crea:
#152: OK, I understand now... For a type of feature request it would be better for the Add-button to appear when the deepest level is reached. But that should be too much at this stage...

Anyway: do you have any other ideas for testing? I would love to help.

I suggest we commit this and open different issue for #153. Since this is compatibility issue between modules and not all users run Content Profile it shouldn't block committing this.

I second this.

#156: Sounds very reasonable as nothing else seems to create any problems...

@crea: should I open this new issue regarding #153?

@mitkoru once it committed, yes

Updated patch against HS 6.x-3.x-dev 2009-Aug-05

hmm, strange, info file wasn't touched. New version.

@crea: And what is the difference between the patch from #131 and from #161

Previous patch didn't apply clearly for me - there was a problem with info file.

This worked for me once upon a time (with the original patch), but I don't seem to be able to get it working now.

I'm thinking it's conflicting with some other module, but haven't figured out which one yet.

The preview works fine, but on the actual page, it doesn't seem to work well.

[edit]by not work well I mean that actually it doesn't work at all, as if the javascript doesn't function at all. So all I get is a plain HTML multi-select list box[/edit]

It's got to be some sort of conflict. If it were a PHP problem, I'm pretty good at debugging. But with Javascript, I need an error message to get started and there are no errors, just no functionality

Tom

yay! :)

Upgraded to the 6.x-dev version of Aug 18, now I'm getting the error stated in http://drupal.org/node/518830#comment-1942834

It was said before that module compatibility issues should be dealt in separate issues. Even while myself I use Content Profile, most users don't. So it's not a blocker.

got it!

I was able to apply the patch in #161, however not cleanly ( the .info file would not patch for some reason so I patched it manually on my test system). The patch once applied seems to work well using the new dev version of HS and of Content Taxonomy.

New info - I applied the patch in 161. It applied cleanly on Linux (I first tried it on Windows and no go, apparently because of /n/r versus /n for newlines I think).

On a couple of test installs it works great. On the site I want to use it for, none of the javascript loads. I mean literally, the the

Installed from scratch... 6.x-dev from Aug-18, plus the patch on #161

All seems working right.

Deselected 'Save values additionally to the core taxonomy system (into the 'term_node' table).' on the field configuration, only, otherwise, the field doesn't record the values. Don't know if that's by design. Noticed that the "hidden-lineages" input is not on the Page's form for that control.

When clicking 'Preview' after editing I get:

    * warning: Illegal offset type in isset or empty in \home\modules\taxonomy\taxonomy.module on line 1011.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1012.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1015.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 591.
    * warning: Illegal offset type in isset or empty in \home\modules\taxonomy\taxonomy.module on line 1011.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1012.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1015.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 591.
    * warning: Illegal offset type in isset or empty in \home\modules\taxonomy\taxonomy.module on line 1011.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1012.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 1015.
    * warning: Illegal offset type in \home\modules\taxonomy\taxonomy.module on line 591.

@arielon check that you have latest Content Taxonomy installed. Preview errors were triggered in it.

Tested with HEAD. The patch from #161 applied except for hs_content_taxonomy.info which I had to edit manually.

I suggest adding in 2 lines to support localized terms.

One inside function theme_hs_content_taxonomy_row():

+   $term  = taxonomy_get_term($item['value']);
+    _content_taxonomy_localize_term($term);

Second one here:

@@ -492,6 +412,9 @@
     return FALSE;
   }
   $term = taxonomy_get_term($item);
+  _content_taxonomy_localize_term($term);
+  // Bug: tid isn't set to zero for some reason when root term is not set, so we make workaround for this
+  //$params['tid'] = $params['tid'] ? $params['tid']: 0;
   return ($term->vid == $params['vid'] && _hs_content_taxonomy_term_within_allowed_depth($term->tid, $term->vid, $params['tid'], $params['depth']));
 }

Attached is a new patch, including fix for #174.

subscribing, thx.

For the guy(s) getting:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'hs_content_taxonomy_config_form' was given in [path]\home\includes\form.inc on line 366.

Just wanted to report this as #79 oboskovic is having it... Maybe is due to the patch/downloads/ hand edits combinations...

Just checked my hs_content_taxonomy.admin.inc and it was.... empty! So, replaced with content and that was it.

Great job!

Dunno if this is only happening to me, but:

1- Make a HS Content Taxonomy Required.
2- Go to the Node and save it without the Required data for that field.
3- Normal Drupal Message: "[field_name] field is required."
3- Go again and select something from the drop-down - Popup Error: "Received an invalid response from the server." The value doesn't get added to the dropbox.

Firebug:
POST http://[path]/hierarchical_select_json 200 OK 1.34s

Response

Fatal error: Unsupported operand types in [path]\home\includes\common.inc on line 2845

I can reproduce it all the time consistently for different content types.

@arielon: see #147 and #541132: Hierarchical Select breaks with >1 Hierarchical Select form item on the page

thanks!

Posted a temp solution there (http://drupal.org/node/541132#comment-2014334) 'cause didn't make it with the patch/cvs, etc combination found there... and Aug-18 version breaks it all on my install..

subscribing...

Wow, what a long thread.

/subscribe.

Does the last patch still work against dev? I dont't see why this should be implemented in the content taxonomy module. HS improves select lists and is good to keep in a own module, and even though content taxonomy is a special case it's HS home should be the HS module.

I'm ok with that approach, as long as it speeds up the release of a stable D6 version that we all will be happy to see.

Subscribing.

I would add my 2 cent. I think content taxonomy integration must be a HS task to provide the d6 versions with same features than d5 versions.

The 5.x and the 6.x versions of Drupal are the currently supported versions, and modules that provide integration with both should make the update as easy as possible.

I'm agree on the background idea, this is more a content taxonomy task to integrate with HS than HS to integrate with content taxonomy. But when a stable d6 version will come out.

subscribing. Really looking forward to stable release.

Also please be patient with this kind of modules that require compatibility because while we can always test on a clean install the real complex builds that need testing take a while to troubleshoot.

So far my own install is behaving nicely with a bunch of modules.

Guys, it's not a problem with CT patch, that it doesn't work or something like that (though it SHOULD work with any HS version with min. changes cause it doesn't change HS files besides info file). The real issue here is Wim not wanting to commit and support it.

@Wim:
Are you so afraid to say "I don't want to commit and support it" ? Come on, it's not that hard or scary. We are mostly adults here, and everyone has their own lives/families/ business/etc. It is not disaster to say "No" in this case. It would be completely understandable.
However, what is real silly here, it that you from the start behaved like it's going to be commited at some point, and now you come with silly excuses like "It should live in CT". Remember you asked me to update the patch so it meets your committable criteria, and I did that. Its very sad to see people treated like that.

Thanks for all the effort, HS is already a very important module.
There's a wide need of tying cck to taxonomy so both HS and CT will be indispensable.
You are right in that the task can be great trouble (such as happened to the category module) but it will pay off to have them compatible and updated.

Thanks for committing the patch Wim :)

About the support thing that's cool with me. And I'm sure others will understand. You're not paid to do this, you're volunteering. One advantage of Drupal being open source is that you can share this workload with contributors.

yipee. Looking forward. Thank you.

Looks good!

A couple of minor issues:

The entry on the CCK edit form ends up in a group labeled: "Vocabularies" but in the "manage fields" section of the content type it's shown as "Taxonomy - Taxonomy Module Form". All HS fields in a given form end up in this same group.

In addition there are some problems with drag and drop with this group in "manage fields". I could not move it everywhere I wanted, and not into another group. This group does not show up in the alphabetical list at the top of the manage fields page, or in the "Display Fields" section.

I would expect the HS field to be alone in the CCK form and the fields list, ie not in a group, and be labeled with the name of the taxonomy.

Hi,

Could it be that: #35 is still in the committed code: "doesn't seem to load saved term on node edit".?
I filed a new issue http://drupal.org/node/629156 because this one is closed.
Should I make some changes in module weights?

EDIT: I missed something, fixed http://drupal.org/node/629156.
I can't remove this comment, so I will use it to tell you guys. Thank you for porting this module to D6!

Greetings, Martijn

Hi,
sorry to bother with old stuff but #153 is still a problem for me. Content Taxonomy fields with Hierarchical Select in Content Profile don't save their values after a new user registration (however, they save if the user later edits his profile).
Looks like a permission matter, but the guest user has the rights to view and edit the CT field.
When he registers, everything seems ok BUT the value is not saved.

Did someone open a new issue or we are still stuck here?

Hi,

Could it be that the VID and TID of the HS content taxonomy field is inserted with the same value, the TID of the HS object?
I thought this is about HS content taxonomy, that's why I insert this issue here, If you want me to make a new issue, that is fine by me.

greetings, Martijn

Made new issue: http://drupal.org/node/777630.
greetings, Martijn