Need:
Many sites require advanced search functions. These include the ability to search specific node types as well as specific taxonomy terms or vocabs. Furthermore, many sites would benefit from the integration of the Location modules radius search ability within an normal search environment. Finally, sites would benefit from the ability to create multiple "restricted" advanced searches. RSS feeds could be assigned to searches allowing users to monitor specific search criteria automatically through their feed reader. Email notification could also be useful.
Use Cases:
The most obvious use case for such a module would be a job search board. Admin could create a vocabulary for job postings and a flexinode or custom node type. Job searches would be restricted to this node type. Example: http://www.aupeace.org/search/jobs. On the same site, admin could create a "smart search" for housing restricted to housing vocabs and/or node types. Admin could also create a "smart search" within a taxonomy term, or possibly within a specific book with longer publications.
Past Implementations:
As of 4.7, the ability to search based on taxonomy and node type is included in the core. However, the advanced search defaults to include all node types and terms (at least all non-free tagging terms from what I can tell). The SQL Search module does offer the ability to control which vocabs and which node types are part of an advanced search, but the module is being discontinued after 4.6. Also, SQL Search allows an admin to create specific settings for one advanced search. Admin cannot create multiple advanced searches.
Eventfinder is a good starting point for such a module. Eventfinder integrates with the location module's radius searching and allows filtering by node type and taxonomy. Eventfinder can also provide email updates for users who'd like to be notified of events matching certain criteria (such as "all events within 20 miles of 10003 and in the 'Party' category). The weakness with Evenfinder as a general solution lies in the fact that content must be an event with a start an finish date to be included. Also, there is only one eventfinder search. Admin cannot create multiple specified searches with Eventfinder.
Solution- Smart Search Module:
Smart Search would allow admins to create as many "smart searches" as they like with as specific a criteria as they choose. Just like SQL Search now, Smart Search would let the admin create restricted searches, restricted by vocabs, taxonomy terms, node types, dates, and users. These same filters should be available to the user when appropriate.
Smart Search should also include the possibility for integration with the location module if present in an install. Location integration should allow admin or a user to restrict a search by Country, State/Province, or Postal Code. For example, and admin could create a US only job search, but the user could sort by States within the US or use a zip code radius search. Example: Show all jobs in the "plumbing" category in Arizona.
Smart Search would really be a combination of features from Eventfinder, SQL Search , and the Location api to allow for multiple restricted, "Smart Searches" on a site. It may make sense to develop Smart Search as an advanced search api so other modules could hook-in. For example, a resume'/CV module may want to hook into smart search for people to submit their resumes to the poster of a job, or for employees to find resumes that match their job description. Smart Search could really be a small module that just allows admin to create several restricted searches, or an open api that allows for many types of integration.
Moving Forward:
First I'd like to know other people's thoughts on this. Do you see a need for this? Are you developing, or know of a project similar to this? Are there other modules that should be included in this, or built on to achieve the Smart Search functionality? How should smart search relate to Drupal's core search? Are you interested in developing Smart Search?
Once I have some more feedback we can discuss the best way to get this developed expeditiously.
Comments
node types
all this sounds very useful. for example, someone searching for restaurants would only search the restaurant flexinode.
even more important I think is the sorting of results. thank you for working on this. I'm sure many people are interested, even if they do not happen to see this thread
multiple search pages
The idea of multiple search pages sounds appealing to me. I've had clients before who have requested 'a search form for section x of the site, and another one for section y' (where each section is a different vocabulary under the surface).
I imagine that this 'smart search' module would maintain a database of search forms, and that each form would have a customizable set of fields attached to it. Kind of like flexinode, but for search forms. 'Flexisearch'? hahaha... nah, I think there's too many modules already that have (over) exploited the word 'flexi'.
I'll be looking out for this module in contrib! If it is a success, I anticipate that it just might replace the core search module one day.
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
I think there could be some
I think there could be some demand for this. I think there are some features in trip search that are now not in the core 4.7 search. They don't necessarily belong in the core search, but that does not mean they should not be developed and would not be useful in a lot of cases.
Google is often really good at searching parts of a site, like site: drupal.org/handbook, but most people will not do this. Google for searching dynamic content on a site is quickly limiting. One major problem is 'paged' content which can quickly give useless results from google unless you rely on the cache to see the results - paged pages like http://drupal.org/node?page=1 Then, for searching content by location, within date ranges, by certain users, you cannot do this with google, and if you could, it certainly would not be as easy as you could make it with a drupal module.
So, the ability to essentially design search forms based on different modules' ability to create nodes and things in with differing attributes, and give the search its own url, or its own block, and decide what parts of the search form show up in the block as well, could be very helpful. You could then put links to the search form where you need to, and use the block where you need it - like within a job search area of your site.
Look at different sitewide search engines. Amazon.com is a good example. Something that is not in core 4.7 search but is in trip search is the ability to, after running an initial search, further filter by category. I have an idea to make this even more intuitive here: http://drupal.org/node/46337 Amazon.com's search allows for category filtering after running an initial search. Something else useful as an addon could be 'suggested search terms' or alternative search terms so if someone searches for toshiba, the search results page can list other suggested words to search, like laptop, computer, or japan.
Anyone have any thoughts on if this is something that could easily build off of the core search functionality?
Ian
filtering
I agree that further filtering by category after an initial search is a very important feature.
Yes please...
I agree that it would be very useful to be able to search by a combination of node type, taxonomy, node title, and node content text.
At the moment (with Drupal 4.6) I am having to use the "search", "taxonomy_browser" and "pathauto" modules to search through various custom node types that I have implemented... it would be much cleaner to just have one powerful search module.
views
I'm testing out the new views module, which may help with some of this. does anyone know why the 4.7 search module isn't including the functionalities that trip module has? is there some conflict? I guess not since you might write smartsearch, but I don't understand why Wittens didn't go ahead and include this.
How will views help?
Waht features are there in veiws that are similar to this proposal? I don't know much about that module.
The way that views creates a
The way that views creates a GUI for building page view queries could be similar to a smartsearch, where the admin is given an interface to help build parameters for a search query, then save is as a page located on its own url. So, in a sentence, smartsearch could be a GUI which takes search in its raw form and lets the admin add elements which customize the search, and then can save the custom search to a page, and can create and save as many custom searches as needed. A smartsearch page which has been saved you could call "jobs" and have it show up on smartsearch/jobs. Based on how you constructed the custom search, the interface is assembled for the user to see and run their search.
You could have widgets like:
Category filter:
Check off which category terms to make available in the category filter
(this would be like 4.7 advanced search)
Node filter:
Check off which node types to make available in the node filter
User:
Allow restriction by user
Date:
Add a date range widget
Location:
Add a location widget.
include zipcode search (checkbox)
include state search (checkbox)
include metro search (checkbox)
Name of this search:
enter name
Url for where search appear:
enter url
Make block available for this search?
(checkoff)
So, you get all these different filtering options which you add to your search, save it, and boom, it becomes available on the entered URL. :)
I think the trickiest part is since you could end up with a ton of filters - making it look nice no matter how many or few filters you add to your custom search. Though, not that tricky.
Then you could also use
Then you could also use something like views_bookmark module, or a relationship module, to tag or relate your nodes, then make this data available to use as additional search parameters when building a smartsearch.
This would allow you to do things like make a smart search to lets users search through all the content are involved with (like a user-centric search for /tracker), and if personal bookmarks were enabled for some views_bookmarks then a you could use smartsearch to build a page that lets users search their own bookmarks. This might be over the top, but I hope it gives an idea of the extensibility I'm imagining and I think Jason is talking about.
Ian
Relationships
Ian, those are good ideas. Node relativity has a query function like this that lets a user set up "node queries" based on relativity data. The "node queries" are actually a node type so users with permissions can create as many as needed. It is even possible to set the depth of a search and restrict how many relationships deep to go (sidenote: a useful feature also for social networking sites searching for friends of friends). The problem is that Node relativity is being deprecated from what I can tell and it creates its own relationships that aren't tied to taxonomy at all. It seems like there are a few parallel relationship apis being developed between tagging, cck, and relationship so I'm not sure what will become the standard
Views integration is a good idea and possibly a good way to link this module, building off it. For example, dynamic Smart Searches would also be dynamic views. The simplest example of this being a block that displays a jump menu for filtering a taxonomy term by node type. A user goes to taxonomy/term/3 and is presented with the jump menu to further filter and see only news stories or blogs. This seems like more a views function than Smart Search, but illustrates the close relationship between any modules that are making queries.
Now that I've made some abstract comments, I'm not sure how to move forward. Maybe talk to the views maintainers about this? Are we thinking too big for this module or on the right track? Anybody have guesstimate of the work hours needed to develop this or possible pricing? Time to start a bounty?
bounty
views maintainer is merlinofchaos and i find him to be very friendly and helpful.
i'd help with the bounty except i'm organizing an ecommerce paid membership bounty right now.
thank you!
Take a look at in views how
Take a look at in views how you can now expose a filter in the "exposed filters" area when creating/editing a view. Basically, when you create a view, you can add filters, which could be taxonomy terms, for example, then, you can expose this filter, which will show on the views page you make, in this case w/ a taxonomy filter, a listing of the terms you've included to filter by, which a user can then use to filter the view. This is a step toward making custom search pages.
check this out, it talks
check this out, it talks about views and searching drupal http://www.lullabot.com/articles/drill_down_system
I think the idea is to keep
I think the idea is to keep the core search fairly light weight, then use a contributed module to expand on core as needed.