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
Added a flag (--by-id) to maintenance/deleteBatch.php that allows users to pass page IDs instead of titles.
Bug: T357019
Change-Id: I599f9fcc8d4cfd9e667717d5a575b05990141fb2
Maintenance class provides a method for getting a fresh reference
of the MW services container instance. Let's make use of these in
maintenance scripts now that we have it.
NOTE: There are still some static methods like in refreshLinks.php
that makes use of services that we can't use this method for now.
Change-Id: Idba744057577896fc97c9ecf4724db27542bf01c
With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
One exception message contained a trailing dot/space, which I removed
as well, following I935835316c0.
A very small number of exceptions and output() calls contained trailing
space, which I removed for consistency.
Change-Id: I16f48c1a051c452bbef699eb9b7476d83f8821d8
DeleteBatch: The check for isLocal ensures that the file is a LocalFile
SpecialMovepage: File is retrieved from LocalRepo, so is always local
Bug: T245710
Change-Id: Id0589e12f478a77c342d1f1d36d8ca0308b6cdb9
These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
Benefit of keeping the parameter optional:
- In maintenance scripts that really only have one parameter, it's a
little more convenient to be able to ask for *the* parameter via an
empty getArg().
Disadvantages:
- It's unclear what getArg() means when there is no indication *which*
argument the code asks for. This might as well return the last
argument, or an array of all arguments.
- In scripts with two or more arguments, it's confusing to see
getArg( 1 ) next to an empty getArg().
- The methods are more complex and a bit more complicated to use with
the extra feature of this parameter being optional. Users need to
look up what the default is to be able to use it safely.
Change-Id: I22a43bfdfc0f0c9ffdb468c13aba73b888d1f15e
The most notable removal is done in the orphans script. This code was
really never used. Brion introduced it in 2005, already disabled.
I have all the respect for what Brion did. I just think it does not make
much sense to keep code around for so long if it does not work anyway,
and must be rewritten from scratch anyway now that we have multi-content
revisions and such.
Change-Id: I4e8050929f90e44a6e6051bf938993a8b0cdf649
Pages with many revisions experience transaction size exceptions,
due to archiving revisions. Use the job queue to split the work
into batches and avoid exceptions.
Bug: T198176
Change-Id: Ie800fb5a46be837ac91b24b9402ee90b0355d6cd
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
AuthManager is coming, which will make it easier to add alternative
methods of authentication. But in order to do that, we need to finally
get around to ripping the password-related bits out of the User class.
The password expiration handling isn't used anywhere in core or
extensions in Gerrit beyond testing for expired passwords on login and
resetting the expiry date on password change. Those bits have been
inlined and the functions removed; AuthManager will allow each
"authentication provider" to handle its own password expiration.
The methods for fetching passwords, including the fact that mPassword
and other fields are public, has also been removed. This is already
broken in combination with basically any extension that messes with
authentication, and the major use outside of that was in creating
system users like MassMessage's "MediaWiki message delivery" user.
Password setting methods are silently deprecated, since most of the
replacements won't be available until AuthManager. But uses in unit
testing can be replaced with TestUser::setPasswordForUser() immediately.
User::randomPassword() and User::getPasswordFactory() don't really
belong in User either. For the former a new PasswordFactory method has
been created, while the latter should just be replaced by the two lines
to create a PasswordFactory via its constructor.
Bug: T47716
Change-Id: I2c736ad72d946fa9b859e6cd335fa58aececc0d5
Set the $commit parameter of WikiPage::doDeleteArticle() to true so
the transaction it starts is explicitly committed. Also fixed similar
bugs in two other maintenance scripts.
Follows-up 02f17b5790.
Bug: T110189
Change-Id: Ifde98066e25cb616f23c8998f9461ebf7a2073d6
Previous behavior had the maintenance script deleteBatch.php
delete both the redirect in the file namespace and the file
from the target page the redirect is pointing to. This is
no longer the case, but it will still delete the redirect
page if it is still on the listfile.
Bug: 52587
Change-Id: I83374ddb98131f9f8f766bb2b444ab3e7cda7735
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
* Rename some variable for consistency
* Check for valid user before opening the file containing pages to delete, there's no point doing the latter if the former fails
* Don't ouput "FAILED to delete associated file" if the file is from a foreign repository
