Parser::getRevisionRecordObject() returns `null` if the revision is
missing, but it invokes ParserOptions::getCurrentRevisionRecordCallback()
(ie, Parser::statelessFetchRevisionRecord() by default) which returns
`false` as its error condition.
This reverts commit ae74a29af3, and instead
fixes the bug at its root.
Bug: T251952
Change-Id: If36b35391f7833a1aded8b5a0de706d44187d423
In the new hook system, it is invalid to have two hooks that differ only
in case.
This reverts commit afb5b38e15.
Change-Id: I160ece0a7bc68c748037b383137364b787be86a0
This was moved before doBlockLevels in c23cb2c when it used to be a more
general cleanup that conflicted with it. Since 02ff859 that no longer
seems necessary.
Further, this gives the consistency of armoring inside wikilinks and
avoids some unnecessary row definition list colons being armored.
Maybe this should be moved to the end of internalParseHalfParsed after
language conversion but before tidying, where the other call to the
sanitizer happens, Sanitizer::normalizeCharReferences. But let's change
things one step at a time and start by moving it here before we try to
move it further.
The goal here being to make french space armoring a post-processing
step, rather than an intermediate transformation, more consistent with
how Parsoid will/wants to do it.
Bug: T197879
Change-Id: I3eae3719ab8fb50b7996d4fd8a9fa0d5ca250023
This will allow us to deprecate the ParserBeforeStrip and ParserAfterStrip
hooks by covering the one case where ParserBeforeStrip is called but
ParserBeforeInternalParse is not.
Bug: T250450
Change-Id: Ia298fecba77e97fc30dc30a09ac69a4239767d8c
Originally we created a Parser object on every request, and so care
was taken to make Parser construction lightweight. In particular,
all potentially costly initialization was moved into a separate
Parser::firstCallInit() method. Starting with 1.32, parser construction
has instead been done lazily, via the ParserFactory registered with
MediaWikiServices. The extra complexity associated with the old manual
lazy initialization of Parser is therefore no longer needed.
Deprecate Parser::firstCallInit() as part of a general plan to refactor
the Parser class to allow subclasses and alternate parser implementations.
Add some tests to assert that parsers are being created lazily, and are
not being created when they are not needed.
Bug: T250444
Change-Id: Iffd2b38a2f848dad88010d243250b37506b2c715
This was overlooked in a5afda55bf, probably
because casual inspection of
https://codesearch.wmflabs.org/deployed/?q=mVariables&i=nope&files=&repos=
made it look like extensions/AbuseFilter was using Parser::$mVariables.
But AbuseFilterParser (and AbuseFilterCachingParser) is its own thing, not
a subclass of Parser, and the (re)use of the $mVariables name for the
property is just coincidence.
Change-Id: I4debb11c804b2ef4f1b727d521f38f35de691708
The following Parser methods were deprecated in favor of new methods:
- ::fetchCurrentRevisionOfTitle (use fetchCurrentRevisionRecordOfTitle)
- ::statelessFetchRevision (use statelessFetchRevisionRecord)
- ::getRevisionObject (use getRevisionRecordObject)
The following ParserOptions methods were likewise deprecated:
- ::getCurrentRevisionCallback (use getCurrentRevisionRecordCallback)
- ::setCurrentRevisionCallback (use setCurrentRevisionRecordCallback)
To ensure backwards compatibility with calling the ParserOptions
CurrentRevisionCallback methods, while allowing extensions to call
the CurrentRevisionRecordCallback methods without worrying about if
other extensions also deployed have been updated, both
::getCurrentRevisionCallback and ::getCurrentRevisionRecordCallback,
if the respective option is still set to the default, check if the
other option is set and, if it is, convert the other option rather
than returning thed default.
It's not pretty, but it works, and will be hard deprecated shortly
and removed in 1.36.
Bug: T249384
Change-Id: I66cbcb963a96cc49c75ca72faa7e439ae6d6614d
Parser::Options(), Parser::OutputType(), and Parser::Title() have been
deprecated. All of these had incomplete replacements with either a
::get* method or a ::set* method (and in the case of Title, both).
Add the missing getters or setters where required.
Only Parser::Title() has been hard deprecated. Replacing the other
uses in deployed code requires the newly-added Parser::getOutputType()
or Parser::setOptions() methods, so we can't replace those methods in
our deployed code after this patch has been merged.
Code search:
https://codesearch.wmflabs.org/deployed/?q=-%3E%28OutputType%7CTitle%7COptions%29%5C%28&i=nope&files=&repos=
Bug: T236809
Change-Id: I0b4d5f170216597afb259cedbb13b8028d284715
This setting has been effectively constant since 2008. In modern code
we should be using a ParserFactory instead to customize Parser creation
and not calling the Parser constructor directly (T236811).
Because the ParserFactory is cached, which freezes the current value of
the content language and other options, we need to reset the ParserFactory
object when running parser tests (T248977). Thanks to
Peter Ovchyn <peter.ovchyn@speedandfunction.com> for first uncovering this
issue and suggesting a fix in I4203bf7719a8555a09b72cdb5b1ae7a6e1505acf.
Code search:
https://codesearch.wmflabs.org/deployed/?q=wgParserConf&i=nope&files=&repos=https://codesearch.wmflabs.org/deployed/?q=ParserConf&i=nope&files=&repos=
Bug: T248977
Bug: T236811
Depends-On: I97d58750c91b06eeca5d810509becdf53a39cc95
Depends-On: Idf59cd54146d31c1c32883f4318e6a0bf60e1a8a
Change-Id: I787f22ea9bf59a049b13631ba6974866a1300988
Disabling tidy has been deprecated since 1.33. This cleans up the code
paths which still used untidy output.
Bug: T198214
Change-Id: I821ef3b8f59b272d983583d407b2f0794fe1e791
This allows them to be more easily reused by other Parser implementations
(ie, Parsoid), and helps keep Parser.php compact.
Bug: T236813
Change-Id: I68fb1e786374e445b7df047934c532d7e10b8e94
We formally deprecated running the parser with tidy disabled in 1.33, but
I missed a hard-deprecation on this code path.
Be careful not to spam the logs with deprecation warnings triggered by
(deprecated) API requests, though.
Change-Id: I10f64e76ec0c5aee8b26fc00bc11ebb0e39f961b
This is preparatory work for I28e88e574ec9f99231bd590e9a87fbc1c4349fa1
which simply splits comma-separated lists into individual lines and
does minor documentation tweaks, so that the main body of the follow-up
patch is easier to review.
Bug: T248889
Change-Id: I196d047ce694fe0e8447bd96455c7fb1b75247e4
The reset state of the Parser $mStripList was made a public field,
presumably so it could be customized by extensions? But nobody seems
to have ever used this. Remove this unnecessary extension point.
Code search:
https://codesearch.wmflabs.org/search/?q=mDefaultStripList&i=nope&files=&repos=
Bug: T248889
Change-Id: I10fa521f62e6b9696ab6b96bcf7eb05091b35022
Ensure that the value returned is always also added to the cache, since
we (eventually) want to remove the hook's access to
$parser->mVarCache. Also don't allow monkeying with the value passed
as $magicWordId, even though it's a reference.
Code search:
https://codesearch.wmflabs.org/deployed/?q=ParserGetVariableValueSwitch&i=nope&files=&repos=
Bug: T236813
Depends-On: Ia12faefada7e4cf04f1a6b12b3ed1703bf28e437
Depends-On: Ia9e2e00c6b7d0e62cbe80c3b124165b691b1ff3d
Depends-On: I1e48fa47b8723958d543a69aaf9b62b872200dc5
Depends-On: If9a0885a8664c22473ade712364c2dd0a5c04e0b
Change-Id: I3d6b281f8e4e0bf68eefbf9767047527b4573b79
The existing magic word API (including hooks) gives implementers direct
access to $parser->mVarCache and full control of caching. Simplify the
implementation (prior to moving the magic word implementations out of
Parser.php) by always caching built-in magic words in $parser->mVarCache.
The cases which were skipping the cache don't vary anyway.
This behavior change is split from the rest of the refactoring in
I68fb1e786374e445b7df047934c532d7e10b8e94 to allow it to be deployed
separately, just in case there was some strange reason this would
cause regressions in practice.
Bug: T236813
Change-Id: I34a0d9a37e41c854c801d546427fc8cd0fe39dc4
All existing uses in our codebase are to OutputPage::enableOOUI.
Further, the implementation here in Parser::enableOOUI calls
OutputPage::setupOOUI() without arguments, which means that the skin
and the page directionality are not initialized correctly.
(OutputPage::enableOOUI() does this correctly). So even if anyone
*was* using Parser::enableOOUI... they shouldn't be.
Use $parser->getOutput()->enableOOUI() instead.
This was originally added in 2d50e28975 to
enable OOUI to be used from parser tags (T101666), but the current patches
for this (eg I29e876c768819413bf31499f067d545732e591b0) can just use
$parser->getOutput()->enableOOUI() instead.
Code search:
https://codesearch.wmflabs.org/search/?q=enableOOUI&i=nope&files=&repos=
Bug: T236809
Change-Id: I71be19c1d735fef5b781c68ef7ba47cafc37595d
This is needed to migrate an extension (AutoWIGO2) that uses ArticleSave
to a version of MW after that hook was removed. The extension was using
ArticleSave to do its own PST processing, which probably doesn't work
with PageContentSave, and wasn't really the right way to do it in the
first place. Surprisingly, there were no useful hooks in PST or its
callers.
Change-Id: If1b3d7ea130a2b77609afe206eedc8445e1ab9f9
As long as no parsing was started, and $this->startParse() was not
triggered at least once, the $this->mOptions property is null. This
does have a lot of consequences. I'm intentionally not fixing all of
them in this patch to not make it to big, only the most obvious ones.
This came up in I6714400 which was actually running into this issue.
This patch also removes a few comments that *literally* repeat what
the code already says. Such comments are not helpful, but clutter the
code, make it harder to read, and create error-prone redundancy.
Change-Id: Ic1ab18242b2f79d3da2a2e7c25e3af3e6907f7b4
isset() does two things: It checks if a variable (or array element)
is declared, *and* it checks if it is null. If a variable is null,
isset() fails as if the variable was not set. All these additional
null checks are dead code.
Change-Id: I71e8cc26dac839c9d081bf00b4164b7b5147e586
Follows-up d4045035b0.
This class was added to the MediaWiki\Special namespace, contrary to the
plan in T166010 which reserves that namespace for core special pages.
Instead, use MediaWiki\SpecialPage, following the directory in which it
is located.
Also, fix two bugs which prevented the introduction of a namespaced
class alias.
Bug: T166010
Change-Id: I6e31340aaae32a89beb7e45b79d76a7fea9808d2
1. into class Parser
2. into class LinkHoderArray
3. into class DefaultPreferencesFactory
Add more tests for DefaultPreferencesFactory:
1. testVariantsSupport verifies that converter with variants is used correctly.
2. Test testUserGroupMemberships verifies that membership is used correctly
Bug: T243320, T243321, T243317
Change-Id: I1e5c37e18332d0d32391c74c06e3d84862e48df8
Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
Parser::magicLinkCallback() and Parser::makeFreeExternalLink() are not
called from outside the parser and have been made private.
Parser::attributeStripCallback() did have one use outside MediaWiki core,
so it has been deprecated rather than made private. The one use inside
the parser has been converted to an anonymous callback.
Code search:
https://codesearch.wmflabs.org/search/?q=magicLinkCallback%7CmakeFreeExternalLink%7CattributeStripCallback&i=nope&files=&repos=
Change-Id: Id909b745f9dea1481d09de4747f4aa32648bf85b
This is an odd "partial parse" endpoint which won't be supported by
the unified Parsoid parser. Most places it appears in our codebase
it is just a name-check, mostly complaining about how broken it is.
It is not called by any WMF-deployed code.
Code search:
https://codesearch.wmflabs.org/search/?q=doBlockLevels&i=fosho&files=&repos=
Change-Id: Iad2a1e5ed593c1f6299b8b45e4390b415537c84c
This reduces the API surface of Parser, in preparation for further
refactoring of the Parser class. Parser::fetchTemplateAndTitle() was
introduced in MW 1.6.0 in 2007, so is always appropriate as a replacement.
Code search:
https://codesearch.wmflabs.org/search/?q=fetchTemplate%5C%28&i=nope&files=&repos=
Depends-On: I2865b12b55aa1412a861fb8db10239018a1d1580
Change-Id: I6f7c3e31ff394781fbaaef267a2772de05f85bf2
This no longer has any effect. The getter and setter in ParserOptions
aren't used in any public git code, and so have been removed without
deprecation.
Bug: T204945
Followup-To: I727f003f9a42d0c92bcbcce8a8289d5af6cd1298
Change-Id: Id48effcba48d1ae1621a4e17a70e65b73f2473b7
Remove the deprecated Preprocessor_DOM class, which was hard-deprecated
in 1.34. This begins to simplify parser configuration and reduce redundant
code paths, but I've left two things for cleanup in a future patch:
1. The `preprocessorClass` configuration option to the parser, exposed
in `$wgParserConf`, ServiceWiring, ParserFactory, etc. There is no reason
for this to be exposed as configurable, but I've left this clean up to a
future patch.
2. The `$wgMaxGeneratedPPNodeCount` configuration, exposed also in
ParserOptions. Only Preprocessor_DOM calculated this count, and since
we are only using Preprocessor_Hash now, this configuration has no effect.
But since this value was exposed in ParserOptions and elsewhere, I've
deprecated where needed but left this clean up to a future patch.
Bug: T204945
Change-Id: I727f003f9a42d0c92bcbcce8a8289d5af6cd1298
Introduced in 2015 via If83b062. Unfortunately the patch fails to mention
why the hook was introduced. A review comment asking for the missing
information was ignored.
The hook was introduced exclusively for the Cite extension, see I0e136f9.
The Cite change got reverted a few days later via I1a71854. As far as I
can tell the hook (oddly specific and underspecified anyway) was never
used again, neither for Cite nor for anything else.
Now unused: https://codesearch.wmflabs.org/search/?q=ParserAfterUnstrip
I suggest to just remove it with no deprecation phase.
My team is currently working on Cite, essentially turning it upside down.
I'm not aware of a need for this hook.
Change-Id: If68a88d7afff60385ff1e33fd13716b20d01a313
Follows-up c537eb1868.
The restrictions used to only apply to "content" namespaces, which
is typically just NS_MAIN. Wikis like Commons and Wikidata use custom
values, NS_FILE and $LexemeNamespace, respectively.
Now, only yield the integer ID for user, project, and talk pages.
This means that NS_FILE, NS_CATEGORY, and other namespaces with
content intended for readers, only yield '' or '-' for this work.
Bug: T235957
Change-Id: Id0110c9ee91ad5750164e9a047bcd6d7621930c1
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
This reverts commit c16b0a533e0d7350bceca7ccbe490efa3e3ce4c4, now
that an appropriate period of time has passed since this behavior
was deprecated.
Bug: T235392
Change-Id: I076ae0dbfbbb8be731367e4641f9c8aacf7586e9
It was deprecated in 1.31, It was a failed experiment, intended to
improve performance, but it never worked and makes the code
much more complex. I also removed two LinkHolderArray helpers which were
accidentally not marked deprecated -- codesearch confirms that they are
not called by anything.
Change-Id: I74754265dde388b590f0b4c995cb4a35a1318299
Affected:
Parser::armorLinks()
Parser::makeKnownLinkHolder()
Parser::getImageParams()
Parser::parseLinkParameter()
Parser::stripAltText()
It wasn't obvious there was a better name for these, so just rename
them with a `...Private` suffix and deprecate the old names. When
the deprecated public methods are removed we'll rename the private
methods to remove the `...Private` suffix again.
Code search:
https://codesearch.wmflabs.org/deployed/?q=armorLinks%7CmakeKnownLinkHolder%7CgetImageParams%7CparseLinkParameter%7CstripAltText&i=nope&files=&repos=
Bug: T236810
Change-Id: I44458490fa86abd0ead048a4c94021da6be333f0
The following public methods were renamed and made private; the old name
is hard-deprecated and calls the new renamed private method:
Parser::doMagicLinks() => handleMagicLinks()
Parser::doDoubleUnderscore() => handleMagicLinks()
Parser::doHeadings() => handleHeadings()
Parser::doAllQuotes() => handleAllQuotes()
Parser::replaceExternalLinks() => handleExternalLinks()
Parser::replaceInternalLinks() => handleInternalLinks()
Parser::replaceInternalLinks2() => handleInternalLinks2()
Parser::getVariableValue() => expandMagicVariable()
Parser::initialiseVariables() => initializeVariables()
Parser::formatHeadings() => finalizeHeadings()
Parser::test{Pst,Preprocess,Srvus}() => fuzzTest{Pst,Preprocess,Srvus}()
Additionally, the following methods are not used externally, but are
used outside the Parser class by core code. They have been marked
@internal:
Parser::doQuotes() (used by {{#displaytitle}}),
Parser::getExternalLink{Rel,Attribs}() (used by Linker),
Parser::normalizeLinkUrl() (used by Special:LinkSearch and elsewhere).
Parser::{brace,arg,extension}Substitution() (used by PPFrame)
Code search query:
https://codesearch.wmflabs.org/deployed/?q=do%28MagicLinks%7CDoubleUnderscore%7CHeadings%7CAllQuotes%29%7Creplace%28ExternalLinks%7CInternalLinks%28%7C2%29%29%7CgetVariableValue%7CinitialiseVariables%7CformatHeadings%7Ctest%28Pst%7CPreprocess%7CSrvus%29%7CdoQuotes%7CgetExternalLink%28Rel%7CAttribs%29%7CnormalizeLinkUrl%7C%28brace%2Carg%2Cextension%29Substitution&i=nope&files=&repos=
Bug: T236810
Change-Id: I19a43ffc5dcfdd2981b51079c33422c964acb076
getConverterLanguage is deprecated since MediaWiki 1.32.
getConverterLanguage always return a Language object and never null.
Change-Id: Ia0480c76416ef1e925619d9e85c7134c2ecf2296
Depends-On: Iea4771161d129c49f6482e1a6822e1324bf2fb49
This never happens in core code; however extensions have slipped into
a state of sin.
Bug: T235392
Change-Id: Ia254949cd8b3bc162b11dcc911dcce40d91bf1b7
* This ensures we run all necessary hooks that extensions expect
will be run for their content.
* We will rip out this method once we decide / discover that we don't
need it anymore.
Change-Id: I683bd6c3cc2c3f4d65326adab78cdf70ae39a51a
This change reverts most of commit 3dff713fe4.
Especially the return type hints for getTitle() and Title() are reduced
to allow the type null as return value, because SematicMediaWiki uses
this by
$this->parser->getTitle() instanceof Title
to check if there is a valid Title object.
The parameter type hints for setTitle() and Title() are kept.
Bug: T235392
Change-Id: I72ac1c9d37059876dbc7cd38158e7abd212da8fe
These were all checked with codesearch to ensure nothing is overriding
these methods.
For the most part, I've updated the signature to use nullable types; for
two Pager's, I've just made all parameters non-optional, because you're
already forced to pass them with a required parameter at the end.
Bug: T231636
Change-Id: Ie047891f55fcd322039194cfa9a8549e4f1f6f14
getTitle() and Title() will never return NULL anymore. When mTitle is
not set then a TypeError be thrown at runtime. The explicit local
checks for is_null( $this->mTitle ) are not needed anymore when
$this-getTitle() instead of $this->mTitle is used.
Change-Id: I09a178e5c6938954edb2949f13660227d6a01fbc
These are reported by phan as PhanTypeMismatchArgumentNullableInternal
when null_casts_as_any_type is disabled.
Change-Id: I85076ee31c1bfc59a19600e84da0d915e425890a
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
