Search Terms Filter only works when exposed

This has been on my list of things to fix. However, it needs to be fixed to work more like normal filters. I'm not quite sure why but the entire search filter seems to be specialcased when it should not be.

I had a similiar issue that I solved by exposing the search filter, hiding it with css, and then using a custom search form to submit (using the get method) search keys to the view url. In my instance I had local tasks on the view for different taxonomies, so in template.php their is some code that rewrites the local tasks to add the query w/ the search keys.

http://www.hazelconsulting.com/blog/views-2-search-exposed-filter

On a recent site I developed in Drupal 6, was faced with the challenge of implementing filtered search (search results filtered down by taxonomy terms). This can be accomplised use the default advanced search in drupal. but implementing this method would require significant rework of the search interface, not to mention additional templates required to make search results fit in with the rest of the site content which was primarily delivered via CCK/Views.
 
After some experimenting with a number of alternatives, I ended up implementing a solution that utilized an exposed search filter, and a custom search form to pass keys to the view. Unfortunately, Views 2 requires an exposed filter, so i ended up faking it by enabling the exposed filter, and then hiding it with CSS.
 
 
 
 
 
Because the View needs a get request to trigger the filter, simply adding ?keys=search-term to the url won't work. So I rewrote the Local Tasks or menu tabs using localized_options and query settings,  then rebuilding the links with the l() function
 
function hook_menu_item_link($link) {
 
/*** some code ***/     $link['localized_options']['query'] = 'keys='. $_GET['keys'];

  $newLink = l($link['title'], $link['href'], $link['localized_options']);  return $newLink;
}
 
 
The custom search form looks like this
function module_search_form(){        $form['keys'] = array(            '#type' => 'textfield',            '#size'=> 15,        );        $form['#action'] = base_path() .'search-view/results/all';        $form['submit'] = array(                        '#type' => 'submit',                '#value' => t('Search'),        );        $form['#method']= 'get';        return $form;    }

Do you still have that documentation? The following link doesn't work for me. In any event, I'm trying to create a block to display on all nodes of a certain content type that will take the title of the node, treat it as a search and display search results (in the form of a views-created block) accordingly. Would I use a similar methodology as what you've used above?

Forgive me if this is old news, but has this been fixed? I'm trying to use the Search: search terms filter, but I'm not sure how it is supposed to work without the counterpart box to enter terms into. I'd like to use this view without its views-filter box to override the standard search results page if possible. In other words, I'd like users to be able to search the site normally through the standard site-wide search box, but to see results displayed in this view.

Also, do you know if "Search: search terms" will be listed in arguments any time soon, or if there's a simple modification I could try to make that work?

Thanks for any help.

It has not. I have not had the time to rewrite the search to be more normal.

What about doing:

    $view = views_get_view('my_view_name');
    $view->set_display('page_1');
    if (isset($view->display_handler) && !empty($search)) {
        $handlers = $view->display_handler->get_handlers('filter');
        $keys_handler = $handlers['keys'];
        $keys_handler->options['expose']['identifier'] = 'keywords';
        $form_state = array('values' => array('keywords' => $search));
        $keys_handler->exposed_validate(NULL, $form_state);
    }

where $search is your search string. The interfaces you are using are too low level and return only arrays and not objects e.g. the handler itself. Doing this method eliminates the need for a patch.

Please note you need to call set_display() to get display_handler to be set.

If someone wants to take another stab at this against the current version, feel free. Until then, I'm putting this in postponed until such time as we close it for ancientness.

I'm marking this as an unassigned task. If anyone would like to role up their sleeves and take it upon themselves to write a patch it would be awesome

a search terms argument would be so nice.
subscribing

Cross posting here as I think the solution is relevant.

http://drupal.org/node/600242#comment-4038736

I used the solution above and it worked great. Looks like that patch has been applied to Views 3. For views 2, you can use the patch as a module.