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
Until now, we relied on setting MW_NO_SETUP which was a) hacky, b) irreversable, and c) likely to be forgotten if you didn't use one of the wrappers like runChild().
Instead, move the freaky magic to doMaintenance and have *it* check if it's in a specific call stack that indicates this is being run from the file scope and should be executed. Rename DO_MAINTENANCE to RUN_MAINTENANCE_IF_MAIN so it's nice and clear what magic happens behind the require_once().
* Docs have been updated to indicate the standard on how to write maintenance scripts (MW.org docs will follow) Have ported vast majority of maintenance scripts to new format. Remaining ones (mostly FiveUpgrade-related) are a bit more tricky. commandLine.inc is untouched for now. Many have gotten code-style updates as well. Deleted .inc files were only used by their .php counterparts, and have been merged into single files.
* (bug 11867) Lock error on redirect table when running orphans.php
* (bug 16322) Allow maintenance scripts to accept DB user/pass over input or params
* (bug 18566) Maintenance script to un/protect pages
* initStats overhaul, now uses class SiteStatsInit. Also fixes bug 18930
* Tweak User::isValidPassword() and hook. Return a STRING msg key on failure, not false. Updated all callers to handle this
* Split too-short/match username errors for clarity
* Update docs, messages.
* Merge fix for bug from maintenance-work branch
* (bug 16322) Allow maint scripts to accept DB user/pass over input or params if no AdminSettings.php
* (bug 18768) Remove AdminSettings.php from MediaWiki core
* (bug 19157) createAndPromote error on bad password
* (bug 14201) Create AdminSettings.php during wiki installation, in the same way as LocalSettings.php
* Introduce new Maintenance class framework and port a good number of scripts over; the ones that are left are a little more complicated. Read the docs.
* Not deleting "unused" files yet, don't want to break everything at once :)
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
Caches for wikis with table prefixes will be lost on upgrade, caches for wikis without table prefixes will be preserved. Custom cache keys in extensions can be migrated at leisure. Extensions which write to core cache keys should be migrated ASAP, as I have done with Special:Makesysop.