For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
Reenable MediaWiki.WhiteSpace.SpaceBeforeClassBrace.NoSpaceBeforeBrace,
because the mentioned bug is fixed
Bug: T172933
Change-Id: I1593bdba2295ebed401b921f2beabed69dba7638
includes/resourceloader/ResourceLoaderOOUIModule.php
* New trait centralizing some logic for dealing with OOjs UI themes,
previously duplicated in OutputPage, ResourcesOOUI.php and
ResourceLoaderOOUIImageModule.
* Follow-up change I74362f0fc215b26f1f104ce7bdbbac1e106736ad uses this
as a base to allow skins/extensions to define new OOjs UI themes.
resources/Resources.php
resources/ResourcesOOUI.php
includes/resourceloader/ResourceLoader.php
* OOjs UI resource module definitions are moved back to their rightly
place in Resources.php. They are again (almost) normal and static.
* Theme-specific logic is now handled by the module code, definitions
only specify 'themeScripts'/'themeStyles'/'themeImages'.
* ResourcesOOUI.php is deleted and no longer loaded by ResourceLoader.
includes/resourceloader/ResourceLoaderOOUIFileModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Glue code previously existing in ResourcesOOUI.php now lives here.
* Use the ResourceLoaderOOUIModule trait to avoid code duplication.
Change-Id: I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc
Regardless of whether other modules exist with group=user or group=site,
these two modules in particular must always be in their own request for
legacy reasons.
This has already always been the case because even in the few cases where
an extension uses this group (eg. MobileFrontend's custom site module) it
would load it instead of another module in that group, never at the same
time. There is one notable exception, which is GlobalCssJs. However the
ext.globalCssJs.user.styles module is usually served from another wiki
which is why that went unnoticed as well. This commit fixes that so that
even if you're viewing a page on the central wiki, the modules are still
in separate requests.
Aside from this one existing edge case, there is also need to add
group=site to gadgets by default so that they load after the DynamicStyles
marker instead of before, which is currently causing problems with the
cascading order (gadget apply before core and skin styles due to being
in the same request group and alphabetically sorting before them).
Semantically, the appropiate solution is group=site, but this wasn't
possible due to core putting "all" group=site modules in the same request
(under the assumption there is only one such module). This commit removes
that fragile assumption.
Bug: T147667
Change-Id: I9eb725c083124d22a9af3bf3d075ade6f3b970a3
This was the only addModules() call ever to be inside Parser.
Introduced in a54ef1a203. Prior to that, mediawiki.toc had always been loaded
by OutputPage (via mediawiki.util; and before that, via wikibits).
This patch restores that, and also fixes T130632 by making OutputPage get
it from the Skin, instead of hardcoding this somewhere in addParserOutput().
* Remove deprecated method OutputPage::enableTOC().
* Move mEnableTOC to addParserOutputText().
Bug: T130632
Change-Id: Iaad84d241a4c4348c712ac1087a664b8c9c46da4
These modules should not be hardcoded in OutputPage::output() which
makes them impossible to override and also very hard to retrieve
through the API for action=parse. Move these instead to Skin which
is where all other default module loading happens already.
Moving these modules is in preparation for customising ApiParse
to support "really" returning all would-be loaded modules on a page
when setting 'useskin', which is also needed for Live Preview
and in theory for ajax navigation and other scenarios where there
is a delay between the "initial" page rendering, and a later re-render
which may not have all all the necessary modules.
Bug: T130632
Change-Id: Ic4afccf0cd0d428d7fbc36d4e747415af3ab49f5
This is equivalent to the existing variable wgIsProbablyEditable and in
keeping with wgRelevantPageName/wgRelevantArticleId; this is done as an
alternative to making a breaking change to the semantics of the former,
as that might cause issues for users who expect wgIsProbablyEditable to
return true on [[Foo]], but false on [[Special:Move/Foo]] and similar.
Change-Id: I6c6ca1cfd93e7be917952980f1e1d57aec3a1292
Follows-up 5f55e9c9c2.
If the logo url is from within /w, then ResourceLoaderSkinModule
will (as it should) apply a file hash query to it.
The preloader didn't do that, so it specified the wrong url.
Refactored SkinModule to make this logic re-usable.
Bug: T100999
Change-Id: I1ba11f7c70d1a725ad72754fee4a3f33c2a4c1be
This greatly increases the priority of loading
the logo on browsers that support rel="preload".
Bug: T100999
Change-Id: I0738fcc0a575153dab65016fa87faaa9b8b97a9d
Directly redirecting based on a url paramter might potentially
be used in a phishing attack to confuse users.
Bug: T109140
Bug: T122209
Change-Id: I6c604439320fa876719933cc7f3a3ff04fb1a6ad
System messages may take parameters from untrusted sources. This
may include taking parameters from urls given by unauthenticated
users even if the wiki is a read-only wiki. Allowing <html> tags
in such a context seems like an accident waiting to happen.
Bug: T156184
Change-Id: I661f482986d319cf41da1d3e7b20a0f028a42e90
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Updated tests to reflect this use case. Currently we assume all web-accessible
paths within ResourceBasePath (e.g "/w") to exist on disk at the same path
in $IP (e.g. "/var/www/mw").
While in theory any number of web server rewrites or aliases could exist,
there is one case in particular that we should support since the information
is available in the configuration: UploadDir and UploadPath. This path may
be rewritten in a way that varies by wiki in multi-wiki installs that share
the same source code. E.g. a server may rewrite "/w/images" to somewhere
else, which means it will not match the directory on disk that is shared
between wikis.
Bug: T155146
Change-Id: I320478c9c262cc012f08b585b48d290594ec2420
transformResourcePath is only supposed to be called with something
that starts with a '/' (absolute path from document root).
While the primary caller (CSSMin) only calls this method if the path
makes sense as a local file path, ResourceLoaderSkinModule did not,
and wgLogo may be set to a full url that includes a domain.
While chance made it so that protocol-including urls were already
discarded, protocol-relative urls were mistaken for being a path
inside the file system root with a duplicate slash (e.g.
'//tmp/foo.txt', as 'foo.txt' in /fmp, instead of '/foo.txt' at
http://tmp).
This should be fixed upstream in the wikimedia/relpath library,
but workaround it for now since it really shouldn't be called
with urls in the first place.
Bug: T155310
Change-Id: I9b063f1219ddeca5cc2c8a48832cdf8c9eaffe58
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
