Add hook interfaces which were generated by a script which parses
hooks.txt and identifies caller namespaces and directories.
Hook interfaces are mostly placed in a Hook/ subdirectory
relative to the caller location. When there are callers in multiple
directories, a "primary" caller was manually selected. The exceptions to
this are:
* The source root, maintenance and tests, which use includes/Hook. Test
hooks need to be autoloadable in a non-test request so that
implementing test interfaces in a generic handler will not fail.
* resources uses includes/resourceloader/Hook
* The following third-level subdirectories had their hooks placed in
the parent ../Hook:
* includes/filerepo/file
* includes/search/searchwidgets
* includes/specials/forms
* includes/specials/helpers
* includes/specials/pagers
Parameters marked as legacy references in hooks.txt are passed
by value in the interfaces.
Bug: T240307
Change-Id: I6efe2e7dd1f0c6a3d0f4d100a4c34e41f8428720
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
This class was last used in ~2008 as @tstarling was developing the
original wikitext Parser. It has since code-rotted and wouldn't work
as a drop in for the Parser class any more anyway. We'll probably
(re)invent something similar when we eventually switch Message
rendering from the legacy parser to Parsoid, but this existing code
isn't a good starting point for that; we'll need to tackle T236812
(splitting Parser into a base class) first.
Last meaningful change to ParserDiffTest:
350b498b9f
Code search:
https://codesearch.wmflabs.org/search/?q=ParserDiffTest&i=nope&files=&repos=
Bug: T236811
Change-Id: I98f1ef8ad296791a810bd8b10343f8640fd23c5e
Amongst other things, this version of phan bundles taint-check, which is
however disabled in the config file because there are lots of issues to
be fixed.
Upgrading phan alone now means that we can have a clean baseline for the taint-check upgrade.
Bug: T248630
Change-Id: I8ab7ef9a9e73952098664176aad6c2b3b88095ee
Updated Doxygen markup in several .php files triggering warnings when mwdocgen.php is executed. Removed
obsolete settings MSCGEN_PATH and TCL_SUBST from Doxyfile. The former would generate a warning in 1.8.16
while TCL support was removed in 1.8.18. Since TCL_SUBST was blank anyway, it was removed prior to getting
to .18 in production. Increased DOT_GRAPH_MAX_NODES from 50 to 200 since Doxygen complained about it being
too low for API and Maintenance.
Bug: T248706
Change-Id: I9c67f0807d1b43089d351263d4f591dee5501f36
Disabling tidy has been deprecated since 1.33. This cleans up the code
paths which still used untidy output.
Bug: T198214
Change-Id: I821ef3b8f59b272d983583d407b2f0794fe1e791
ParserCache work only with WikiPage,remove Article and Page interfaces
Rename WikiPage property names and type hintings
Bug: T248719
Change-Id: I08afded432b059f94538be574a4789e18e89bf03
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
Important for keyboard focusability of elements in order to ensure for
example users with motoric impairments to reach those elements.
This patch does not allow setting tabindex="-1" or tabindex > 0.
tabindex > 1 seems like a terrible idea to allow users to do.
I don't see any valid reason for tabindex="-1" in wikitext, so
lets not allow that for now either.
Bug: T247910
Change-Id: I5065b2deeb14bdb3682dd176b87f254ac6f2cf88
