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
Allow Maintenance::error() and Maintenance::fatalError() to take
StatusValue objects. They now print each error message from the
status on a separate line, in English, ignoring on-wiki message
overrides, as wikitext but after parser function expansion.
Thoughts on the previously commonly used methods:
- $status->getMessage( false, false, 'en' )->text()
Almost the same as the new output, but it allows on-wiki message
overrides, and if there is more than one error, it prefixes each
line with a '*' (like a wikitext list).
- $status->getMessage( false, false, 'en' )->plain()
- $status->getWikiText( false, false, 'en' )
As above, but these forms do not expand parser functions
such as {{GENDER:}}.
- print_r( $status->getErrorsArray(), true )
- print_r( $status->getErrors(), true )
These forms output the message keys instead of the message text,
which is not very human-readable.
The error messages are now always printed using error() rather
than output(), which means they go to STDERR rather than STDOUT
and they're printed even with the --quiet flag.
Change-Id: I5b8e7c7ed2a896a1029f58857a478d3f1b4b0589
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
The type is not created in the script,
looks like a copy from other code area (added in 01a60e52)
Bug: T255309
Change-Id: I1e55a39ba1f35e9f047dd273f7561f566b1f6a6f
This patch fixes three issues:
* Prior to this patch, it logged weird entries, such as
"changed group membership for Test user 22 from (none) to (none)",
when no promotions were actually configured.
* Promotions happen at two places within the script, which directly
results in the following issue.
* When a promotion was requested, the entry (falsefully) said
"changed group membership from administrator to
administrator and administrator", as it loaded the groups from
the database after doing the promotion for the first time.
Follow-up for I6a02042f6972ec718bae3adb2b7afbb2782c5673.
Bug: T340875
Bug: T168205
Change-Id: I8cd1fe4308a08aea6e9ab7c464184697eafc368f
Also change the groups before changing the password; the password policy
can differ based on group membership, resulting in an invalid password
being set because the user was not yet part of the group with a strict
password policy.
Bug: T335702
Change-Id: I0ce7c2cd3eed958bb99f1a2e7c4a45c51668869d
1) The following methods were hard deprecated:
- User::addAutopromoteOnceGroups
- User::getEffectiveGroups
- User::getAutomaticGroups
- User::getFormerGroups
2) User ::getGroups, ::getGroupMemberships, ::addGroup,
::removeGroup were replaced in the production code,
but they were not hard deprecated because of conflict
with UserRightsProxy class.
Bug: T275148
Change-Id: Ia69598316f5dc5dd9511f6112b5b13e1aa07575a
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
Use AuthManager::autoCreateUser when creating a new user via
createAndPromote.php so that configured AuthManager providers have
a chance to perform validations and extra actions beyond local account
creation.
Bug: T212689
Change-Id: I4972507bbaf65bb542934c281c37bd8a5c7a26b7
To limit the likelihood of incidents like T189665, the ability to
edit sitewide CSS/JSON/JS is split out from editinterface, into
separate 'editsitecss', 'editsitejson' and 'editsitejs' rights.
editsitecss, editsitejs, and the right to edit another (potentially
more privileged) user's personal CSS/JS is removed from sysops, and
a new user group, interface-admin, is created specifically for that
task (along with a new grant group 'editsiteconfig').
interface-admin is granted to the first user of a new wiki, along with
sysop and bureaucrat.
Bug: T120886
Bug: T190015
Depends-On: Ia9b2ea1450aff6121dc0f3777bf029292c8aaad9
Change-Id: Ifefd872640642441e26f8b2f144ffe4b88d2eb12
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
Also update createAndPromote.php to use it so it can display errors.
Note that there are two possible approaches. The other is to
do the update for all requests for which the test passed,
even if some tests fail. The approach of the patch seems
more manageable from the caller's point of view
(either the operation was a success, or it failed and
nothing happened).
Change-Id: I86abed4b80472cd888337444fac0cbcb870b1246
Change I2c736ad mostly removed the password handling from the User
object, but left in a little password handling to preserve the existing
ability to call $user->setPassword() before the user was actually added
to the database. That ability is now removed.
Bug: T47716
Change-Id: Id3d40742f2e2b197ad6facd149cc6350006bf289
This lets any group(s) be added using a comma-separated argument,
in addition to the --sysop, --bureaucrat, and --bot that already
existed.
Bug: T105079
Change-Id: I1274b065e3dad917e545f9278b996da014d87ae9
- Added 'bot', a default usergroup, to $permitRoles
- Changed 'administrator rights' to just 'rights', since the script isn't just for administrator rights
Bug: 45160
Change-Id: I61348e2d45b90b65a117efcce65d7c581105e612
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
