This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
Throwing exception is not appropriate here and will prevent proper usage
of ArticleDeleteHook, which is ostensibly meant to allow extensions to
cleanly abort the deletion if they need to.
When the target page deletion fails, instead of blowing everything up
with exception, just cancel the open atomic section and return the
user-friendly deletion error back to the user.
Bug: T265779
Change-Id: I66b4458a103f1274715e22a784344c55a62a59ac
This is the last check before moving and update the title on the page
table. Be sure to delete the page too avoid duplicate entry on the
index.
Change-Id: I75582a13bd1feedc072ea8d044470e445a9f6730
A new user right, `delete-redirect`, is added (not given to anyone
by default). At Special:MovePage, if attempting to move to a single
revision redirect that would otherwise be an invalid target (i.e.
doesn't point to the source page), the user is able to delete the
target.
Deletions are logged as `delete/delete_redir2`, and the move is
then logged normally as `move/move`, mirroring current delete and
move logging.
To allow for separate handling by Special:MovePage,
MovePage::isValidMove now returns a fatal status `redirectexists` if
the target isn't valid but passes Title::isSingleRevRedirect.
Otherwise, `articleexists` is returned (as previously). Other callers
that don't intend to treat single revision redirects differently
should treat `redirectexists` the same as `articleexists`.
Currently, this deletion (like normal delete and move) cannot be
done through the move api. Since the deletion is only valid when
moving a page, unlike for normal deletion, deleting redirects with
this right cannot be done via the delete api either.
Bug: T239277
Change-Id: I36c8df0a12d326ae07018046541bd00103936144
These were never meant to be part of the public interface and should not
ever have been marked with @since. They're only useful for constructing
the respective objects, which no outside users should be doing.
Change-Id: I86e01272d46fc72af32172d8a12b9180971d4613
Once the Revision class is hard deprecated, we will still need to
run hooks that use Revision objects; even though the hooks will be
deprecated, Revision objects still need to be created for them.
To ensure that deprecation warnings aren't triggered by creating
Revision objects in deployed code, for deprecated hooks only
create the Revision object if the hook is registered.
All hooks that pass Revision objects have already been hard deprecated.
Bug: T246284
Change-Id: I7e718551822825cd390662bb201dd13e2e527e8b
We intially thought we wouldn't need this and would only need
PageMoveComplete, but it turns out Flow does need it.
Bug: T250023
Bug: T255608
Change-Id: I8e7308541d2fe6d02b9dad63e1c86c89f6e7cf53
This reverts commit 8f7f133ccf.
Per I8cdef229bf0a3, we still need this in Flow for now, to fix a UBN.
Bug: T255608
Change-Id: Id414c98161b9f560b14d4eaec8aedeec4659df27
Clean up some technical debt; use MutableRevisionRecord instead of
manually constructing a Revision from an array, remove last uses of
RevisionStoreDbTestBase::revisionToRow and remove the method.
Each file can be reviewed separately (except that the removal of
revisionToRow depends on replacing its usage)
Bug: T246284
Change-Id: I0bdc069b21a5c41ef8f9e972c5b17ff189d4a741
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
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
Construct a MutableRevisionRecord instead of creating a Revision object
with an array
Bug: T251856
Change-Id: Ia322a2a1faef53522a47974043e8d69a7290ce49
See codesearch - only deployed call outside of core is in flaggedrevs,
and already passes a RevisionRecord:
https://codesearch.wmflabs.org/deployed/?q=-%3EupdateRevisionOn%5C(&i=nope&files=&repos=
Also fixed a use of Revision::newFromId in orphans.php
Bug: T249561
Bug: T249021
Change-Id: I5933a278de8645b7005c11026c87ae27c0373770
If there's no file to be moved (e.g. it's a redirect in the File
namespace), don't fail with an error about being unable to delete the
nonexistent file. Just let it work.
Bug: T249550
Change-Id: I605b0e4b39e7863bddbebf339994c819528e3a4c
Prior to I4a5fe41fe, the call to Revision::newNullRevision() would load
the Title from the database and use that to create the null revision.
I4a5fe41fe, in removing uses of the deprecated Revision, changed that to
call RevisionStore::newNullRevision() directly. Instead of loading the
Title, that takes one as a parameter. $this->oldTitle was being passed,
which at this point in the execution contains the correct page_id but
the *old* page_namespace/page_title. Passing $nt would also not work,
since that contains the target page's old page_id (likely 0).
The solution is to reset the ID in $nt (so it contains both the correct
ID and name), so we can then pass it to RevisionStore::newNullRevision().
Bug: T248789
Change-Id: I8e0ae616006c0cebde60cfa53c0a842bd2cc1545
The code path updating rev_content_model on a page move wasn't flagged
with $wgMultiContentRevisionSchemaMigrationStage, so removing it was
missed in I1d9f5465.
Bug: T198557
Change-Id: Ibf3fe35112136393c69091fd02f8b433f53f6eb8
