It appears that these two modules use the same approach to accomplish similar tasks. As far as I can tell, the primary difference is that search config allows administrators to hide content types from search results globally, where search restrict hides content types from search results based on role. Both modules use db_rewrite_sql to accomplish this task in Drupal 6.x and if #663916: D7 port and "Exclude all" feature for Search Restrict is committed, both modules will use almost identical hook_query_alter implementations. Is there any interest in combining efforts?

Comments

antony.lovric’s picture

No one replied? I'm looking at using either module and would like to know if anyone has more experience with both modules.

I guess I'll install both and post back my results.

mellenger’s picture

Which one is better? I have some utility content types like homepage hero's that should never show up in search.

leksat’s picture

http://drupal.org/project/search_config
Maintenance status: Abandoned
Development status: Obsolete

Is it an answer?

robert castelo’s picture

We need a comparison of the two modules in terms of features and code quality.

If Search Config does the same and is better I'm happy to close Search Restrict and put my time towards Search Config instead.

alan d.’s picture

In terms of code readability and simplicity, Search Restrict is better.

In terms of usage, for Drupal 7, this is not significant as there are only 36 sites using Search Config and (unknown) number of sites using my patch [site statistics are not kept unless there are official releases].

In terms of features, it was difficult to compare by simply reading the Search Config code, but it is bigger and appears to do more. This appears to be the case after reading the project page.

alan d.’s picture

kerios83’s picture

Sooo... Did you guys discuss about the future of those two projects ? Whit one will be maintained ? I think that merging those two is a great idea.

alan d.’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

Year. The very slow rate of feedback caused me to take over search_config and push it into the Drupal 7 domain. I totally refactored it to take the work that I had done here and to clean up the internals during the port.

Then strangely, after well over a year of nothing happening about the Drupal 7 port patch in search_restrict issue queue, this suddenly got a D7 release a few weeks latter.

Current differences
The main difference is the interface and that search_config does a heck of a lot more with the search form UI.

In search_config, the node search settings page has all of the UI form settings, including a type filter and grouping options (BTW, this is so cool, it removes the wtf from users seeing raw content type names). None of this functionality is present in search_restrict.

Permissions govern the ability to search content types in search_config. There is a global "search all content types" permission and "individual search xxx type content". AFAIK, search_restrict settings are still in the content type settings. IMHO, the permission based way is far easier to manage.

Current status
A strange bug discovered recently means that the query code in search_config is a fraction ahead of search_restrict, but I supplied the workaround in the search_restrict queue too. I could not replicate this bug in any of my installations, but it was easily mimicked it after getting that users DB dump.

Search config is a fresh start from D7, not upgrade path planned from D6-.

Development
Search restrict has a well defined specification and does what it does well. The only significant issue is the interface being hidden in the content settings.

Search config, well this has a much wider scope. It has the same base functionality as Search restrict. To maintain the existing functionality of the D6- versions, I had to port / create a lot of UI based settings:

  • UI labels
  • Flags to hide the basic search form
  • Merge form options
  • Hide individual components from the advanced search form
  • Provide UI level content type restrictions (other items still can show up, they just can not be selected)
  • ...

I'm considering:

  • Search result limits
  • Local menu tab label overrides (or at least find and document the native method of doing this)
  • Add node level exclude from search options
  • Add new fields to the search form (this one is unlikely)

So users have two options with having both modules in play, one small and lightweight, the other larger and more focused on the UI.

I would have considered using search_restrict more often in production, until I found a sweet combination of settings in search_config that I really really like.

* This moves the basic keyword search into the advanced search form.
* It takes the previously searched values and merges as much as it can into the advanced search form elements (i.e: rather than having things like "type:x,y,z term OR t2 t3", these are used to prepopulate the advanced search form fields instead)
* The fieldset is toggled according to the search results
* The any field is removed as having the AND and OR searches are a bit confusing for end users
* And adding grouping settings. For example, even though I have 10+ content types, this is the type options that I'm using in a current project
[ ] Search companies (1 content type)
[ ] Search quotes, jobs or tenders (3 content types)
[ ] Search developer information (multiple content types)
[ ] Search all other pages (dynamically filters by all other content types not already used)

Maybe we need a wiki page for the differences somewhere.

robert castelo’s picture

Status: Active » Fixed

As Alan D. says above, Search Restrict aims to be a lightweight alternative to Search Config module.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.