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
