swish-e

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

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

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.

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.