I have reproduced at least one instance of the message "ParserOutput
does not specify a language and no page language set in helper." by
trying to query a rest.php html endpoint on a module with the
scribunto-doc-page-does-not-exist message deactivated (which is the case
on wikidata).
I do not know if that path is the one that triggers the current large
amount of these messages coming from Wikidata, but it looks reasonable
to fix that one at least.
I'm also not sure this fix is the right one - I'll let people with more
Scribunto and ContentHandler experience chime on that :)
Bug: T362312
Change-Id: I26c1683c803f5cafd08de83e8b428031414d1c4e
Mostly unspecific arrays that can be made more specific. This patch
intentionally doesn't touch any code, only comments.
Change-Id: I5b4690e6160c6c543f9fcb2f62c41f6329d48bdb
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
To avoid an exception when the parser is re-entered.
Bug: T310948
Depends-On: I762b191e978c2d1bbc9f332c9cfa047888ce2e67
Change-Id: I5013ed2a2958c3ff422778f9146f663aff0f5939
