Facet UI Error: The widget does not support the sarnia_term query type

This patch re-enables the UI to select the query type, allowing you to change the query type between 'term' and 'sarnia_term'.

Added bonus: this implementation of hook_facetapi_widgets allows Sarnia facets to work as query type sarnia_term, with the Select widget in the Facet API Bonus module (This should be written in a proper sub-module). Facet API Bonus module required.

/**
 * Implements hook_facetapi_widgets().
 * Add additional support for Sarnia with Facet API Bonus Select Widget
 */
function sarnia_facetapi_bonus_facetapi_widgets() {
  return array(
    'sarnia' => array(
      'handler' => array(
        'label' => t('Sarnia Term Select'),
        'class' => 'FacetapiBonusSelect',
        'query types' => array('sarnia_term'),
      ),
    ),
  );
}

Patch submitted to dev version.

Applied patch was accidentally backed out. The UI should be re-enabled allowing selection of the 'term' query type.

I didn't experience this issue until the recent updates to the module. After the update, I started getting the widget error on all my sites any time I tried to configure the facets. Yes, I can select "term" for the query type, but it leads to broken facets when they contain punctuation, just as it was described in #2. So being able to select the term query type does not help. As it stands, you can either have working facets with the default configuration or broken facets configured the way you want.

I spent a lot of time yesterday and today trying to learn the Facet API to find the correct way to fix the issue. Unfortunately, the API doesn't allow us to alter the widget plugin definitions. If it did, then this would be easy to fix. The quick and dirty way to fix this issue is to hack the Facet API module by adding 'sarnia_term' to the link widget's 'query type' array in facetapi_facetapi_widgets(). If we could alter that with a hook in Sarnia, then there wouldn't be a problem, but I can't find any way to do it.

After trying a few different things to fix the problem I've come to the conclusion that the best way to fix the problem is for Sarnia to define its own widget plugin. We don't have to provide a widget class. We just have to define it and point it at Facet API's link widget class. I've attached a patch that does this.

When you apply the patch and clear the site cache, you should have the 'Sarnia links' widget type available in the facet configuration form. When you select it and the 'sarnia_term' query type everything should work correctly. My only concern about the patch is that it's not the best UX. The 'Links' widget is still only usable with the 'term' query type. The 'Sarnia links' widget will only be usable with the 'sarnia_term' query type. That's the way it has to be if you want the facets to work. Any other combination will give you the widget error, which could be confusing.

To help combat this UX problem, I've set the 'Sarnia links' widget to be the default for Sarnia's facets. For new Sarnia servers, the new widget and 'sarnia_term' should be selected by default. Sites that are updating may have to manually select the 'Sarnia links' widget and/or the 'sarnia_term' query type.

The one other solution I found was capable of breaking Search API's functionality, so I don't consider it to be a viable option. I think this is the only way. At least, it's the only way I found.

+++ b/sarnia.module     2014-09-02 15:49:50.021114800 -0500
@@ -1086,6 +1086,12 @@ function sarnia_facetapi_query_types() {
+    'term' => array(
+      'handler' => array(
+        'class' => 'SearchApiFacetapiTerm',
+        'adapter' => 'search_api',
+      ),
+    ),
   );

I also deleted this re-definition of the Search API's term query type. I don't know why it was added, but I'm fairly positive that it has no effect. If you dump the $plugin_ids in FacetapiAdapter::loadQueryTypePlugins() you can see that it stays the same whether Sarnia re-defines the plugin or not. Was there another point to including it?

It is possible to alter the widget definition through hook_ctools_plugin_post_alter(). I attached a patch that should fix this.

Ah, that will be perfect, @seanB. You've taught me something. Thank you. I'll test your patch once I'm out of this meeting.

I tested #8 and it works for me. I'm only adding a new patch to incorporate the two extra changes that I put into #7. I still don't think we need to redefine the term handler.

Actually, I'm not sure we need to add the 'term' query type on line 1123 anymore either. It could be allowed to default to 'sarnia_term' and it would work correctly now. I didn't take it out because I suppose it doesn't hurt to leave the option in.

I also want to apologize. I just realized that you all probably couldn't apply #7. When all the bugs started popping up with the latest changes I was ordered to work with a local repository and apply patches selectively. So I rolled #7 from that local repo, not using the official repo from Drupal.org. I made sure not to make that same mistake with this patch.

Trying out the patch in #10 on current 7.x-1.1-beta3+24-dev (2015-Jun-03)... Implementing hook_ctools_plugin_post_alter seems like a more elegant solution.

Implementing hook_ctools_plugin_post_alter seems like a more elegant solution.

Agreed. I would have done the same in #7 if I had known about the hook.

#10 also opens up the possibility of better support for Facet API addons like Facet API Bonus and AJAX Facets, which I was struggling with in earlier iterations of this solution.

Hurray!

Looking to implement support for additional Facet API widget modules, such as (and including) Facet API Bonus Select lists.

Looking to implement support for additional Facet API widget modules, such as (and including) Facet API Bonus Select lists.

As a contributed module maintainer you are free to work with issues and organize the module's queue any way you prefer. I only wish to mention that in the Drupal Core queue we would typically handle something like this in a different follow-up issue and allow the original committed/fixed issue to close. There are several reasons why we do it, not all of which are necessarily applicable here since Core is a larger, more active community. I don't want to seem preachy, so I won't go into the reasons unless you would like to discuss them. In general, I think it's a good practice though. You may want to consider doing the same.

dcam: You're right -- what I was pursuing is probably best tabled in a new issue.