Search

I've proposed and extended search session for Szeged. The timing of the session is important as a way to keep momentum going from the Minnesota Search Sprint and focus on what we can achieve in Drupal 7. It will also provide a chance for people to talk about alternatives to Drupal core, what core can do to support the growing number of 3rd-party solutions, and what core can learn from things like ApacheSolr.

http://szeged2008.drupalcon.org/sessions/drupal-search-where-are-we-wher...

Please vote if you like the session.

We have a multilingual website providing German, English, French and Italian content on a Drupal 5 instance.
We used to use Drupal's internal search and had many issues about terms that were not found. I found, that the problems might be solved using stemming.
So i installed stemmer for all the languages: porterstemmer, de_stemmer, ...

Just wanted to let everyone know that I submitted a patch that allows you to rank nodes with more inbound links than other nodes higher in search results using the new ranking hook.

Take a look, give it a try, and please give feedback.

http://drupal.org/node/257216

Trellon recently released the Xapian search module for Drupal. This replaces Drupal's standard search feature seamlessly (except for a core patch) with an interface to the Xapian search engine. There's a post about it over on Trellon.com.

I posted some internal benchmarks from the Xapian module we are working on in the Trellon.com blog. This post describes the performance gains using Xapian can have and does some benchmarking on a really, really slow server.

Would love it if someone could verify those results. We are about to take the sample size of the data up to about 1mil nodes and repeat.

M

Totally disorderly and mostly here for our own reference =)

• Refactor node/user search implementations into own modules.
• Control over the search interface.
• Moving stuff between adv. search form and main search form and/or block.
• Full search building interfaces. Create search environments; Each env. has own settings. eg. What content types are in search? What does the interface look like? Analog to building a view w/ fastsearch.

Drupal’s ambitious search module provides a framework for building searches of all kinds. By isolating the tasks involved in searching, and allowing the actual search implementations to be handled by other modules, the search framework sets the stage for all sorts of creative search applications. This article, which applies to Drupal 6, explores the structure of the search framework by following the steps needed to execute a search.

Full article: http://acquia.com/blog/drupals-search-framework-the-execution-a-search

Project Information:

Current Status: Working to complete tasks outlined below and get them ready for acceptance to D7 core. The Drupal project page can be found here: http://drupal.org/project/search_score_improvements. The project page will contain a downloadable package of all code contributed from this project.

Description:

Continuing the great and growing tradition of bringing people together in small groups to attack focused problems, a search related code sprint will take place from May 9-11 on the campus of the University of Minnesota. Goals of the sprint will be to enhance the search framework, identify improvements to the core search implementations, and consolidate efforts towards making Drupal 7 a fantastic release for search. Sponsors for the search sprint include University of Minnesota Libraries, Acquia, McDean, Inc. / OpenBand, Workhabit, CivicActions, The University of Michigan, Laboratoire NT2, and BoldSource. Attendees include Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Michael Hess, Djun Kim, David Lesieur, and Blake Luchessi.

http://drupal.org/node/247482

This patch adds spelling suggestions to the page that is returned if no search results are found.

This is done by utilizing the Levenshtein algorithm for calculating the nearness of words.

This is a list of issues in the D7 issue queue that pertain to search. They've been vetted and confirmed to be real issues. They cover the entire spectrum, from advanced feature requests to bugs to theming issues. This is a great place to start your quest to make search in D7 a better thing. The table should be re-organized a bit. We should sort it into bugs and features, and make some priority judgements. Remove rows as issues close.

Hi folks,

Please see Google Appliance Module for Drupal .

This module currently supports keymatches, keywords, i18n compat (see the module page for more info).

I will be updating it regularly with new features, as the base class is robust enough to handle an advanced search, sorting, etc. It's currently in beta because I'd like some more feedback on the architecture / integration stories before rolling out more features, but a version of this is in production on a large site.

Background

Hy!
I have a table author with author_id, author_first_name, author_last_name, author_date_of_birth, author_date_of_death, author_website, author_email, author_language_id, author_isDeleted.
I have make a module author, implement the hook_menu and make a table view for my table and a modify form. From the content I have make a new content type called Author. I have implement the hook_search in my module

