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
The Config interface (and it's implementation(s)) was never thought
to be an access method for objects saved in the global state, even
if it works with the current implementation GlobalVarConfig.
Imagine, that MediaWiki core switches to another file-based configuratiion
storage or a a database based one, we wouldn't be able to provide
access to global objects anymore, without weird hacks in the new
config-backend implementation or serializing objects to store in
the database or something else. This all isn't the idea with the Config
interface, as far as I know, so don't use it at all.
This commit changes the access to wgContLang to use the global keyword,
instead of accessing it through Config.
Follow up: Ice4f40911c3761c2542430935bc1898bc4e7a4d4
Follow up: I46f376a82205a5c99b98c9e971f9e9d7868ce9fb
Change-Id: I7a08b3bb649898abd445317a523051b07420b211
It's primarily meant for nullable timestamps in the database.
And for the mere purpose of an is_null() check, it's more confusion
than useful to cause this function since in these two cases its return
value is not used as-is but further conditionalized.
* Also fix fragile link between getRegistration()'s false return
value never being passed to wfTimestamp (to mean "now") because
of the isLoggedIn() guard. The ternary would now make those
follow the 'else' branch toward null.
Change-Id: I9a1ee2a56e1767bfb750e27b1f37bdaeb5e6378d
On pages where the 'user' module is filtered out (e.g.
on Special:Preferences) it would export state 'loading' (or state
'ready') eventhough the actual call to makeResourceLoader() later
in getBottomScripts() would be a no-op due to filtering.
This would cause either an indefinite state of "loading" or a
state "ready" that wasn't true.
This restores status quo as it was before 80e5b160 and 3e7a50d5f.
Test plan:
* Logged-in with non-empty user page common.js.
* View Special:Preferences.
* Verify in <head> source code, or via mw.loader.getState('user')
that it has state "registered" (the default initial state) and
not state "loading" or "ready".
Change-Id: I9b360d7e12703bddb80793aef47296fd63032c3d
* Use OutputPage::output() as the method to mask latency, since it
takes a good while to run. By the time it runs, cache replication
should have caught up, so the reap call will likely not block.
* For redirects emitted after changes in POST, instead of masking
with OutputPage, add a parameter to the redirect and block on
the positions appearing. This uses the redirection RTT to mask
the replication latency.
Change-Id: Ib23690c302e8033610fef9a0ef451dafe8a5803e
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
Follows-up 80e5b160e0, which had to move this call out of the
headElement() and buildCssLinks() methods as it was no longer
allowed to modify the module queue after it was created.
It was moved to OutputPage::output(), right before Skin::outputPage()
is called, which ends up calling headElement().
The point in time was effectively unchanged for page views.
However for the caller in ApiParse() this meant setupSkinUserCss()
no longer got called at all as it never calls output(), but instead
calls headElement() directly.
Move it to getRlClient(), which is where we set all other
OutputPage-specific things relating to module loading already.
* For page views this has no impact.
* For ApiParse it means headElement(), which calls getRlClient(),
will once again include skin stylesheets.
Bug: T144301
Change-Id: I5fd4a27fb2d70b98ce9161dc050788d8ac364110
Before 93ed259cf and 7bb7315d4, 'site' and 'site.styles' module were one module
loaded in two parts. One part via the general queue (not in a separate request),
and the other part in the stylesheet queue (in a separate request).
This was achieved by hacking the stylesheet queue handler to hardcode the group
to be 'site' for a module named 'site' (later 'site.styles' in c20a76ee)
eventhough the module as a whole was not actually in that group.
Now that these modules are separated, this hack is no longer needed
and the module can be registered as being in group 'site' properly.
Change-Id: If193f556be211749b115f3808ee46536b578fb22
