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
