Closed (fixed)
Project:
Drupal core
Version:
5.0
Component:
search.module
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
12 Jan 2007 at 19:02 UTC
Updated:
13 Feb 2007 at 02:33 UTC
Jump to comment: Most recent file
I just upgraded to RC2 and now my custom search implemented in hook_search is incorrectly submitting to search/node instead of search/mytype. I noticed the same behavior for search/user and verified the same behavior on http://drupal.org
when submitted takes me to
http://drupal.org/search/node/dldege
After the incorrect submits I can change tabs and correctly get to
http://drupal.org/search/user/dldege
which shows the correct results.
The forms on the page seem to have the correct action set but still the submit goes to search/node.
This is my first bug report for core so please let me know if you need more information.
thx.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | search-broken-tabs.patch_1.txt | 1.33 KB | dww |
| #13 | search-broken-tabs.patch.txt | 1009 bytes | dww |
| #8 | search.module_11.patch | 898 bytes | drumm |
Comments
Comment #1
ChrisKennedy commentedThanks for the bug report. This issue is being discussed at http://drupal.org/node/102040
Comment #2
dldege commentedSorry, I tried searching for this to make sure I wasn't duplicating and didn't find it ... Its definitely that most recent checkin as I went back to
// $Id: search.module,v 1.206 2006/12/11 16:57:42 dries Exp $
and everything works again.
thx.
Comment #3
dldege commentedI'm not sure this is the same issue as http://drupal.org/node/102040. I just upgraded to DRUPAL-5-0 and this bug is still there despiste their being a patch added for the bug in http://drupal.org/node/102040.
Comment #4
dldege commentedThis seems to be a problem with the module type not being preserved during from submit.
from search_form(...)
on search_form_submit() the type is 'node' always - that is it is set and == 'node' not the module the search orginated from (user, customname, etc.)
I noticed this form item has a type of 'value' which I don't know how that works yet.
I hope this is helping.
Comment #5
dldege commentedComment #6
hickory commentedGetting rid of the callback argument to search_view fixes this, as was originally suggested for the other issue. It's not clear why this was taken out of the patch at http://drupal.org/node/102040#comment-177485.
Comment #7
drummA patch existing on another issue does not imply it has been committed. I think these are still duplicates.
Comment #8
drummActually, I'm wrong.
Here is a patch to fix this issue. The searches submit to 'search/...', while the menu item was being defined for 'search/.../key' since $_REQUEST['keys'] is set on submitting a search. The created menu item did not match the path since it was too restrictive and we fell back to the generic node search.
This patch makes the created path for the main search page instead of the overly-specific results page.
Comment #9
chx commentedYes but this makes impossible to bookmark a search. I willl take a look two hours from now.
Comment #10
drummThe URL sent to the browser is still the same. Only the path of the menu callback used to serve the pages changes.
Comment #11
chx commentedRight you are. The problem was that the search form submits to search/user (for example) but search_get_keys gets the keys from POST and defines only search/user/whatever+you+searched+for .Clever trick -- but still not good enough. Because if you search for node 'foo' and want to search for user 'foo' that can't happen. So, keep the original items need to be kept but the current tab needs a MENU_CALLBACK.
Comment #12
dwwagreed. in 4.7.x, if you search for "foo", end up on /search/node/foo and click "users", you go to /search/users/foo which works. that's nice behavior, which the patch from #8 doesn't retain (although at least it lets you search for users at all). ;)
Comment #13
dwwafter much consultation with chx, we decided drupal_goto() is the only solution. if you make a MENU_CALLBACK at, e.g. /search/node, then that destroys all the tabs we just tried to register to at search/*/$keys. :(
Comment #14
dwwnew patch with some comments about the weird drupal_goto() in search_menu().
Comment #15
drummTested and it works for me.
Comment #16
drummCommitted to 5.x
Comment #17
dldege commentedYes, this is fixed for me - THANKS!
Comment #18
dldege commentedSorry - this fixes the redirect but breaks advanced search as well as my own custom search form items that I add on search/mymodule. The keys created by the custom form stuff is lost.
Comment #19
drummA patch was committed to fix advanced search.
Comment #20
(not verified) commented