Content Taxonomy Views config not retrieved properly and Views fusion compatibility

Just so I'm clear, which HS config am i saving again? There's the one for the taxonomy, the once for the CCK Content Taxonomy field in the node-type itself, and the one in the view. Or am I doing all three? If so, does the order matter?

shawn

OK, tried re-saving, and no joy. No add button. I'll send you a log-in and URL info via your contact form.

Any progress, Wim?

Great! and good luck with the exam. :-)

shawn

Did a little investigating, and found something interesting:

1. When configuring the HS Exposed Filter, $config['config_id'] in function hierarchical_select_process has the value content-taxonomy-views-userNodeInfo-field_profiledetails_location, which corresponds to the row with name hs_config_content-taxonomy-views-userNodeInfo-field_profiledetails_location in the variables table. The row is there, and the values correspond to the form. So the configuration form seems to be working as it should.
2. However, when viewing the view, $config['config_id'] in function hierarchical_select_process has the value content-taxonomy-views-userNodeInfo-4. No row in the variables table starting with "hs_config_" matches this value.
3. My main view is a views-fusion view, and so this same variable in the views-fusion view is reported as content-taxonomy-views-userlist-4. "userlist" is the name of the main view.

Hope this helps...

@wim: my debug "drupal_set_message" calls are still in the hs.module file on my site. That's how I investigated this.

shawn

No worries. Note that in point #2 above, that particular view is the non-fused one. It's just the view of #1 but in view-mode, not edit/config-HS mode. It still has the wrong value for the config_id, with a '4' instead of 'field_profiledetails_location'.

shawn

OK, found (and think have the fix) for one defect. In function hs_content_taxonomy_views_form_alter within the hs_content_taxonomy_views.module file, line 84 reads:

          hierarchical_select_common_config_apply($form["filter$id"], "content-taxonomy-views-$view->name-$vid", $defaults_override);

and should read (i think)

          hierarchical_select_common_config_apply($form["filter$id"], "content-taxonomy-views-$view->name-$field_name", $defaults_override);

with $field_name instead of $vid.

That gets rid of the problem in point 2 in #9 above, and also the correct field name is showing up for point 3 with this change, even though the view-name part within the $config_id variable is still not matching. So, for the point 2 view, the add button now shows up, as it should.

Point 3 is I believe, and as you suspect, Wim, because of Views Fusion.

Just thought I'd post this further bit of my investigation.

shawn

OK, so for problem 3 of #9 above, what about leveraging a function like:

/**
 *  Determine the actual view that defined a filter.
 *
 *  @param
 *    $view - a view object containing the filter
 *  @param
 *    $fieldName - the name of the field that is being filtered
 *
 *  @return
 *    a view object of the filter-defining view, or FALSE if the filter is not defined
 *    in either the main view specified by $view or any of its fused views if module
 *    views_fusion is in stalled.
 *
 **/

function get_defining_view_for_filter( $view, $fieldName ) {

  $sql = "SELECT count(vid) FROM {view_filter} WHERE vid = %d AND field = '%s'";
  
  $found = ( db_result( db_query( $sql, $view->vid, $fieldName) ) > 0 );
  
  if ( $found ) {
    $returnValue = $view;
  }
  else {
    if ( module_exists( 'views_fusion' ) ) {
    
      $sql1 = "SELECT mvid, uses FROM {views_fusion} WHERE vid = %d'";
      $result = db_query( $sql1, $view->vid );
      $returnValue = FALSE;
      
      while ( $row = db_fetch_object( $result ) ) {
        if ( $row->uses == 'nodefamily_parent' &&
              db_result( db_query( $sql, $row->mvid, $fieldName) ) > 0 ) {
            $returnValue = views_load_view($row->mvid);
        }
      }
      
    }
    else {
      $returnValue = FALSE;
    }
  }
  
  return $returnValue;
  
}

and then using this when determining the view name? for example, for line 84 in function hs_content_taxonomy_views_form_alter within the hs_content_taxonomy_views.module:

      $filterView = get_defining_view_for_filter( $view, $field_name );
      hierarchical_select_common_config_apply($form["filter$id"], "content-taxonomy-views-$filterView->name-$field_name", $defaults_override);

OK, slightly revised function that is a bit more efficient, and only returns the view name, instead of an entire view object, as that is all that is needed.

/**
 *  Determine the actual view that defined a filter.
 *
 *  @param
 *    $view - a view object containing the filter
 *  @param
 *    $fieldName - the name of the field that is being filtered
 *
 *  @return
 *    a view name of the filter-defining view, or FALSE if the filter is not defined
 *    in either the main view specified by $view or any of its fused views if module
 *    views_fusion is in stalled.
 *
 **/

