Error when accessing search/user

Confirmed the bug.

it happens also for regular users with access profile permission, when the search type argument is some other word than 'node', 'user'

I.e. for this path: /search/one/two

I think the problem was the menu system calling drupal_get_form('menu_view'), but menu_view doesn't return a form structure.

Here's the patch which also adds some more control on the parameters that are passed to menu_view.

Committed to HEAD.

This caused http://drupal.org/node/108587 , I now try to roll this one back and re fix this issue.

So the problem was that search/user did not work after this patch, because submitting to search/user meant that the callback for 'search' was called and that had a wired in 'node' callback argument.

Given that search module redirects from the path search to search/node anyways because $type is empty, the fix is quite simple: we just need to remove the callback argument.

The patch does restore user searching functionality, but doesn't fix the original issue of displaying an access denied message when an anonymous user without "access profiles" permission manually visits search/user. With the patch a search box and button are displayed that don't return any results (for users without "access profiles" permission).

I can not reproduce what ChrisKennedy describes. Have you rebuilt your menu?

A screenshot.

I get the access denied error if the user doesn't have "search content" access, but if they have "search content" but not "view user profiles" I just get the non-working search box for search/user. You get "access denied" in the second case too?

This is after deleting cache, cache_menu and cache_page.

Ah yes. Let's see this one. Note that user_search protects every op with appropriate permission check.

Ok this version works correctly.

Two more suggestions: add a comment and tweak the regex to allow module names with numbers.

According to Chris the version already worked correctly, I just added comment and numbers.

Yup, looks good.

Why on earth are you using a regular expression? Just check if the hook returns an empty string or not.

In fact, I think this is a completely wrong approach. In search_menu():

    $keys = search_get_keys();
    $keys = strlen($keys) ? '/'. $keys : '';
    foreach (module_list() as $name) {
      if (module_hook($name, 'search') && $title = module_invoke($name, 'search', 'name')) {
        $items[] = array('path' => 'search/'. $name . $keys, 'title' => $title,

In other words, if you go to "search/user", a dynamic menu item "search/user" is created (as $keys == '') which should take precedence over "search".

In fact, so search_menu() already checks if the search provider advertises itself. So, the solution is relatively simple... we define an explicit 403 menu item for the case when 1) the search type is supported but 2) the permissions are not set.

The result is that search/user will properly return a 403, and will not require a useless invocation of search_view('user') like in the earlier patch. If you use a non-existant search type, it's as if it wasn't there (e.g. search/foobar == search) and you get the regular node search. This is in line with other drupal behaviour (e.g. admin/foobar == admin).

I was hovering around this solution for a while but could not get it right. In your wisdom we are humbled.

But still, this can be written in less code.

Less code is good, but chx's patch defines a 403 menu item for every module, even those that don't implement search (like color or watchdog). This is bad too, so I re-added the hook check.

And of course, module_list() + module_hook() = module_implements(). Even less code!

Committed with Dries' okay.

There is still a bug in search in DRUPAL-5-0 that search forms all submit to search/node. This patch seems related but didn't fix that problem.

See http://drupal.org/node/108925

Thx.