Change Details

ContentHandler::makeParserOptions() should be removed since it is ill-conceived, and incompatible with the idea of MCR: Ill-conceived because the only reason to have it would be content-specific options, which would be set depending on some outside factor like user options. But that kind of thing should not exist: MediaWiki core should be able to have definite knowledge of what parameters influence parsing, to enable caching, etc. Incompatible with MCR because the need for constructing a combined ParserOutput object. Which ContentHandler should control the options for the combined output?

ContentHandler::makeParserOptions() should be removed since it is ill-conceived, and incompatible with the idea of MCR: Ill-conceived because the only reason to have it would be content-specific options, which would be set depending on some outside factor like user options. But that kind of thing should not exist: MediaWiki core should be able to have definite knowledge of what parameters influence parsing, to enable caching, etc. Incompatible with MCR because the need for constructing a combined ParserOutput object. Which ContentHandler should control the options for the combined output? The creation of canonical ParserOptions could be left to a RevisionRenderer (T194048) or some kind of PageTypeHandler. For now, it probably OK to move the logic to WikiPage::makeParserOptions(). Or have it in DerivedPageDataUpdater::getCanonicalParserOptions() directly. But we'll still need WikiPage::makeParserOptions() to work, for backwards compatibility. It's used quite a bit. On the other hand, WikiPage is going to be deprecated as the MCR refactoring progresses.

ContentHandler::makeParserOptions() should be removed since it is ill-conceived, and incompatible with the idea of MCR: Ill-conceived because the only reason to have it would be content-specific options, which would be set depending on some outside factor like user options. But that kind of thing should not exist: MediaWiki core should be able to have definite knowledge of what parameters influence parsing, to enable caching, etc. Incompatible with MCR because the need for constructing a combined ParserOutput object. Which ContentHandler should control the options for the combined output? The creation of canonical ParserOptions could be left to a RevisionRenderer (T194048) or some kind of PageTypeHandler. For now, it probably OK to move the logic to WikiPage::makeParserOptions(). Or have it in DerivedPageDataUpdater::getCanonicalParserOptions() directly. But we'll still need WikiPage::makeParserOptions() to work, for backwards compatibility. It's used quite a bit. On the other hand, WikiPage is going to be deprecated as the MCR refactoring progresses.