2016-10-13 08:14:18 +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;
|
|
|
|
|
2020-05-26 17:58:52 +00:00
|
|
|
use ApiQuerySiteinfo;
|
2016-11-22 19:15:32 +00:00
|
|
|
use Content;
|
2024-05-31 22:02:32 +00:00
|
|
|
use JobQueueError;
|
2024-04-04 21:59:34 +00:00
|
|
|
use JobQueueGroup;
|
2022-09-07 01:54:33 +00:00
|
|
|
use MediaWiki\Api\Hook\APIQuerySiteInfoGeneralInfoHook;
|
2024-06-09 16:38:49 +00:00
|
|
|
use MediaWiki\Config\Config;
|
|
|
|
use MediaWiki\Context\IContextSource;
|
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\Deferred\DeferrableUpdate;
|
2024-01-06 16:03:30 +00:00
|
|
|
use MediaWiki\Deferred\MWCallableUpdate;
|
2022-09-07 01:54:33 +00:00
|
|
|
use MediaWiki\Hook\InfoActionHook;
|
|
|
|
use MediaWiki\Hook\ParserLogLinterDataHook;
|
2023-02-07 01:27:16 +00:00
|
|
|
use MediaWiki\Linker\LinkRenderer;
|
2019-11-26 01:02:29 +00:00
|
|
|
use MediaWiki\Logger\LoggerFactory;
|
2024-06-09 16:38:49 +00:00
|
|
|
use MediaWiki\Output\Hook\BeforePageDisplayHook;
|
2024-01-06 16:03:30 +00:00
|
|
|
use MediaWiki\Output\OutputPage;
|
2022-09-07 01:54:33 +00:00
|
|
|
use MediaWiki\Page\Hook\RevisionFromEditCompleteHook;
|
|
|
|
use MediaWiki\Page\Hook\WikiPageDeletionUpdatesHook;
|
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\Page\WikiPageFactory;
|
|
|
|
use MediaWiki\Parser\Parsoid\ParsoidParserFactory;
|
|
|
|
use MediaWiki\Revision\RenderedRevision;
|
2022-02-08 23:19:12 +00:00
|
|
|
use MediaWiki\Revision\RevisionRecord;
|
2024-01-06 16:03:30 +00:00
|
|
|
use MediaWiki\SpecialPage\SpecialPage;
|
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\Storage\Hook\RevisionDataUpdatesHook;
|
2023-08-19 04:17:17 +00:00
|
|
|
use MediaWiki\Title\Title;
|
2022-02-08 23:19:12 +00:00
|
|
|
use MediaWiki\User\UserIdentity;
|
2022-09-07 01:54:33 +00:00
|
|
|
use Skin;
|
2020-01-10 10:06:26 +00:00
|
|
|
use WikiPage;
|
2016-10-13 08:14:18 +00:00
|
|
|
|
2022-09-07 01:54:33 +00:00
|
|
|
class Hooks implements
|
|
|
|
APIQuerySiteInfoGeneralInfoHook,
|
|
|
|
BeforePageDisplayHook,
|
|
|
|
InfoActionHook,
|
|
|
|
ParserLogLinterDataHook,
|
|
|
|
RevisionFromEditCompleteHook,
|
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
|
|
|
WikiPageDeletionUpdatesHook,
|
|
|
|
RevisionDataUpdatesHook
|
2022-09-07 01:54:33 +00:00
|
|
|
{
|
2024-04-04 21:59:34 +00:00
|
|
|
private LinkRenderer $linkRenderer;
|
|
|
|
private JobQueueGroup $jobQueueGroup;
|
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
|
|
|
private ParsoidParserFactory $parsoidParserFactory;
|
|
|
|
private WikiPageFactory $wikiPageFactory;
|
2024-04-04 22:55:43 +00:00
|
|
|
private CategoryManager $categoryManager;
|
2024-04-05 02:20:45 +00:00
|
|
|
private TotalsLookup $totalsLookup;
|
2024-04-11 01:20:43 +00:00
|
|
|
private Database $database;
|
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
|
|
|
private bool $parseOnDerivedDataUpdates;
|
2023-02-07 01:27:16 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @param LinkRenderer $linkRenderer
|
2024-04-04 21:59:34 +00:00
|
|
|
* @param JobQueueGroup $jobQueueGroup
|
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
|
|
|
* @param ParsoidParserFactory $parsoidParserFactory
|
|
|
|
* @param WikiPageFactory $wikiPageFactory
|
2024-04-04 22:55:43 +00:00
|
|
|
* @param CategoryManager $categoryManager
|
2024-04-05 02:20:45 +00:00
|
|
|
* @param TotalsLookup $totalsLookup
|
2024-04-11 01:20:43 +00:00
|
|
|
* @param Database $database
|
2023-02-07 01:27:16 +00:00
|
|
|
*/
|
2024-04-04 21:59:34 +00:00
|
|
|
public function __construct(
|
|
|
|
LinkRenderer $linkRenderer,
|
2024-04-04 22:55:43 +00:00
|
|
|
JobQueueGroup $jobQueueGroup,
|
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
|
|
|
ParsoidParserFactory $parsoidParserFactory,
|
|
|
|
WikiPageFactory $wikiPageFactory,
|
2024-04-04 22:55:43 +00:00
|
|
|
CategoryManager $categoryManager,
|
2024-04-05 02:20:45 +00:00
|
|
|
TotalsLookup $totalsLookup,
|
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
|
|
|
Database $database,
|
|
|
|
Config $config
|
2024-04-04 21:59:34 +00:00
|
|
|
) {
|
2023-02-07 01:27:16 +00:00
|
|
|
$this->linkRenderer = $linkRenderer;
|
2024-04-04 21:59:34 +00:00
|
|
|
$this->jobQueueGroup = $jobQueueGroup;
|
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
|
|
|
$this->parsoidParserFactory = $parsoidParserFactory;
|
|
|
|
$this->wikiPageFactory = $wikiPageFactory;
|
2024-04-04 22:55:43 +00:00
|
|
|
$this->categoryManager = $categoryManager;
|
2024-04-05 02:20:45 +00:00
|
|
|
$this->totalsLookup = $totalsLookup;
|
2024-04-11 01:20:43 +00:00
|
|
|
$this->database = $database;
|
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
|
|
|
$this->parseOnDerivedDataUpdates = $config->get( 'LinterParseOnDerivedDataUpdate' );
|
2023-02-07 01:27:16 +00:00
|
|
|
}
|
|
|
|
|
2016-10-13 08:14:18 +00:00
|
|
|
/**
|
2017-03-10 22:09:17 +00:00
|
|
|
* Hook: BeforePageDisplay
|
2016-10-13 08:14:18 +00:00
|
|
|
*
|
|
|
|
* If there is a lintid parameter, look up that error in the database
|
|
|
|
* and setup and output our client-side helpers
|
|
|
|
*
|
2022-09-07 01:54:33 +00:00
|
|
|
* @param OutputPage $out
|
|
|
|
* @param Skin $skin
|
2016-10-13 08:14:18 +00:00
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onBeforePageDisplay( $out, $skin ): void {
|
2017-03-10 22:09:17 +00:00
|
|
|
$request = $out->getRequest();
|
2016-10-13 08:14:18 +00:00
|
|
|
$lintId = $request->getInt( 'lintid' );
|
|
|
|
if ( !$lintId ) {
|
|
|
|
return;
|
|
|
|
}
|
2017-03-10 22:09:17 +00:00
|
|
|
$title = $out->getTitle();
|
|
|
|
if ( !$title ) {
|
|
|
|
return;
|
|
|
|
}
|
2016-10-13 08:14:18 +00:00
|
|
|
|
2024-04-11 01:20:43 +00:00
|
|
|
$lintError = $this->database->getFromId( $lintId );
|
2016-10-13 08:14:18 +00:00
|
|
|
if ( !$lintError ) {
|
|
|
|
// Already fixed or bogus URL parameter?
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$out->addJsConfigVars( [
|
|
|
|
'wgLinterErrorCategory' => $lintError->category,
|
|
|
|
'wgLinterErrorLocation' => $lintError->location,
|
|
|
|
] );
|
|
|
|
$out->addModules( 'ext.linter.edit' );
|
|
|
|
}
|
2016-11-22 19:15:32 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Hook: WikiPageDeletionUpdates
|
|
|
|
*
|
|
|
|
* Remove entries from the linter table upon page deletion
|
|
|
|
*
|
|
|
|
* @param WikiPage $wikiPage
|
|
|
|
* @param Content $content
|
|
|
|
* @param array &$updates
|
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onWikiPageDeletionUpdates( $wikiPage, $content, &$updates ) {
|
2024-05-04 11:53:17 +00:00
|
|
|
// The article id of the title is set to 0 when the page is deleted so
|
|
|
|
// capture it before creating the callback.
|
|
|
|
$id = $wikiPage->getId();
|
|
|
|
$ns = $wikiPage->getNamespace();
|
|
|
|
|
|
|
|
$updates[] = new MWCallableUpdate( function () use ( $id, $ns ) {
|
2024-04-10 20:52:53 +00:00
|
|
|
$this->totalsLookup->updateStats(
|
2024-05-04 11:53:17 +00:00
|
|
|
$this->database->setForPage( $id, $ns, [] )
|
2024-04-10 20:52:53 +00:00
|
|
|
);
|
2016-12-15 03:43:53 +00:00
|
|
|
}, __METHOD__ );
|
2016-11-22 19:15:32 +00:00
|
|
|
}
|
2016-12-15 03:43:19 +00:00
|
|
|
|
2022-02-25 22:44:27 +00:00
|
|
|
/**
|
|
|
|
* This should match Parsoid's PageConfig::hasLintableContentModel()
|
|
|
|
*/
|
|
|
|
public const LINTABLE_CONTENT_MODELS = [ CONTENT_MODEL_WIKITEXT, 'proofread-page' ];
|
|
|
|
|
2022-02-08 23:19:12 +00:00
|
|
|
/**
|
|
|
|
* Hook: RevisionFromEditComplete
|
|
|
|
*
|
|
|
|
* Remove entries from the linter table upon page content model change away from wikitext
|
|
|
|
*
|
|
|
|
* @param WikiPage $wikiPage
|
|
|
|
* @param RevisionRecord $newRevisionRecord
|
|
|
|
* @param bool|int $originalRevId
|
|
|
|
* @param UserIdentity $user
|
|
|
|
* @param string[] &$tags
|
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onRevisionFromEditComplete(
|
|
|
|
$wikiPage, $newRevisionRecord, $originalRevId, $user, &$tags
|
2022-02-08 23:19:12 +00:00
|
|
|
) {
|
2022-03-02 20:39:37 +00:00
|
|
|
// This is just a stop-gap to deal with callers that aren't complying
|
|
|
|
// with the advertised hook signature.
|
|
|
|
if ( !is_array( $tags ) ) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-02-25 22:44:27 +00:00
|
|
|
if (
|
2022-02-28 22:48:01 +00:00
|
|
|
in_array( "mw-blank", $tags ) ||
|
|
|
|
( in_array( "mw-contentmodelchange", $tags ) &&
|
|
|
|
!in_array( $wikiPage->getContentModel(), self::LINTABLE_CONTENT_MODELS ) )
|
2022-02-08 23:19:12 +00:00
|
|
|
) {
|
2024-04-10 20:52:53 +00:00
|
|
|
$this->totalsLookup->updateStats(
|
2024-04-11 16:24:42 +00:00
|
|
|
$this->database->setForPage(
|
2024-04-10 20:52:53 +00:00
|
|
|
$wikiPage->getId(), $wikiPage->getNamespace(), []
|
|
|
|
)
|
|
|
|
);
|
2022-02-08 23:19:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-15 03:43:19 +00:00
|
|
|
/**
|
|
|
|
* Hook: APIQuerySiteInfoGeneralInfo
|
|
|
|
*
|
|
|
|
* Expose categories via action=query&meta=siteinfo
|
|
|
|
*
|
|
|
|
* @param ApiQuerySiteInfo $api
|
|
|
|
* @param array &$data
|
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onAPIQuerySiteInfoGeneralInfo( $api, &$data ) {
|
2017-04-16 07:36:32 +00:00
|
|
|
$data['linter'] = [
|
2024-04-04 22:55:43 +00:00
|
|
|
'high' => $this->categoryManager->getHighPriority(),
|
|
|
|
'medium' => $this->categoryManager->getMediumPriority(),
|
|
|
|
'low' => $this->categoryManager->getLowPriority(),
|
2017-04-16 07:36:32 +00:00
|
|
|
];
|
2016-12-15 03:43:19 +00:00
|
|
|
}
|
2016-12-15 03:58:18 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Hook: InfoAction
|
|
|
|
*
|
|
|
|
* Display quick summary of errors for this page on ?action=info
|
|
|
|
*
|
|
|
|
* @param IContextSource $context
|
|
|
|
* @param array &$pageInfo
|
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onInfoAction( $context, &$pageInfo ) {
|
2023-02-07 01:27:16 +00:00
|
|
|
$title = $context->getTitle();
|
|
|
|
$pageId = $title->getArticleID();
|
2016-12-15 03:58:18 +00:00
|
|
|
if ( !$pageId ) {
|
|
|
|
return;
|
|
|
|
}
|
2024-04-11 01:20:43 +00:00
|
|
|
$totals = array_filter( $this->database->getTotalsForPage( $pageId ) );
|
2016-12-15 03:58:18 +00:00
|
|
|
if ( !$totals ) {
|
|
|
|
// No errors, yay!
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ( $totals as $name => $count ) {
|
2019-12-17 04:56:34 +00:00
|
|
|
$pageInfo['linter'][] = [
|
|
|
|
$context->msg( "linter-category-$name" ),
|
|
|
|
htmlspecialchars( (string)$count )
|
|
|
|
];
|
2016-12-15 03:58:18 +00:00
|
|
|
}
|
2023-02-07 01:27:16 +00:00
|
|
|
|
|
|
|
$pageInfo['linter'][] = [
|
|
|
|
'below',
|
|
|
|
$this->linkRenderer->makeKnownLink(
|
|
|
|
SpecialPage::getTitleFor( 'LintErrors' ),
|
|
|
|
$context->msg( 'pageinfo-linter-moreinfo' )->text(),
|
|
|
|
[],
|
2023-11-07 18:28:43 +00:00
|
|
|
[ 'wpNamespaceRestrictions' => $title->getNamespace(),
|
|
|
|
'titlesearch' => $title->getText(), 'exactmatch' => 1 ]
|
2023-02-07 01:27:16 +00:00
|
|
|
),
|
|
|
|
];
|
2016-12-15 03:58:18 +00:00
|
|
|
}
|
2019-11-26 01:02:29 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Hook: ParserLogLinterData
|
|
|
|
*
|
|
|
|
* To record a lint errors.
|
|
|
|
*
|
|
|
|
* @param string $page
|
|
|
|
* @param int $revision
|
|
|
|
* @param array[] $data
|
|
|
|
* @return bool
|
|
|
|
*/
|
2022-09-07 01:54:33 +00:00
|
|
|
public function onParserLogLinterData(
|
2019-11-26 01:02:29 +00:00
|
|
|
string $page, int $revision, array $data
|
|
|
|
): bool {
|
|
|
|
$errors = [];
|
|
|
|
$title = Title::newFromText( $page );
|
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
|
|
|
|
2019-11-26 01:02:29 +00:00
|
|
|
if (
|
|
|
|
!$title || !$title->getArticleID() ||
|
|
|
|
$title->getLatestRevID() != $revision
|
|
|
|
) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
$catCounts = [];
|
|
|
|
foreach ( $data as $info ) {
|
2024-04-04 22:55:43 +00:00
|
|
|
if ( $this->categoryManager->isKnownCategory( $info['type'] ) ) {
|
2017-12-07 22:30:14 +00:00
|
|
|
$info[ 'dbid' ] = null;
|
|
|
|
} elseif ( !isset( $info[ 'dbid' ] ) ) {
|
2019-11-26 01:02:29 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$count = $catCounts[$info['type']] ?? 0;
|
|
|
|
if ( $count > Database::MAX_PER_CAT ) {
|
|
|
|
// Drop
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$catCounts[$info['type']] = $count + 1;
|
|
|
|
if ( !isset( $info['dsr'] ) ) {
|
|
|
|
LoggerFactory::getInstance( 'Linter' )->warning(
|
|
|
|
'dsr for {page} @ rev {revid}, for lint: {lint} is missing',
|
|
|
|
[
|
|
|
|
'page' => $page,
|
|
|
|
'revid' => $revision,
|
|
|
|
'lint' => $info['type'],
|
|
|
|
]
|
|
|
|
);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$info['location'] = array_slice( $info['dsr'], 0, 2 );
|
2018-01-09 21:58:15 +00:00
|
|
|
if ( !isset( $info['params'] ) ) {
|
|
|
|
$info['params'] = [];
|
|
|
|
}
|
2019-11-26 01:02:29 +00:00
|
|
|
if ( isset( $info['templateInfo'] ) && $info['templateInfo'] ) {
|
|
|
|
$info['params']['templateInfo'] = $info['templateInfo'];
|
|
|
|
}
|
|
|
|
$errors[] = $info;
|
|
|
|
}
|
2024-05-22 19:06:50 +00:00
|
|
|
|
2024-07-11 22:59:58 +00:00
|
|
|
LoggerFactory::getInstance( 'Linter' )->debug(
|
2024-05-22 19:06:50 +00:00
|
|
|
'{method}: Recording {numErrors} errors for {page}',
|
|
|
|
[
|
|
|
|
'method' => __METHOD__,
|
|
|
|
'numErrors' => count( $errors ),
|
|
|
|
'page' => $page
|
|
|
|
]
|
|
|
|
);
|
|
|
|
|
2019-11-26 01:02:29 +00:00
|
|
|
$job = new RecordLintJob( $title, [
|
|
|
|
'errors' => $errors,
|
|
|
|
'revision' => $revision,
|
2024-04-11 01:20:43 +00:00
|
|
|
], $this->totalsLookup, $this->database );
|
2024-05-31 22:02:32 +00:00
|
|
|
|
|
|
|
try {
|
|
|
|
$this->jobQueueGroup->push( $job );
|
|
|
|
} catch ( JobQueueError $e ) {
|
|
|
|
// Since linting is currently tied up with read views,
|
|
|
|
// don't let a failure to enqueue block a parse.
|
2024-07-03 00:10:49 +00:00
|
|
|
LoggerFactory::getInstance( 'Linter' )->debug(
|
2024-05-31 22:02:32 +00:00
|
|
|
'{method}: Failed to inject job: "{msg}"!',
|
|
|
|
[
|
|
|
|
'method' => __METHOD__,
|
|
|
|
'msg' => $e->getMessage(),
|
|
|
|
]
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2019-11-26 01:02:29 +00:00
|
|
|
return true;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* @param Title $title
|
|
|
|
* @param RenderedRevision $renderedRevision
|
|
|
|
* @param DeferrableUpdate[] &$updates
|
|
|
|
*/
|
|
|
|
public function onRevisionDataUpdates( $title, $renderedRevision, &$updates ) {
|
|
|
|
if ( !$this->parseOnDerivedDataUpdates ) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ( $renderedRevision->getOptions()->getUseParsoid() ) {
|
|
|
|
// Parsoid was already used for the canonical parse, nothing to do:
|
|
|
|
// onParserLogLinterData was already called.
|
|
|
|
// This will be the case when parsoid page views are enabled.
|
|
|
|
// Eventually, ParserLogLinterData will probably go away and we'll
|
|
|
|
// have the lint data in the ParserOutput. We'll then just use
|
|
|
|
// that data to create a RecordLintJob.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ( !in_array( $title->getContentModel(), self::LINTABLE_CONTENT_MODELS ) ) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$updates[] = new LintUpdate(
|
|
|
|
$this->parsoidParserFactory->create(),
|
|
|
|
$this->wikiPageFactory,
|
|
|
|
$renderedRevision
|
|
|
|
);
|
|
|
|
}
|
2016-10-13 08:14:18 +00:00
|
|
|
}
|