I want to add a custom sort field in the block. The field I want to sort by is a CCK field that is present in every type that gets indexed by Solr, however is not displayed as a facet (it's a float) and does not get indexed separately. I'm thinking the best way to go about this is to implement apachesolr_cck_field_mappings hook to first have it indexed separately and then
apachesolr_sort_links hook alter to add the sort.

Is it a good approach? I've noticed there is a patch(for D5) to allow individual CCK fields to be indexed separately(http://drupal.org/node/271753) but not yet ported to D6? Any other way of doing it?

Comments

pwolanin’s picture

The current D6 code allows you to manipulate the query object to add more sorts - though I haven't actually played with it and seems likely that we'll need further changes. Might be easiest to do by extending the query class, though peraps it will work at runtime too.

There is also an alter hook thanks to Mosh that could be used to add or remove sort links.

francewhoa’s picture

@all: If you're not a coder but a site administrator you might be interested in the following feature request http://drupal.org/node/590706

claudiu.cristea’s picture

Title: custom sort link in <Sort by> block » Add a custom sorting

@pwolanin

There is also an alter hook thanks to Mosh that could be used to add or remove sort links.

Yes, there is hook_apachesolr_sort_links_alter() but is only half of the road. When performing the search the custom sort key is stripped out in Solr_Base_Query->parse_sortstring() because your custom sort is not contained in Solr_Base_Query->available_sorts array.

New configurations have to be implemented. I imagine something like "Enabled filters" but for sorting. Then, at runtime, the custom "enabled sort keys" must be added to Solr_Base_Query->available_sorts.

claudiu.cristea’s picture

Title: Add a custom sorting » Custom sortings
Version: 6.x-1.0-beta6 » 5.x-2.x-dev
Component: Documentation » Code
Assigned: Unassigned » claudiu.cristea
Category: support » feature
Priority: Normal » Critical

I need too this feature, that's why I changed the version to 5.x-2.x-dev. After the feature will be implemented in 5.x-2.x, we will do a simple port to 6.x-1.x-dev & 6.x-2.x-dev.

Before patching I want to propose a battle-plan for this issue and I need a quick input from the community and special from the module developers/maintainers:

  1. Custom sorting fields UI: As for Enabled filters we need a UI to enable custom sortings. I propose to use a unified page to do that. Proposal:
    • Enabled filters page/tab will became Filters and Sorts. This page will be the UI for existing Enabled filters and for new Enabled sorts. While filters are checkboxes, sortings will be selects with values: "no sorting", "ascending/descending", "only ascending", "only descending". The page will be designed a table with three columns: "Enabled filters", "Enabled sorts", "Fields".
    • Terms, fields infos, labels, titles, callback names, comments, documentation will be adapted.
    • Custom sortings will be also stored in Drupal variable as for filters.
  2. Including in the Solr query: The custom sorts will have to be included in the Solr query initialization. We will do that in Solr_Base_Query object's constructor or in the Solr_Base_Query protected default_sorts().
  3. Outputting in Sort block: We will display user customized sort links in the sorting block.

Tell me if this plan is something that I can follow or please add your comments...

francewhoa’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev

@claudiu: Thanks for your comment. All contributions are welcome for this new feature.

Changing 'Version' because usually new features are back port not port. In other words this new feature would probably be first for the 6.x-2.x-dev then back port to 5.x. The difference between 6.x-1.x-dev and 6.x-2.x-dev branches is that 6.x-2.x-dev is mostly for adding new features "New features, refined architecture, better API, and more." http://drupal.org/node/518826.

Plus according to the module project page there is only 80 sites using the 5.x version compare to 3,600 sites for the 6.x version. http://drupal.org/project/usage/apachesolr On top of that when Drupal 7.x is release Drupal 5.x core will be supported less longer, and contains less features and enhancements than Drupal 6.

All of the above is decided by the module maintainers of course.

I'm not a developer but would be happy to contribute testing for this new feature. Any volunteers for a patch?

claudiu.cristea’s picture

Version: 6.x-2.x-dev » 5.x-2.x-dev

@Onopoc,

I will not create a patch against 6.x-2.x-dev (or 6.x-1.x-dev) because I'm using 5.x-2.x-dev. In this way I can test the patch in a live environment. After that I'll be happy to port the patch to DRUPAL-6--1 & DRUPAL-6--2.

It will be better if you can give me some feedback on my proposal instead of useless version switching...

francewhoa’s picture

@claudiu:

In this way I can test the patch in a live environment. After that I'll be happy to port the patch to DRUPAL-6--1 & DRUPAL-6--2.

That's great news. Thanks for clarifying. I would be happy to contribute testing on both 5.x then 6.x branch.

It will be better if you can give me some feedback on my proposal...

You can find my feedback in comment #5. As well as links for the rational and numbers behind it. Like I said I'm not a developer. So in other words I'm able to contribute feedback on some points but not on the developer (coder) points. I leave that to other developers.

pwolanin’s picture

I think this is probably duplicate to this issue which has a patch: #597174: Make it easy to add custom sorts

claudiu.cristea’s picture

@pwolanin... Yes it is a duplicate in terms of goal... The difference is that this ticket propose a UI solution. Drupal admins will be able to select sorts based on UI while #597174: Make it easy to add custom sorts is using a hook to add additional sorts...

I think that both should be implemented in Apache Solr module...

claudiu.cristea’s picture

Status: Active » Closed (won't fix)

This feature in not a priority right now.