Okay, so the dev branch is now running live on the Wikipedia servers. A few more days to clean up remaining obvious bugs, and we'll branch this off as the new stable branch. (Should we give it a version number, or a release codename?)
Problems I found and fixed during the rollout:
* Language.php hadn't gotten updated to use $wgSitename, which broke some languages and all the non-Wikipedia wikis
* Cached pages were being gzipped twice due to a broken merge (I'd moved the call to tryFileCache(), and we ended up with both the old and the new positions calling this function and installing output buffer handlers! I trimmed the extra call and added a double-call check to the function.)
* Initial text wasn't being put into the 'reason' field in the confirm deletion screen due to a missing global declaration (also, this check wasn't working for non-article namespaces due to incorrect usage of namespace/title in the queries)
* 'Go' search wasn't skipping the MATCH query when $wgDisableTextSearch was set, due to a missing global declaration
* Doubled google form, missing the search term in the text box
Problems found that still need to be fixed:
* Cookie check in Special:Userlogin fails if that's the very first page the visitor came to in the session (possible fix: do a single redirect if the cookie isn't found; on the second try if there's still no cookie we complain)
* Editing MediaWiki: messages doesn't clear the entries from memcached. ($wgUseDatabaseMessages is off until this is fixed.)
There are probably other problems out there...
-- brion vibber (brion @ pobox.com)
Persistent link caching is not being updated properly, I've disabled it pending further testing.
-- brion vibber (brion @ pobox.com)
Search engine was still issuing the title query even when disabled, then discarding the result. :P
Seeming a little snappier now that that's fixed...
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> Problems found that still need to be fixed:
BV> * Cookie check in Special:Userlogin fails if that's the very BV> first page the visitor came to in the session (possible fix: BV> do a single redirect if the cookie isn't found; on the second BV> try if there's still no cookie we complain)
Do you mean if the user comes straight in to the login form, and submits the login form? That seems to be working. What _won't_ work is bookmarking something like:
wiki.phtml?title=Special:Userlogin&wpName=UserName&wpPassword=password&action=submit
...and loading that without going to any other pages first. It will tell you that you have cookies disabled when in fact you may not.
Is that _really_ something we have to support? Logging in without the login form? It seems like a bit of a pathological case. In fact, I believe that fixing bug 842921 (forms accept GET parameters) would prevent that URL from working anyways.
One other possible scenario is that there's a form on another Web site (outside the cookie domain) that has a login form that submits to a MediaWiki site. Again, I wonder if this is worth development effort.
If it really is worth writing code for, maybe the best way to do this is to check the referrer and bounce them back to the login form if the referrer is empty or isn't on the same site.
~ESP
On Nov 24, 2003, at 09:04, Evan Prodromou wrote:
Do you mean if the user comes straight in to the login form, and submits the login form? That seems to be working. What _won't_ work is bookmarking something like:
wiki.phtml?title=Special: Userlogin&wpName=UserName&wpPassword=password&action=submit
...and loading that without going to any other pages first. It will tell you that you have cookies disabled when in fact you may not.
Errr, that's what I shoulda said. This broke quinlan's emacs editing-helper tool which does a direct login submission. I did give him the workaround, though.
Is that _really_ something we have to support? Logging in without the login form? It seems like a bit of a pathological case. In fact, I believe that fixing bug 842921 (forms accept GET parameters) would prevent that URL from working anyways.
You'd have the same problem submitting that form all through POST.
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> Errr, that's what I shoulda said. This broke quinlan's emacs BV> editing-helper tool which does a direct login submission. I BV> did give him the workaround, though.
OK, yeah. Quickest workaround would of course be to just load another page and get a session cookie.
I've reworked the cookie checking to do a redirect check after login or account creation. If the redirect check fails -- still no cookie -- then it goes back to the login page with an error. If the redirect check succeeds, it just shows the appropriate login success page.
I also added a little login prompt that says that you should have cookies enabled. It seems like a good idea and should cut down on people seeing these errors in the first place.
I tried the new function with these scenarios:
* Log in, existing user, cookies enabled * Log in, existing user, cookies disabled * Log in, existing user, cookies disabled but turned on on login page * GET login, existing user, cookies enabled * GET login, existing user, cookies disabled * New account, cookies enabled * New account, cookies disabled * New account, cookies disabled but turned on on login page
This isn't really a righteous patch. I made the mistake of installing a PHP mode for Emacs, and it mucked around with the formatting, so there's a number of bogus diff lines. I'm too lazy to figure out how to customize this *%^$#! mode to get it to format correctly; hopefully whoever applies the patch can do that.
Hopefully this clears some things up.
~ESP
wikitech-l@lists.wikimedia.org