Merge in features from Restricted Search (search_block)

@canen: Sorry, must have typo'ed the link - it is the "search_block" project: http://drupal.org/project/search_block. I renamed it as it was confusing before, but it's virtually impossible to change a module's short name.

The reason Restricted Search uses cron the way it does is to prevent any issues with module weights. What happens if search_config_update_index() get's called before node_update_index() (or some other contrib module)? I know the module could just set it's weight to be higher, but that's not really a great solution either.

I looked at the module and it has the same problem as search config. There doesn't seem to be an easy way to prevent nodes from being indexed. Jeff Eaton wrote an article on how something similar can be done using hook_db_rewrite_sql. It might be an option worth looking into.

I am new to the search_config module and see this issue is now marked as fixed with a link to the search_restrict module.

This sounds good too me, but I am still a little unclear on the direction of this, the search_config module, having also read the readme file.

I think the way that search_config allows configuration of the advanced search feature is very useful.

As for affecting search results, I do not know if that is necessary or even desirable to include as it may impact adversely on other access control modules such as og or modules that do some access control such as support, etc. There are already several warnings that using combinations of access control modules may not work and may conflict so it may be advantageous to leave that out of this module.

Simply configuring the advanced search in a theme independent way is great for this contrib module. I think it would be great if the core search configuration included this.

I am happy to see the search_restrict is a separate module. I have not explored that module as I do not have an immediate need.

I hope these personal thoughts are useful for discussion.

Thanks,

Izzy

I'll consider this.

Cross-posting to #934754: Capability to apply a "nosearch" tag to a node which prevents it from showing up in a search result

After some more thoughts on this and after experiencing #1210072: PDOException: SQLSTATE[42000]: Syntax error or access violation:, this will have to be fairly limited in functionality. We will not be able to do anything like where nid not in (subquery) or where nid not in (nid list), otherwise we risk hitting the core bug found in the other issue. However, queries like this where nid != x AND nid != y AND nid != z should be OK.

So I'm going to purpose having an additional textarea that you can add node ids on the search configuration page and to use this to define the nodes that you want to exclude. This will hopefully exclude extensive usage of the feature that could potentially slow the searches down too much.

ETA in a month or two, to provide time for feedback

Wow. This was extremely easy to implement. I've pushed it into dev.

There is one new table and this is set via the publishing fieldset (if user has permission to access this) or the checkbox is appended onto the form.

The query access required one join and one condition. There is extremely little overhead in this, so performance is not a significant issue.

There is one permission to allow users to access this checkbox to exclude the node, and there is one permission to grant overrides to bypass this restriction. Remember that admin user uid == 1 never has any search restrictions enforced.

Nice! Will check it out soon!!!