revert r108367 : breaks tests

When doing a change that break tests, update the tests in the same
commit. That makes the change more obvious and let us merge in
another branch easily.

[mediawiki.action.history.js] Provide cleaner handling of action=historysubmit hack.
* Follows-up r108341, r108370
* Doesn't remove it, server will still handle them properly (as provided by r57415) when JavaScript is off. This commit adds a progressive enhancement when possible so that submit will go to either of these:
* title= & diff= & oldid=
* action=revisiondelete & ids[..]=
instead of one of these
* action=historysubmit & title= & diff= & oldid= & ids[..]=
* action=historysubmit & revisiondelete=1 & ids[..]= diff= & oldid=
(removing redundant parameters and parameters from the other submission-type that don't belong in that url)
* Also re-adding support for action= revisiondelete in the query, as it was originally. Due to this hack it appears that support for the original action name (which is still returned as "revisiondelete" from MediaWiki::getAction() ) was removed or never existed in that place of the code at all. Fixed now.

* r107986: Added readOnly checks to prepare(), secure(), and clean() in FileBackendBase.
* Added some prepare()/clean() tests.

Fix double-escaping in 108312

Fixup documentation

Swap require for require_once

Wrap long line

[mediawiki.action.history.js] Clean up
* Using named variables instead of eq(0) and eq(1), also future proof by checking name="" instead of depending on their respective position in the DOM.

[HistoryAction] Clean up
* Don't build $s as well as $this->buttons for re-use later in getEndBody(), simply use it in both cases.
* Adding a css class for compareselectedversions button just like there is for the revisiondelete button

[HistoryAction] Revert r108341 as this breaks revision delete.

This construction never looked cool, but looks like this fix is not the right way, so reverting it.

This form is used for two purposes:
-- Submitting diff/oldid to (implied) action=view
-- Submitting ids-array to action=revisiondelete

That makes it complicated. Also for IE6/IE7 compatibility, there is no way to do this from the HTML itself (i.e. using <input type="submit" name="action" value="revisiondelete"> would work but leaves no option to have a custom i18n label. and <button type="submit"  name="action" value="revisiondelete">I18N LABEL</button> works but IE7 submits "I18N LABEL" as value for "action" instead of "revision delete".

Will re-fix bug 33587  in a few minutes with a "progressive-enhancement" solution from the front-end instead.

* Fixed 'success' value of doOperations() Status to match documentation.
* Made 'success', 'successCount', and 'failCount' fields reflect the overall operation in FileBackendMultiWrite::doOperationsInternal(). This makes it match up with single-write backends.
* Made FileBackend::clearCache() part of the public API.

* Improved error message for LockServerDaemon when parameters are missing and bumped default 'maxClients' value.

Fix the regression pointed out by Robin in r105855.

Fix str_replace parameter order fail from r108364

* Use WikiPage instead of Article to call doEdit()
* Pass the User doing the edit to doEdit()
* Check for invalid title before fecthing content and doing the edit

Followup r108363 for bug 33571

Refactor out duplicate code

* bug 33571: fix yottabits/s in Language::formatBitrate

Problem was caused by inexact floating-point comparisons with values returned from
log10(); worked around by simply duplicating the very similar code in the function
immediately below, which does the same thing with 1024 instead of 1000 unit sizes,
uses only simple division, and passes the test cases.

Fix method name in comment: Article::followRedirect() -> WikiPage::getRedirectTarget()

Followup r108358, bring back DelayedParserTest

r92975 caused wikitable in MediaWiki:Recentchangestext (eg. enwiki)
as it was no longer beginning a new line.

* Drop old parserTests.php way of running parser tests. You can run parser tests via --group Parser or specifying
  the includes/parser/MediaWikiParserTest.php test case
* Drop now unused various test recorder options -- phpunit outputs its data in lots of machine-readable formats, use those if you need to work with
  test data
* There's still a lot of duplication between NewParserTest::setUp() and MediaWikiTestCase, but hey one step at a time ;-)
* All tests pass for me (make phpunit && make parser)

Another @group Broken

@group Broken rather than marking incomplete

* Follow-up r107170: Moved FileBackend::concatenate() outside of doOperations() as it's own separate operation. It does not mutate storage files like the others and having it in doOperations() broke FileBackendMultiWrite. This change also makes overriding doOperationsInternal() easier (suching as using a custom batch operation storage API).
* Added sanity check to FileBackendMultiWrite constructor.
* Moved FileBackend::create() function up a bit.

In FileBackend:
* Added getFileSize()/getFileStat() functions. Refactored some functions to use the stat function for better reuse and caching/consistency.
* Refactored streamFile() to allow for subclasses to avoid local file copying with less duplication. Also make last-modified check actually work since we always get the timestamp of the original file.
* Renamed 'ignoreErrors' parameter to 'force'.
In FileBackendMultiWrite:
* Simplified how read ops are done (use 'master' backend for consistency).
* Added consistency check to doOperationsInternal() to check if the files are synced.
* Various fixes after testing.
In StreamFile:
* Split out prepareForStream() function from stream() in StreamFile for code reuse.
In FileBackendTest:
* Properly cover FileBackendMultiWrite in tests.
* Various test improvements.

Fix typo from r108342.

[Skin] Add CSS hook for action ("action-.." class on body)
* Fixes bug 4438
* Depends on r108342. See also r108343 which did a similar thing for mw.config wgAction

Previously attempted in r91871, which was reverted in r94131.

Added in OutputPage instead of Skin::getPageClasses, as this is not directly page nor skin related. It also ensures independency from skins, this CSS class should be always available so that it can be relied on by the front-end.

release notes for r108343

[mw.config] wgAction shouldn't use direct URL values
* Fixes bug 25800
* Depends on r108342

Implement MediaWiki::getPerformedAction()
* Fixes:
-- Bug 27930 - Ablity to get current action (The Right Way)

Remove action=history from submit on HistoryAction
* Not needed, and not used. Is internally converted to "view" as much as possible.
* Fixes bug 33587
* See also https://bugzilla.wikimedia.org/show_bug.cgi?id=25800#c6
* Other diff links from MediaWiki don't do this either

Re-applying change to code from r106516
* Diff in r106516 didn't show that these changes where made due to new file creation, fixed now.
* Follows-up r108339

Re-do svn copy from r106516 preserving history

Updating stat in the README

No need of $wgDBmwschema after r108060

Calls to editToken() that r103294 missed.

Profile all returns (r107319 follow-up)

Fixed name of $wgLockManagers var in DefaultSettings.php

Remove empty statement added in r108193

r102411 fixup. Close register globals vuln, and document
why is there that require_once.

Localisation updates for core and extension messages from translatewiki.net

Simplify the check to make it more understandable

Cleanup in WikiPage::getRedirectURL():
* Call Title::isValidRedirectTarget() in case of special page instead of checking only for Special:Userlogout
* Refactor the code a bit to be more readable and remove unneeded nested conditions

(follow-up r108145) Mark test as needing a database, and fix bug number in comment.

* Use WikiPage instead of Article
* Use getRedirectTarget() instead of followRedirect(); the latter may return a string, which is not wanted here
* No need to call updateRedirectOn(); getRedirectTarget() already populates the redirect table if needed

* Don't select (even twice for PHPUnit tests) "FOR UPDATE", but use the master database directly instead
* Also pass the line number
* Removed useless usage of $title when throwing the exception about invalid since that variable is always null
* Added $ignoreDuplicate parameter to ParserTest::addArticle()

Don't expand templates in html <title>. This seems to have regressed some time ago.

r108300: updated parserTest.inc tests and re-enabled testBug29408()

Dependency inject the repo/backend for proper testing rather than relying on the wiki config

r108300: also destroy the repo/backend singletons for upload test

* Fixed bogus dollar signs left in $tmpGlobals array keys in r108300.
* Various documentation cleanups.

Partially reverted bits from r108300. Not allowing underscores is too restrictive and breaks on default DB name value suggested by installer. Azure can use resolveContainerName() to enforce its extra restrictions. A new resolveWikiId() function was added to allow for it to mangle the wiki ID by translating underscores. Also restored previous size limit in isValidContainerName() since it makes sense to either go all the way lowest-common-denominator or not here (in this case not). Preserved "first char is a alphanumeric" check since it's pretty weird to have anything else.

In FileBackend/FileOp:
* Replaced 'media' portion of container names with the repo name. This makes it easy for multiple repos to use the same backend without 'wikiId' hacks. Full container names are now like <wiki>-<repo>-<zone> (or <repo>-<zone> if 'wikiId' is set to an empty string).
* Restricted isValidContainerName() more in light of Azure portability and shorted shard suffix.
* Bumped $maxCacheSize to 75 storage paths.
* Code comment cleanups and additions.
Unit tests:
* Updated related tests and marked testBug29408() as broken (I can't find the problem).
* Reduced leakage in UploadFromUrlTestSuite a bit.

Localisation updates for core and extension messages from translatewiki.net

Register the 2 new access message keys from r108262 for meintenance files

Ignore the 2 new access message keys from r108262 for translation

rv r108284 since PHP has different behaviors

should fix jenkins

Fix formatBitrate behavior on Mac OS X

Language::formatBitrate() uses log10() to makes a long number human readeable.
There is a nasty rounding error on Mac OS X for log10():

 log10(pow(10,15)) => gives 15

 floor( log10(pow(10,15)) ) => gives 14 (should be 15)

The end result is that pow(10,15) is formatted as 1,000Tbps instead of 1Pbps

log( $foo, 10) does not suffer from this:

 php -r 'print floor(log(pow(10,15),10)) ."\n";'

PHP Version used:

 $ php -v
 PHP 5.3.6 with Suhosin-Patch (cli) (built: Sep  8 2011 19:34:00)
 Copyright (c) 1997-2011 The PHP Group
 Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
     with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans
 $

TEST PLAN:

BEFORE
======

$ php phpunit.php ./languages/LanguageTest.php
PHPUnit 3.6.3 by Sebastian Bergmann.

...............................................................  63 / 170 ( 37%)
............................................................... 126 / 170 ( 74%)
.......................................F....

Time: 2 seconds, Memory: 32.25Mb

There was 1 failure:

1) LanguageTest::testFormatBitrate with data set #5 (1000000000000000, '1Pbps', '1 petabit per second')
formatBitrate('1000000000000000'): 1 petabit per second
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'1Pbps'
+'1,000Tbps'

FAILURES!
Tests: 170, Assertions: 174, Failures: 1.

AFTER
=====

PHPUnit 3.6.3 by Sebastian Bergmann.

...............................................................  63 / 170 ( 37%)
............................................................... 126 / 170 ( 74%)
............................................

Time: 1 second, Memory: 32.25Mb

OK (170 tests, 174 assertions)

minor w/s + move $title instantiation above Enotif

w/s, remove unused vars per note in bug #33537

Revert r105790 and move back view counter back to WikiPage with two modifications:
* WikiPage::$mCounter is now marked as protected
* Call WikiPage::loadPageData() from WikiPage::getCount() if the count is not set intead of loading the page_counter field only

* Added WikiPage to RequestContext and related so that it can be shared to avoid creating a new object each time and thus avoiding database queries to load the state of the object
* Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle()
* Use it WikiPage::main() to call doViewUpdates()

I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release

Couple of fname -> __method__

wl edit tooltip messages from r108262

(bug 32787) Add DB name to debug output. Based on patch by Solitarius

Add tooltip/accesskey to EditWatchlist
* Fixes bug 33565

release-notes: remove notes for r108203; adding new ones for r108230

Follow up r108248, r108141: use wfUnpack() so we don't duplicate logic. Could also pass $length for sanity, but someone else can do that

Made UnwatchArticle, UnwatchArticleComplete, WatchArticle and WatchArticleComplete pass a WikiPage object instead of Article.
There are two extensions (InterwikiIntegration and Syslog) that use these hooks and they don't Article-only methods so they won't break by this change.

XCF: suppress warning on unpack + early exit on error

follow r108141

(bug 29309) allow CSS class per tooltip (tipsy)

Let us use the new "className" upstream option to add a class per tooltip.

Partial merges of upstreams changes:
 - 602f2fe5 Per-tooltip classes
 - f5563566 Helper function for call or return idiom

Add a few @since entries

Followup r108231, remove useless _this

Followup r108184: fix loading in Opera. Before, Opera would only begin to render the document after all async scripts were loaded, now it's the other way around (scripts load after the document is ready). This is not an improvement compared to the current situation, but it's not a regression either.

* Added callback to send notices from WikiImporter and use it in ImportReporter so that it can use the context to get messages and send them to OutputPage (also removes on usage of $wgCommandLineMode)
* Early abort on invalid title in ImportReporter::reportPage() since a notice has already been sent
* Localised message saying the title is invalid

Fix broken oldParser call in r108230

Fix up r108203: just loading mw.jqueryMsg in the bottom queue, then assuming its presence in mw.Message doesn't work, see CR comments.

* Moved message parsing (including $1 replacement) to Message.prototype.parser(), and let jqueryMsg override that when loaded
** Make the Message constructor public to make this possible
** Moved logic for skipping jqueryMsg when the message is simple from mw.Message to mw.jqueryMsg, where it belongs
* Remove mw.jqueryMsg from the default modules list in OutputPage. Modules that require PLURAL/GENDER should depend on mw.jqueryMsg
* TODOs
** The jqueryMsg parser is recreated for every mw.msg() call. It should probably be cached, but the only way I can think of is to add it as a member of the Map object, which is kind of weird
** Because jqueryMsg doesn't support a 'text' mode that expands PLURAL/GENDER but doesn't output HTML (leaves e.g. links alone), mw.Message.plain() and mw.Message.parse() currently behave identically. This is wrong and should be fixed, but that needs support in jqueryMsg too

* Don't allow to import a page in the Media: namespace, this didn't work just because WikiPage::factory() throws an exception when a Title in NS_MEDIA is passed
* Added localised message when trying to import a page with an interwiki prefix

Set position => 'top' for wikibits, required to support legacy gadgets. Spotted by Niklas on TranslateWiki. Ping r107327.

Remove unneeded dependency from wikibits, and move the showtoc and hidetoc messages to mw.util where they're used

Prevent #firstHeading overriding the language specific h1 height.
Ref Bug 30809

Use mw.jqueryMsg parser for message parsing to support PLURAL and GENDER
Follow up r107556 and based on the discussions on wikitech-l about this.
mediawiki.jqueryMsg is now loaded always. mw.msg uses the parser if required.
Add qunit test cases.

Fix grammar in r108154.
Spotted by kgh https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Perfcached/en

Correction in the test comment, followup r107824

r108192: Explicitly set flags for RecursiveDirectoryIterator constructor

* Cleanup for r108175: made if easier for extensions to interact with each other in TitleReadWhitelist hook. A handler can set $whitelisted to true to whitelist the page or it can set it to false and return false (most restrictive wins).
* Added some hook doc comments.

Fixes for r106752:
* Make sure FSFileIterator::current() directly returns the string path and that it is relative to the directory being searched.
* Fixed silly bug in testGetFileList that masked any bugs.
* Added a few code comments.

Fix a race condition in classic edit toolbar setup

mediawiki.action.edit used to call mw.toolbar.init on its own during DOMReady -- this required that the module already be loaded *before* DOMReady, *and* that it be fully loaded before the immedate-execution code that sets up the default toolbar items (output from EditPage.php).
This failed since we've gone fully async in the bottom-loading items, and could result in failed calls to mw.toolbar.addButton.

Wrapped those immediate calls in a mediawiki.loader.using call to ensure they're run after the module is loaded, and moved the mw.toolbar.init call into that section so we guarantee it gets run first.

Partially reverted r108111: we can't assume subclasses put thumbnails in the...thumbnails zone. They might override the thumbnail path functions.

ResourceLoader: Add an experimental option to move the main module loading queue (the bottom queue) from the bottom of the <body> up into the <head> , while still being loaded asynchronously. This makes them load earlier, which should make the page load faster. This is the product of a long discussion on bug 27488

* Added a "blocking" state to mw.loader . When loading scripts while the document is not ready, the loader will use document.write() if blocking is true, and append to the <body> or the <head> if blocking is false. If the document is ready, the loader will always append to the <body>
* Enable blocking mode while loading the top queue, and disable it after. This ensures that modules in the top queue are still loaded in a blocking way as they were before
* If $wgResourceLoaderExperimentalAsyncLoading is true, the bottom queue is also loaded in the head, but with blocking mode disabled. Otherwise, it's loaded at the bottom of the <body> as before
* scripts-only and messages-only requests need special treatment:
** in the top queue, they can continue to use <script src="..."> tags because they are blocking
** if the bottom queue is at the bottom of the <body> (experimental async loading disabled), they can continue to use <script src="..."> tags as before
** if the bottom queue is in the <head> (experimental async loading enabled), they cannot use <script src="..."> tags, because those would block. Instead, call mw.loader.load() on the load.php URL

Make sure that if we fail to read the App13 (iptc) block of a JPG file, that that doesn't block other metadata from being read. Also makes sure if more then one app13 block is in the file, they are all read, not just the last one that appears in the file (This required some changes to tests since before the intermediate value was just one value, now its an array of all such blocks)

XCF: remove var_dump() statement

Localisation updates for core and extension messages from translatewiki.net

Per request of Aaron Schulz, follow-up r102187: added new 'TitleReadWhitelist' hook to allow extensions to bypass core (and other extensions) checks to allow an user to read the page

Per Nikerabbit, fix for r107637: added @since

Followup r107932

Check random class to be isntantiated is a subclass of DatabaseBase

Follow-up r108137: @since

Follow-up r108147. PLURAL in message.

For new 'export all' feature, cleanup whitepspace, remove redundant check, add documentation. Bug 10574y

add basic XCF pictures for testing purpose

(bug 33456) show $wgQueryCacheLimit on cached query pages, so users know that the results are artificially cut off, and its not just that there is only 1000 wanted files (or whatever else) on the wiki.

(bug 33321. Sort of) Adding a line to MediaWiki:Sidebar that contains a pipe, but doesn't
have any pipes after being transformed by MessageCache, causes exception on
all pages.

This can happen with lines like:
**{{#if:yes|Something}}

Thank you to liangent for figuring out how to escape a | without {{!}} existing and &#124; not working.