Enable the search.module block. Have it show up only on node/15 (or any existing node). Type something in and click "submit" - you get redirected to search/node, but your term is ignored, nor does it show up in the primary "Enter your Keywords" block. I suspect what is happening is that, since the block does NOT show up in this page (because it's been restricted to node/15), the POST variable it sent along ("search_block_form_keys") is being treated as unknown (ie., "well, there's no form on this page that uses it, so it's garbage").

CommentFileSizeAuthor
#18 search-block-pass-term-47x-104662-18.patch779 byteswebchick
#17 search-block-pass-term-47x-104662-17.patch1.48 KBwebchick
#16 search-block-pass-term-5x-104662-16.patch783 byteswebchick
#7 search_old-104662-7.patch918 byteschx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

This would probably affect any form with these conditions (form block on one page, but not on destination page).

krewemaynard’s picture

krewemaynard CreditAttribution: krewemaynard commented

I was having trouble with this in 5.0 RC-1, and I still have the same problem now using the final 5.0 release. If I limit the search module to a specific node, any search will take you to the search module itself, not the results. You have to re-do your search to get it to work.

cburschka’s picture

cburschka
they
CreditAttribution: cburschka commented
Component: search.module » forms system

This is either a block.module or a Forms API issue. I'm tending to the latter, since it applies to any form not present on the page its action refers to.

Something very similar happens if you disable the user login block on some pages.

Very simple, though possibly change-intensive fix: Forms API should detect if a given form ID was submitted and call the appropriate submission handler, even if drupal_get_form() wasn't called on this particular form on the target page.

cburschka’s picture

cburschka
they
CreditAttribution: cburschka commented
Title: "only on node/15" search block fails to work » Form breaks if #action points to URL where it isn't displayed.

Title change would also be appropriate. I think this one sums it up.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Component: forms system » forum.module

Wow, nice. We're getting this bug on a site where the search block is on the front page, but not on any other pages. When I enter a term, it redirects to just search/node, not search/node/X.

FWIW, this broke in 5.x. 4.7.x behaved fine.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Component: forum.module » forms system

wtf @ forum.module?

chx’s picture

chx CreditAttribution: chx commented
Title: Form breaks if #action points to URL where it isn't displayed. » Search blocks breaks if the block is not visible on the search page.
Status: Active » Needs review
FileSize
search_old-104662-7.patch918 bytes

This can be fixed by removing code. We do not need to add anything.

snufkin’s picture

snufkin CreditAttribution: snufkin commented
Status: Needs review » Reviewed & tested by the community

tested, works as it should.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

So this makes you stay on the same page, which essentially makes all pages showing the block search pages?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Reviewed & tested by the community » Needs review
cburschka’s picture

cburschka
they
CreditAttribution: cburschka commented

To help clear up a confusion that I felt before testing and examining this more closely:

Removing the #action value does not have any effect on where search results are displayed. A search query consists of two HTTP requests:

1. The user submits the form via POST (first request)
2. The _submit function builds a search query URL ("search/node/[term]").
3. The site redirects the user to this URL (second request)

The #action value controls only the target of the first POST request, invisible to the user. The user still ends up on search/node/[term] once the POST is processed and redirected. I believe that solves the problem quite elegantly...

chx’s picture

chx CreditAttribution: chx commented
Status: Needs review » Reviewed & tested by the community

I believe too...

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Reviewed & tested by the community » Fixed

This sounds good, thanks. Committed.

zoo33’s picture

zoo33 CreditAttribution: zoo33 commented
Status: Fixed » Patch (to be ported)

So this bug is also present in Drupal 5 (see comment #5 and #174494). Should this patch be ported?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Version: 6.x-dev » 5.x-dev

Mark for 5.x then.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Patch (to be ported) » Needs review
FileSize
search-block-pass-term-5x-104662-16.patch783 bytes

Looks like this'll fix it. Needs to be ported to 4.7.x as well, from the look of http://drupal.org/node/103909.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
FileSize
search-block-pass-term-47x-104662-17.patch1.48 KB

And here's one for 4.7.x.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Assigned: Unassigned » webchick
FileSize
search-block-pass-term-47x-104662-18.patch779 bytes

Sigh. ;) Drupal 6 making me lazy about double-checking my patches. ;)

robertDouglass’s picture

robertDouglass CreditAttribution: robertDouglass commented
Status: Needs review » Patch (to be ported)
robertDouglass’s picture

robertDouglass CreditAttribution: robertDouglass commented

Hmm. Now I don't know: is "patch (to be ported)" the right status for this since webchick has already ported the patch? Or was it right with "patch (needs review)"?

Anyway, seems like this deserves some attention from Drumm.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Patch (to be ported) » Needs review

Yeah, it's needs review if there's already a port.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Needs review » Fixed

Committed to 5.x.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Jody Lynn’s picture

Jody Lynn
she/her
Primary language English
CreditAttribution: Jody Lynn commented
Version: 5.x-dev » 7.x-dev
Assigned: webchick » Unassigned
Status: Closed (fixed) » Active

This fix broke the ability for search to work from 404 pages: http://drupal.org/node/292565#comment-1065064

fmitchell’s picture

fmitchell CreditAttribution: fmitchell commented

Still not passing the search terms in Drupal 6.6. No $form['#action'] in search.module (Acquia version).

You can test at http://brightplum.hobby-site.com/where2hoop/

Search term 'Ray Meyer'

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Active » Closed (fixed)

Oops. :( Sorry. :(

Marking this back to closed, since this is being handled over at #292565: Regression: Can't set /user to 403 page (was: login destination is broken)