Merge search_block module's features

Hi Andrew,
I used your module originally, but had problems with it - if I remember correctly during cron runs it removes items from the search index (??), my experience was that if other tasks were performed during cron that timed out the script then search_block might not have a chance to run, and content was not excluded from search.

Search Restrict module modifies the search SQL before it's executed, so no danger of time outs, and it also means that content can be indexed and available for search by users with permission to search for that content type.

Restricted Search module has the advantage of being able to exclude specific nodes, something that could be added to Search Restrict I think.

I'd be happy to collaborate with you on Search Restrict module if you think the approach has advantages, if not we can do a comparison and cross link from each of the projects so users get an understanding of what the differences are.

Hi guys :)

I also use(d) search_block for many sites, but I have to admit that we needed to completely rewrite the module to make it work properly. That said, quickly looking at search_block also reveals a few obvious causes for bugs (which may be filed as separate issues already, dunno).

I would like to propose to merge Restricted Search (search_block) into Search Restrict (search_restrict), and I would happily join this effort.

Both modules do more or less the same, but they slightly differ:

- search_restrict filters search results dynamically, based on user permissions.

- search_block removes nodes entirely from search index.

However, that's a technical detail. Feature and UX-wise, the high-level merge would simply result in more (global) options for each content-type: Index as usual (core search) or don't index at all (ex. search_block) or only display to certain user roles (search_restrict).

For why merging in this way: "search_block" sounds like a module that provides a block to search.

All of that being said, development on search_restrict seems to be somewhat stalled - I'd also be open to take over this project to move forward.

Thoughts?

Does search_block offer any additional functionality over Search Restrict?

My opinion is that search_block takes a fundamentally wrong approach by trying to remove nodes from the search index. In cases where cron does the search indexing but then times out, nodes don't get excluded, and remain available to view as search results. I got badly hit by that problem on a high profile site, search_block didn't prevent sensitive information being shown in search results, and I had to scramble to write this module to fix that.

My advice is to scrap search_block completely - it doesn't scale well and is not a flexible solution.

That's unfortunate, but ok. I think I explained the differences in detail.

well, now I have to find out what to do with the rewritten search_block module I have here (which, to my knowledge, scales reliably)...

Sun, how did you get round the issue of cron timing out and search_block not having a chance to remove nodes from the index?

I think the only feature search_block has that Search Restrict doesn't is restricting individual nodes, but that's something that could be added in fairly easily by adding a subquery to the query rewrite, same for exclude by taxonomy.

I'd be interested in seeing the differences in sun's module. As released, search_block is supposed to handle cron timeouts gracefully, and nodes should eventually be unindexed, but if you have a really large delay in cron runs I could see it never catching up. Truthfully, I didn't really write it for big scaling, as most sites I've dealt with that have a lot of content aren't using search.module anyways.

I'm about to set up a new site (D6) which needs images excluded from searches, so I'll have a good chance to explore this module and we can go from there.