None of the search tabs is marked active

1. The advanced search form is now gone. This means we lose one of the most important features: the ability to filter by node type. I notice faceting by author, which is nice, but node type is a critical piece of functionality.

You also have the "by type" facet. It was very down below, I reordered the blocks a little.

2. There is no way to search for user profiles any more. I used to use this functionality daily.

Oupsie. This is now part of a separate module. We will restore that.

3. The new "search downloads" box represents a major loss of functionality. Instead of searching a keyword within projects titles and descriptions, it now only searches for project titles.

Hum. True, but this is only temporary it will change under the influence of the MB design, starting Monday 9th in Paris!

No tab is active when clicking into the search interface.

URL and / or screenshot please?

I believe this last one to be a core bug.

@webchick:

Re: #0 point 3: Something is screwy with the project blocks after the upgrade. That block shouldn't be showing up for "Search downloads" at all -- that's really the project navigation block, which we don't even use on d.o. I suspect the problem is that project.module is still using int deltas for the blocks, instead of strings. Anyway, I turned it off yesterday when I noticed it.

Regardless, we should use a solr search block for this now, instead of the core search index (which is what the old "Search downloads" block does). It's all coming as initial roll-out of redesign functionality, even before we have the full theme, etc.

Re: comment #1: Let's talk over at #367430: /search/issues is WSOD. ;) Thanks.

Still active for:

A. Core issue with the tabs.
B. There is no way to search for user profiles any more. I used to use this functionality daily.

A) This is certainly a core issue. For one, it does not mark any of the tabs default, so when it does not know which one to mark, it does not mark any. Second it defines '$module/%menu_tail' for the tab, so if there is no slash after $module (such as when you just go to the search page), there is no active tab.

B) This is only about us applying the core-searches patch to remove the core search tabs, but then not enabling the user search module which is a result of that patch. We might opt to not apply the user module hunk and then we get back our tab from user module. Or we enable the user search module. It should be committed to SVN, since looks like the patch was applied but the resulting two search modules were not committed.

Anyway, looks like the issue was marked critical for the missing advanced search, so since that was a misunderstanding, and we only have smaller issues here, setting back to normal.

For (B), user search is enabled on the site.

For (A) now none of the tabs mark themselves chosen when I choose them, but that should be a core bug IMHO. Retitling for it.

I know its a bug, but if u want only solution, try to hook menu tabs. For my purpose, i used this simple code in template.php which works for me well:

/* 

add "active" class to <li> tabs based on which label u entered

parameter $tabs_num:
'tabs' - alter primary tabs (by default)
'tabs2' - alter secondary tabs

*/
function phptemplate_set_active_tab($label, &$vars, $tabs_num = 'tabs') {
  $tabs = explode("\n", $vars[$tabs_num]);
  $vars[$tabs_num] = '';

  foreach($tabs as $tab) {
    if(strpos($tab, '>'.$label.'<') === FALSE) { // find?
      $vars[$tabs_num] .= $tab."\n";
    }
    else {
      $vars[$tabs_num] .= str_replace('<li ><a ', '<li class="active"><a ', $tab)."\n";  /* have space in <li >, so mabye u have to change it to just <li> only */
    }
  }
}


function phptemplate_preprocess_page(&$vars) {
  if (arg(0) == 'search' && arg(1) == 'node' && !arg(2)) {
    phptemplate_set_active_tab('Obsah', $vars);  // im using Czech labels..dont know EN eqs..probably 'Node', 'Content', 'Users' etc.
  }
  elseif (arg(0) == 'search' && arg(1) == 'user' && !arg(2)) {
    phptempalte_set_active_tab('Uživatelé', $vars);
  }
.
.
.
.

I tried to solve this with hook_menu_alter(). I changed $items['search/node/%menu_tail']['type'] = MENU_DEFAULT_LOCAL_TASK; That is not a good solution because the Content tab is highlighted, even when you're on search/user, etc...

boreg's workaround is interesting and I'll probably use it. But it unacceptable in the long term for multiple reasons, one of which is that it works for only one language at a time.

I view this as a bug in the menu system. It appears in the search, but it would appear anywhere a module creates a similar menu structure.

I think the issue is resolved.
I searched for kiamlaluno using the search form present at the top of every pages; when the search page appeared, I clicked on users, and the tab is shown selected.