* Moved the code from User::decodeOptions() to the maintenance script,
the only place it is (indirectly) used.
* Changed the script to insert new rows itself rather than calling
User::saveSettings(), avoiding bug 63677.
* Removed FOR UPDATE and COMMIT lacking a matching BEGIN.
* Made ORDER BY explicit.
* Removed pointless "Do each user sequentially [...]" comment dating
back to r48732, in which the script would increment a user's ID
to get the next one.
Bug: 63677
Change-Id: I86365a7363af3376cc4f55fa528b050b44378656
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I727deec35a712de0f0c676cc87dfa661f1ee965b
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
The user_options migration messages were not prefixed with '...' and
were split on several lines. This patch make the output messages more
inline with the existant ones.
Follow-up r103917
. <-- that is a patch of ink sorry. ><OO>
Added run of ConvertUserOptions maintenance script into update.php before dropping the column
Removed usages of user_options in code
Marked User::decodeOptions() deprecated as of 1.19.
Made ConvertUserOptions drop out early if the user_options field doesn't exist
Made ConvertUserOptions update user_options to '' after migration of user options to mOptions
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
