When ApiParse is used to parse a page containing numeric image links
like [[File:1]], those image links are returned in the "images" section
as numbers, not strings. This is due to a longstanding PHP feature where
numeric strings get converted into numbers when used as keys in an
associative array. So, coerce them back to strings.
While numeric image links seem rather useless, they still occur in the
wild, whether by design or by accident, and may break API consumers that
expect to deal with strings here.
Bug: T346265
Change-Id: I9bd3813afd1867d0ba9c7ef480ad5e6b062c1e94
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
I found myself needing to just get the stashes name without the
placeholder for T331397, and I thought that this seems like a weird
API. The caller should get the placeholder separately if desired,
which is easy to do in all of the current callers.
Follow-up to 65f04c763a.
Change-Id: Icf1d24f17b60a461ef682bc5da01be6ebc3a2d93
When the value of the associated array is not used, there is no need to
use array_keys and create internal a copy of the array, just omit the
value with $_ to tell static analyzer that the var is unused.
Change-Id: I5c6d667e98c0167c0573c683f0d617bc1d4ca619
This is in preparation for changes on the Parsoid side to make
sure its signature is compatible with the ContentMetadataCollector
interface there.
Change-Id: Ife4ae81dbc304097da7dcba40b143f7030b959f3
For pst on parse/compare/editstash/(all)revisions/(all)deletedrevisions
Do not show the IP when IP masking is enabled,
instead show a previous aquired temp name or a placeholder on preview.
MediaWiki itself used this for the ajax preview on GUI's action=edit
Cannot acquire a new unsaved temp user as api parse does not persist
the global session (each request results in a new id)
and it would require a db write on a read request.
Bug: T331397
Change-Id: I74bb4d655f371bd99e3b618d1a0ac45d730c746c
Also moving TemplatesOnThisPageFormatter to the same namesapce as it's
only used by EditPage
Bug: T321882
Change-Id: Ibefc44eb64aedb430148b109090584c3e35794ab
expandtemplates API has had its own documentation page since 2016.
[[API:Parsing wikitext]] is now only about the parse API.
https://www.mediawiki.org/w/index.php?diff=2222810
Change-Id: Ia882752485926b89fbcb57d247ca0b41f048ac20
The rules for how ParserOptions::getUserLang() are set are a little
baroque. When the 'uselang' option is set on the request, for example,
RequestContext::getLanguage() can differ from the user language; we
also deliberately force the "user language" to the content language
during the post-edit path to avoid having the user language leak into
the links table.
The changes in this patch make the ParserOutput::getText() calls "more
correct" but really they are just removing some uses of the global
RequestContext::getMain() from the code path, since in all of these
cases the main request context (which is what we use by default) does
have the correct language set.
For consistency, this patch also adds `allowTOC=false` in many of the
places where we already had `enableSectionEditLinks=false`; for
example, user interface messages, wikitext content injected on special
pages, etc.
Change-Id: Ib0d8c5e538e472ad672c45e5b68907242afb1e14
To follow Message. This is approved as part of RFC T166010.
Also namespace it but doing it properly with PSR-4 would require
namespacing every class under language/ and that will take some time.
Bug: T321882
Change-Id: I195cf4c67bd51410556c2dd1e33cc9c1033d5d18
The newly created #mw-content-subtitle element should not be
included in parse API responses. That element is meant to identify
the subtitle area only.
Bug: T324876
Bug: T316830
Change-Id: Id8436324e2ae2fd9f488b65b3b7bfc19611870d1
When setting causeAgent for jobs, be specific.
When creating parserOptions, call setRenderReason.
This allows us to capture statistics on what actions cause jobs,
renders, and cache writes.
Change-Id: Iaef64beadce1489bebb6bb00855c3ba6013a29d8
Note: we should wait a full parser cache expiration time
after I3b76010f1e2283add629b84bf3824f215f932903 is deployed
in order to ensure that the parser cache entries all contain
the SHOW_TOC flag where appropriate.
Bug: T310083
Bug: T314000
Depends-On: I3b76010f1e2283add629b84bf3824f215f932903
Change-Id: I10c3d06fb162103c06395bf9d1d27ac3c199d7b6
This was briefly used in ApiParse output, but never in a released
MW version. We've transitioned VisualEditor to showtoc instead
to better match the underlying ParserOutput flag name, and so
hidetoc can be removed.
Bug: T314000
Depends-On: I823f26652b9770ea577daee32bff05864a7498bb
Change-Id: Icb9a79d4f7f1c2d01a8ac99a2de7d0784901b195
This ParserOutput flag will be renamed, so let's rename the API
property as well before this escapes out into the wild.
Bug: T314000
Change-Id: I1644a74370b42b04d0db167879f7de2207ebfcf5
WikitextContent methods replaceSection() (used when adding a section
to an existing page) and addSectionHeader() (used when creating a new
page) behaved inconsistently - the former would omit the heading
syntax when the section title was empty, but the latter would not.
They both omit it now.
Some callers of addSectionHeader() handled this case, but others did
not, which caused T311489. (I am removing the checks now, since the
change makes them redundant.)
Bug: T311489
Change-Id: Icd59bcf2b75bf50865f19fac92bddabe0c183dcc
The table of contents is supposed to be hidden when the page has less
than 4 headings, but it can be overridden by several magic words.
The API provided no way to find out if it should be shown or hidden
for skins that don't use the built-in table of contents.
Using getTOCHTML() to check this is weird, but the TOC code is
currently enduring a rewrite, and this is how it's done in OutputPage.
Bug: T294950
Bug: T310083
Change-Id: I6cf76c870124c162dc1bcbc2f7e9ca0c5fdcd10e
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
The 'contentformat' param should only have effects when the parsing
is based on the 'text' param, as what the document described.
Bug: T206253
Change-Id: Ia12b8697e515c6ba89ea81f085292d1ef018bf58
Format like 'application/json' is not supported for content model
wikitext, don't fail as internal exception.
This fix the case when providing text/title parameter.
Bug: T206253
Change-Id: I20ef52aa961143b7c50283c0d06acea9f220619c
This allows Parsoid to properly merge jsconfigvars via the external API
(ie, when Parsoid is run in 'standalone mode') when an extension uses
the new-in-1.38 ParserOutput::appendJsConfigVar() method.
Change-Id: I974d9ecfb4ca8b22361d25c4c70fc5e55c39d5ed
This reverts commit 2bcb3fe567.
Reason for revert: this is a good change,
just needed more work to not break CI
Change-Id: I23768bee242e3cf81b1493a740cf070e7ad1e224
This does not move the actual limit report data into
ParserOptions yet, that should be done separately
given that it will require serialization changes.
Let's get this change settled first before messing
with serialization.
This unifies canonical and non-canonical ParserOptions,
so ParserCache can now be used with both. It is hard
to say how this will affect the ParserCache capacity,
so we should monitor it after releasing this.
Change-Id: I154c0a77a5b0287b5572614d56339fb57ac56c33
Clean up loose ends from the skin table of contents patch (I44045b3b9).
* Clarify $options -> $skinOptions (because there are so many different
"options" classes!)
* Remove redundant default when Article::doOutputFromParserCache()
calls ParserOutput::getText() -- the 'injectTOC' option defaults
to true inside ParserOutput::getText() as well.
Bug: T287767
Followup-To: I44045b3b9e78e7ab793da3f37e3c0dbc91cd7d39
Change-Id: I04b8d8a4076df551347ec6d6599d597424a2dadf
* Do not store table of contents in parser output
* Instead inject table of contents via strpos where needed
inside Article based on Skin "toc" option
* Use <mw:tocplace> as a TOC placeholder; for Parsoid compatibility
this will be replaced with a <meta> tag in a followup patch.
Bug: T287767
Change-Id: I44045b3b9e78e7ab793da3f37e3c0dbc91cd7d39
