Closed (fixed)
Project:
Search Restrict
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
19 Oct 2010 at 13:33 UTC
Updated:
12 Sep 2012 at 20:51 UTC
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
Comment #1
antony.lovric commentedNo 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.
Comment #2
mellenger commentedWhich one is better? I have some utility content types like homepage hero's that should never show up in search.
Comment #3
leksat commentedhttp://drupal.org/project/search_config
Maintenance status: Abandoned
Development status: Obsolete
Is it an answer?
Comment #4
robert castelo commentedWe 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.
Comment #5
alan d. commentedIn 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.
Comment #6
alan d. commentedHere is a start: #1192448: Drupal 7 permission based configuration
Comment #7
kerios83 commentedSooo... 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.
Comment #8
alan d. commentedYear. 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:
I'm considering:
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.
Comment #9
robert castelo commentedAs Alan D. says above, Search Restrict aims to be a lightweight alternative to Search Config module.