Replace taxonomy/term/XXX node listings with Apache Solr search results
| Project: | Apache Solr Search Integration |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | janusman |
| Status: | closed |
This would make clicking on taxonomy term links from nodes, Tagadelic and other modules deposit the user inside a full-fledged Apache Solr session, where the only enabled filter(s) would be the term id(s).
How it would work for a visiting user:
- You have a "Hello world" node, tagged "Cool".
- Normally clicking on "Cool" redirects to taxonomy/term/123 and shows a list of node teasers, and has an RSS feed.
- When proposed module is enabled, taxonomy/term/123 shows the exact same result listing for search/apachesolr_search/?filters=tid:123
To test
This patch requires #358166: Search for just facet(s) to be solved first, until then you can apply the patch from http://drupal.org/node/358166#comment-1615422 to test.
You have to enable a new module "Apache Solr Taxonomy Integration" in admin/build/modules, and make sure you have enabled some filters under admin/settings/apachesolr/enabled-filters; the proposed module only "hijacks" term node listings for enabled filters.
Caveats
The module falls back to the regular display when:
- more than one term is requested (e.g. taxonomy/term/123+456)
- a depth != 0 is requested (e.g. taxonomy/term/123/1)
- an RSS feed is requested (e.g. taxonomy/term/123/0/feed)
It needs to be seen whether these are blocking issues or not. For instance, RSS feeds would look exactly independently of which module provides them, so it's probably ok to fallback to the core functionality. Depth handling might be tricky to do in Apache Solr with the current indexing code. Multiple terms per request are easier to do, except when the terms come from different vocabularies and one or more of them is not an enabled filter.
| Attachment | Size |
|---|---|
| apachesolr_replace_taxonomy.patch | 2.7 KB |
#1
Forgot to mark as needs review.
#2
It's the node listings that are changed, not the links. Changing issue title.
#3
Patch did not correctly display when falling back to taxonomy_term_page(). Fixed in this one.
#4
Okay, here's another go, turns on retain_filters by default. It's ugly as hell though, manipulating $_GET... I'm really against it. It seems to me that the function actually doing the view / search in apachesolr_search should not contain code directly accessing globals.
But for now, this is totally fine, and does the job.
#5
this looks too ugly to use...
#6
Okay, this isn't a whole lot better... The problem is the retain-filters bit.
The only other option is to use some new global var I think, or embed some logic in the apachesolr_search_form_alter to know that we are on a taxonomy page...
I honestly don't see how we can avoid setting $_GET in this case...
Anyway, attached.
#7
Why not assume that we'll be able to do this with Views 3? The whole point of Views 3 integration is that all displays and listings can be done with the Solr index. Adding more hardcoded taxonomy listings in core's footsteps is undesirable, imo.
#8
this shoudl set the correct include file on the menu entry, rather than calling include
+include_once(drupal_get_path('module', 'apachesolr') .'/apachesolr.taxonomy.inc');
+
/**
* @file
* Provides a content search implementation for node content for use with the
@@ -80,6 +82,12 @@
$menu['search']['page arguments'] = array('apachesolr_search');
}
}
+ if (variable_get('apachesolr_serve_taxonomy_links', 0)) {
+ if (isset($menu['taxonomy/term/%'])) {
+ $menu['taxonomy/term/%']['page callback'] = 'apachesolr_override_taxonomy_term_page';
+ unset($menu['taxonomy/term/%']['file']);
+ }
+ }
}
#9
@robertDouglass: IMO this issue is about *replacing* taxonomy term listing URLs with a fully-fledged apachesolr search when possible. Core taxonomy term listings are "browse" mechanisms, and faceted search is (IMO) making browse and search one seamless experience.
I am yet unfamiliar with Views 3. Are you saying that Views 3 can override core taxonomy term listings? Could it also dump users into a fully-fledged Apache Solr search session (where they can further refine by, say, another term or a keyword search?)
#10
In Views2 and onward you can override ANY page callback. For instance, you can override node/%.
If you look at views.module, you will see no hook_menu(). What you see is hook_menu_alter().
My feeling on this issue is that this is feature creep. -1
That said, #8 is on target, whenever you write
<?phpinclude_once
?>
#11
This is, in a sense, a way to demonstrate the filter-only search. Quite possilby something that can be removed later if appropriate.
#12
Things never get removed from code, do they?
As I said, this can already be done with Views and the apachesolr_views module (possibly pending some handlers that are yet to be ported). The future of building searches lies in the apachesolr_views module. I see this as feature creep and would like to suggest that we reconsider putting it in.
@janusman - yes, you can make a view that shows taxonomy terms, similar to the default views that do the same in Views 2. Then you can expose a search box filter. Then you turn on the facet blocks. Done.
#13
@robert - well we moved attachments out, rolled in mlt, etc, so I think we will change/remove it if there a better option.
That being said - the patch demonstrates at least one serious API flaw that we should figure out
#14
This patch tries to fill in a niche that was previously fulfilled in the earlier (earliest?) version of apachesolr.module, when the search could be something like "tid:XXXX". You could plug in taxonomy_redirect.module and make clicks on the term links in nodes start a Solr session, from where the user can continue browsing/searching from there.
If I understand what @robert and @Scott are saying, we can have Views to achieve this. IMO it *feels* like a bit of overkill to have to: install Views, install ApacheSolr Views, then configure it to meet this need.
The patch IMO is simple & quick, and does that one thing--although I admit, it is a bit hackish? I was kind of hoping for some of you to suggest how to un-hack it =) I guess one way is to shift the task over to Views and to the site admin figuring out how to configure it.
What next? Might you consider a view definition inside the module (or a new module in contrib/) to do this?
#15
We can ship a default view that does this - almost zero configuration needed. Just turn it on.
#16
I think the impetus for this came from Dries who was looking for a lightweight way to add functionality to his site for "section browsing". I agree that views would be more powerful (although I'm a little dubious about trying to use Solr as your relational database and trying to maintain a views plugin that performs).
The idea here is that for anyone who doesn't know that someone cannot be distracted, trying to figure out the views UI and make sense of the abstractions is not trivial. So Solr could provide a 90% use case scenario with these 100 lines of code and a nice UI as well.
If someone wants to go whole hog, they always can.
Perhaps we should put this back to being a contrib module instead of part of the core, but we figured with the module page looking bloated already, and since it is so few lines of code, throwing it in the core was simpler.
#17
I know you'll go install it eventually and give it a try =) All Views does in this case is let the user mix and match the fields, filters, sorts that are exposed by Solr, define a path, choose whether it is a page, block, feed, etc, and control some display elements. No database involved. It is a query builder for the index. And since it can hijack paths and customize displays, plus expose any filters as form elements (eg the search box), it makes the code in this patch 100% redundant.
The module page looking bloated is not a concern for me. We're going to solve that problem down the road with a more "feature" oriented approach to installation. A much bigger problem is modules that do more than they should and can't be divided. Such as the node module providing search to core, and such as the apachesolr_search module hijacking core's taxonomy (even if it can be disabled).
If we ship with a default view then people don't need to do anything with the Views UI except enable the view, which is as much as we're expecting them to do here, so I don't buy that part of your argument.
Making this a separate "contrib" module would reduce my objection to it enough that I will shut up.
#18
Here's a thought - we essentially already have a global - the current query object.
I think we always run the query before we build the form.
#19
I think this is pointless, since this function will only ever get called once per page load:
+ static $vids_to_override;+ if (!isset($vids_to_override)) {
+ $vids_to_override = apachesolr_get_enabled_facets('apachesolr_search');
+ }
Also, the submit for the settings form needs to do a menu rebuild if the setting changes - see what I put in for the case of making Apache Solr the default. Possibly the same function can check this condition too.
#20
subscribed
#21
I have a multisite installation and a global tree taxonomy shared over all the sites. So , i need that the users when browsing in a site by taxonomy terms send a search to ApacheSolr filtering by this term. If i do in this form the user ever has the feeling that always are in the same site.
I download the latest development snapshot that has search just for facets resolved, but if i see this thread i don't know what patch or view i can active for having taxonomy filter...
Thanks in advanced
Xarbot
#22
@xarbot: You could try the patch in http://drupal.org/node/472600#comment-1719976
You'll need to flush caches after installing that patch (best to have the Devel module installed if you plan to do it frequently).
#23
This patch don't works for me. Don't do anything. When i click a term taxonomy then it shows the default browse taxonomy pages. I put an echo apachesolr_taxonomy_override_taxonomy_term_page and it don't show the echo.
I don't know if it is important but i though that when i don't enter a word in the searcher then it show the facets for do the faceted search with the latest beta but it doesn't it....
but i can do a filter search by term in the form search/apachesolr_search/?filters=tid%3A1435377 without key to search
i think that the function don't override taxonomy term page but i don't know why. I also disable the view that have taxonomy drupal module
Thanks in advanced
Xarbot
#24
@xarbot
You have to enable the module "Apache Solr Taxonomy Integration".
#25
if i applied the patch here http://drupal.org/node/472600#comment-1719976 as janusman says me i don't have a new module i have an option in advanced settings of apachesolr ...
Thanks
Xarbot
#26
Only if serves for anything. It's posible that i18ntaxonomy.module execute it's own hook and then don't execute the hook from apachesolr taxonomy?
how can i try if it is this the problem without disabling i18ntaxonomy module?
Thanks
xarbot
#27
Ok, i do this function
/*** Implementation of hook_link_alter().
*/
function apachesolr_search_link_alter(&$links, $node) {
foreach ($links as $module => $link) {
if (strstr($module, 'taxonomy_term')) {
// Link back to the forum and not the taxonomy term page
$links[$module]['href'] = str_replace('taxonomy/term/', 'search/apachesolr_search/?filters=tid:', $link['href']);
}
}
}
and i put this in apachesolr_search.module
now the link terms (yes all, but i need all :XD) rewrites to the new url but i have the problem that the ?,= and : simbols are replaced by %3F, %3D, %3A in the url, so the apachesolr don't understand that there is a filter in the search and thinks the the term to search is another thing.
Any idea to solve this?? Or all the things that i sayd in this thread :XD
Thanks in advanced
Xarbot
#28
Ok, i found the solution to this thread.
It's more easy as we think. I found this module
Taxonomy redirect
http://drupal.org/project/taxonomy_redirect
With this module it's posible to redirect some taxonomies and some terms of this taxonomies if you desire.
If you activate this module when you enter the urls to redirect, do it in this format (i have a headache for this cause...)
http://search/apachesolr_search/?filters=tid:!tid
It's important the http at the first
Thanks a lot to all :XD
Xarbot
#29
Here's a major re-write passing info via the query object.
#30
doesn't work quite yet.
#31
Don't like retain_filters as part of the Query class...
worse than globals hack IMO.
#32
ok, this one is basically working - goes back to setting GET for the retain-filters param
#33
This hunk belongs in a different patch?
<?php/**
* @file
@@ -82,10 +82,9 @@ function apachesolr_settings() {
);
$form['advanced']['apachesolr_read_only'] = array(
'#type' => 'radios',
- '#title' => t('Index write access'),
+ '#title' => t('Read-only index'),
'#default_value' => variable_get('apachesolr_read_only', 0),
- '#options' => array(0 => t('Read and write (normal)'), 1 => t('Read only')),
- '#description' => t('<em>Read only</em> stops this site from sending updates to your search index. Useful for development sites.'),
+ '#options' => array(0 => t('Both update and search (normal)'), 1 => t('Only search (read-only)')),
);
return system_settings_form($form);
}
?>
#34
Re: @pwolanin's # 32:
I was thinking the patch was just about redirecting to an Apache Solr search (exactly like searching for just a facet), not actually creating a something that looks different (by replacing the title, forcing the order by creation date, etc). If @xarbot's #28 works, I could go back to solving that way (will look into it).
I'm not sure whether I like this or not... hmm, taxonomy term pages are good ways to see what's new in a certain setting (like blogs) but doesn't always apply (in, say, a library catalog I might not care about the newness of nodes, rather I'd present items sorted by stickyness, by item type, number of comments or other factors... which I can set in the ApacheSolr bias settings).
So, IMO if we set these pages to default-sort by creation date we might loose a lot of the good stuff the admin can set in the content bias.
Any thoughts?
#35
@janusman i install opensearch to syndicate the searches. Well, i need to do a pair of changes for working with the latest dev module, so the users can be syndicate the searches, and of course a syndicate a search that retrieves the new content for example for a taxonomy term, order by...
I don't know if i explain very well... :)
Bye
Xarbot
#36
@robert - thought that patch was already in CVs, let me cross check.
@janusman - we could certainly allow admin-selected options for sorting, but seemed sensible to have at least the default mimic what's getting replaced.
#37
Here's a clean patch.
@janusman - Jacob suggested doing this page override, since many sites use taxonomy pages like site "sections" and hence would still want to be able to apply custom styling or blocks to them vs. the plain search page.
#38
Here's a patch to add a variable for setting the sort. I started adding a setting form as below, but there are problems since "relevancy" doesn't work right, so omitting UI for now.
$query = apachesolr_drupal_query();if (!empty($query)) {
$sorts = $query->get_available_sorts();
$options = array();
foreach ($sorts as $key => $value) {
$options[$key .' '. $value['default']] = $value['name'];
}
$form['advanced']['apachesolr_search_taxonomy_sort'] = array(
'#type' => 'radios',
'#title' => t('Default sort for taxonomy link pages'),
'#default_value' => variable_get('apachesolr_search_taxonomy_sort', 'created desc'),
'#description' => t('Drupal core sorts taxonomy pages by Date. Sorting by Relevancy will use the bias options you selected for search results.'),
'#options' => $options,
);
}
#39
missed rolling back a $retain_filters param
#40
Well, the redirect method can be used in addition with no real conflict, and this patch has some other minor clean-up. I think I'm going to proceed, since almost all the new code is in the .inc file which can be readily removed later.
#41
oops last patch missed the new file. Here's the actual patch committed.
#42
Automatically closed -- issue fixed for 2 weeks with no activity.