This patch introduces a namespace declaration for the
MediaWiki\RenameUser to RenameUserJob and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ibf7d6d54e0047c6c298c02926d8a811d26f6361c
* Deprecate and stop using $wgBlockTargetMigrationStage. Remove
block_target migration code.
* Make the $schema parameters to DatabaseBlockStore methods default to
SCHEMA_BLOCK. Avoid passing these parameters where possible.
* Remove cleanupBlocks.php
* Deprecate DatabaseBlock static methods which try to present the old
schema for b/c.
Bug: T362133
Change-Id: I845bad8cc09a4528fef46a6f9d490ebdec881d99
Some less trivial cases. Also update variable names.
This doesn't really change anything, but I hope it helps promote
getConnectionProvider() as the common way to do this.
Follow-up to 8604c384f6.
Change-Id: I6657d783375fac5c7fa856b884ff1fb09285e94c
Found via (?<!IDBAccessObject)::READ_
We are planning to deprecate and remove implementing IDBAccessObject
interface just to use the constants.
Bug: T354194
Change-Id: I89d442fa493b8e5332ce118e5bf13f13b8dd3477
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
I fixed some edge cases in the script that migrates to SQB and it
managed to fix these now.
Bug: T344971
Change-Id: I00cc9a6660d9bd4c64c976121b2121ccd7aae1f0
* Use IConnectionProvider
* Inject services into the job
* Use JobSpecification to avoid unnecessary service construction
Bug: T27482
Change-Id: I75ac8c53b874742a3a54526692767d0f549e5259
* Use dependency injection or centralize access to the service
container.
* Remove code from RenameUserJob which was obsoleted by the actor table
migration. This job class is not used to update revision or logging
anymore.
Bug: T27482
Change-Id: I2bbea713f4c68a15e22e5c3f64d8decbd0b0a9de
Copy the Renameuser extension into core, with minimal code changes. The
hook handlers are inlined into Article, SpecialLog and
SpecialContributions.
Bug: T27482
Change-Id: I314021f4138773df6aaf2753b33ab8283cd16974