As of MW 1.40, the default targets are now ["desktop","mobile"] so we
don't need to define this ourselves. Minimum MW version bumped to
match.
Bug: T328497
Change-Id: I763607ad4a9eb6f9c35a1ac73c0d44b84b9063d2
These modules get silently removed on mobile. This seems
unnecessary and most likely unwanted behaviour.
Bug: T324723
Change-Id: Ie3473deb10d96df046963b0bcf1b00bea965e3b3
Needed for I869af06896b9757af18488b916211c5a41a8c563, where I am
trying to change LanguageFactory in MediaWiki core not to use
MWException.
Language::isSupportedLanguage() does not actually throw,
so this sigh can be one of relief.
Change-Id: I3079d8e18d88a4a26c2f2b09dccd4beea06678ee
composer:
* mediawiki/mediawiki-codesniffer: 38.0.0 → 40.0.1
The following sniffs are failing and were disabled:
* MediaWiki.PHPUnit.AssertEmpty.AssertEmptyUsed
npm:
* stylelint-config-wikimedia: 0.11.1 → 0.13.1
Change-Id: I5c0a3179d60555a334000e4acddf1b5cb0ba0bfa
As explained in T322883, the switch to
TextContent::normalizeLineEndings() means that rtrim() is run over the
input, which is a breaking and unintentional change.
This partially reverts commit 912324993f.
Bug: T322883
Change-Id: I2ad47d46e05112f413af453d61eb3f13434b2774
mw.loadData() allows for optimizing the loading Lua tables by requiring
only one parse and lookup. However it's often easier for people to
write/maintain bulk data in JSON rather than Lua tables.
mw.loadJsonData() has roughly the same characteristics as mw.loadData()
and it can be used on JSON content model pages in any namespace.
As noted on the linked bug report, it's possible to already implement
this by writing a wrapper Lua module that loads and parses the JSON
content. But that requires a dummy module for each JSON page, which is
just annoying and inconvenient.
Test cases are copied from the mw.loadData() ones, with a few omissions
for syntax not supported in JSON (e.g. NaN, infinity, etc.).
Bug: T217500
Change-Id: I1b35ad27a37b94064707bb8c9b7108c7078ed4d1
For the most part, it is a good idea to avoid global variables and use
`local` variables instead. Quoting from the ScopeTutorial[1], "The
general rule is to always use local variables, unless it's necessary for
every part of your program to be able to access the variable (which is
very rare)."
Wikimedia module authors have written "Module:No globals", which errors
on the use of any global variable. On the English Wikipedia, this is
used on 32% of pages (18 million). Wikidata[2] indicates that it's been
copied to 334 other wikis.
Lua itself distributes an extra named "strict.lua"[3], which is what
this is based off of. Similar to bit32.lua, this is a pure-Lua library
that can be imported/enabled with `require( "strict" )` at the top of a
module.
The two changes I made from Lua's strict is to exempt the `arg` key,
which is used internally by Scribunto, and remove `what()`, since we
don't enable access to `debug.getinfo()` for security reasons.
[1] https://lua-users.org/wiki/ScopeTutorial
[2] https://www.wikidata.org/wiki/Q16748603
[3] http://www.lua.org/extras/5.1/strict.lua
Bug: T209310
Change-Id: I46ee6f630ac6b26c68c31becd1f3b9d961bcab29
In Chromium-based browsers the lack of padding means the cursor
isn't visible in the textarea when focused. In this case, it's
probably more important for the cursor to be visible than the
lack of padding to make it look more like a terminal.
Bug: T272678
Change-Id: I09ed2933bdac292ee9b9b98a2c8c48d96914d096
Use OOUI's PopupWidget to display error tracebacks/details instead of a
deprecated jquery.ui dialog.
Bug: T319361
Change-Id: Ie7796c853782de9874595674fe250f6702db717e
This fixes a warning on php8.1 related to preg_match_all returning
null when given invalid UTF-8.
I made a separate patch to change the null into an exception Ic0c9083b
In a sense, this is a follow-up to ec103b6966.
Bug: T319218
Change-Id: Ia17fc2fa428ec35bdbd242f1127fcdff501fb741
This is basically unexploitable, given that Scribunto sessions are
"extremely ephemeral", protected by a 31-bit non-cryptographically
random token and generally contain very little useful data.
But, requiring a CSRF token is a best practice and since this module
is internal and only used in one place, it's also unlikely to break
anything. Because it needs a token, the module is POST-only now too.
Bug: T212071
Change-Id: I7fb6b4f856ee6194eb37c26e14f178fea6c0a3f6
