The default query type setting is hard coded to "term" which causes issues for widgets that don't support "term" queries

Hi levialliance.

Thanks for posting. I am changing this to a support request, because I can confirm that the conclusion in the bug report isn't correct. Facet API most definitely can have facets and widgets that don't support the "term" query type.

Did you create a query type plugin for "myquerytype" and register it with the adapter you are using? See the apachesolr_facetapi_query_types() function and the associated classes for an example.

Also, are you sure you want to implement a new query type? I'm not sure I understand the desire to have a facet that is only tied to one widget. I can see the flip use case, where a widget is only tied to one facet. I just discovered that this isn't documented in facetapi.api.php :-(, but there is a "requirements" key that you can use in the widget definition for this purpose.

/**
 * Implements hook_facetapi_widgets().
 */
function mymodule_facetapi_widgets() {
  return array(
    'mywidget' => array(
      'handler' => array(
        'label' => t('My Widget'),
        'class' => 'MymoduleFacetapiMywidget',
        'query types' => array('term'),
        'requirements' => array(
          'facetapi_requirement_facet_property' => array('name' => 'myfacetname')
        ),
      ),
    ),
  );
}

What this says is that the widget can only be applied to the facet named "myfacetname".

Hope this helps,
Chris

Bumping this, because I'm experiencing it too. A good example of a widget that doesn't support "term" is the Slider Widget referenced on FacetAPI's module page. This is a correctly defined widget (as far as I can tell!).

Then I try to create a new facet for it, for example:

  $facets['is_age'] = array(
    'name' => 'is_age',
    'label' => t('Minimum Age'),
    'description' => t('Minimum age requirement'),
    'field' => 'is_age',
    'field api name' => 'field_job_min_age',
    'query types' => array('numeric_range'),
    'query type' => 'numeric_range',
    'index_type' => 'integer',
  );

(note I have both the array and singular definition in there, to be doubly sure)

This is an integer data type, numeric_range in Facet parlance. But try and select the Slider widget, and you'll get a form validation error that this widget doesn't support the "Term" query type. that error comes from facetapi.admin.inc, function facetapi_facet_display_form_validate().

function facetapi_facet_display_form_validate($form, &$form_state) {
  // Gets the selected query type and widget.
  $query_type = $form_state['values']['global']['query_type'];
  $widget_name = $form_state['values']['widget'];

  // Loads the widget plugin, makes sure it supports the selected type.
  if ($widget = ctools_get_plugins('facetapi', 'widgets', $widget_name)) {
    $widget_types = drupal_map_assoc($widget['handler']['query types']);
    if (!isset($widget_types[$query_type])) {
      $error = t('The widget does not support the %type query type', array('%type' => $query_type));
      form_set_error('widget', $error);
    }
  }
  else {
    $error = t('Widget %name not valid.', array('%name' => $widget_name));
    form_set_error('widget', $error);
  }
}

It's throwing the error because the widget does not support the query type defined in $form_state['values']['global']['query_type']; , which comes from a hidden field on the form... which doesn't seem to care about the facet definition.

If it is intended to check against a hardcoded value, can someone explain why?

Otherwise, thank you levialliance for a good patch. Attaching a re-roll against the current version (rc4)

Doesn't work with latest version of Facetapi (rc4) and facetapi slider on numeric field.

I have the exact same problem implementing a widget for a new query-type. This problem only appers in widgets supporting only one query type (not being term) and/or one operator (not beeing AND). Was going to start a new issue, but will submit my patch, (very similar to other patches in this tread).

Add this in your custom module

function hook_ctools_plugin_post_alter(&$widget, &$plugin_type_info) {
  if (!empty($plugin_type_info['hook']) && $plugin_type_info['hook'] == "facetapi_widgets") {
    $widget['handler']['query types'][] = 'your_query_term';
  }
}

@Nick_vh I'm not sure if you have misunderstood the problem. The issue occurs when defining new facets supporting one query_type (not term).

In this piece of code in facetapi.admin.inc:

  // Loop through the query types so the key is the same as the value
  $query_types = drupal_map_assoc($facet['query types'], 'check_plain');
  $form['global']['query_type'] = array(
    '#type' => 'select',
    '#access' => count($facet['query types']) > 1,
    '#title' => t('Query type'),
    '#prefix' => '<div class="facetapi-global-setting">',
    '#suffix' => '</div>',
    '#default_value' => $global_settings->settings['query_type'],
    '#options' => $query_types,
    '#description' => t('Select the query type this facet will use.'),
  );

if $query_types has only one element, the form element will be hidden with the default_value hard-coded to "term". So if $query_types contains the single element "my_query_type", it will not be saved, but overriden by "term", $options being ignored by FAPI when not a visible select element.

I am trying to wrap my head around this. I do agree there is definitely a usability WTF here. There should at least be some JavaScript that doesn't present options that aren't valid.

An issue I see with the Facet API Slider module is that it doesn't implement requirements, so it presents itself as an option for facets that do not support the query type plugin. It is in these cases where I see the phenomenon mentioned above. For cases like number fields which do allow numeric range queries, the user is presented with an option to select the correct query type, although again JavaScript should be changing the values so it doesn't default to something that won't validate.

Thanks for all of the discussions and research around this issue. Look forward to more discussion and a better understanding of the bug.
Chris

Marking as needs work, more so in helping me understand the issue fully.

Thanks for the very detailed explanation! I understand much better what the problem is and have wrapped my head around it. Marking #1443340-11: The default query type setting is hard coded to "term" which causes issues for widgets that don't support "term" queries as needs review.

I totally get it now and can replicate the bug. Patch works as expected. I am refactoring a bit just to highlight exactly why to code is written as such, but marking as RTBC. Thanks for sticking with me on this one.

Chris

Committed to all active versions of Facet API.

• http://drupalcode.org/project/facetapi.git/commit/d3775b9 (7.x-1.x)
• http://drupalcode.org/project/facetapi.git/commit/dcc2f82 (7.x-2.x)
• http://drupalcode.org/project/facetapi.git/commit/2d0289b (6.x-3.x)

Congrats on becoming the 28th code contributor to Facet API!

If being really anal about it, shouldn't $facet['allowed operators'] also first be filtered like:

$allowed_operators = array_filter($facet['allowed operators']);

Since a valid value for $facet['allowed operators'] could be:

array(FACETAPI_OPERATOR_AND => FALSE, FACETAPI_OPERATOR_OR => TRUE)

and that would cause the same problem?
Either that or refactor the code so that $facet['allowed operators'] stores the allowed operators as values instead.

gnucifer,

You are absolutely right, and great catch! If we take $allowed_operators = array_filter($facet['allowed operators']); approach that you mentioned, we can actually replace the reset($facet['allowed operators']); statement with your snippet and read the key() of the captured variable. We don't need reset() because the internal pointer isn't transferred to the array returned by array_filter(). The attached follow-up patch takes this approach.

Thanks for the contribution,
Chris

This is a small change, so I committed it to all major versions of Facet API giving gnucifer credit.

• http://drupalcode.org/project/facetapi.git/commit/b9678a7 (7.x-1.x)
• http://drupalcode.org/project/facetapi.git/commit/a42292b (7.x-2.x)
• http://drupalcode.org/project/facetapi.git/commit/a117310 (6.x-3.x)

gnucifer, congrats on becoming the 29th code contributor to Facet API!

Added tests for the 7.x versions of Facet API.

• http://drupalcode.org/project/facetapi.git/commit/dd53fb1 (7.x-1.x)
• http://drupalcode.org/project/facetapi.git/commit/db28f8a (7.x-2.x)

I know this has been closed for several months now, but I'm still running into this error with facetapi-7.x-1.2 and facetapi_slider-7.x-1.x-dev:

The widget does not support the term query type.

Re-closing as fixed. You have to make sure that the correct query type is used, because sliders should work with term query types. They should only work with ranges. If the problem persists, I suggest opening up a new bu report with detailed steps to reproduce.

Thanks,
Chris

Hi cpliakas, you said

You have to make sure that the correct query type is used

where do you set the query type? My field is ubercart Sell Price field and it was set by default to decimal in search_api field type.

Let's open a separate issue for this as opposed to re-opening an old one. It helps to make sure we aren't trouble shooting multiple things in one thread.

No problem. I have opened another issue.

#3: 1443340-3facet-global-defaults-1.patch queued for re-testing.

Dear,

I still have this error while using facet api and slider widget...

Does anybody have a solution ?

Best regards,

3: 1443340-3facet-global-defaults-1.patch queued for re-testing.

Any news on this? I still get this error even with the latest dev version of Facet API.
Am using 7.x-1.x-dev of facet slider and the latest dev version of Facet API.

Thanks

May be you can fix it already? This problem has existed for two years.

Thanks

Hi,

I also get the error:

Error message: The widget does not support the term query type

I use Facet API 1.4 with With Facet API Slider 1.0. I tried to apply widget Slider to my field price (Integer) when I get this error. Anyone has a way to quickfix this?

Any update on this? @cpliakas you say this was committed (back in 2012), but I still don't see this reflected in the current codebase, 1.5. Needless to say I'm running into this error. What's the status?

EDIT: Looks like the the settings array was changed to remove the operator and query_type keys. Still, this problem appears to have resurfaced and is causing issues.