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
Anon users have predictable edit tokens, hence someone could
force an anon to execute arbitrary CSS by means of a CSRF.
Bug: T133147
Change-Id: I442b2b46cadb967aaa1f35648eff183fc7eaa475
Follows-up 80e5b160e which moved queue formatting out of OutputPage into a
a separate ResourceLoaderClientHtml class.
The special handling for 'user' and 'user.styles' modules, and the exempt
module groups was kept in OutputPage. However the handling for it was
hardcoded for the modules in that group by default. It did not account for
modules with a group of 'user' loaded by an extension (e.g. GlobalCssJs).
GlobalCssJs modules were wrongly loaded in the regular style queue
(still in a separate request group, but not in the right cascading order
below the DynamicSyles marker).
This commit generalises the handling previously put in buildExemptModules
and moves it to getRlClient() so that it may apply to all style modules.
This commit should be a no-op besides the moving of any <link rel=stylesheet>
for non-core modules in group 'site' or 'user' now being one line lower
in the <head> HTML (after the DynamicStyles marker).
Bug: T143357
Change-Id: I1d6ea10b42293acfc535578172ad7ab2369f6299
Follows-up 80e5b160e, which moved filter logic to getRlClient()
so that ResourceLoaderClientHtml doesn't have to deal with this.
While that worked fine for most modules (including 'site'),
it no longer applied the filter for exempt/hardcoded modules
(such as 'site.styles' and 'startup').
Bug: T143066
Change-Id: Iec924003873bc47484a0dc2f1a215f87aa4afdfb
HTML formatting of the queue was distributed over several OutputPage methods.
Each method demanding a snippet of HTML by calling makeResourceLoaderLink()
with a limited amount of information. As such, makeResourceLoaderLink() was
unable to provide the client with the proper state information.
Centralising it also allows it to better reduce duplication in HTML output
and maintain a more accurate state.
Problems fixed by centralising:
1. The 'user' module is special (due to per-user 'version' and 'user' params).
It is manually requested via script-src. To avoid a separate (and wrong)
request from something that requires it, we set state=loading directly.
However, because the module is in the bottom, the old HTML formatter could
only put state=loading in the bottom also. This sometimes caused a wrong
request to be fired for modules=user if something in the top queue
triggered a requirement for it.
2. Since a464d1d4 (T87871) we track states of page-style modules, with purpose
of allowing dependencies on style modules without risking duplicate loading
on pages where the styles are loaded already. This didn't work, because the
state information about page-style modules is output near the stylesheet,
which is after the script tag with mw.loader.load(). That runs first, and
mw.loader would still make a duplicate request before it learns the state.
Changes:
* Document reasons for style/script tag order in getHeadHtml (per 09537e83).
* Pass $type from getModuleStyles() to getAllowedModules(). This wasn't needed
before since a duplicate check in makeResourceLoaderLink() verified the
origin a second time.
* Declare explicit position 'top' on 'user.options' and 'user.tokens' module.
Previously, OutputPage hardcoded them in the top. The new formatter doesn't.
* Remove getHeadScripts().
* Remove getInlineHeadScripts().
* Remove getExternalHeadScripts().
* Remove buildCssLinks().
* Remove getScriptsForBottomQueue().
* Change where Skin::setupSkinUserCss() is called. This methods lets the skin
add modules to the queue. Previously it was called from buildCssLinks(),
via headElement(), via prepareQuickTemplate(), via OutputPage::output().
It's now in OutputPage::output() directly (slightly earlier). This is needed
because prepareQuickTemplate() calls bottomScripts() before headElement().
And bottomScript() would lazy-initialise the queue and lock it before
setupSkinUserCss() is called from headElement().
This makes execution order more predictable instead of being dependent on
the arbitrary order of data extraction in prepareQuickTemplate (which varies
from one skin to another).
* Compute isUserModulePreview() and isKnownEmpty() for the 'user' module early
on so. This avoids wrongful loading and fixes problem 1.
Effective changes in output:
* mw.loader.state() is now before mw.loader.load(). This fixes problem 2.
* mw.loader.state() now sets 'user.options' and 'user.tokens' to "loading".
* mw.loader.state() now sets 'user' (as "loading" or "ready"). Fixes problem 1.
* The <script async src> tag for 'startup' changed position (slightly).
Previously it was after all inline scripts and stylesheets. It's still after
all inline scripts and after most stylesheets, but before any user styles.
Since the queue is now formatted outside OutputPage, it can't inject the
meta-ResourceLoaderDynamicStyles tag and user-stylesheet hack in the middle
of existing output. This shouldn't have any noticable impact.
Bug: T87871
Change-Id: I605b8cd1e1fc009b4662a0edbc54d09dd65ee1df
Also make EditPage::getPreviewLimitReport return the same
output instead of using copy-pasted code from the old hook.
Bug: T142210
Bug: T142214
Change-Id: I16c3c2da067fd24bf7ae564cb1d61beaa3be58c1
Fixes addModuleStyles() violation from T92459 (a464d1d41).
Similar to 93ed259cf and Id2342454b for the 'site' module.
Doesn't need to be in separate commits since per-user HTML isn't
cached the same way.
Bug: T92459
Bug: T108590
Change-Id: I195f67d061de1306c97413aada7919e9f1b1d12c
* Instead of having messy code to create a hidden HTML
comment of English strings at the bottom of the page,
expose the structured data of the parse information
to JS so tools can use it.
* Make makeConfigSetScript() use pretty output so these
variables are also easy to read in "view source".
* Remove ParserLimitReportFormat hook, since the data
is not formatted to HTML anymore.
Bug: T110763
Change-Id: I2783c46c6d80f828f9ecf5e71fc8f35910454582
Right now OutputPage requires head items to have a name when using
the addHeadItem() method.
This in contrary to most of the helper methods, which don't require
a name. ParserOutput::addHeadItem() also doesn't require a name.
Since the existing signature isn't easily changed without adding
confusion, add a separate method that allow numerical indexes
to be pushed.
This ability was already exposed via addParserOutputMetadata()
and its array_merge. This method exposes it directly.
Change-Id: I433afd124b57526caa13a540cda48ba2b99a9bde
No uses of 'modulemessages', getModuleMessages() or addModuleMessages()
anywhere in Wikimedia Git.
Change-Id: I59420880f3545d1aabf9bcbea1e34b1475697d26
We originally imagined rolling out the display of empty elements
simultaneously with the Html5Depurate, but now we have added support for
marking empty elements to Html5Depurate and plan on having some sort of
longer migration period. So, move the relevant CSS to content.css, and
remove the concept of CSS dependant on tidy driver.
Add a body class which will allow the effect to be toggled in a gadget or
extension. Actual toggling in the CSS will be in the stage 2 patch, to be
deployed after the varnish cache and parser cache have expired.
I originally imagined that there would be a gadget that overrides the
rule with an !important selector, but that method does not allow you to
recover the original display property, which is often overridden by the
style attribute or site CSS to be "inline".
Also, in RaggettWrapper, switch to the new class mw-empty-elt, following
Html5Depurate, instead of mw-empty-li. The old class will be removed in
the stage 2 patch.
Change-Id: Ic0f432c43a006629ca5a1a7c2dda3552ceb4dc4f
This allows dynamically loaded modules to depend on page-style modules
without it causing the page-style module to be loaded a second time.
* New method Module::getType() indicates whether a module is
a page-style module or supposed to be dynamically loaded.
* Emit warning from addModuleStyles() when given a module that is
not a page-style module (to be enforced later)
Bug: T92459
Bug: T87871
Change-Id: I8b6c6a10d965e73965f877c42e995d04202524f3
Right now, getInlineHeadScripts(), buildCssLinks() and getExternalHeadScripts()
all return WrappedString::join(). But because they don't know about each other
and because they need to return strings (not arrays), headElement() has no way
of merging them.
WrappedStringList allows this array to be kept, whilst still being backward-compatible
with code that calls these methods and assumig a string (since it will lazy-join
the array if the object is treated like a string).
To be used by I8b6c6a10d965e7396. Output is not changed in this commit.
Merely refactoring.
Change-Id: Iae08345473bd93cc0948d51b62c48aeb1ea460a3
Follows-up:
* 8ff36ebd (r9793) Set ETag header on article views.
* 8167b89e (r16205) Add $wgUseETag, false by default (broke Squid; T9098).
ETag is a useful alternative for If-Modified-Since (see T33639, T49529 about
use cases and bugs it may fix). However the current incomplete implementation
isn't useful.
It's a feature flag that has been disabled since 2006. Enabling it stores
ParserCache::getETag in OutputPage and sends it out as a response header.
It's ignored on incoming requests. We don't check If-None-Match for
'304 Not Modified' anywhere.
ResourceLoader has a working implementation that could be leveraged.
To be re-evaluated in the future. ParserCache::getETag() could use
improvement as well.
Change-Id: I37fd9d0ce1ce9bffb79243c6ae340403fdfd769f
Follows-up 93ed259 which changed the module to be 'site.styles', but
the override was still looking for a module called 'site' (which isn't
listed in that queue anymore).
Bug: T138586
Change-Id: I3052a2e378f804d0d4d117f8ed446fe9b4b59f99
This is with T92459 in mind to simplify the process of splitting
the 'user' module for the styles-only queue.
Consequences:
* Cached HTML isn't relevant in practice since there is no caching for logged-in
users and this module is only for logged-in users. Even then, cached HTML will
work and may happen as browsers re-use HTML responses when revisiting a
privately cached page (after 304 Not Modified).
Note that OutputPage (via isKnownEmpty) only actually tries to load 'user.groups'
if the wiki has 'MediaWiki:Group-*.{js,css}' pages for the current user's groups.
- Old style queue request will continue to ask for user.groups which is now a
FileModule with no styles (simply concats the empty string to the bundle)
- Old load() request will resolve with an empty function.
* The are no known dependants of 'user.groups'. If there are, they will work
by proxy of it now being an empty module that just ensures 'user' is loaded.
* The security origin of 'user.groups' was USER_SITEWIDE. The origin of 'user'
is lower (USER_INDIVIDUAL). Pages that are restricted to USER_SITEWIDE
previously received user.groups, but won't anymore. This should be fine as
OutputPage::reduceAllowedModules() is mainly used to either allow everything
or restrict all the way down to CORE. The only exception is disallowUserJs()
if $wgAllowSiteCSSOnRestrictedPages is enabled (T73621) but that edge case was
made for Common.css, not Group-*.css.
Change-Id: I74cd2368ebd2989c5e1c22bea491a80beb0319dc
This avoids edge cases where the user isn't logged in but we still need
varying for proper cache behavior.
Bug: T125283
Change-Id: I43cde3a48371e62a16bda1291b1b51986e60fe4c
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
When MediaWiki encounters an unhandled exception, the error message it produces
includes a randomly-generated token, which allows the exception details to be
looked up in the error logs. This is useful but narrow: would it not be useful
to have the ability to retrieve all log records associated with a particular
request, rather than just exception details? (Hint: yes.)
So: introduce the notion of a request-global unique ID, retrievable via
WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id
(which provides the same facility) or some other software which sets a
UNIQUE_ID envvar, the value of that envvar is used as the request ID.
Otherwise, it is a randomly-generated 24-character string.
The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId()
is deprecated, accordingly. The request ID is also added as an annotation to
all Monolog-processed log records, and is exposed client-side as 'wgRequestId'.
This allows developers to associate a page view with log records even when the
page view does not result in an unhandled exception. (For the WMF, I also
intend to add it as an annotation to profiling data).
The request ID is not a tracking token; it does not persist, and it is
associated with a backend request, not with a particular user or a particular
session. Like the data in the NewPP report, the request ID is designed to be
cacheable, so that if, for example, a developer notices something weird in the
HTML, s/he can associate the output with a backend request regardless of
whether the response was served from the cache or directly from the backend.
Some prior art:
* https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html
* http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
* https://github.com/dabapps/django-log-request-id
* https://packagist.org/packages/php-middleware/request-id
* https://github.com/rhyselsmore/flask-request-id
Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
* Remove trailing space in self-closing tag.
Brings parserTest output of Parser and Parsoid closer together.
* Remove various line breaks at begin and end of script contents.
* Remove FILTER_NOMIN from makeConfigSetScript() output.
This isn't part of any user- or page-dependent module and not minified.
And Xml::encodeJsCall already ensures compact output for prod mode.
Bug: T127328
Change-Id: I85a5a59fd0955c1a112e8b24b933f0d9e983a156
Follows-up 80a090ea7 (r104483).
I'm assuming the difference is that pageLanguage will be the canonical variant
for the page (as authored in wikitext, presumably the wiki's default), whereas
pageViewLanguage will be the variant of the pageLanguage based on the current
user-interface language (if and only if the user interface is related).
Viewing zh by default has:
* userLanguage: zh
* pageLanguage: zh
* pageViewLanguage: zh
Viewing zh-cn by default has:
* userLanguage: zh
* pageLanguage: zh
* pageViewLanguage: zh-cn
Viewing zh-cn with uselang=en has:
* userLanguage: en
* pageLanguage: zh
* pageViewLanguage: zh-cn
Viewing zh-cn with uselang=zh-tw has:
* userLanguage: zh-tw
* pageLanguage: zh
* pageViewLanguage: zh-cn
The main use case behind wgPageContentLanguage in 80a090ea7 was tablesorter
which should match the language and variant of the rendered wikipage content.
The parser output and div#mw-content-text element use pageViewLanguage, so
let's set wgPageContentLanguage to that as well.
Change-Id: Ibf399dfe5ca60fb55e7acd75a5c0238d8b903807
Deprecated since 1.22. Six use remain in Gerrit extension
SemanticPageMaker, that's been unmaintained since MediaWiki 1.17. They
were not replaced.
Change-Id: I8d68657562f683a4933cc5321d5df04c80cdfc29
Deprecated since 1.24. One use remains in Gerrit extension
SemanticPageMaker, that's been unmaintained since MediaWiki 1.17. It was
not replaced.
Change-Id: I50afa8217e7bf1b47aef3951ef2ee7295d6db21e
Output cache-control headers that disable intermediate caching even if
OutputPage->mEnableClientCache is true when the response includes
set-cookie headers as well. This change mirrors logic that has been in
use on the Wikimedia Foundation production cluster's Varnish cache
system for over 2 years to guard against accidentally caching backend
responses which include Set-Cookie headers.
Co-Author: Max Semenik <maxsem.wiki@gmail.com>
Bug: T127993
Change-Id: I1a0d38a5b9dba754b91a7832371b3dc0df51bd5a
If you have MediaWiki installed in the root of the domain, then
$wgScriptPath and $wgResourceBasePath is an empty string. In HHVM and
PHP, passing an empty string as the second parameter of strpos() causes
a warning and returns false, which will cause the condition to fail, as
if the path were not within the base path.
So, normalize such paths. Using substr() instead of strpos() for a
"starts with" check would have worked except that RelPath also fails
when given an empty string.
Bug: T127652
Change-Id: If7e94ae638d6834f7cc0f31f67a5fe6a2f74771c
If the Title object isn't the title of the current viewed WikiPage, the page_lang
field of the database isn't requested. This results in the problem, that
Title::getPageLanguage() always returns the default content language, even if
the page language is different (changed with Special:PageLanguage, if
wgPageLanguageUseDB is true). That is problematic for the Translate extension,
which relies on the correct page language.
This change makes sure, that getPageLanguage() always return the correct page
language. If the page language isn't loaded already, Title::getPageLanguage()
now does a database lookup (if $wgPageLanguageUseDB is true) to get the correct
page language. It will use LinkCache for the page_lang field.
Bug: T121666
Change-Id: I0ae5ea39f7a124ed427ca5dfb26c1a116b27a94e
Until Setup.php completes, we can't access the "current" user and
trying to do so logs a warning. So don't try.
Bug: T124367
Change-Id: I1acc82760c368a24448f3c90e268b24414e43a30
The whole comment was added in fc359e16f1 together with a strtolower().
In dcd44cdf7d the strtolower() and a part of the comment was removed.
The rest of the comment makes no sense without a strtolower().
Change-Id: Ifa0d88a618e31f4a558bc93a098aabad35761569
Use a <meta> tag added when enabling OOUI, and a skipFunction that
looks for it, to avoid double-loading the modules: oojs-ui.styles,
oojs-ui.styles.icons, oojs-ui.styles.indicators, oojs-ui.styles.textures.
This saves us loading of around 200K of CSS (20K when gzipped) on pages
that both use OOjs UI PHP server-side and load OOjs UI client-side.
(For example, all MediaWiki special pages using OOUIHTMLForm.)
Interesting caveat: this causes the aforementioned modules to no
longer appear in the output of `mw.loader.inspect()` on such pages.
Bug: T125292
Change-Id: Ia7e2256cd239841e1f78c4a6bf666dd939c0d2c7
See the task for more details. This is a backwards-compatible change.
If your script only needs a subset of OOjs UI functionality, you can
use one of the new smaller modules instead of the old big one.
New modules:
oojs-ui-core
The core JavaScript library.
oojs-ui-widgets
Additional widgets and layouts module.
oojs-ui-toolbars
Toolbar and tools module.
oojs-ui-windows
Windows and dialogs module.
Changed modules:
oojs-ui.styles
Now correctly only loads the styles needed by OOjs UI PHP.
oojs-ui
Now just loads core+widgets+toolbars+windows as dependencies.
Using the new modules in I58799e22f9c0a2f78c1b4a02c4b7af576157883a.
Bug: T113677
Change-Id: I0a3bf8fb25fb82325705a473cebd883e20b3ab8d
Keep in CSSMin as-is for back-compat and to ensure library remains
independent of MediaWiki.
Moved down a few lines as there is no need to compute the md5 hash when we're
returning a data URI. Previously md5_file was called twice during module builds
(once for the fallback url, and another time when producing the embedded data uri).
Applied to logo in SkinModule as example. To be applied elsewhere as needed.
Without it, fallback is current behaviour (no cache invalidation).
Bug: T99096
Change-Id: I7f38bfc1bea5c241bc4f8ec4f4b640fd65f2c04f
The plan here is to take it out of 1.27.0-wmf.12 and put it back in
1.27.0-wmf.13.
Since BotPasswords depends on SessionManager, that's getting temporarily
removed too.
This reverts the following commits:
* 6acd424e0d SessionManager: Notify AuthPlugin before calling hooks
* 4d1ad32d8a Close a loophole in CookieSessionProvider
* fcdd643a46 SessionManager: Don't save non-persisted sessions to backend storage
* 058aec4c76 MessageCache: Don't get a ParserOptions for $wgUser before the end of Setup.php
* b5c0c03bb7 SessionManager: Save user name to metadata even if the user doesn't exist locally
* 13f2f09a19 SECURITY: Fix User::setToken() call on User::newSystemUser
* 305bc75b27 SessionManager: Don't generate user tokens when checking the tokens
* 7c4bd85d21 RequestContext::exportSession() should only export persisted session IDs
* 296ccfd4a9 SessionManager: Save 'persisted' flag in session metadata
* 94ba53f677 Move CSRF token handling into MediaWiki\Session\Session
* 46a565d6b0 Avoid false "added in both Session and $_SESSION" when value is null
* c00d0b5d94 Log backtrace for "User::loadFromSession called before the end of Setup.php"
* 4eeff5b559 Use $wgSecureCookie to decide whether to actually mark secure cookies as 'secure'
* 7491b52f70 Call session_cache_limiter() before starting a session
* 2c34aeea72 SessionManager: Abstract forceHTTPS cookie setting
* 9aa53627a5 Ignore auth cookies with value 'deleted'
* 43f904b51a SessionManager: Kill getPersistedSessionId()
* 50c5256352 SessionManager: Add SessionBackend::setProviderMetadata()
* f640d40315 SessionManager: Notify AuthPlugin when auto-creating accounts
* 70b05d1ac1 Add checks of $wgEnableBotPasswords in more places
* bfed32eb78 Do not raise a PHP warning when session write fails
* 722a7331ad Only check LoggedOut timestamp on the user loaded from session
* 4f5057b84b SessionManager: Change behavior of getSessionById()
* 66e82e614e Fix typo in [[MediaWiki:Botpasswords-editexisting/en]]
* f9fd9516d9 Add "bot passwords"
* d7716f1df0 Add missing argument for wfDebugLog
* a73c5b7395 Add SessionManager
Change-Id: I2389a8133e25ab929e9f27f41fa9a05df8147a50
SessionManager is a general-purpose session management framework, rather
than the cookie-based sessions that PHP wants to provide us.
While fallback is provided for using $_SESSION and other PHP session
management functions, they should be avoided in favor of using
SessionManager directly.
For proof-of-concept extensions, see OAuth change Ib40b221 and
CentralAuth change I27ccabdb.
Bug: T111296
Change-Id: Ic1ffea74f3ccc8f93c8a23b795ecab6f06abca72
The functionality for marking a debug log message for delivery to a log
file but not to MWDebug was removed in 1.25 with the introduction of
the PSR-3 logging system. Convert the messages that were marked for this
special handling in a7a0883 to use 'private' instead.
Bug: T122644
Change-Id: Iefaac07a5922c16c2899904c7b678199c5b1efe9
Some extensions may want to replace, remove or manipulate a specific
feed link after it was build. For this purpose: Add a new hook to enable
this. The hook isn't meant for adding new feed links, this is already
easily possible using OutputPage::addFeedLink().
Bug: T121774
Change-Id: If48bd07a0e7e67fd1c1a94ebaa28ca9dae146c55
If you edit your user JS page, change the JS, and click Show preview,
the new JS will be loaded ("previewed"). However, this "preview"
is also engaged when you click Show changes, or click "Save page"
and fail to save. Don't do that: only "preview" JS when the user
has actually chosen to preview it.
Change-Id: Id9bcd235d3414b68de6e5d491b7b0c4f9b16e05f
Deprecated: addExtensionStyle, getExtStyle
These had been deprecated unofficially for a while now. ResourceLoader
is preferred.
Internal/Unpreferred: addHeadItem, addScript, addScriptFile,
addInlineScript, addStyle, addInlineStyle.
All should be used as littel as possible, in favor of ResourceLoader
and a few other higher level accessors. They are not truly deprecated,
but should not really be used unless you have a really good reason.
Also added a few missing wfDeprecated calls to methods marked as
deprecated in the phpdoc.
Bug: T89955
Change-Id: I472d906b6de16257fa34a2f9bfe9e4eb284d02b4
This effectively reverts d6b4d3c537 and declines T97420.
This was previously attempted in b7c0e537eb.
Drop support for position "bottom" for addModuleStyles().
This feature was only recently introduced with the intent
to optimise page load performance, but had an adverse effect.
It increases chances of FOUC due to late discovery of these styles.
It also caused minor problems for some gadgets and extensions
that did not or were unable to set these flags. Some mobile
code was introduced around the same time as this feature and
was never given position=top.
Stylesheets that don't affect initial render or are only needed
on interaction should be loaded via addModules() instead; which
is handled by the asynchronous loader in JavaScript.
Change-Id: Ib9821b7b87cfc8a59062bb6ca358974fdb01ced1
This allows empty lines inside the comment as found by the
MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.EmptyComment sniff
Change-Id: Iac155bbda4a84562db2b452baeae9b8973899453
Ensure that OutputPage::haveVaryCacheCookies() handles falsey values correctly,
and that it requires a cookie to have a nonempty value before it declares a
match.
Change-Id: I2afe54b62c940187a427498cb4037e1dd0e78dd9
MediaWiki currently has support for a header called X-Vary-Options
(XVO), used to communicate to upstream caches more granular cache
variance options than the Vary header can.
The header was envisioned by Tim Starling back in 2008 and implemented
into MediaWiki and Squid 2.0, with those patches submitted to the
squid-dev mailing list at the time:
http://www.squid-cache.org/mail-archive/squid-dev/200802/0085.html
The patches never actually made it into an upstream Squid release,
however, and Squid has since evolved in potentially significant ways.
Wikimedia has since switched to Varnish but XVO was not ported over as
it was deemed too complex at the time; custom VCL was used instead. To
our knowledge, noone else is using XVO in production and certainly not
with recent, up-to-date MediaWiki releases.
There is currently work at IETF's httpbis working group for a "Key"
header that is in concept and implementation very similar to Tim's XVO
header: https://datatracker.ietf.org/doc/draft-fielding-http-key/
Rather than rip XVO out of MediaWiki, replace it with support for the
Key header, as preliminary defined by the draft spec. This is an almost
straight search-and-replace.
No other software (caching proxy or user-agent) currently implements Key
to my knowledge, so this is essentially untested.
Change-Id: I949fc289dd5d48bd34f3b37f7739e2b9cd5db277
* $wgCdnMaxageLagged controls exactly what that TTL is
and the usual "max lag" settings determine what "high"
is for lag (which already makes the site read-only).
* This helps avoids stale content getting stuck in CDN
for a month just because a slave was lagged for a minute.
Of course race conditions with normal slave lag and WAN
cache relay purges can still lead to this problem, though
the scope of it is reduced.
Bug: T113204
Change-Id: I7ff0a8d88665f4e557566e7b412e75edee2627fe
- Removed space after cast
- Removed spaces in array index
- Removed double spaces
- Added spaces around string concat
- Fixed mixed tabs and spaces at begin of line
Change-Id: I38e849723f055d2d4c05cba72f5c245a28e8d5da
Nested media queries are not allowed in CSS 2 and not supported
in older browsers.
This reverts commit 11e47561e4.
Bug: T108727
Change-Id: Ibef40e79a5d5e229df8f874b7dea5b590f3f7320
Rewrite OutputPage::addVaryHeader which had a very confusing
structure.
There is one breaking change: the $option argument was declared
as array|null, but the function accepted everything and showed
inconsistent behavior; e.g.
$op->addVaryHeader( 'Foo', 'bar' )
resulted in 'X-Vary-Options: Foo;bar' but
$op->addVaryHeader( 'Foo' )
$op->addVaryHeader( 'Foo', 'bar' )
resulted in 'X-Vary-Options: Foo'. With the patch, non-array
arguments (other than null) result in an error.
Change-Id: Id31d95fe27b01b00ec8a1d7a3996275fc0aacf3c
The $options parameter to OutputPage::addVaryHeader() is undocumented as
to what exactly is supposed to be passed to it. Fix that.
Change-Id: I5fcbb8cf6219c6ab001962a4c2170e1733732426
