In TitleLibrary::getContentInternal(), an external (interwiki) title will
fail when we try to `Parser::fetchCurrentRevisionRecordOfTitle`, but by
that time we've already tried to add it to the dependency list for the
page via `ParserOutput::addTemplate()`, which causes issues further on.
Bug: T362222
Change-Id: I171e97f17b6de176f92ced47757d10c341c979fd
(cherry picked from commit 5bde75bf38)
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I6d3edc5f8dddcfc6bd6a7d2a8f2ad9467372908d
Added escapes for "!" and ";" as well as additional escapes
at beginning and end of string.
Bug: T168763
Co-Authored-By: vlakoff <vlakoff@gmail.com>
Co-Authored-By: C. Scott Ananian <cananian@wikimedia.org>
Depends-On: I34f2fa8c329e6f6771453b2f94dc4afbec31dac8
Change-Id: I6c9dcfdbbb2c6eff9414e24d3f2693ebe576505a
In order to avoid misleading the caller, set some title properties to
nil for interwiki links. That value should still be falsey, but can
prevent making unwarranted assumptions about the destination of
interwiki links.
Split from I847ac4b7587b98be06b25fe14765e9efdc7b774d because this
could possibly have effects on existing modules.
Change-Id: I06efea9b264ba0f09bfb36e6bf1bb04f1cdd03e4
This allows conversion of MediaWiki-internal codes to standardized
codes suitable for inclusion in HTML.
Change-Id: I5d2102ca57cc6861b8ec144a90f9c17b630f38ce
ScribuntoContent now supports content being redirects, if the underlying
ScribuntoEngine does so. For Lua, a redirect looks like:
return require [[Module:Foo]]
which also happens to be perfectly valid Lua. There is intentionally no
`#REDIRECT`-style token (like in wikitext/JavaScript/CSS) because no one
will create a page with this content except for the purposes of a
redirect.
Bug: T120794
Co-Authored-By: DannyS712 <DannyS712.enwiki@gmail.com>
Co-Authored-By: C. Scott Ananian <cscott@cscott.net>
Co-Authored-By: Jackmcbarn <jackmcbarn@gmail.com>
Change-Id: I405e7953d00af8a34d5e8addc61a245732c71e8e
empty() should only be used to suppress errors
When the type of the variable is array,
a falsy check is the same (checks for null, false and empty array)
Found by a new phan plugin (T234237)
Change-Id: Id855be9dd25a27d9e46e3065dacbd268177b073d
phan under php8.1 also detects PhanImpossibleTypeComparisonInLoop here,
but that cannot suppressed under php7.4,
so use @phan-var to set to the correct type, but keep the comment.
The suppression was added with 8328acb9 for a update of phan
According to the doc proc_get_status can only return array
(at least under php8.1)
Change-Id: Ieda5abc30126eed2e3a9f5fc283d36e64180f496
timeout while converting timestamps should be a timeout for the whole
parse of that wikitext and not hidden by a invalid time.
Just let the exception bubble up to the caller
See ca71e69f for more information
Change-Id: I1f44e45dcc9b052717814990a3f5ce3a1bdf9d26
- Force a content model on the title used by LuaEngineTestBase, so that
calls to getPageLanguage() won't end up hitting the DB
- Don't actually use SiteStats from SiteLibrary in unit tests. There
seem to be no test actually using this data.
Bug: T345372
Change-Id: I35884f04b582678982fb5f64d9199bab41cd8bce
Using code by David Manura, published at lua-users.org/wiki/StringTrim
Note '\t\r\n\f ' is replaced with '%s', thus '\v' (vertical tab) is added to the characters trimmed by default.
Bug: T338561
Change-Id: I98e2677f1181b88f4cd97cffca3a53ce426ec5cd
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
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
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
