upper right search and login forms are broken on issue pages

I don't know anything about the project module. But the likely issue is that the project module's search form on the issue page hasn't been converted to FAPI. It probably checks $_POST for a certain variable and hijacks the page.

Converting it to FAPI and giving it a unique form ID should fix the issue.

Cheers
-K

.

this bug is easily reproducable on a 4.7 test site, so it's got nothing to do with drupal.org or the bluebeach theme. something's just broken in issue.inc. therefore, i'm glad zen/gatsby just moved this to project's issue queue (via discussion on IRC). also, i think this is critical for project to fix, since it makes drupal.org look bad. :(

on a hunch that this was caused by FAPI badness in project and the two buttons labeled "search" clobbering each other, i tried renaming the issue-specific search buttons to "search issues". alas, that didn't solve the problem, either. guess we should do what zen just said about making this a real form with a unique id...

more descriptive title to help people find this issue more easily

i'll take a look when i have some time (today's not good, probably monday). thanks for the investigation!

a) on a test site, i can't seem to reproduce the search bug, though i know it's there. the specific problems on d.o might be b/c the search bar is handled differently in the code than the usual search form boxes from either the search block or the search box handled by the theme...

b) i know a related bug is that if you give anonymous users permission to view issues, and goto the /project/issue page as an anonymous user, you can't login.

so, i think your patch is working, since when the patch is applied, and i try to login on the /project/issue page, it gets a lot further than it used to. however, it hits a code path that's been broken in the code for a while, and you end up trying to do an invalid SQL query. :(

basically, the code currently relies on the fact that project_issue_query_result() will have something in the $query. in project_issue_query_parse(), if $query is going to be empty, we add the default issue states. your patch changes this, and we end up with a NULL query, which leads to the bogus, broken query from ~line 1203 (in your patched version).

that's really a separate bug, but it's related to what you're doing here. namely, your patch, while probably a good move (i wish i knew why it was clearing POST edit and op like that), is exposing a new code path that never used to be hit. we should fix this other problem, regardless. once that's done, we can revisit this patch.

so, this issue is hereby postponed until http://drupal.org/node/77710 is resolved (patch is there, just needs review).

ok, that other patch is now committed. this is back in play. however, the wisdom i discovered needs to be put into practice in this patch. you can't just return from project_issue_query_parse() without doing anything, or all hell breaks loose.

i'm just going to investigate ripping out that crazy unset() call completely. it was added here:

revision 1.21
date: 2003-10-05 13:40:51 -0700;  author: kjartan;  state: Exp;  lines: +33 -28;
- Fixed mail subjects being wrapped and nl2br()'s.
. Added RSS feeds to issue listings.
- Fixed tablesort loosing search values.

i'm guessing it was for the "tablesort loosing search values" mojo. i'm guessing enough has changed since 2003 that this is no longer a problem. initial testing after removing the unset completely seems to work fine. well, actually, it seems that the unset() isn't helping for the tablesort stuff. if you select some custom values in the query via the form elements, and then use the tablesort (e.g. click on a given column in the table to sort by a different value), then the query gets lost, anyway, and you end up with the wrong behavior. ;) just submitted this as http://drupal.org/node/77730 *sigh*

aside from the fact that http://drupal.org/node/77730 is broken (independently of this, it seems), i offer the following as a solution to the site-wide search and anonymous login problem. light testing seems to indicate that a) login now works and b) nothing that currently works stops working using the issue query forms. this seems a lot cleaner than the conditional return, and allows project_issue_query_parse() to continue doing its job of populating $query with something valid.

needs more testing. i was trying to get chx to help me try to understand why the unset() was there in the first place. if that ever happens, i'll certainly report back here.

chx believes (and i tend to agree) that all the messing around with $_POST in project_issue_query_parse() is, to quote chx: "a remnant of distant past age". ;) here's a new patch that goes 1 step further to remove all such $_POST-munging mojo. further testing seems to indicate this doesn't break anything. i'm inclined to apply it. any last objections/complaints?

applied to HEAD, 4.7 and 4.6.
woo hoo! ;) thanks to everyone who helped out with killing this bug...