These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
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
When creating a link with Skin::makeLink and specifying the
link-class option, makeLink blindly assumes the class attribute
it is given to be a string and will concat the value of link-class
to it, even when it is an array. PHP's type juggling will coerce
the array into a string and throw a notice.
Reproducable test case:
$link = [
'text' => 'Link text',
'href' => 'example.com',
'class' => [ 'class1', 'class2' ]
];
$options = [
'link-class' => 'link-class'
];
$skin->makeLink( 'test', $link, $options );
Change-Id: I6381e3e8893e4992dbed33c88674a5cf4367314f
* Skin::getAllowedSkins
* Skin::getSkinNames
Both are hard-deprecated and their equivalents in
SkinFactory should be used instead.
Bug: T257993
Depends-On: Ib8e4ec28f6755abec7e33476efefa78dcc2c6b78
Depends-On: Icc945ce1e3287a3b25152702818e5b2a90232677
Change-Id: I9595248ae5410361a5db50d1b95df1e513ac5a2c
* Move the method to SkinFactory and replaces usages.
* Inject $wgSkipSkins into the SkinFactory
Bug: T257993
Change-Id: I9869cf34c5e87cbad963f48db0649b3b7a252a4a
Skins can now specify responsive in the skin option, which will add
a meta tag with the value width=device-width, initial-scale=1.0,
user-scalable=yes, minimum-scale=0.25, maximum-scale=5.0.
If responsiveness is not constant, but based on, for example, a
user preference, then skins can override isResponsive to indicate
when the skin is responsive.
When enabled, it will also add the skin--responsive class to <body>.
Bug: T258290
Change-Id: I6e69b482cdbc49c09adc6f7cee54f5e17b7c92c4
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
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
This isn't a default setting or fallback, it's unconditional
business logic that can't be overidden. This doesn't need to
run on every web request in Setup.php.
Bug: T189966
Change-Id: I708131b111cd2ff0e34c3cc8a4b933eff260b3da
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
This optimisation attempts to minimise loading the styles in places
they are not needed.
The logic is kept inside Skin::getDefaultModules to avoid fragmentation
of where modules get defined.
Update ApiParse to avoid repetition of code.
Bug: T42792
Bug: T42812
Change-Id: I59f02a7bab3baa9d43f6bc2ef1f549d9d31d8456
