Wrong additional search results for multi-attachment nodes
| Project: | Search attachments |
| Version: | 5.x-3.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
The Search Attachments module is a very valuable additional function for my Drupal website. Without wanting to "advertise", here is the link: http://www.iteraplan.com
However, I found a problem that occurs if there are multiple attachments assigned to a single node, and some of these are of a type that shouldn't be indexed (e.g., gif files). When I use the search attachments function, additional (wrong) results entries may occur pointing to non-text attachments of such a node.
I am using the following configuration:
Drupal 5.6
Search attachments 5.x-3
No additional driver, only standard helpers (for .txt and .pdf).
I found a solution and so, luckily, I can propose a correction. The search index turned out to be incorrect, as a database check revealed. The problem results from a bug in function search_attachments_nodeapi in search_attachments.module. There is a loop iterating over all the attachments of a node, and within this loop there is an if statement commented "Look for the extension in the list of helpers". The if statement works fine, but however the call to the "search_index" function is outside the scope controlled by the if statement and thus executed also if an attachment's extension does not match the helper list. Thus an outdated content of the $attachment_text variable is entered to the search index resulting in the problem described above.
So I recommend to move the call to "search_index" inside the scope controlled by the named if statement. I did this and it seems to fix the problem: after removing the unwanted entries from the search_index and search_dataset database tables, the additional search results don't appear any longer, even if I change the contents of the node in question and force re-indexing by running cron manually.
I'm rather new to Drupal and still not used to creating a patch, but however I hope my description is precise enough so that it can by employed by anyone interested.

#1
The upcoming version of search_attachments (5.x-4) drops the use of _nodeapi entirely, so this particular problem won't occur in that version. Thank you for pointing out the logic error, however -- I'll make sure that I check for an analogous problem in the new version. I will test the use case you describe thoroughly. It looks like I won't have 5.x-4 ready for public testing until I return from holiday after Feb. 19th, but it is very close at this point.
I'm pleased to hear that you are finding the module a useful addition to your site. Thanks again for helping make it a better module.
#2
Fixed in version 5.x-4, currently in beta.
#3
Automatically closed -- issue fixed for two weeks with no activity.