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
It currently inherents from the mw-parser-output div, which sets
it based on the documentation page (content language).
Change-Id: I79847cd8cfe75598c843e96a09d9aa61b00304a9
Title::castFromPageReference() and similar methods can return null
instead of Title when the parameter is null. Although that could not
happen in this code, there is no way to tell that to Phan, so
suppressions were required to avoid its warnings about possible nulls.
Instead, since MW 1.41, we can just use Title::newFromPageReference(),
which can't return null (and doesn't accept null as the parameter).
See also Ida4da75953cf3bca372a40dc88022443109ca0cb in MediaWiki core.
Change-Id: Ia3c415cdd68fe4b19869aa8eb8e816e707bb5ad6
When OutputPage/Skin call ParserOutput->getText(), this already takes
care of the appropriate attributes. This redundancy is non-obvious
however, because in this code $parserOutput is re-purposed in an odd
way that makes it seem like it has to mark its own language, so as to
separate it from the appended portions for validation error and
syntax highlighted code.
However, at least the way the code has been in recent years, this
has always been a redundant wrapper since OutputPage/Skin already
set the same attributes on the resulting container. With T341244
closed, this is more obvious now that it is located in
ParserOutput::getText, but even before I worked on T341244, the Skin
will have already been doing the same thing as this code was doing,
setting the same redundant attributes.
Bug: T350806
Change-Id: Idb8471eec5d5ac39b7a347c70f3a618eba18a57b
The ParserOutput object used here starts life as the ParserOutput for
parsing the docpage (wrapped via an interface message). In order to
remove use of the Title::getPageViewLanguage method there, we need to
re-arrange some logic such that we parse the doc page first, and see
what language it was rendered in, instead of currently where
Title::getPageViewLanguage tries to "guess" what Parser and
LanguageConverter will do.
As prep for that stop reading/writing the HTML text of this
ParserOutput object in favour of being more like the Parser itself,
which accumulates metadata in ParserOutput and calls setText only
once at the end.
* Refactor highlight() to return standalone HTML instead.
* Refactor validation error to append to $html instead.
Other improvements while at it:
* Document how stuff works today.
* Clarify variable names.
* Separate concerns better by moving responsibility of `<pre>`
fallback to highlight(), and limiting knowledge of
ScribuntoEngineBase to the caller.
Bug: T350806
Change-Id: I9fe6d93727f29c284ea21db6edd6a2b1663e8e06
Some exception messages add tracking categories, which fail when there
is no title context.
Bug: T351045
Change-Id: I47d0160010c9da5a9a9974718a432fd5e79f8286
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
This replaces the use of ParserOutput::addJsConfigVars(), deprecated
since 1.38, and ensures that the IDs used for error messages are
independent of page parse order. (See T300979.)
This is an improved replacement for Ibd3fbcbc774491179b0d4fe29ba3b6a128220703
which was reverted (T346094).
Bug: T300307
Bug: T305161
Bug: T346094
Change-Id: I2c660972b289bbad730ceee1325d70d5ba75d27e
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
This reverts commit 9f8d16f9c9.
Reason for revert: Causes internal error on certain pages.
Bug: T346094
Change-Id: Ia9ccffbbbe2fe2413b54fb5e16f5cfc53527990e
Most uses can be replaced with ::setJsConfigVar(); the major semantic
change is that ::setJsConfigVar() is not expected to overwrite
previous values. That *may* be an issue here, but if so it's not
a change from existing behavior, as the way ::addJsConfigVars() was
being called it would override previous values as well.
Bug: T300307
Bug: T305161
Change-Id: Ibd3fbcbc774491179b0d4fe29ba3b6a128220703
- 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
The use of "HookHandlers" attribute in extension.json makes it possible
to inject services into hook handler classes in a future patch.
Bug: T271026
Change-Id: I1583f5075937c4ce71a0d8748700f7012280851c
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
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
