wiki.techinc.nl/includes/page/PageCommandFactory.php

361 lines
8.7 KiB
PHP
Raw Normal View History

<?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
* @author DannyS712
*/
namespace MediaWiki\Page;
use ActorMigration;
use BagOStuff;
use CommentStore;
use Config;
use ContentModelChange;
use JobQueueGroup;
use MediaWiki\Cache\BacklinkCacheFactory;
use MediaWiki\Collation\CollationFactory;
use MediaWiki\Config\ServiceOptions;
use MediaWiki\Content\IContentHandlerFactory;
use MediaWiki\EditPage\SpamChecker;
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
use MediaWiki\HookContainer\HookContainer;
use MediaWiki\Permissions\Authority;
use MediaWiki\Revision\RevisionStore;
use MediaWiki\Storage\PageUpdaterFactory;
use MediaWiki\User\ActorNormalization;
use MediaWiki\User\UserEditTracker;
use MediaWiki\User\UserFactory;
use MediaWiki\User\UserIdentity;
use MergeHistory;
use MovePage;
use NamespaceInfo;
use Psr\Log\LoggerInterface;
use ReadOnlyMode;
use RepoGroup;
use Title;
use TitleFactory;
use TitleFormatter;
use WatchedItemStoreInterface;
DeletePage: add option to delete the associated talk page Currently this is implemented internally as a second method call. In the future, it might be possible to optimize the implementation, e.g. to reduce the amount of DB queries/jobs etc. without changing anything for callers. Since the implementation of e.g. the result getters is generic, a future commit may add an option to delete subpages with relatively low effort. The revision limit for big deletions is now using the total number of revisions (base page + talk page). This is because both deletions would happen in the same main transaction, and we presumably want to optimize the deletion as a whole, not as two separated steps. This would become even more important if the aforementioned improvements are ever implemented. Note, the whole concept of "big deletion" might have been superseded by batched deletions in the author's opinion, but as long as such a limit exists, it should serve its purpose. The current interpretation of the associated talk option is that the request is validated, and an exception is raised if we cannot delete the associated talk, as opposed to silently ignoring the parameter if the talk cannot be deleted. The only exception to this is that it will not fail hard if the talk page turns out not to exist by the time the deletion is attempted, as that's hard to foresee due to race conditions. Note that the summary for the talk deletion is prefixed with the delete-talk-summary-prefix message. The main reason behind this is that the delete UI can sometimes offer an auto-generated summary like "the only contributor was XXX" or "the content was YYY", and since this may not apply to the talk page as well, the log entry might look confusing. Bug: T263209 Bug: T27471 Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
use Wikimedia\Message\ITextFormatter;
use Wikimedia\Rdbms\LBFactory;
use WikiPage;
/**
* Common factory to construct page handling classes.
*
* @since 1.35
*/
class PageCommandFactory implements
ContentModelChangeFactory,
DeletePageFactory,
MergeHistoryFactory,
MovePageFactory,
RollbackPageFactory,
UndeletePageFactory
{
/** @var Config */
private $config;
/** @var LBFactory */
private $lbFactory;
/** @var NamespaceInfo */
private $namespaceInfo;
/** @var WatchedItemStoreInterface */
private $watchedItemStore;
/** @var RepoGroup */
private $repoGroup;
/** @var ReadOnlyMode */
private $readOnlyMode;
/** @var IContentHandlerFactory */
private $contentHandlerFactory;
/** @var RevisionStore */
private $revisionStore;
/** @var SpamChecker */
private $spamChecker;
/** @var TitleFormatter */
private $titleFormatter;
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
/** @var HookContainer */
private $hookContainer;
/** @var WikiPageFactory */
private $wikiPageFactory;
/** @var UserFactory */
private $userFactory;
/** @var ActorMigration */
private $actorMigration;
/** @var ActorNormalization */
private $actorNormalization;
/** @var TitleFactory */
private $titleFactory;
/** @var UserEditTracker */
private $userEditTracker;
/** @var CollationFactory */
private $collationFactory;
/** @var JobQueueGroup */
private $jobQueueGroup;
/** @var CommentStore */
private $commentStore;
/** @var BagOStuff */
private $mainStash;
/** @var string */
private $localWikiID;
/** @var string */
private $webRequestID;
/** @var BacklinkCacheFactory */
private $backlinkCacheFactory;
/** @var LoggerInterface */
private $undeletePageLogger;
/** @var PageUpdaterFactory */
private $pageUpdaterFactory;
DeletePage: add option to delete the associated talk page Currently this is implemented internally as a second method call. In the future, it might be possible to optimize the implementation, e.g. to reduce the amount of DB queries/jobs etc. without changing anything for callers. Since the implementation of e.g. the result getters is generic, a future commit may add an option to delete subpages with relatively low effort. The revision limit for big deletions is now using the total number of revisions (base page + talk page). This is because both deletions would happen in the same main transaction, and we presumably want to optimize the deletion as a whole, not as two separated steps. This would become even more important if the aforementioned improvements are ever implemented. Note, the whole concept of "big deletion" might have been superseded by batched deletions in the author's opinion, but as long as such a limit exists, it should serve its purpose. The current interpretation of the associated talk option is that the request is validated, and an exception is raised if we cannot delete the associated talk, as opposed to silently ignoring the parameter if the talk cannot be deleted. The only exception to this is that it will not fail hard if the talk page turns out not to exist by the time the deletion is attempted, as that's hard to foresee due to race conditions. Note that the summary for the talk deletion is prefixed with the delete-talk-summary-prefix message. The main reason behind this is that the delete UI can sometimes offer an auto-generated summary like "the only contributor was XXX" or "the content was YYY", and since this may not apply to the talk page as well, the log entry might look confusing. Bug: T263209 Bug: T27471 Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
/** @var ITextFormatter */
private $contLangMsgTextFormatter;
public function __construct(
Config $config,
LBFactory $lbFactory,
NamespaceInfo $namespaceInfo,
WatchedItemStoreInterface $watchedItemStore,
RepoGroup $repoGroup,
ReadOnlyMode $readOnlyMode,
IContentHandlerFactory $contentHandlerFactory,
RevisionStore $revisionStore,
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
SpamChecker $spamChecker,
TitleFormatter $titleFormatter,
HookContainer $hookContainer,
WikiPageFactory $wikiPageFactory,
UserFactory $userFactory,
ActorMigration $actorMigration,
ActorNormalization $actorNormalization,
TitleFactory $titleFactory,
UserEditTracker $userEditTracker,
CollationFactory $collationFactory,
JobQueueGroup $jobQueueGroup,
CommentStore $commentStore,
BagOStuff $mainStash,
string $localWikiID,
string $webRequestID,
BacklinkCacheFactory $backlinkCacheFactory,
LoggerInterface $undeletePageLogger,
DeletePage: add option to delete the associated talk page Currently this is implemented internally as a second method call. In the future, it might be possible to optimize the implementation, e.g. to reduce the amount of DB queries/jobs etc. without changing anything for callers. Since the implementation of e.g. the result getters is generic, a future commit may add an option to delete subpages with relatively low effort. The revision limit for big deletions is now using the total number of revisions (base page + talk page). This is because both deletions would happen in the same main transaction, and we presumably want to optimize the deletion as a whole, not as two separated steps. This would become even more important if the aforementioned improvements are ever implemented. Note, the whole concept of "big deletion" might have been superseded by batched deletions in the author's opinion, but as long as such a limit exists, it should serve its purpose. The current interpretation of the associated talk option is that the request is validated, and an exception is raised if we cannot delete the associated talk, as opposed to silently ignoring the parameter if the talk cannot be deleted. The only exception to this is that it will not fail hard if the talk page turns out not to exist by the time the deletion is attempted, as that's hard to foresee due to race conditions. Note that the summary for the talk deletion is prefixed with the delete-talk-summary-prefix message. The main reason behind this is that the delete UI can sometimes offer an auto-generated summary like "the only contributor was XXX" or "the content was YYY", and since this may not apply to the talk page as well, the log entry might look confusing. Bug: T263209 Bug: T27471 Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
PageUpdaterFactory $pageUpdaterFactory,
ITextFormatter $contLangMsgTextFormatter
) {
$this->config = $config;
$this->lbFactory = $lbFactory;
$this->namespaceInfo = $namespaceInfo;
$this->watchedItemStore = $watchedItemStore;
$this->repoGroup = $repoGroup;
$this->readOnlyMode = $readOnlyMode;
$this->contentHandlerFactory = $contentHandlerFactory;
$this->revisionStore = $revisionStore;
$this->spamChecker = $spamChecker;
$this->titleFormatter = $titleFormatter;
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
$this->hookContainer = $hookContainer;
$this->wikiPageFactory = $wikiPageFactory;
$this->userFactory = $userFactory;
$this->actorMigration = $actorMigration;
$this->actorNormalization = $actorNormalization;
$this->titleFactory = $titleFactory;
$this->userEditTracker = $userEditTracker;
$this->collationFactory = $collationFactory;
$this->jobQueueGroup = $jobQueueGroup;
$this->commentStore = $commentStore;
$this->mainStash = $mainStash;
$this->localWikiID = $localWikiID;
$this->webRequestID = $webRequestID;
$this->backlinkCacheFactory = $backlinkCacheFactory;
$this->undeletePageLogger = $undeletePageLogger;
$this->pageUpdaterFactory = $pageUpdaterFactory;
DeletePage: add option to delete the associated talk page Currently this is implemented internally as a second method call. In the future, it might be possible to optimize the implementation, e.g. to reduce the amount of DB queries/jobs etc. without changing anything for callers. Since the implementation of e.g. the result getters is generic, a future commit may add an option to delete subpages with relatively low effort. The revision limit for big deletions is now using the total number of revisions (base page + talk page). This is because both deletions would happen in the same main transaction, and we presumably want to optimize the deletion as a whole, not as two separated steps. This would become even more important if the aforementioned improvements are ever implemented. Note, the whole concept of "big deletion" might have been superseded by batched deletions in the author's opinion, but as long as such a limit exists, it should serve its purpose. The current interpretation of the associated talk option is that the request is validated, and an exception is raised if we cannot delete the associated talk, as opposed to silently ignoring the parameter if the talk cannot be deleted. The only exception to this is that it will not fail hard if the talk page turns out not to exist by the time the deletion is attempted, as that's hard to foresee due to race conditions. Note that the summary for the talk deletion is prefixed with the delete-talk-summary-prefix message. The main reason behind this is that the delete UI can sometimes offer an auto-generated summary like "the only contributor was XXX" or "the content was YYY", and since this may not apply to the talk page as well, the log entry might look confusing. Bug: T263209 Bug: T27471 Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
$this->contLangMsgTextFormatter = $contLangMsgTextFormatter;
}
/**
* @param Authority $performer
* @param WikiPage $wikipage
* @param string $newContentModel
* @return ContentModelChange
*/
public function newContentModelChange(
Authority $performer,
WikiPage $wikipage,
string $newContentModel
): ContentModelChange {
return new ContentModelChange(
$this->contentHandlerFactory,
$this->hookContainer,
$this->revisionStore,
$this->userFactory,
$performer,
$wikipage,
$newContentModel
);
}
/**
* @inheritDoc
*/
public function newDeletePage( ProperPageIdentity $page, Authority $deleter ): DeletePage {
return new DeletePage(
$this->hookContainer,
$this->revisionStore,
$this->lbFactory,
$this->jobQueueGroup,
$this->commentStore,
new ServiceOptions( DeletePage::CONSTRUCTOR_OPTIONS, $this->config ),
$this->mainStash,
$this->localWikiID,
$this->webRequestID,
$this->wikiPageFactory,
$this->userFactory,
$this->backlinkCacheFactory,
DeletePage: add option to delete the associated talk page Currently this is implemented internally as a second method call. In the future, it might be possible to optimize the implementation, e.g. to reduce the amount of DB queries/jobs etc. without changing anything for callers. Since the implementation of e.g. the result getters is generic, a future commit may add an option to delete subpages with relatively low effort. The revision limit for big deletions is now using the total number of revisions (base page + talk page). This is because both deletions would happen in the same main transaction, and we presumably want to optimize the deletion as a whole, not as two separated steps. This would become even more important if the aforementioned improvements are ever implemented. Note, the whole concept of "big deletion" might have been superseded by batched deletions in the author's opinion, but as long as such a limit exists, it should serve its purpose. The current interpretation of the associated talk option is that the request is validated, and an exception is raised if we cannot delete the associated talk, as opposed to silently ignoring the parameter if the talk cannot be deleted. The only exception to this is that it will not fail hard if the talk page turns out not to exist by the time the deletion is attempted, as that's hard to foresee due to race conditions. Note that the summary for the talk deletion is prefixed with the delete-talk-summary-prefix message. The main reason behind this is that the delete UI can sometimes offer an auto-generated summary like "the only contributor was XXX" or "the content was YYY", and since this may not apply to the talk page as well, the log entry might look confusing. Bug: T263209 Bug: T27471 Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
$this->namespaceInfo,
$this->contLangMsgTextFormatter,
$page,
$deleter
);
}
/**
* @param PageIdentity $source
* @param PageIdentity $destination
* @param string|null $timestamp
* @return MergeHistory
*/
public function newMergeHistory(
PageIdentity $source,
PageIdentity $destination,
string $timestamp = null
): MergeHistory {
return new MergeHistory(
$source,
$destination,
$timestamp,
$this->lbFactory->getMainLB(),
$this->contentHandlerFactory,
$this->revisionStore,
$this->watchedItemStore,
$this->spamChecker,
$this->hookContainer,
$this->wikiPageFactory,
$this->titleFormatter,
$this->titleFactory
);
}
/**
* @param Title $from
* @param Title $to
* @return MovePage
*/
public function newMovePage( Title $from, Title $to ): MovePage {
return new MovePage(
$from,
$to,
new ServiceOptions( MovePage::CONSTRUCTOR_OPTIONS, $this->config ),
$this->lbFactory->getMainLB(),
$this->namespaceInfo,
$this->watchedItemStore,
$this->repoGroup,
$this->contentHandlerFactory,
$this->revisionStore,
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
$this->spamChecker,
$this->hookContainer,
$this->wikiPageFactory,
$this->userFactory,
$this->userEditTracker,
$this,
$this->collationFactory,
$this->pageUpdaterFactory
);
}
/**
* Create a new command instance for page rollback.
*
* @param PageIdentity $page
* @param Authority $performer
* @param UserIdentity $byUser
* @return RollbackPage
*/
public function newRollbackPage(
PageIdentity $page,
Authority $performer,
UserIdentity $byUser
): RollbackPage {
return new RollbackPage(
new ServiceOptions( RollbackPage::CONSTRUCTOR_OPTIONS, $this->config ),
$this->lbFactory->getMainLB(),
$this->userFactory,
$this->readOnlyMode,
$this->revisionStore,
$this->titleFormatter,
$this->hookContainer,
$this->wikiPageFactory,
$this->actorMigration,
$this->actorNormalization,
$page,
$performer,
$byUser
);
}
/**
* @inheritDoc
*/
public function newUndeletePage( ProperPageIdentity $page, Authority $authority ): UndeletePage {
return new UndeletePage(
$this->hookContainer,
$this->jobQueueGroup,
$this->lbFactory->getMainLB(),
$this->readOnlyMode,
$this->repoGroup,
$this->undeletePageLogger,
$this->revisionStore,
$this->wikiPageFactory,
$this->pageUpdaterFactory,
$this->contentHandlerFactory,
$page,
$authority
);
}
}