Download & Extend
Issues

Search blocks breaks if the block is not visible on the search page.

Posted by Morbus Iff on December 21, 2006 at 3:51pm
Project:Drupal core
Version:7.x-dev
Component:forms system
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

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").

Login or register to post comments

Comments

#1

Posted by Morbus Iff on December 21, 2006 at 3:52pm

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

#2

Posted by krewemaynard on January 16, 2007 at 5:46pm

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.

#3

Posted by cburschka on July 1, 2007 at 12:57pm
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.

#4

Posted by cburschka on July 1, 2007 at 12:59pm
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.

#5

Posted by webchick on September 21, 2007 at 10:43pm
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.

#6

Posted by webchick on September 21, 2007 at 10:47pm
Component:forum.module» forms system

wtf @ forum.module?

#7

Posted by chx on September 23, 2007 at 10:16am
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

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

AttachmentSizeStatusTest resultOperations
search_old-104662-7.patch918 bytesIgnored: Check issue status.NoneNone

#8

Posted by snufkin on September 23, 2007 at 12:31pm
Status:needs review» reviewed & tested by the community

tested, works as it should.

#9

Posted by Gábor Hojtsy on September 25, 2007 at 1:17pm

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

#10

Posted by Gábor Hojtsy on September 25, 2007 at 2:56pm
Status:reviewed & tested by the community» needs review

#11

Posted by cburschka on October 1, 2007 at 1:39am

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...

#12

Posted by chx on October 1, 2007 at 6:44am
Status:needs review» reviewed & tested by the community

I believe too...

#13

Posted by Gábor Hojtsy on October 1, 2007 at 8:50am
Status:reviewed & tested by the community» fixed

This sounds good, thanks. Committed.

#14

Posted by zoo33 on October 12, 2007 at 6:24pm
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?

#15

Posted by Gábor Hojtsy on October 13, 2007 at 1:30pm
Version:6.x-dev» 5.x-dev

Mark for 5.x then.

#16

Posted by webchick on November 14, 2007 at 2:03am
Status:patch (to be ported)» needs review

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.

AttachmentSizeStatusTest resultOperations
search-block-pass-term-5x-104662-16.patch783 bytesIgnored: Check issue status.NoneNone

#17

Posted by webchick on November 14, 2007 at 2:08am

And here's one for 4.7.x.

AttachmentSizeStatusTest resultOperations
search-block-pass-term-47x-104662-17.patch1.48 KBIgnored: Check issue status.NoneNone

#18

Posted by webchick on November 14, 2007 at 2:12am
Assigned to:Anonymous» webchick

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

AttachmentSizeStatusTest resultOperations
search-block-pass-term-47x-104662-18.patch779 bytesIgnored: Check issue status.NoneNone

#19

Posted by robertDouglass on April 15, 2008 at 11:20am
Status:needs review» patch (to be ported)

#20

Posted by robertDouglass on April 15, 2008 at 11:21am

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.

#21

Posted by webchick on April 15, 2008 at 1:03pm
Status:patch (to be ported)» needs review

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

#22

Posted by drumm on May 14, 2008 at 6:35am
Status:needs review» fixed

Committed to 5.x.

#23

Posted by Anonymous (not verified) on May 28, 2008 at 6:41am
Status:fixed» closed (fixed)

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

#24

Posted by Jody Lynn on October 18, 2008 at 2:04am
Version:5.x-dev» 7.x-dev
Assigned to:webchick» Anonymous
Status:closed (fixed)» active

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

#25

Posted by fmitchell on November 21, 2008 at 6:06am

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'

#27

Posted by webchick on January 4, 2009 at 4:41am
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)