Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
<?php
|
|
|
|
/**
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
*
|
|
|
|
* @file
|
|
|
|
*/
|
|
|
|
|
|
|
|
namespace MediaWiki\Linter\Test;
|
|
|
|
|
|
|
|
use MediaWiki\Content\JavaScriptContent;
|
2024-09-17 17:29:51 +00:00
|
|
|
use MediaWiki\Content\JavaScriptContentHandler;
|
2024-10-20 07:25:08 +00:00
|
|
|
use MediaWiki\Content\WikitextContent;
|
2024-09-17 17:29:51 +00:00
|
|
|
use MediaWiki\Content\WikitextContentHandler;
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
use MediaWiki\Linter\LintUpdate;
|
|
|
|
use MediaWiki\MainConfigNames;
|
|
|
|
use MediaWiki\Parser\ParserOutput;
|
|
|
|
use MediaWiki\Revision\MutableRevisionRecord;
|
|
|
|
use MediaWiki\Revision\RenderedRevision;
|
|
|
|
use MediaWiki\Revision\RevisionRecord;
|
|
|
|
use MediaWiki\Revision\SlotRecord;
|
|
|
|
use MediaWikiIntegrationTestCase;
|
|
|
|
use RefreshLinksJob;
|
|
|
|
use WikiPage;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @group Database
|
|
|
|
* @covers \MediaWiki\Linter\LintUpdate
|
|
|
|
*/
|
|
|
|
class LintUpdateTest extends MediaWikiIntegrationTestCase {
|
|
|
|
|
|
|
|
protected function setUp(): void {
|
|
|
|
parent::setUp();
|
|
|
|
|
2024-10-02 20:54:01 +00:00
|
|
|
$this->overrideConfigValues( [
|
|
|
|
MainConfigNames::ParsoidSettings => [
|
|
|
|
'linting' => true
|
|
|
|
],
|
|
|
|
'LinterParseOnDerivedDataUpdate' => true,
|
|
|
|
// Ensure that parser cache contents don't
|
|
|
|
// affect tests.
|
|
|
|
'ParserCacheType' => CACHE_NONE,
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
] );
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Assert that we trigger a parse, and that parse triggers onParserLogLinterData,
|
|
|
|
* and in turn triggers the ParserLogLinterData hook via Parsoid.
|
|
|
|
*/
|
|
|
|
public function testUpdate() {
|
|
|
|
// NOTE: This performs an edit, so do it before installing the temp hook below!
|
|
|
|
$rrev = $this->newRenderedRevision();
|
|
|
|
|
|
|
|
$hookCalled = false;
|
|
|
|
$this->setTemporaryHook( 'ParserLogLinterData', static function () use ( &$hookCalled ) {
|
|
|
|
$hookCalled = true;
|
|
|
|
}, false );
|
|
|
|
|
2024-09-17 17:29:51 +00:00
|
|
|
$update = $this->newLintUpdate( $rrev );
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$update->doUpdate();
|
|
|
|
|
|
|
|
$this->assertTrue( $hookCalled );
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Assert that we don't parse if the content model is not supported.
|
|
|
|
*/
|
|
|
|
public function testSkipModel() {
|
2024-09-17 17:29:51 +00:00
|
|
|
$contentHandler = $this->createNoOpMock(
|
|
|
|
JavaScriptContentHandler::class,
|
|
|
|
[ 'getParserOutput' ]
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
);
|
2024-09-17 17:29:51 +00:00
|
|
|
$contentHandler->expects( $this->never() )->method( 'getParserOutput' );
|
|
|
|
$contentHandlers = $this->getConfVar( MainConfigNames::ContentHandlers );
|
|
|
|
$this->overrideConfigValue( MainConfigNames::ContentHandlers, [
|
|
|
|
CONTENT_MODEL_JAVASCRIPT => [
|
|
|
|
'factory' => fn () => $contentHandler,
|
|
|
|
],
|
|
|
|
] + $contentHandlers );
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
|
|
|
$page = $this->getExistingTestPage();
|
|
|
|
$rev = new MutableRevisionRecord( $page );
|
|
|
|
$rev->setSlot(
|
|
|
|
SlotRecord::newUnsaved(
|
|
|
|
SlotRecord::MAIN,
|
2024-09-17 17:29:51 +00:00
|
|
|
new JavascriptContent( '{}' )
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
)
|
|
|
|
);
|
2024-10-02 20:54:01 +00:00
|
|
|
// Clear the local cache in the ParserOutputAccess
|
|
|
|
$this->resetServices();
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
2024-09-17 17:29:51 +00:00
|
|
|
$update = $this->newLintUpdate( $this->newRenderedRevision( $page, $rev ) );
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$update->doUpdate();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Assert that we don't parse if the given revision is no longer the
|
|
|
|
* latest revision.
|
|
|
|
*/
|
|
|
|
public function testSkipOld() {
|
2024-09-17 17:29:51 +00:00
|
|
|
// This may use the "real" wikitext content handler
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$page = $this->getExistingTestPage();
|
|
|
|
$rev = new MutableRevisionRecord( $page );
|
|
|
|
$rev->setSlot(
|
|
|
|
SlotRecord::newUnsaved(
|
|
|
|
SlotRecord::MAIN,
|
|
|
|
new WikitextContent( 'bla bla' )
|
|
|
|
)
|
|
|
|
);
|
|
|
|
|
|
|
|
// make it not the current revision
|
|
|
|
$rev->setId( $page->getLatest() - 1 );
|
2024-09-17 17:29:51 +00:00
|
|
|
$newRev = $this->newRenderedRevision( $page, $rev );
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
2024-09-17 17:29:51 +00:00
|
|
|
// Ok, now set up a mock content handler for the remainder
|
|
|
|
$contentHandler = $this->createNoOpMock(
|
|
|
|
WikitextContentHandler::class,
|
|
|
|
[ 'getParserOutput' ]
|
|
|
|
);
|
|
|
|
$contentHandler->expects( $this->never() )->method( 'getParserOutput' );
|
|
|
|
$contentHandlers = $this->getConfVar( MainConfigNames::ContentHandlers );
|
|
|
|
$this->overrideConfigValue( MainConfigNames::ContentHandlers, [
|
|
|
|
CONTENT_MODEL_WIKITEXT => [
|
|
|
|
'factory' => fn () => $contentHandler,
|
|
|
|
],
|
|
|
|
] + $contentHandlers );
|
|
|
|
|
2024-10-02 20:54:01 +00:00
|
|
|
// Clear the local cache in the ParserOutputAccess
|
|
|
|
$this->resetServices();
|
|
|
|
|
2024-09-17 17:29:51 +00:00
|
|
|
$update = $this->newLintUpdate( $newRev );
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$update->doUpdate();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Assert that a LintUpdate is triggered on edit through the RevisionDataUpdates
|
|
|
|
* hook, and in turn triggers the ParserLogLinterData hook via Parsoid.
|
|
|
|
*
|
|
|
|
* @covers \MediaWiki\Linter\Hooks::onRevisionDataUpdates
|
|
|
|
*/
|
|
|
|
public function testPageEditIntegration() {
|
2024-10-02 20:54:01 +00:00
|
|
|
// Clear the local cache in the ParserOutputAccess
|
|
|
|
$this->resetServices();
|
|
|
|
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$hookCalled = 0;
|
|
|
|
$this->setTemporaryHook( 'ParserLogLinterData', static function () use ( &$hookCalled ) {
|
|
|
|
$hookCalled++;
|
|
|
|
}, false );
|
|
|
|
|
|
|
|
$status = $this->editPage( 'JustSomePage', new WikitextContent( 'hello world' ) );
|
|
|
|
|
|
|
|
$this->assertSame( 1, $hookCalled );
|
|
|
|
|
|
|
|
$page = $this->getServiceContainer()->getWikiPageFactory()
|
|
|
|
->newFromTitle( $status->getNewRevision()->getPage() );
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Assert that a LintUpdate is triggered from RefreshLinksJob through the
|
|
|
|
* RevisionDataUpdates hook, and in turn triggers the ParserLogLinterData
|
|
|
|
* hook via Parsoid.
|
|
|
|
*
|
|
|
|
* @covers \MediaWiki\Linter\Hooks::onRevisionDataUpdates
|
|
|
|
*/
|
|
|
|
public function testRefreshLinksJobIntegration() {
|
|
|
|
// NOTE: This performs an edit, so do it before installing the temp hook below!
|
|
|
|
$page = $this->getExistingTestPage();
|
2024-10-02 20:54:01 +00:00
|
|
|
// Clear the local cache in the ParserOutputAccess
|
|
|
|
$this->resetServices();
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
|
|
|
$hookCalled = 0;
|
|
|
|
$this->setTemporaryHook( 'ParserLogLinterData', static function () use ( &$hookCalled ) {
|
|
|
|
$hookCalled++;
|
|
|
|
}, false );
|
|
|
|
|
|
|
|
$job = new RefreshLinksJob( $page, [] );
|
|
|
|
$job->run();
|
|
|
|
$this->assertSame( 1, $hookCalled );
|
|
|
|
}
|
|
|
|
|
2024-10-26 13:06:43 +00:00
|
|
|
private function newRenderedRevision( ?WikiPage $page = null, ?RevisionRecord $rev = null ) {
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$page = $this->getExistingTestPage();
|
|
|
|
$title = $page->getTitle();
|
|
|
|
|
|
|
|
$rev ??= $this->getServiceContainer()->getRevisionLookup()->getRevisionByTitle( $title );
|
|
|
|
$pOpt = $page->makeParserOptions( 'canonical' );
|
|
|
|
|
|
|
|
$rrev = new RenderedRevision(
|
|
|
|
$rev,
|
|
|
|
$pOpt,
|
|
|
|
$this->getServiceContainer()->getContentRenderer(),
|
|
|
|
static function () {
|
|
|
|
}
|
|
|
|
);
|
|
|
|
|
|
|
|
$rrev->setRevisionParserOutput( new ParserOutput( 'testing' ) );
|
2024-10-02 20:54:01 +00:00
|
|
|
// Clear the local cache in the ParserOutputAccess
|
|
|
|
$this->resetServices();
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
|
|
|
return $rrev;
|
|
|
|
}
|
|
|
|
|
2024-09-17 17:29:51 +00:00
|
|
|
private function newLintUpdate( RenderedRevision $renderedRevision ) {
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$wikiPageFactory = $this->getServiceContainer()->getWikiPageFactory();
|
2024-10-02 20:54:01 +00:00
|
|
|
$parserOutputAccess = $this->getServiceContainer()->getParserOutputAccess();
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
|
|
|
|
return new LintUpdate(
|
|
|
|
$wikiPageFactory,
|
2024-10-02 20:54:01 +00:00
|
|
|
$parserOutputAccess,
|
Trigger Parsoid run when page metadata is being updated
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
2024-04-19 09:59:00 +00:00
|
|
|
$renderedRevision
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|