Author: zu_doggy
Description:
The wiki loads with the search page as the default page and you can't go to any
other page (none of the links on the menu work to bring you to another page). If
you delete the cookie, the problem is resolved and you can navigate to any page.
I have seen the problem with IE, Firefox and Safari and with Mediawiki version
1.8 as well.
Version: 1.5.x
Severity: normal
OS: Windows XP
Platform: PC
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T9681 Stored cookie displays search page not index.php | |||
| Resolved | None | T13559 WebRequest input handling cleanup: use $_GET and $_POST, not $_REQUEST |
mediazilla wrote:
The "search" cookie causes this behaviour.
Moreover, it does not appear to honour the $wgCookiePrefix variable.
mediazilla wrote:
I apologize for the curtness of the previous post. I've now had some time to
look into this (unfortunately, I am diagnosing someone else's problem, and
currently am looking at the 1.5.7 codebase).
The problem appears to stem-from a cookie being set outside of mediawiki,
"search". Unfortunately, when mediawiki looks at $_REQUEST (line 137 of
includes/WebRequest.php in the codebase I'm looking at, in the getVal method)
this takes in $_COOKIE['search'] which is for some reason confusing it,
resulting the the behavior described by the initial reporter.
Hopefully that's enough to duplicate the behaviour. If it isn't, feel free to
contact me, and I can try and provide additional information, and possibly look
into it more.
robert wrote:
After searching the code "getVal( 'search' )" is only used in SkinTemplate.php. This could, however, still cause a collision with a search cookie, if, and only if, that cookie was set on the same website (possibly on the exact same (sub)domain). There is no need to add a cookie prefix as this isn't specifically trying to find a cookie, the fact it finds a cookie is a side-effect of running other software on the same domain as MediaWiki. It could be fixed by making it possible for you to set a flag when calling getVal to ignore cookies, but I am unsure of whether this is the best solution and might not be possible given the current way WebRequest variables are stored.