Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: I7dec01892a987a87b1b79374a1c28f97d055e8fa
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
And start using them instead of wfGetDB(), LB/LBF connection methods or
worse, $this->getDB().
$this->getDB() reuses the database object regardless of whether you're
calling a replica or primary, leading to returning a replica on a
primary and other way around.
Bug: T330641
Change-Id: I9e2cf85ca277022284fc26b9f37db57bd12aaa81
Builds a condition comparing multiple values, for use with indexes
that cover multiple fields, common when e.g. paging through results
or doing batch operations. Can also be to generate a simple comparison
without writing raw SQL (see T210206).
Update a few manually constructed conditions to use this method.
There are more maintenance scripts and API classes that use the
same patterns, but this is a start.
As you can see by the code I'm replacing, there are many ways to do
this. I picked the one used by maintenance/TableCleanup.php, since
I found it the easiest to understand.
Change-Id: Ic368a87fb5ce4c13608b03206cd68518ec9732d4
Make phan stricter about conditional variable declaration
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T259172
Change-Id: I1f200ac37df7448453688bf464a8250c97313e5d
This class is not stable to extend, nor does codesearch reveal
any classes extending it outside of core, so we can just evaluate
if $wgUser needs to be set for this class and subclasses in core.
TableCleanup is not set up to be run directly, it requires that it
be subclassed and the subclass run as a maintenance script. Within
TableCleanup itself, nothing depends on $wgUser. Looking at the
subclasses in core:
* CleanupCaps overrides the execute method, so the code to set
$wgUser in TableCleanup::execute() is not being run
* CleanupImages, TitleCleanup, and ClenupWatchlist do not
appear to have any code that relies on anything related to the
current user or context
Since nothing is using the user in any form, simply remove the
write to $wgUser, no need to replace it with setting the context
user
Bug: T243708
Change-Id: I1a22f2ebab028822e663ab1fdcbd6c7b02331fef
