Closed (fixed)
Project:
Drupal core
Version:
x.y.z
Component:
search.module
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Apr 2006 at 03:13 UTC
Updated:
16 Apr 2006 at 13:15 UTC
Jump to comment: Most recent file
Comments
Comment #1
webchickSorry, no patch. ;(
Comment #2
webchickAnd actually, looks like it does the same thing no matter what keyword-limiting stuff you plug in; it's not limited to the first box.
Comment #3
webchick*sigh* one more title change, then I'm leaving this alone. :P~ And it's definitely critical.
Using _any_ of the restirctions in advanced search will cause the keyword to be "Array" even if it's simply restricting to a certain node type or term.
Comment #4
Zen commentedAttached is a patch that resets things to how it originally was - this works fine, but chx reckoned that this is not the correct way of using #ref.. I personally think that both ways are not terribly intuitive (or wrong):
My 10p,
-K
Comment #5
Zen commentedApologies for the open tag.. Previews don't work in project atm.
Thanks
-K
Comment #6
Zen commentedAnd furthermore, in the above post it should be:
Thanks and apologies for the flood :|
-K
Comment #7
chx commentedNO! This makes absolutely no sense -- can't you see that you are setting something that does not exist and works only because it's a global variable?
Comment #8
Zen commentedWell, something is broken in forms api - if not the way #ref works currently, then it is: http://drupal.org/node/56921
-K
Comment #9
chx commentederm not because it's a global variable but the way PHP handles globals and arrays in globals. again an array in an array and the reference to it..
Comment #10
Zen commentednode.module patched according as per the current #ref implmentation.
-K
Comment #11
Zen commented.
Comment #12
chx commentedNow, that's good to go.
Comment #13
killes@www.drop.org commentedapplied
Comment #14
(not verified) commented