function author_search($op = 'search', $keys = null)
{
switch ($op)
{
case 'name':
return t('Content');
case 'search':
$find = array();

The following is my first revision of a proposal to create a search API module. I'd love to get some feedback.

Project Details
A Drupal search API would allow for separation between the search interface that end users interact and the back-end indexing and retrieval work that a search engine performs. The advantages to creating a search API are:

I am planning to hand in a proposal on improving the Apache Solr Search Integration module.
The project would include:

• Porting the module to drupal 6 (if necessary)
• Integration in Views 2, enabling the use of Views 2 as a front-end to display the search results
• Writing simpletest unit tests for this module, especially for the new functionality

What's your opinion on that? I have already contacted Robert Douglas to ask for his.

Drupal's search APIs received some good attention at the recent Boston Drupalcon. Following up on discussions there, here is an attempt to draw together ideas on directions for refactoring core search. Please wade in and add your ideas and observations.

Existing core search

Drupal core search is implemented in an integrated way, providing a powerful working solution but little flexibility. Core search integrates several distinct pieces, among them:

• For nodes, a custom SQL-based indexing solution.
• For nodes, an SQL-based search algorithm.

I think the way information is presented and search results are displayed can be optionally enhanced. This somewhat related to the following discussions, however a new idea
1. http://groups.drupal.org/node/9934
2. http://groups.drupal.org/node/9946

A short description of what I would love to see with this module

Following Yelvington I'm crossposting this to the following groups: SOC2008, Knight Foundation, Newspapers on Drupal and Search

One thing that would be really cool, is a module integrating http://www.sphinxsearch.com/ and Drupal. Our experience is that core search doesn't play nice when you have alot of nodes (we have 150.000+). Indexing simply kills the server.

So instead we use Sphinx. It's REALLY fast, both when searching and when indexing. BUT everytime we alter our content-types we have to manually reconfigure the sphinx configuration. This is why I propose this as a module for the SOC08 - a module that integrates Sphinxsearch and Drupal

We've had a good discussion today at Drupalcon, in a BoF session led by Robert Douglass. Here's the plan that emerged to build a killer search for Drupal that will help take us Drupalers further towards world domination. ;)

http://drupal.org/project/finduser

This is a custom search module for users. It provides a search page that can search for users by username, email, or a custom text field. The custom text field can come from any content type, thus this module plays nicely with any user-as-node strategy.

The module does one thing and does it well, and is independent of search module. It has enough customization options to allow you to bend it to your will, as well as a healthy number of themable functions.

On the administer settings page for the Find user module you have the chance to set many configuration options. If you have CCK enabled and have added any text fields to any content types, these fields will show up as options to be searched. This allows you to use a module like nodeprofile or usernode or bio to extend your user profile and make it searchable via the Find user module.

As I am entering the home stretch of the project I have gotten a small amount of feedback from various testers regarding my fuzzy search module but so far have gotten no feedback on how good the algorithm is at returning relevant results. I have just recently reworked my algorithm to tighten up the matching. I'd really appreciate it if I could get a person with a site that has over 400+ nodes or so to test out the module and see how fast it performs and how relevant they believe the results are.

The Fuzzysearch module is now available for testing and feedback. The results being returned during my tests have thus far been quite good and performance has been better than search.module (overall query times and page generation times were faster with fuzzysearch.module, testing based on results displayed by devel.module).

Please try it out if you have a chance and leave me some feedback/post issues on the project page.

http://drupal.org/project/fuzzysearch

You can try out the module and read more information about the release on my blog http://boldsource.com
-Blake

Over the past week and a half or so I have made much progress on my project. The following are main accomplishments:

I'm contemplating how to implement a scoring factor hook into my new fuzzy search engine module. I believe what may work out to be the best way of doing this is allowing modules to tap into this scoring hook at the time of indexing.

Each hook should return a value between 0 and 10 as a score to add to the node being indexed. Then in the administration screen an administrator would be able to set the importance of the score given by that hook. This would allow the administrator of a drupal site to manage the scoring from different contributed modules.

Fuzzy Search Module (search_fuzzy.module)

Part 1 of my project (implementing synonym matching in the search index) is nearly completed, I am waiting for the patches to be accepted into core for drupal 6. In addition to synonym matching I also submitted a patch to index usernames with the nodes as requested in the Search group on drupal.org. The patches can be reviewed here, all comments welcome.

http://drupal.org/node/155262 - Taxonomy synonym search indexing
http://drupal.org/node/155254 - Username search indexing

For part 2 of my project I am to implement a fuzzy search engine in drupal.

This is my first update on groups.drupal.org about my SoC Project regarding enhancing drupal's search engine. I still have 3 more days of finals so I havn't gotten to any of the coding, but after putting forth much research and thought (and some kind help from my mentor Robert Douglass), I've decided on the following 2 parts as goals for my project.

Goals for Summer of Code Search Project:

I've been doing my best to wrap my head around ways to make drupal more fuzzy search capable. The following are some goals of fuzzy search and I guess some comments. I'm not exactly sure how this will help as of now, but I really feel like along with improving the search engine's speed we should look at ways to provide more relevant results.

6.x is moving to mysql 4.1. I think this removes the need for any support for temporary tables, but first, I'd like to confirm that 4.1 supports subselects. We also need to evaluate the pgsql options. Does pgsql support the sub-selects? Does pgsql support something similar to the ALTER IGNORE TABLE construct for adding a unique index to a table that has duplicated?

If you're just joining us, please also read: #143160 (search_index has duplicate entries) and #102088 (views_fastsearch 5.x-dev release notes)

do_search currently takes a bunch of parameters which are supposed to be sql snippets that get used in building the search queries. The only example of these being used is in node_search() where extra tables are joined to make scoring factors for things like comments count and page views, etc. My idea is to explore whether each of these scoring factors could be added in a more organized way, in do_search, by invoking a hook:

hook_scoring_factor($search, $keys)