Facet blocks anywhere

Well, the search blocks should still, I think, be disabled by default on all except the search page.

We'd either a per-block config setting or something else to handle this.

I'd like to hear your opinion on this idea:

Are these "facet blocks", when the facets are taxonomy terms, duplicating the functionality of modules like tagadelic? Why/why not?

O man facet navigation is really exciting. Those facet blocks can then be tied to a search form block thereby allowing quiet a bit of stuff.

@David would encourage you to take a look at http://drupal.org/project/apachesolr_views . This project ties into the facet blocks allowing for that to happen. Just need to have the 'facet' either as an exposed filter or an argument

@dave, re #3: I was speaking of *just* the case where the facets are taxonomy terms, since we're essentially using Drupal data to show the terms and perhaps their lineage (Solr stores only the term ids); but I was missing the scenario where these blocks were populated as a result of a search (internal or user-started) which, of course, can't be done with Tagdelic.

Are we aiming to show these blocks somehow filtered to facets after a search result? Or just something like tagadelic (showing the complete available facet values for a facet, with no filtering? I find it hard to come up with a use case for the former.

Thanks for the time =)

Sorry to insist with questions, I just want to get my involvement right =)

@david: I'm thinking this is a complete duplicate of #358166: Search for just facet(s) as that issue's goal is to *start* a full-fledged apachesolr search with just a facet value and no keys... I still don't understand what's different?

Perhaps the "different" portion of this issue is showing a "start browsing" page like this? http://www.peb.com.mx/faceted_search/ ... however those facets are not limited and represent the whole node corpus.

Ok so I achieve this though Im not happy about it yet. It takes a node/NID page and runs a query that loads up the facet blocks for the nodes terms. The links to go back work.

Basically, the approach is to have apachesolr, on hook_init() execute a query so apachesolr_has_searched() is true and there is a valid search that happened. My approach using my apachesolr_views but it uses standard apachesolr facet blocks.

/**
 * Implementation of hook_init().
 */
function mc_init() {
  // use menu_get_item() to fetch the node
  $router = menu_get_item();
  if (is_array($router['load_functions'])) {
    foreach ($router['load_functions'] as $position => $function) {
      if ($function == 'node_load' && !empty($router['map'][$position])) {
        $tags = array(implode(",", array_keys($router['map'][$position]->taxonomy)));
        // grab the View and execute it.
        // need to use preview, as you can't pass in arguments any other way
        // cause the $view->build will parse arguments from the url
        // calling $view->pre_execute($args = array()) won't work either
        // as that relies on a display handler being active
        // thus we be stuck
        // also we need a display_id so the links generated by the blocks make sense
        $view = views_get_view('conversations');
        $view->preview(MC_CONVERSATIONS_PAGE, $tags);
      }
    }
  }
}

It is using apachesolr_views to do the query but all the facet blocks work. The same thing can be done with apachesolr standard.

I hope this gets you started.

Thats not where you want to invoke it. It becomes a race between who's hook_block() gets called first. You want it in hook_init(), and you probably want it configurable.

Right, there's a huge flaw here. Perhaps the part that's missing is checking the block delta to execute the search only if we're really dealing with an apachesolr_search block.

lost me there. Why would you want it to only work with apachesolr_search block.

I'm a bit wary of hook_init(), afraid to perform a search in some cases where it is not necessary, as it is really required only on a search page or when a facet block is actually visible.

like in my example, it only performs searches on node/NID pages. You can do something similar based on loading up the block and checking the visibilty settings. I believe the blocks are static cached so there is no db queries thats really added.

Then there is also the problem of apachesolr_has_searched() and apachesolr_static_response_cache() allowing only a single search. I'm afraid we'll soon want to be able to perform multiple searches per page request, but that would be a separate issue. IMO it should be perfectly legitimate to have an apachesolr_search facet block on an apachesolr_views page even though these would be separate searches.

That happens already. The response is exactly the same. The apachesolr_current_query() returns an object that implements Drupal_Solr_Query_Interface which both the standard Solr does, and apachesolr_views. So all the facet blocks work. I do not think there is a need to make these store multiple.

all facet blocks expect for sorts #443410: Apachesolr Sort block doesn't integrate with this module. And this is because Views doesn't have a concept of exposed sorts. But its rumoured that its being worked on in the recently branched, Views3.

Still confused here. So Im going to take an implementation stab here. Lets say on standard node View page of type = 'page' you want to display the taxonomy facet block with fq=type:page.

On init(), check to see if !apachesolr_has_searched() and url matches the View (Views has a static cache as well something like current_view()). If it does, run a apachesolr search.

So basically, you need a way to set up those rules. The facet blocks shouldn't care what type (standard, local solr, apachesolr_views) the query is.

This doesn't feel like something that belongs in apachesolr.module.

Subscribing -- any movement here (or elsewhere) on a solution for this? It would be great to allow faceted browsing using Solr.

@brant: Maybe these alternatives *might* be of some use:

The 2.x branch already has some options to show "browse by" blocks at the search start page (/search/apachesolr_search)

As an alternative you can also use taxonomy_menu to show taxonomy blocks (expandable if you use DHTML_menu module or the like) you can place anywhere, that will lead to an ApacheSolr search if you enable "Use Apache Solr for taxonomy links" under the Advanced configuration fieldset in admin/settings/apachesolr/settings.

So, for 7.x-1.x (and 6.x-3.x) this sounds like what EclipseGC suggested was possible w/ Views context + panels.

I don't think it's something we should directly support.

We already have the facet browsing working in 7.x

For D6, you can use something like this in a hook_init to send a query to Solr so that facet blocks can be displayed on any page ($query and $response will be saved as static variables) :

function MYMODULE_empty_search($base_path = '', $filterstring = '') {
  //Based on apachesolr_search_execute
  $query = apachesolr_drupal_query('', $filterstring, '', $base_path);
  $params = apachesolr_search_basic_params($query);
  if (!apachesolr_server_status()) {
    apachesolr_failure(t('Solr search'), $filterstring);
    return FALSE;
  }
  apachesolr_search_add_facet_params($params, $query);
  apachesolr_do_query('apachesolr_search', $query, $params);
  apachesolr_has_searched(TRUE);
  return TRUE;
}

hi all,

I am using Apache Solr Search Integration 7.1.2, facet api 7.1.3 with solr 4.0? ( opensolr service ).

I can not see facet block in non-search page even-though I set up

/admin/config/search/apachesolr/settings/solr/facets?destination=admin/config/search/apachesolr/settings

Non-search paths
node
node/*
content/*
user/*

and
/admin/config/search/apachesolr/search-pages/core_search/edit

advanced option
[x]Show enabled facets' blocks in their configured regions and first page of all available results

when i hit search button with no key words, it returns

Please enter some keywords.

hope any solution.

best,
yoshi

May I change the status?