For addScriptFile(), just remove the appending of wgStyleVersion.
Going forward, anyone still using this, should simply append a query
parameter themselves in a way that is specific to that one url
(instead of relying on a generic global variable). Alternatively, one
could use OutputPage::transformResourcePath if the file is in /w/.
For addStyles(), also remove the appending of wgStyleVersion. Since this
method takes paths relative to /w/skins, we can easily update this to
automatically use transformResourcePath(), so that file-hash based query
parameters are automatically added.
Test Plan:
* Add calls to top of OutputPage::output():
`$this->addStyle( 'Vector/README.md' );`
`$this->addScriptFile( "{$GLOBALS['wgScriptPath']}/composer.json" );`
* Before, they are both inserted as `<link>` (head) and `<script>` (body)
with a query parameter based on wgStyleVersion.
* After, the `<script>` (end of body) has no query.
After, the stylesheet (head) has a SHA1 content hash as query.
Bug: T181318
Change-Id: Ie5ab5066ef7d07279086bde838d7305e9e4eabaf
Test Plan:
* Add calls `$this->addScriptFile( 'example.js' )` and
`$this->addScriptFile( '/example.js' )` to top of OutputPage::output().
* Without this change, two `<script>` are added.
* With this change, only for the latter a script is added,
and the former triggers a deprecation warning.
Bug: T71277
Bug: T181318
Change-Id: I0576ef09fafa4ba34d52d75f4211fcfa28f4f3b0
This effectively applies safemode to the mw.loader client,
without the client itself needing specific knowledge of safemode.
Test Plan:
* Unchanged: When viewing a page in safemode, the 'user' and
'site' modules are still not queued by OutputPage.
* New: mw.loader.getState('site'), previously would yield
'registered', but will now yield null.
* New: mw.loader.load('site'), previously loaded the module,
it now logs a dependency warning for unknown module, like for
any other unknown module.
* New: mw.loader.using('site'), previously resolved, it is now
rejected.
Bug: T185303
Change-Id: I672e3891c8e1b3c2d13655fa134d0f1d031b8247
Follows-up 70941efd35 which broke various public
signatures of the ClientHtml class that I'd prefer to handle
differently.
This commit mainly restores support for all previously public
signatures, and either removes the need for a parameter, or moves
it to the end of the original signature (as optional param).
* ClientHtml::getHeadHtml: Remove the positional/required parameter
that was added. Restoring the method to being a stateless computer
that requires no parameters. Pass the option via construct instead.
* ClientHtml::makeLoad:
- Make $nonce optional.
- Restore $extraQuery as optional.
* ResourceLoader::makeInlineScript: Document $nonce as optional
(matching the implementation).
Change-Id: Iaf33f2a060048e6606fba8d875b6d2953b21ef45
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
And the counter-part in ParserOutput as well.
This follows-up on 80e5b160e0, which removed the last use of this
method. It also deprecated ResourceLoaderClientHtml::setModuleScripts()
but that isn't usually used directly. The public interfaces are
mainly in OutputPage/ParserOutput, which are now deprecated as well.
Bug: T188689
Change-Id: I90baafdfc089ac03c4c3abc12065c0b60d43994e
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
There has long been a hack for previewing edits to user JS/CSS, where
OutputPage would pass an 'excludepage' parameter to
ResourceLoaderUserModule to tell it not to load one particular page and
would instead embed that page statically. That's nice, but there are
other places where we could use the same thing.
This patch generalizes it:
* DerivativeResourceLoaderContext may now contain a callback for mapping
titles to replacement Content objects.
* ResourceLoaderWikiModule::getContent() uses the overrides, and
requests embedding when they're used. All subclasses in Gerrit should
pick it up automatically.
* OutputPage gains methods for callers to add to the override mapping,
which it passes on to RL. It loses a bunch of the special casing it
had for the 'user' and 'user.styles' modules.
* EditPage sets the overrides on OutputPage when doing the preview, as
does ApiParse for prop=headhtml. TemplateSandbox does too in I83fa0856.
* OutputPage::userCanPreview() gets less specific to editing user CSS
and JS, since RL now handles the embedding based on the actual
modules' dependencies and EditPage only requests it on preview.
ApiParse also gets a new hook to support TemplateSandbox's API
integration (used in I83fa0856).
Bug: T112474
Change-Id: Ib9d2ce42931c1de8372e231314a1f672d7e2ac0e
The siteinfo API response's 'writeapi' value is now hard-set to true,
as are the ResourceLoader variables wgEnableAPI and wgEnableWriteAPI,
to be deprecated later.
Bug: T115414
Change-Id: I54ff9428b247ba203d67aba079149393f323d5a9
In preparation for passing down 'safemode' from OutputPage.
Only used in one place in Wikimedia Git: OutputPage::getRlClient().
Bug: T185303
Change-Id: If01eca96986ff8d7dcdaab6910bf183ba7c7311f
This also removes all the in-core calls that had been kept for the
benefit of extensions, and causes them to not have any effect since
anything that had been calling them was already either a no-op or will
probably be broken now that nothing in core is setting or checking the
flags.
Change-Id: Id22c1a5a6d6a249debb14063ae3f8838d105b634
Eighteen uses of readOnlyPage and three of addExtensionStyle; all
have fixes awaiting merge. Marking as dependent on the only one
in a Wikimedia-deployed extension.
Depends-On: Ib3ea649bc68dd0edc025133721b46996d1e8901f
Change-Id: I636ebc7dead55f1ae654a13d3b6ebb023ecfe8e1
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
For browsers that support older versions of the Referrer Policy
specification (Edge and Safari), using a value from a newer version of
the specification will result in those browsers falling back to a
default of "default".
So allow $wgReferrerPolicy to have fallbacks if the browser does not
recognize the currently set value. It will emit <meta> tags for each
value in the array, but in reverse order, as browsers will use the last
one that they recognize.
Bug: T180921
Change-Id: Ie0f523fc6937c9ecffc8a6fc791c6b54d5a1cb06
We still set the state in many cases for benefit of extensions, but all
calls within core should no longer be using non-default state.
Change-Id: I78b62ec33fcb8273acb9b3b4e9012215442be94c
Depends-On: I140ff32373430b61b92226689ef9b58cca317450
The only known callers were using it to call ->setEditSections( false ),
which has been the default since MediaWiki 1.19.
Change-Id: Ib021d7e80e44782ba6ebe66cf8366bae9147ce00
Depends-On: I7de0102e6cac6b5aa0147b825fa2cb6ebd37b434
Depends-On: I7b0604773a8692c7cb37fffa3fcb8aaac83d81ba
Renamed and deprecated in MediaWiki in f606fd8d since 1.27.
Only six uses in Wikimedia-hosted git repositories, marked as
dependencies. Also one use snuck back into MediaWiki itself,
fixed in this patch.
Depends-On: Ie8c13a6b1dc1b7861f6c27bbba996099375f066b
Depends-On: Ic2ea90343efda6533c06ca1325bc85d9aa776078
Depends-On: Ibba2f486f0ecb684ded7efb09f9942f5e0f5fd7a
Depends-On: Id27a48e10fd127e00f68e1020e8f40e30ba9a251
Depends-On: Ifd6db7910a71bb700484d6b588327424f11c00e0
Depends-On: I6523059941eb5f86274e364a8d5cc74b849655a4
Change-Id: I2cdfcd60fc7934830e3e6ec132958aa2aa1fe486
SVGs could already be used through $wgLogo. However, if a PNG fallback
is desired for older browsers, using SVGs was previously not possible.
This commit adds support for using an SVG image in $wgLogoHD and,
using $wgLogo as the fallback image.
Usage example:
> $wgLogo = '/path/to/png';
> $wgLogoHD = [
> 'svg' => 'path/to/svg',
> ];
Note: When the 'svg' key is set in $wgLogoHD, any '1.5x' and '2x' keys will
no longer be used because SVGs can render optimally on any screen sizes.
@Reedy, @Krinkle and @Brion VIBBER helped me alot with this.
Bug: T86229
Change-Id: I6197d96ce9110f4711ef2c4b198445bc5c6ae110
Make it impossible to instantiate this class without passing it
context. This appears to be the oldest wfDeprecated() in MediaWiki.
All callers have been updated.
Change-Id: I00b9e283ad22c6274b358063b9f9e60fe93d5ee7
This lets us take advantage of ResourceLoader's on the fly minification
rather than needing to ship a minified copy, which is problematic for
other distributions like Debian.
Because the startup module excludes raw modules, it is not possible to
load or depend upon this module, and trying to use
`mw.loader.load('html5shiv')` for example will throw an exception.
This follows-up 3a30e03645.
Change-Id: I635e224fb043c614c4918771c7c8f836575c683b
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
There's currently no way to get, e.g., all categories except the
hidden ones just as text. The OutputPage::getCategories() method
always returns all categories as an array of strings (titles) and
the getCategoryLinks() method returns the result of Linker::link
but with the distinction between "normal" and "hidden" categories.
This change adds a new parameter to OutputPage::getCategories(),
$type, which can be used to define, what categories should be
returned. The default value is "all", which means, that all categories
are returned (the current result of the method). With the value
"normal" and "hidden", the method will return the respective values.
This could be used in I97d7de723fe72da26c7dbde0a559a13704c7099a to
remove the stupid Linker::link() and isset workaround.
Change-Id: Iadda9ae362a21fbee770240234b8f55326219932
This change resulted in unreasonable feature loss (human-readable
limit report was gone). Three months and multiple followups later,
the functionality is still not completely restored. Given lack
of response from the original author, I think it is time to revert
and reconsider, especially since the 1.28 release is soon.
A machine-readable limit report would be a very useful feature,
but not at the cost of losing human-readable limit report.
This reverts the following commits:
* Move NewPP limit report HTML comments to JS variables
b7c4c8717f
* Only pretty-print the parser report JS vars
28adc4d7ee
* Show wgPageParseReport on page previews too
1255654ed5
* Re-add human readable parser limit report
0051f108b9
* Restore hooks.txt for ParserLimitReportFormat
4663e7a737
Resolved minor merge conflicts in OutputPage (with 80e5b160)
and release notes.
Bug: T110763
Bug: T142210
Change-Id: Id88c8066fae3f369e8977b4b7488f67071bdeeb7
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
This makes frequently changed pages be less likely to be
seen in stale forms if purges are delayed or lost. Pages
that have not been edited for somewhat longer than the
nominal CDN cache TTL will retain the nominal TTL.
Category pages will adapt based on page_touched rather
than the last revision, given the possibility of constaintly
changing membership. With their lesser overall usage,
this is less risky than for Article, and also more useful.
Change-Id: If621aca2fb68e9f87a50c891dac8dc6ec7641f5c
* Remove filter between $moduleStyles and preloadTitleInfo().
Previously, this was filtering out wiki modules created by
gadgets and extensions. Still causing a couple of direct queries
from getTitleInfo().
* Store __METHOD__ in $fname outside getWithSetCallback.
This way queries are logged as either getTitleInfo or preloadTitleInfo.
This regressed in 0852a000a5, after which the latter was logged
as "::{closure}".
Change-Id: I454e43f43f8ad3270b86f4cfdbd68192c305cc07
This mostly reverts commit 1255654ed5.
This re-adds the human readable parser limit report, and makes a few
adjustments necessary for it to work properly.
* In EditPage::getPreviewLimitReport(), only generate the HTML report,
the JS variable will be added by OutputPage
* If there are multiple calls to OutputPage::addParserOutputMetadata(),
only use the limit report data from the first one.
* Only add the wgPageParseReport variable if limit report data is
available.
Bug: T142210
Change-Id: Iad2646acde79b8a59710bb9fd5fbbfea5a39c341
