Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
Check the internal array of styles to determine whether
the method was inappropriately used to alter the array of styles and
if it was, call wfDeprecatedMsg().
Change-Id: I591b03c2e19d4b8cadfe220b498ae244d332f9fb
The commit did not really hard-deprecate overriding of setupSkinUserCss() as stated in the commit message, rather it removed core calls to setupSkinUserCss(), instantly breaking the many skins that still override it. It did not actually create a deprecation period for graceful migration.
As discussed in T267080, there is presently no way to hard-deprecate the override of a method.
This reverts commit 334cfeffd6.
Bug: T257990
Change-Id: I8f669ba30affc437800890c3a875994a9f2eb3c8
* Move the method to SkinFactory and replaces usages.
* Inject $wgSkipSkins into the SkinFactory
Bug: T257993
Change-Id: I9869cf34c5e87cbad963f48db0649b3b7a252a4a
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
Disabling tidy has been deprecated since 1.33. This cleans up the code
paths which still used untidy output.
Bug: T198214
Change-Id: I821ef3b8f59b272d983583d407b2f0794fe1e791
The old way of providing a callable to SkinFactory::register is
still supported. Those callables expected the skin name as their
first argument. Coincidentally, so does the constructor of Skin.
Some skins might not define any constructor parameters at all,
which is acceptable to PHP, as it will just discard the argument.
The registration using $wgValidSkinNames has not been changed,
and skins that want to define services to be injected will still
need to manually register their skin to the skin factory.
CodeSearch did not indicate any extensions or skins manually
constructing a SkinFactory in tests, but for posterity, the old
way of creating a SkinFactory for testing can be replaced with
new SkinFactory( new ObjectFactory(
$this->createMock( ContainerInterface::class )
) );
Note that the constructor for SkinFactory for internal use only,
in accordance with the Stable interface policy.
You should use MediaWikiServices::getInstance()->getSkinFactory
instead.
Bug: T244466
Change-Id: I8ba9d869bddd9b6124e47697b789d752c0620b02
Remove the deprecated Preprocessor_DOM class, which was hard-deprecated
in 1.34. This begins to simplify parser configuration and reduce redundant
code paths, but I've left two things for cleanup in a future patch:
1. The `preprocessorClass` configuration option to the parser, exposed
in `$wgParserConf`, ServiceWiring, ParserFactory, etc. There is no reason
for this to be exposed as configurable, but I've left this clean up to a
future patch.
2. The `$wgMaxGeneratedPPNodeCount` configuration, exposed also in
ParserOptions. Only Preprocessor_DOM calculated this count, and since
we are only using Preprocessor_Hash now, this configuration has no effect.
But since this value was exposed in ParserOptions and elsewhere, I've
deprecated where needed but left this clean up to a future patch.
Bug: T204945
Change-Id: I727f003f9a42d0c92bcbcce8a8289d5af6cd1298
The setting of $pageParams in that code path was assuming the page was
specified by title, breaking when it was passed a pageid.
Bug: T241362
Change-Id: Ia5b34ee392c94e5ae7693e95b58806c1dac2b24e
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
Was reverted by I549810a4cd2e424cc4a438887d2f24614a24cc00 due to
T224607.
Original change by Vedmaka Wakalaka was
Ia0d840b772ea5f20c9594ce151cc57adc270e48b.
Original commit message:
The following methods should are factored out of the User class into PermissionManager,
leaving only deprecated stubs:
- User::isAllowed -> PermissionManager::userHasRight
- User::getRights -> PermissionManager::getUserPermissions
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::getGroupPermissions -> PermissionManager::getGroupPermissions
-User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
- User::getAllRights -> PermissionManager::getAllPermissions
Depends-On: I7909e9bd6bbfbd708c0a00b861a9b22a38c6665d
Bug: T218558
Bug: T223294
Change-Id: I8899240378f636ea70f447616710516c0a3c5c31
We don't want to depend on the entire site configuration when we only
need a few specific settings.
This change additionally means that these services no longer see a live
version of the settings, but rather a copy. This means in tests you
really do have to call overrideMwServices() if you want services to pick
up your config changes.
ResourceLoader and SearchEngineConfig will need more work to port,
because they expose their member Config in a getter, and the getter is
actually used.
Parser and NamespaceInfo are also relatively complicated, so I split
them into separate patches.
Tested with 100% code coverage. \o/
Depends-On: If6534b18f6657ec1aba7327463f2661037f995b3
Change-Id: I1a3f358e8659b49de4502dc8216ecb6f35f4e02a
The addModuleScripts() methods were deprecated in 1.31 and 1.32,
these are now removed.
The getModuleScripts() are now deprecated as well, always returning
an empty array. To be removed in 1.34.
Depends on commits for bundled/wmf-deployed extensions that
remove the last few remaining callers to the deprecated functions
in: 3D, Collection, Flow, GlobalUserPage, and Wikibase.
Bug: T188689
Depends-On: If9f0bc6aef85117587fa1929f34f8861c8d80314
Depends-On: Ia8d41b97fbf6822f5f8f7ac889408acce1ac9a3a
Depends-On: I503b919739ea474ff33726815b0da55e2f7e2724
Depends-On: I236ef637fd03b810a46eb361e25067a037e9d183
Depends-On: I62e17779753b977a452cc0c9694947941e999cc3
Change-Id: I5a19b8f164ccf666485d2971202194b747f882df
This will be unsupported by future wikitext parsers, which always
construct well-formed HTML.
Bug: T198214
Change-Id: Ic189cd1b38bca5b9ec0ef9810555fe0cbd8b733d
Instead of applying wrapping the the parser and unwrapping in
ParserOutput::getText(), turn this around and apply wrapping in getText(),
and only if desired.
This avoids search&replace logic for unwrapping, and it also makes it a lot
easier to merge the output of multiple slots for MCR output.
This changes behavior in two hopefully irrelevant ways:
1) the limit report comments will be inside the wrapper div, instead of
following it.
2) if HTML with a wrapper div is explicitly injected into a ParserOutput
object, it will not be possible to unwrap the text.
Bug: T174035
Change-Id: I1641b7995af9bd297f1acd610d583fbf874f34e0
Also removed a sketchy-looking usage of ?: with a string in
ApiParse.php. In this case I think it was fine, because it would only
cause a bug if a page's display title was '0' but its actual title was
not '0', which is only possible if $wgRestrictDisplayTitle is false,
which is broken by design anyway and I don't think is worth testing.
But ?: used for something that should be interpreted as a string is
generally not a good idea.
One bug fixed: an error message that used an undefined variable.
Depends-On: Id0e6184aff8f9d7e8f32558e1de14faa0168cc1d
Change-Id: I0904bff0f9d80892d0db2ebb590c24fb862f2418
Follows-up 90c95fc7f2, which included result of Skin::getDefaultModules
in the prop=modules list. All hardcoded modules in OutputPage and Parser
were also subsequently moved into Skin::getDefaultModules.
However, a number of modules cannot be moved there because fundamentally
Skin::getDefaultModules can only load modules via OutputPage::addModules().
For style modules, addModuleStyles() must be used.
Fortunately, there is already a centralised place for that, namely
Skin::setupSkinUserCss(). Include that in the ApiParse return as well.
That should resolve the last bit of inconsistency between ApiParse
and OutputPage when it comes to the module queue.
Bug: T140664
Change-Id: I35e2e3bbdccdd1aa2a259b8e624daa80c609ba8c
Now that ParserOptions->isSafeToCache() exists, use it where necessary.
This also moves the use inside the makeParserOptions() method so other
callers can pick it up as well.
Then pass the flag as $forceParse into WikiPage::getParserOutput()
instead of duplicating the logic in several cases, and generally clean
up the logic in the module to let WikiPage decide when to use the cache
in more cases.
Change-Id: I0079e10a40997e4a3b59ac21ef6c92246a147736
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
All tests based on APITestCase can be slow. I've also seen more than one
Jenkins failure due to GlobalTest::testMerge timing out.
Also, added a meta-test on APITestCase to make sure that all its
subclasses are marked with @group medium or @group large, to prevent new
tests from re-causing the bug.
Change-Id: I48630736a3d06574876fd1fa3d90899cfbc48012
Changeset Iec98e472 changed the behavior of action=parse&page=... when
passed a page that does not exist: previously, it would return a
"missingtitle" error instead of assuming an empty page. As some people
had been depending on this old behavior, restore the error checking.
Change-Id: I4c76ce458ceb01e233c6074cd9251879013ec143
