Change Details

In order to allow VisualEditor to use Parsoid in MediaWiki core directly, we need Parsoid output to pre pre-generated and stored in the ParserCache. "on every edit" in the task description is an attempt at being concise, see T320534#8627356 for a more detailed explanation of when this parsing/storage will happen. [x] beta [x] testwiki (and labtestwiki?) https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/843955 [ ] officewiki [ ] labswiki (aka wikitech) [x] mediawikiwiki [x] hewiki (group1, consistent use of VE, not so big it might flood parser cache) [ ] ... [ ] all wikis Relevant config for probabilistic pre-warming trigegred by requests coming from RESTbase to the Parsoid endpoints: ```lang=php wgTemporaryParsoidHandlerParserCacheWriteRatio = '1.0'; ``` This is preferred during roll-out, since parsing will happen on the dedicated parsoid cluster. Relevant configuration for native pre-warming (blocked on using the JobQueue): ```lang=php wgParsoidCacheConfig = [ 'StashType' => null, // see T320536 'StashDuration' => 24 * 60 * 60, // after one day, edits may fail 'CacheThresholdTime' => 0.0, // 0 means cache all 'WarmParsoidParserCache' => true, // enable cache warming ] ``` Parsoid will use the backend configured in `$wgParserCacheType`, with the key prefix `"parsoid"`. If we need to be able to configure the backend separately, we will need to introduce a new config setting for it and pass it into `ParserCacheFactory`. NOTE: This may double the storage capacity needed for ParserCache. Though parsoid output is less fragmented, so it may not be quite that much. NOTE: Keep DBAs posten on where this is being enabled where, it has the potential to overload the ParserCache database servers! See the `'parsercache-dbs'` key in `ProductionServices.php`.

In order to allow VisualEditor to use Parsoid in MediaWiki core directly, we need Parsoid output to pre pre-generated and stored in the ParserCache. "on every edit" in the task description is an attempt at being concise, see T320534#8627356 for a more detailed explanation of when this parsing/storage will happen. [x] beta [x] testwiki (and labtestwiki?) https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/843955 [x] officewiki [ ] labswiki (aka wikitech) [x] mediawikiwiki [x] hewiki (group1, consistent use of VE, not so big it might flood parser cache) [x] all wikis Relevant config for probabilistic pre-warming trigegred by requests coming from RESTbase to the Parsoid endpoints: ```lang=php wgTemporaryParsoidHandlerParserCacheWriteRatio = '1.0'; ``` This is preferred during roll-out, since parsing will happen on the dedicated parsoid cluster. Relevant configuration for native pre-warming (blocked on using the JobQueue): ```lang=php wgParsoidCacheConfig = [ 'StashType' => null, // see T320536 'StashDuration' => 24 * 60 * 60, // after one day, edits may fail 'CacheThresholdTime' => 0.0, // 0 means cache all 'WarmParsoidParserCache' => true, // enable cache warming ] ``` Parsoid will use the backend configured in `$wgParserCacheType`, with the key prefix `"parsoid"`. If we need to be able to configure the backend separately, we will need to introduce a new config setting for it and pass it into `ParserCacheFactory`. NOTE: This may double the storage capacity needed for ParserCache. Though parsoid output is less fragmented, so it may not be quite that much. NOTE: Keep DBAs posten on where this is being enabled where, it has the potential to overload the ParserCache database servers! See the `'parsercache-dbs'` key in `ProductionServices.php`.

In order to allow VisualEditor to use Parsoid in MediaWiki core directly, we need Parsoid output to pre pre-generated and stored in the ParserCache. "on every edit" in the task description is an attempt at being concise, see T320534#8627356 for a more detailed explanation of when this parsing/storage will happen. [x] beta [x] testwiki (and labtestwiki?) https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/843955 [ x] officewiki [ ] labswiki (aka wikitech) [x] mediawikiwiki [x] hewiki (group1, consistent use of VE, not so big it might flood parser cache) [ ] ... [ x] all wikis Relevant config for probabilistic pre-warming trigegred by requests coming from RESTbase to the Parsoid endpoints: ```lang=php wgTemporaryParsoidHandlerParserCacheWriteRatio = '1.0'; ``` This is preferred during roll-out, since parsing will happen on the dedicated parsoid cluster. Relevant configuration for native pre-warming (blocked on using the JobQueue): ```lang=php wgParsoidCacheConfig = [ 'StashType' => null, // see T320536 'StashDuration' => 24 * 60 * 60, // after one day, edits may fail 'CacheThresholdTime' => 0.0, // 0 means cache all 'WarmParsoidParserCache' => true, // enable cache warming ] ``` Parsoid will use the backend configured in `$wgParserCacheType`, with the key prefix `"parsoid"`. If we need to be able to configure the backend separately, we will need to introduce a new config setting for it and pass it into `ParserCacheFactory`. NOTE: This may double the storage capacity needed for ParserCache. Though parsoid output is less fragmented, so it may not be quite that much. NOTE: Keep DBAs posten on where this is being enabled where, it has the potential to overload the ParserCache database servers! See the `'parsercache-dbs'` key in `ProductionServices.php`.