A new configuration variable $wgUseLegacyParserByDefault will allow opting out (until the next LTS release).
Major components of this work are subtasks:
- T310512: Parsoid and the legacy parser should emit exactly the same ParserOutput metadata
- The way we do this with confidence is via T310511: Metadata comparison testing between Parsoid and the legacy parser: building a testing infrastructure similar to the one we have with visualdiff and round-trip testing so that we can quantify metadata differences between legacy and parsoid.
- T393716: [EPIC] RefreshLinksJob should use Parsoid-generated metadata
- Probably this will use the parallel parsing done in T310511 for comparisons, and then just selectively start using the Parsoid parse instead of the legacy parse (unless $wgUseLegacyParserByDefault is set).
- It is possible this will be a wiki-by-wiki deploy the same way we've done Parsoid Read Views roll out, depending on how the comparison looks.
- T370926: [EPIC] Use Parsoid for UX (optional)
- We can meet our goals for MW 1.47 if UX message parsing is the *only* thing using the legacy parser, but ideally we should at least provide an experimental option to enable use of Parsoid for UX. (Maybe separate config than $useLegacyParserByDefault.)
- T420491: ParserOptions::newFromAnon() should return `useParsoid` set to `true` by default.
- This is a small code change but fixing CI is probably a much larger task: any test which relies on particular parser output will need to be updated.
- The ParserMigration extension should still work, but in an opposite sense (allowing individual users to opt out of Parsoid).
- Our mediawiki-config will have to be flipped, with individual wikis setting $wgUseLegacyParserByDefault=true (or maybe still via the ParserMigration extension).