* Added $wgLanguageConverterCacheType global to control LC cache type. We can use it to enable direct apc use for language converter (to match the live hack).
Change-Id: I04616469aa53ccd1a5ce51af50a18acca5bb8bc4
* (bug 35317) CSRF in Special:Upload
Revert r56793, which removed the CSRF check for Special:Upload for normal file
uploads. Cross-site posting of file uploads without user interaction has been
possible since at least as early as Chrome 8 (late 2010) and Firefox 6 (mid
2011).
Commonist has used api.php since version 0.4.0 (April 2010), and the API
already requires an edit token, so Commonist 0.4.0+ is not affected by this
change.
* (bug 34907) Fix for CSRF vulnerability due to mw.user.tokens. Patch by Roan
Kattouw and Tim Starling.
* Filter out private modules early in ResourceLoader::makeResponse() and just
pretend they weren't specified. This means these modules cannot be loaded
through load.php . This filtering must not happen in makeModuleResponse(),
because that would break inlining.
* Force inlining of private modules in OutputPage::makeResourceLoaderLink(),
disregarding $wgResourceLoaderInlinePrivateModules
* Remove $wgResourceLoaderInlinePrivateModules
* Remove special treatment of private modules ($private) in
ResourceLoader::makeResponse() and sendResponseHeaders(), because we're not
allowing private modules to be loaded through here any more
* Remove identity checks in ResourceLoaderUserOptionsModule and
ResourceLoaderUserCSSPrefsModule, they didn't make a lot of sense before but
they're certainly useless now.
* Factored out error comment construction in ResourceLoader.php and stripped
comment terminations from exception messages. I didn't find an XSS
vulnerability but it looked scary.
Patchset2:
Removes whitespace error that prevented automatic merge by Gerrit:
includes/resourceloader/ResourceLoaderUserOptionsModule.php
Change-Id: I2dec8b8caf9db3c64919763865cc10cccdd6a1a3
So far we've still been using ./tests/qunit/index.html in TestSwarm, today I've tested locally
to submit a url to SpecialJavaScriptTest instead and made a bunch of browsers join my swarm,
quite a few problems popped up. This commit fixes those issues so that we can actually use
SpecialJavaScriptTest in TestSwarm.
* Add QUnit configuration variable for TestSwarm's inject.js
In order to use TestSwarm, the urls that TestSwarm loads in clients that has
the QUnit test suite running on it need to include a little javascript.
This inject.js registers hooks with QUnit to listen for when the test suite finishes
and contacts the parent window (TestSwarm loads the qunit test suite url in an iframe)
to submit the results. Previously I included a copy of TestSwarm's inject.js in
./tests/qunit/data and in our testrunner.js a relative link to that.
However this is currently breaking because it is an outdated version. Updating brings
no good since someone else might use their own TestSwarm would could still run on an old
version etc. The TestSwarm submitted too always expects that it's own inject.js is used,
not some snapshot copy. I've removed the copy of it in MediaWiki and instead added a
configuration option to point to wherever the you want is located.
Also, since the old static index.html version of the unit test can't retrieve PHP based
content, this means TestSwarm submissions through the old static index.html are no longer
supported. Only through the new Special:JavaScriptTest from now on. I'll probably remove
the whole index.html soon-ish as it's getting quite annoying to maintain all that by hand,
and it's been superseded in everywhere imaginable now anyway. Even not used anymore by
intergration.mediawiki.org because that's been quiet since the Git-switchover.., and when
we update it, we can update it to point to the new SpecialPage instead.
* OutputPage::allowClickjacking() on SpecialJavaScriptTest/qunit.
When initially testing the TestSwarm setup to submit SpecialJavaScriptTest/qunit urls
(instead of the old ./tests/qunit/index.html) it was failing due to an iframe DENY.
This was a bit odd since `$wgBreakFrames = false;` by default, and although
`$wgEditPageFrameOptions = 'DENY';` by default, it wasn't obvious at all that that value
("DENY") is used for all OutputPages by default (as supposed to just action=edit and the
like). This is because OutputPage has mPreventClickjacking=true by default and when it's
true-ish it uses $wgEditPageFrameOptions for the X-Frame-Options.
* 'position' => true; for the mediawiki.tests.qunit.suites module.
QUnit has a hook for "done". Which is called when QUnit.start() is called and all queued tests
have been executed. QUnit.start() is automatically called on window.onload by QUnit.
TestSwarm uses QUnit's hook system to hook into the QUnit "done" event, and at that point
takes the stats, submits them to TestSwarm and go on with the next job.
When testing locally, I got semi-random failures reporting that only 0/0 tests were
successfully ran in IE6. This is because when QUnit.start (and consequently QUnit.done)
are first called, apparently no test suites had finished downloading and/or execution yet
(the bottom queue is asynchronous, and doesn't postpone domready nor window.onload).
When normally viewing Special:JavaScriptTest/qunit this doesn't break anything, because if
QUnit start/done is in the past and another module(), test(), or equal() etc. is called it just
picks up again and adds more results to the page and calls QUnit.done() again.
However in the case of the TestSwarm embed, it submits the results after the first done() and
cleans up the iframe. So I'm making mediawiki.tests.qunit.suites a blocking module instead, so
that there will only be one QUnit.start/done and that's the one that TestSwarm gets and after
which TestSwarm can safely garbage the iframe.
This means that basically all test suite modules and the original modules they are testing will
be loaded from the head. Shouldn't have any side effects, but might cause minor breakage in
future in modules that badly assume they're being put on the bottom.
I'm not considering that a bug in the test, it'll just help catch that bad code sooner :),
it's a test suite after all.
(Yay, my first Git commit to MediaWiki core)
Change-Id: I83f83377f2183b6deb4e901af602ac9a5628558b
* Introduce $wgDebugDBTransactions facility to help
figure out what's going on with transactions.
Currently PostgreSQL only.
PostgresTransactionState can be easily be made more general
to trace all sorts of state machinery.
* Improve r113408: we don't need to full reconnect on error,
rollback is enough.
Rolling back breaks search_path, as PostgreSQL
can manage sessions settings under transaction therefore
we need to improve schema sniffing introduced in r82674
* Introduce few schema handling functions. This could
probably be generalized for other databases like DB2 and Oracle.
* Fix bug 15816 - Add a switch for SETting the search_path
We try to avoid touching search_path at all unless
really necessary. Even in this case we append MediaWiki
core schema to the front of the list.
* No longer add $wgDBmwschema to PostgreSQL role search_path
in the installer. This is no longer necessary as
setting schema on connect should ReallyWorkNow(tm).
* Get rid as much as possible of $wgDBmwschema and
bring us one step closer to fix bug 16794 (wgSharedDB
support).
All references to core MediaWiki schema in PostgreSQL
specific code should now use Database::getCoreSchema()
unless we know what we are doing.
Followup-To: r113408 r82674
Introduce a global variable which causes language conversion to not be disabled in interface messages (as before r94279). Use $wgContLang for conversion (as before r97849) since $wgContLang is set to the base language (e.g. zh) on converter wikis, whereas a typical user language (e.g. zh-tw) only has a FakeConverter.
Extension authors are supposed to be notified of deprecated code they are using that may disappear. This config variable was added so that devs who had an explicit reason to hide specific ranges of deprecation notices from MediaWiki (as opposed to all MediaWiki deprecation notices, or all php deprecation notices) not as a method of hiding notices that people are supposed to see from everyone.
Any dev who wants to should shoot themselves in the foot, that's their job. It is NOT our job to shoot everyone in the foot because some devs are too lazy to shoot themselves.
* Introduces $wgPreloadJavaScriptMwUtil
* Instead of loading mediawiki.util as base module from the bottom, now loading it from queue position "top" if $wgPreloadJavaScriptMwUtil is true. And if false it'll remain in the bottom in practice as implied by other modules loading it as a dependency (i.e. mediawiki.page.ready depends on it)
* Fixes bug 33746
This is reintroduced after a discussion with TimStarling considering the discussion about r58717.
Note that a change to the parser will be needed to cause links from <a> tags to be recorded in the externallink table.
- [Actions] -
* I am aware that eventually these classes should be more than just a few lines re-directing control to WikiPage, but I'm keeping these commits as uncontroversial as possible due to feature freeze. Refactor could be done later.
* Contributes to solution of bug 27930 - Ablity to get current action (The Right Way)
* Final goal: Get the current action without needing access to Wiki.php internals (i.e. with Action::factory in one hand and an instance of IContextSource in the other)
* Required for proper fix of r108342/108343 (currently marked FIXME)
trunk is frozen pending stabilisation so we can release MediaWiki 1.19.
Those changes introduces API changes and new SQL tables, so that sounds like
new feature we do not have time to review right now.
Please reapply changes in branches/concurrency and have code review handled
there. Once the branch has been reviewed, please hold. Once trunk is stable
enough and 1.19 got branched, you are welcome to merge the branch in trunk.
Note: we can have a Jenkins jobs setup to run the branch tests if you need.
Reverts:
r108595 r108591 r108585 r108584 108572 r108564 108560 r108559
There is no point in ignoring a deprecated function. The call really need
to be migrated OR the core function should not be deprecated if there is
any kind of valid usage.
If you really want to hide notifications, uses:
$wgDevelopmentWarnings = false;
Reverts r106993 r106946
* 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.
* 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
Changed written by Timo and reviewed by Hashar. This should be harmless.
To enable the feature:
$wgEnableJavaScriptTest = true;
Then head to:
[[Special:JavaScriptTest/qunit]]
* Refactored FileRepo::initZones() to require the specific zones; nothing was using it differently.
* Removed deleted zone check in deleteBatch(), a similar error will instead trigger with the initZones() call as needed.
* Added $wgLocalFileRepo comment.
* Updated tests.
