Add scoring factor controls to advanced search form

Well, we would need an admin setting

Hmm, I think we should consider encoding them in the URL. This could be done using a score:1,2,3,4 syntax or something. This is how the other search stuff works at the moment. The only problem there is again the conflict between the form controls and the text box. It's a hairy problem.

The tricky part is that for some things (like phrases or or), there is no reverse mapping from an arbitrary query string back to the controls. So, we have to clear these boxes after inserting the result in to the keyword box.

However, for terms and type restrictions, we could really remove these from the text box and fill out the form options correctly. The same could be done for the search results. This would keep the URLs clean and readable, while keeping the form as usable as possible.

Of course this could be considered a bit outside of the scope of this patch, but as we pile on more search features, this rapidly becomes an issue. Any takers?

I'm also thinking it should be styled better/more compact. Maybe even some jQuery slider magic like MSN search had at one point.

Personally, I'm not convinced that we want to add this functionality. Do we really have to expose this level of control (and internal details) to the user? Shouldn't the search "just work"?

In general, I'm +1 for advanced filters (like we have now) but -1 for controls that manipulate the order of the search results.

What the article tells me is that we might want to change the default scores.

Dries: yes, it is a bit of cruft, but on the other hand, this isn't that much of a change. It's just some numbers internally that change. With the right UI (e.g. sliders) and the right search data set, this can be a very useful feature.

Hacking it in via a module is kind of hard, because the node search is not extensible that way. These weights appear in the SQL query that calculates scoring... it woud be piling abstraction layer upon layer upon layer already, and too much would slow down performance or result in insanely complicated UIs. If we had a more robust query builder in core, this would be different, but that's no reason to work on this today.

Improving the default set of rankings is a different issue and in fact applies to all scoring factors in search module. The weights given HTML tags are purely arbitrary for example and based only on intuition and minimal testing.

For me, this can go in, provided it is improved as suggested.

I definitely want to support the idea of this issue. Beeing able to control the output of search results in my opinion is really important for users. Maybe not for all of them, but when I visit a website that doesn't offer this option, I like it less.

Moving to D7.

We could try the following:

Sort search results (descending to ascending, or vice-versa) by clicking on the currently selected column header. as follows:

Relevance, Activity, Rank, Date published, Latest Comments, # of Comments

No surprises here, but this fails against Drupal HEAD:

$ patch -p0 < advanced-search.patch
patching file modules/node/node.module
Hunk #1 succeeded at 1219 with fuzz 2 (offset 352 lines).
Hunk #2 FAILED at 1240.
Hunk #3 succeeded at 1875 (offset -663 lines).
Hunk #4 succeeded at 1932 with fuzz 2 (offset -663 lines).
1 out of 4 hunks FAILED -- saving rejects to file modules/node/node.module.rej

LIVE FROM THE MINNESOTA SEARCH SPRINT, I agree that some minimal UI for sorting within a results set would be helpful. This needs to be re-rolled, but should wait until #145242 is committed.

#145242: refactor search node_rank with hook_node_rank scoring factors has been fixed.

I patched—ahem—'hacked'—Drupal core to rank results by Date. This is something that, imo, should be a link that a user has exposed on the default search page... along with other options for sorting.

You could just have a block that an admin could enable for the search page with the following:

Sort search results by:
-keyword
-date
-number of comments
-etc.

Heck, you could even have the options be in a checklist, so the admin can choose which sorting rules are allowed. This would improve Drupal's search results a ton.

Another +1 if you can let the administrator choose the default sort by date...

Another +1 if you can let the administrator choose the default sort by date...

Actually that already is implemented: Just go to admin/settings/search and you can change the priority where it says:

The following numbers control which properties the content search should favor when ordering the results. Higher numbers mean more influence, zero means the property is ignored. Changing these numbers does not require the search index to be rebuilt. Changes take effect immediately.

This discussion here is about exposing these settings to the user.

Yan - true, but it would be nice to also have the ability to set the default sort by date (maybe adding that as one of the sortable options with a weight in the admin interface).

Yan - true, but it would be nice to also have the ability to set the default sort by date (maybe adding that as one of the sortable options with a weight in the admin interface).

geerlingguy, don't you see the three options "Keyword relevance", "Recently posted", and "Number of comments" there? Just set "Recently posted" to 10 and the other two to 0 and the search results should appear sorted by date (descending). The settings are very limited but at least basic options are available.

@ yan - I had that set, but it still didn't sort by date first, then other rankings... I had to modify node.module to add a sort to the search, and even then, it's not easily configured (except by me). If, during the search, there was a "Sort by Date" link somewhere near the top, that would be quite nice.

I'm moving this to the search queue, since it's a search feature (and yes I realize it's currently in the node module, and node-search-specific, but I am hoping in Drupal 8 to decouple node.module's search stuff out of node.module and search.module)... we'll see. Anyway, Iam trying to keep all search feature requests together. Hope that is OK.

Since 8.0.x-beta1 has been released, our policy at this point is No feature requests until 8.1.x. See #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Sorry, it's just too late for 8.0.x at this point, so even if we had a viable patch, the core committers would not commit it.