What is the difference between search attachments and swish-e?

My actual problem is that I want to search content and attachments in one search with the results in one list. Perhaps swish-e will do that (I've a problem installing it at the moment)

there's a module called search all, but that merely does all searches and puts the result blocks one after the other, including their respective pagers. Not elegant.

Comments

markj’s picture

markj commented

The main difference is that the swish-e module requires that you install both swish-e and helper applications, while search-attachments doesn't require the installation of swish-e.

Getting search results back in one tab, as opposed to separate tabs for content and files, is the feature that users of search_attachments request most often. I'm a bit overdue at releasing the latest version of search_attachements (some new headers already sent errors have somehow cropped up) and this feature is high on the list of new features. If the swish-e module, or any other contributed search module you know of, produces a single tab of results, I'd be happy to take a look at how they do it.

Thanks for your vote,

Mark

matslats’s picture

matslats commented
Status: Active » Postponed

Thanks that was a helpful comment.

Swish-e works very similarly to search_attachments. I have an idea its search results are better prioritised, and it uses a wider range of helper-applications to search a wider range of file types; like search_attachments it adds another search tab called 'files', which returns links to the attachments directly, rather than to the nodes.

It seems to me that while Swish-e generates its own search swish_fulltext search index table, search attachments uses the same search_dataset table as the core. Why then does the search attachments have a different search scope (it's own tab on the search page), and search function.

Matthew

markj’s picture

markj commented

Thanks, that important difference didn't occur to me but that's right, search_atttachments uses the core search_dataset and search_index tables, while swish-e uses an external indexer. Both modules use helper apps to extract text from files.

Any module that calls hook_search() and do_search(), both of which search_attachments does because it uses the core index tables, gets its results placed in a separate tab, I assume because hook_search and do_search() are called separately for each module that implements them. hook_search() even has a parameter for the name of the tab. This is just the way the search API was designed, as confirmed by VanDyke and Westgate in Pro Drupal Development: "When the search API invokes hook_search('name'), it’s looking for the name the menu tab
should display on the generic search page" (201).

In order to make the results from the core search and search_attachments appear in one tab, we have a few options: 1) merge the results of both types of search, 2) override the core search so it also invokes do_search() on the file entries in the search_index table (maybe using hook_form_alter), or 3) programmatically create minimal nodes, one per file, that contain the extracted text of each file and let the core invocation of hook_search() search them. The second and third strategies seem to be the most promising.

If you have any other suggestions or questions, let me know.

markj’s picture

markj commented

Hi again Matthew. You said swish-e "uses a wider range of helper-applications to search a wider range of file types". I don't agree -- search_attachments lets you add whatever helper apps you want, and as many as you want. Unless swish-e can use helpers that output extracted text to a file; search_attachments can only use helpers that output to STDOUT.

bachomp’s picture

bachomp commented

To have all your results in the one page use http://drupal.org/project/search_all

This works with the core search aswell as swish and search_attachments.