Was running a command-line entry point from the middle of an updater, which is bad bad bad -- will kill the web installer and may fail on command-line updates, depending on circumstances.
Ugh! Somebody please clean up this duplicated code.... allpages and prefixindex have lots of duplicated bits. I swear one used to be a subclass of the other, did they get copied? Or did I do that years ago and forget? :D
God I wish this browser would finish dying. :D
The particular situation was that the session cookie was getting eaten as "disabled", thus not sent back to the server so your session state never quite happened. Other cookies on submit seemed to come in intact, but without the session cookie you'd get a big fat error message, even if you set the long-term login cookie option.
Mac/IE seems to always *see* the HttpOnly cookies, but it sometimes marks them as "disabled". It seems to be incorrectly parsing the options after the path, sometimes seeing "/;" as the path instead of "/". Failure is more likely if there's no expiration option (as with the session cookie), or if there *is* a secure option set.
Anyway, just set up a user-agent blacklist $wgHttpOnlyBlacklist and copied the Mac/IE entry over. The HttpOnly setting now gets ignored for blacklist hits as well as for old PHP versions, the check being encapsulated into wfHttpOnlySafe().
Also added some logging for cookie settings, around the setcookie() and session_set_cookie_params() calls.
Files marked as being larger would be horribly client-side scaled on Image: page inline display for users who set their options up to 1280 or larger. 2048 is still not insanely-huge while still encompassing common screen sizes.
Problem was that the Modern skin uses a different way of setting up the print stylesheet from the other skins.
Others:
* always include main stylesheet
* override that stuff with print stylesheet for print media or ?printable=yes
Modern:
* include main stylesheet only for screen & projection media only
* add some additional print styles for print media or ?printable=yes
The screen stylesheet was still being used when ?printable=yes is set, but would be hidden when actually printing. I've changed it to now exclude the screen stylesheets when ?printable=yes is switched in, so it looks the same on screen as when actually printing.
Adds the appropriate id for Modern skin to the set of justify CSS thingies.
This isn't totally satisfactory; the various skins should be refactored to unify this stuff better, but it'll do for now.
The setup code was using a MonoBook-specific div ID to insert the results container into. Swapped that for the plain ol' document.body and fixed the styles for MonoBook and Modern so it gets the scale-up fix for the font size (they both use a weird system where they shrink the font size on the body, then scale it back up inside.... very wtf territory!)
Added setup for form and input IDs used for the second search box on Cologne Blue, and copied those IDs over to Nostalgia and Classic skins.
Note that the drop-down is a bit unsatisfactory on the page-bottom search boxes in Nostalgia, Classic, and Cologne Blue, as it tries to squish in at the bottom of the page, and you only get two lines of data. The sidebar search boxes are also not very wide, which makes results pretty cramped.
A few notes:
* This seems to drop the 'action=success' page in favor of dumping all the output directly on the POST response. That's probably necessary, but tends to cause annoyances with back/forward navigation (warnings about re-POSTing data etc)
* The subpage checkbox is shown on the form based only on the target page's namespace. This means it'll show for the vast majority of, say, talk pages which don't have any subpages. To be consistent with the talk namespace, it should be kept hidden if there aren't any.
* Subpages may exist for a talk namespace while not existing for the article namespace. When moving an article with its talk, and the talk has archive subpages, it would probably make sense to do the moves -- but no check will show here due to the check only on the article space.
* There's a couple copy-pasted instances of $something ? ' checked="checked"' : '' ... since these are passed to a function looking for a boolean, they should just use the boolean $something. :)
* I see some unnecessary uses of =& ... this is a PHP 4-ism and not needed here.
* This query's kind of creepy:
SELECT /* MovePageForm::doSubmit WikiSysop */
page_id,page_namespace,page_title FROM `page` WHERE 0 = 1
* Generally speaking, there may be a _lot_ of subpages. English Wikipedia Main_Page will net you 169 total including itself, talk, and all subpages. How safe is it to move potentially thousands in one request here?
* Say "log in / create account" if an anonymous user can create an account, otherwise just "log in", consistently across skins. (Currently Monobook always says "log in / create account " and non-Monobook always says "log in".)
* On Special:UserRights, when you can add a group you can't remove or remove one you can't add, a notice is printed to warn you. This is to avoid confusion like that exhibited at bug 13503; it's a fairly unusual situation in MediaWiki to be unable to reverse your own actions, so a notice seems to be appropriate. (I changed the userrights-groups-help message to point out the meaning of the extra markup; should it be renamed? It's a common and kind of annoying problem, we should think up some consistent way of versioning messages. Start adding numbers to the end?)
pt_title field in page_protections was added without a binary marker when used on non-binary schema.
This means you get false matches for ASCII case-insensitive bits, and probably for horribly wrong UTF-8 mish-mashes as well.
Adds an updated to fix the field's encoding to binary, matching all our other title keys,
so you can join and get correct matches.
Revert r33473, which seems to assume that pt_title is supposed to be case-insensitive.
(Even if it was, it woudln't work correctly as written.)
