ParserOutput::getText() is not a simple getter, but does
transformations on the "text" of the ParserOutput; the simple getter
is named ::getRawText().
To maintain consistency, rename ParserOutput::setText() to
::setRawText() and the property name ParserOutput::$mText to
::$mRawText so future readers are not confused.
The JSON property name as it appears in the serialized ParserCache
is left as 'Text' so that we don't have any forward- or backward-
rollback issues.
Change-Id: I3ef34814ab9473cc70d0a6806e8c5a4a02b73491
This has been replaced by ::getLinkTarget(), which returns a Parsoid
LinkTarget. This is identical to the core LinkTarget interface, but
we can't quite alias them for technical reasons (sigh). In actual
practice, LinkTargets generated by core are usually Title objects, so
Title::newFromLinkTarget() is a no-op that just returns the argument
after a type check.
It appears that newer code uses a TitleFormatter rather than calling
methods on Title, but TitleFormatter currently takes LinkTarget not a
ParsoidLinkTarget. That would force us to go via
TitleValue::newFromLinkTarget() which isn't a simple type check.
Change-Id: I490bb38108d0202b43ea2a9b391b2e664e7d2d48
This follows the deprecation of PageConfig::getTitle() in Parsoid.
Depends-On: Id3c3ff34a0c796ed0956cb9fb73247056e68667b
Change-Id: I9a24e765bfe914c5ba8496d01b0f9e1bac1c6aea
Call getRawText() and extract the body instead of calling getText()
which invokes the full output transform pipeline which is both
unncessary and could potentially introduce subtle bugs by running
output transforms on nested document content (since output stages
could set parser output config vars, extension data, etc.).
Change-Id: I82aaad965d3d0dd0366b9f3a1891e79ed316d29d
This reverts commit 0791724ead.
Reason for revert: Breaks math rendering in Parsoid (and hence for all clients)
Change-Id: I9abe07060e5d11a9a1a2c953344eb50d4536e8c4
DataAccess::getPageInfo takes a full PageConfig object only to use its
title string. Passing the title string directly allows us to use this
method in other contexts (such as OutputTransform) where PageConfig is
not available.
Change-Id: Ia5c7648caff0818a83df1383d42050e2c68b7799
* See T351461 and T303015 for examples where calling top-level doc
parser hooks during extension processing causes problems further
downstream.
The hooks are: ParserAfterTidy and ParserAfterParse
* Since any extension that relies on those two hooks will need a
Parsoid-equivalent implementation to work properly with Parsoid,
we don't need to preemptively run those hooks on a sublevel doc.
We can instead let the Parsoid-compatible implementation process
the full doc.
* Accordingly, this patch removes the parseExtensionTagAsTopLevelDoc
method from Parser.php and has DataAccess::parseWikitext simply
call Parser::recursiveTagParseFully instead.
Change-Id: I58e693499e1a53e0814911dc2ea424aa822b8320
* I had already used this on one property of one file here
and noticed that Isabelle used this on a newly created
class in output transform and that prompted me to switch
over all these files.
* I am about to start adding new files here for new hooks for
DiscussionTools and updated everything in this namesspace
to keep usage consistent.
* This exposed initialization and bad typing issues in
SiteConfig.php and LanguageVariantConverter.php
Change-Id: I35f131a8f584ccc82a915dbfb1b50b3ef1ec6b06
This nominally takes a string-valued language code conforming to the
BCP-47 standard, but this is often generated from a Bcp47Code object.
Since the MediaWiki Language code implements Bcp47Code, we may have
the case where we have a Language object in hand (but typed as a
Bcp47Code not Language) and call Language::toBcp47Code() only to pass
it to LanguageCode::bcp47ToInternal to convert it back to a
mediawiki-internal code.
We can save steps and be more efficient if allow the parameter to be a
Bcp47Code object, and write a fast path for the special case where
that Bcp47Code happens to be a Language object and we can simply call
Language::getCode() to obtain the internal code.
Change-Id: I24932449b8c40e3a5072748d87667184f4befa67
Remove parser creation from service creation
In ParsoidSiteConfig inject the ParserFactory and call getMainInstance
later, ParsoidSiteConfig is created often without calls to the parser.
For ParsoidDataAccess store the factory and call it when needed.
Bug: T343070
Change-Id: Ib3acadaf190383e4a8b3d266a9fd75c9b20c6649
The db/ directory does not have an owner and it's a mess in general.
These classes don't depend on anything in core except the rdbms library.
Let's simply move it there. In other words, Krinkle made me do it.
Since the class was moved in I6202e52ba73 merged less than a week ago,
no need to alias anything.
Bug: T321882
Change-Id: I24ceeb8bf765a50f441270136acd612359d50aa2
They are not suitable to go to rdbms library as they depend on mediawiki
pieces, the second best place is the db/ directory.
Bug: T321882
Change-Id: I6202e52ba7306d74261206c2ba7930c5f1a0a18e
This reverts commit 42aa5f9481.
Reason for revert: Caused T334753, the proposed fix may need more time for review. Let's revert for now, before the train cut.
Bug: T310453
Bug: T334753
Change-Id: I790604eef00491b7f2a921fb3423a2f727f6593b
Clarify that the classes used to interface MediaWiki with Parsoid are
not for external use and have no stability guarantees. External
clients should use forthcoming support in Parser and
ParserOutputAccess to access Parsoid content and not rely on these
internal classes.
Change-Id: I684fa3ef3e25317c114551de3e2f233c7e84ce6f
Now largely automated:
VARS=$(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | \
tr "\n" '|' | sed "s/|$/\n/;s/'//g")
sed -i -E "s/'($VARS)'/MainConfigNames::\1/g" \
$(grep -ERIl "'($VARS)'" includes/)
Then git add -p with lots of error-prone manual checking. Then
semi-manually add all the necessary "use" lines:
vim $(grep -L 'use MediaWiki\\MainConfigNames;' \
$(git diff --cached --name-only --diff-filter=M HEAD^))
I didn't bother fixing lines that were over 100 characters unless they
were over 120 and triggered phpcs.
Bug: T305805
Change-Id: I74e0ab511abecb276717ad4276a124760a268147
This is moved from TemplateData, but the interface isn't quite right.
Filed T304899 to improve it in the future.
Bug: T304740
Change-Id: Iadd1ed70b72fc282bd5addfc1654aa73322ea470
This hook was formerly defined by Extension:Linter and invoked by
Parsoid, but as this part of Parsoid is moving into core the hook
should now be defined by core as well.
Bug: T304740
Change-Id: Iffd073e510202e5766632cc01d3585815289b7b4
* This is the first step of migrating Parsoid integration code into
core and transitioning Parsoid from an extension to a pure library.
* Parsoid already has conditional code to skip loading Parsoid's
copy of its classes, but it relies on the existence of ParsoidServices.
Technically ParsoidServices isn't needed once Parsoid is migrated to
core -- users can just use MediaWikiServices instead -- but we need
to temporarily add ParsoidServices as a marker class during the
transition.
This version of Parsoid's ServiceWiring comes from Parsoid commit
898c813fd832b3f2d7b5a37f60bd65e8368ce18f.
Bug: T302118
Change-Id: I0b388d93143a782c2c3b72e46407572e5c586e4a
