Administrative user search form not working
theborg - January 15, 2008 - 11:58
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | user system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | theborg |
| Status: | closed |
Description
There is a typo error in user search form that renders the same content without doing the search.
Patch provided.
| Attachment | Size |
|---|---|
| user_search_a.patch | 819 bytes |
#1
trivial patch, tested, works, RTBC.
#2
Related to this form also: http://drupal.org/node/208790
#3
Hm, we use NULL not null. Also what does search_data() do there? There is not even a parameter at that position AFAIS:
in the patch:
drupal_get_form('search_form', url('admin/user/search'), $keys, 'user', null, search_data($keys, 'user'));
function signature:
function search_form(&$form_state, $action = '', $keys = '', $type = NULL, $prompt = NULL) {
#4
Corrected NULL typo.
As per form_api:
drupal_get_form can take optional additional arguments, which will be simply passed on to the $form builder function.
#5
Yes, that doc refers to the arguments of the form builder I quoted above. How does search_data($keys, 'user') get there.
#6
What Gabor says is that you are passing NULL for $prompt and then something else which has no matching parameter in the function signature.
#7
Yes, I'm aware of that, sorry, I missunderstood documentation.
The keys end as a callback parameter to drupal_retrieve_form and search_form function
// If $callback was returned by a hook_forms() implementation, call it.// Otherwise, call the function named after the form id.
$form = call_user_func_array(isset($callback) ? $callback : $form_id, $args);
Sure there is a correct way of solving this bug.
#8
SIGH! You are passing five (5) arguments to search_form which takes four (4) arguments aside from the form_state that's automatically added. The fifth argument is not going to be used. Got it?
#9
Ok, got it, sorry for that mess.
This patch sets the action to null, so it will go to 'search/user'.
#10
Only affects the admin end.
The patch works but I don't think you need to check for keys. search_data will handle it just fine but I'm not sure if the returning nothing and appending to the string would cause a notice.
#11
If you pass in NULL then the action
<?phpif (!$action) {
$action = url('search/'. $type);
}
?>
search/user. This is not what you want. I agree with dvessel that passing in a NULL forsearch_datawill work the function returns NULL very fast which PHP nicely casts to the empty string.#12
Why in the first place do we have this page? What does it do that search/user does not?
#13
catch said we nuked admin/content/search for it did nothing that search/node did not. Same for this page. Fixing the search form does not hurt, however.
#14
Nothing.
fwiw, admin/content/search was removed a couple of months ago for similar reasons.
#15
I guess catch crossposted my patch.
#16
Works just fine. The menu link still exists though. Thought it was cached in the menu system.. got it cleared and it's still there.
#17
Tested and works ok.
Removed the search link from the admin users menu.
#18
Edit:
$form['#redirect'] = FALSE;causes /search path to not work.#19
#20
OK.
#21
Hm, all right. The argument sounds right that we removed the content search on the same grounds. Well, committed.
#22
Automatically closed -- issue fixed for two weeks with no activity.