function get_defining_view_for_filter( $view, $fieldName ) {

  $sql = "SELECT count(vid) FROM {view_filter} WHERE vid = %d AND field = '%s'";
  
  $found = ( db_result( db_query( $sql, $view->vid, $fieldName) ) > 0 );
  
  if ( $found ) {
    $returnValue = $view->name;
  }
  else {
    if ( module_exists( 'views_fusion' ) ) {
    
      $sql1 = "SELECT mvid FROM {views_fusion} WHERE vid = %d AND uses = 'nodefamily_parent'";
      $result = db_query( $sql1, $view->vid );
      $returnValue = FALSE;
      
      while ( $row = db_fetch_object( $result ) ) {

        if ( db_result( db_query( $sql, $row->mvid, $fieldName) ) > 0 ) {
            $sql2 = "SELECT name FROM {view_view} WHERE vid = %d";
            $returnValue = db_result( db_query( $sql2, $row->mvid) );
        }
      }
      
    }
    else {
      $returnValue = FALSE;
    }
  }
  
  return $returnValue;
  
}

which would make the call then look like:

          $filterViewName = get_defining_view_for_filter( $view, "content_$field_name.$field_name".'_value' );
          hierarchical_select_common_config_apply($form["filter$id"], "content-taxonomy-views-$filterViewName-$field_name", $defaults_override);

Question: I had to prepend the field name with "content_", double-up the field name, and append "_value" for this to work; will this construction always be the case?

This makes the add button appear as it should now in both the underlying view and the fused view.

Hope this helps. How do we make it "standard" in HS?

shawn

...and now that I got this far, with the "Add" button appearing so i can choose multiple options, it seems as if the filter is "ANDing" all the values, which of course means I get no results, as a node has only one content_taxonomy lineage in the taxonomy, and thus wouldn't have the two or three showing in the filter. In other words, seems the filter is looking for "is all of" as opposed to "is one of".

Also getting double "Remove" labels... one an actual link, the other a checkbox, after the submit of the view comes back.

shawn

OK, ignore the "ANDing" problem... that was my own fault in how I set up the view. It's fine.

However, the double "Remove" labels are still there.

Had to make a couple more changes to get this to work.

First, the construction "content_$field_name.$field_name".'_value' for the call to get_defining_view_for_filter( $view, "content_$field_name.$field_name".'_value' ) will not always work. It doesn't work when the field is stored in the content_type table. This happens when full lineage is not being stored, and multiple values for the taxonomy are not allowed for the node. However, $filterViewName = get_defining_view_for_filter( $view, $filter['field'] ); will work for both situations.

Secondly, again for the same circumstance where the field is actually stored in the content_type table, the function _hs_content_taxonomy_views_parse_fieldname_from_id needed a second test to pick up the case where $id was of the form "content_type_contenttypename.field_fieldname_value".

/**
 * Given an id of the form "content_taxonomy_<field name>.tid", get the
 * field name.
 *
 * @return
 *   When no valid id was given, FALSE, otherwise the field name.
 */
function _hs_content_taxonomy_views_parse_fieldname_from_id($id) {
  $field_name = FALSE;

  // When "save as tag": content_taxonomy_field_<field_name>.tid
  // Other save options: content_field_<field_name>.<field_name>_value
  if (preg_match("/(content|content_taxonomy)_(field_[A-Za-z0-9_]+)\.(\\2_value|tid)/", $id, $matches)) {
    $field_name = $matches[2];
  }

  // Second test to get field name when field stored in the content_type table.
  elseif ( preg_match("/(content_type_[A-Za-z0-9_]+)\.(field_[A-Za-z0-9_]+)_value/", $id, $matches) ) {
    $field_name = $matches[2];
  }
  return $field_name;
}

With these changes, I now have HS Content Taxonomy working with the Content Taxonomy field on my nodes for location, and in the views filters permitting searches, in both the cases where (a) the full lineage is stored in a table specific to that field, and (b) when only the deepest term is stored in the content_type table, for both a regular view and a views_fusion view.

@Wim: Does this all look "correct" from your perspective? Also, do you feel it should be folded into HS?

shawn

I think I indicated in the various posts which modules / files I was changing, did I not?

shawn

No problem. Was a fair bit of detective work to figure this much out.

On a slightly different note, is it just me, or is Wim missing in action?