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
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
Various maintenance scripts assume reserved usernames like
"MediaWiki default" exist, but since they're reserved
User::isUsableName() returns false and therefore the actor migration
created them as anonymous actors. Which would then prevent those
maintenance scripts from using User::newSystemUser() to ensure they
actually exist.
This adjusts User::newSystemUser() to be able to create users for
those anonymous actors.
This also adjusts uses of "MediaWiki default" in core to create it as a
system user.
Bug: T236444
Change-Id: I59a646df36ff9343cc43c05aa20b2b69b2ee124a
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
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
For back-compat, keep the default as-is, because it is also
used as a post-update script by the installer.
But for convenience and safe manual use, do add a dry-run option.
(Ideally this would be a --delete option and dry-run by default.)
Change-Id: I3ca70f15f50b66f9d19fa705cef9a4aae2dd4e5c
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
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
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
deleteDefaultMessages.php was failing during upgrade
from MediaWiki 1.7.3 with a databaser error.
A stub user:
$user = User::newFromName( 'MediaWiki default' );
has user ID 0, so that $user->isAnon() is true.
Unfortunately, ManualLogEntry::publish() from r96441
tries to insert $user->getName() ("MediaWiki default")
into rc_ip.
PostgreSQL won't allow this, because rc_ip is of
Postgres-specific CIDR type.
Traceback:
Checking existence of old default messages...
...deleting old default messages (this may take a long time!)...A database query syntax error has occurred.
The last attempted database query was:
"INSERT INTO "recentchanges" (rc_timestamp,rc_cur_time,rc_namespace,rc_title,rc_type,rc_minor,rc_user,rc_user_text,rc_comment,rc_this_oldid,rc_last_oldid,rc_bot,rc_moved_to_ns,rc_moved_to_title,rc_ip,rc_patrolled,rc_new,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,rc_id) VALUES ('2012-03-14 21:51:05 GMT','2012-03-14 21:51:05 GMT','8','1movedto2','3','0','0','MediaWiki default','No longer required','0','0',1,'0','','MediaWiki default','1','0',NULL,NULL,'0','1','delete','delete','a:0:{}','1')"
from within function "RecentChange::save".
MySQL returned error "1: ERROR: invalid input syntax for type cidr: "MediaWiki default"
LINE 1: ...ki default','No longer required','0','0',1,'0','','MediaWiki...
^"
Backtrace:
#0 /usr/home/saper/public_html/pg/w/includes/db/DatabasePostgres.php(332): DatabaseBase->reportQueryError('ERROR: invalid...', 1, 'INSERT INTO "re...', 'RecentChange::s...', '')
#1 /usr/home/saper/public_html/pg/w/includes/db/Database.php(904): DatabasePostgres->reportQueryError('ERROR: invalid...', 1, 'INSERT INTO "re...', 'RecentChange::s...', '')
#2 /usr/home/saper/public_html/pg/w/includes/db/DatabasePostgres.php(604): DatabaseBase->query('INSERT INTO "re...', 'RecentChange::s...', '')
#3 /usr/home/saper/public_html/pg/w/includes/RecentChange.php(199): DatabasePostgres->insert('recentchanges', Array, 'RecentChange::s...')
#4 /usr/home/saper/public_html/pg/w/includes/logging/LogEntry.php(479): RecentChange->save('pleasedontudp')
#5 /usr/home/saper/public_html/pg/w/includes/WikiPage.php(2042): ManualLogEntry->publish('1')
#6 /usr/home/saper/public_html/pg/w/includes/WikiPage.php(1937): WikiPage->doDeleteArticleReal('No longer requi...', false, 0, false, '', Object(User))
#7 /usr/home/saper/public_html/pg/w/maintenance/deleteDefaultMessages.php(73): WikiPage->doDeleteArticle('No longer requi...', false, 0, false, '', Object(User))
#8 /usr/home/saper/public_html/pg/w/maintenance/update.php(128): DeleteDefaultMessages->execute()
#9 /usr/home/saper/public_html/pg/w/maintenance/doMaintenance.php(105): UpdateMediaWiki->execute()
#10 /usr/home/saper/public_html/pg/w/maintenance/update.php(151): require_once('/usr/home/saper...')
#11 {main}
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
* (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.
* Convert "$dbw =& wfGetDB( DB_MASTER );" --> "$dbw = wfGetDB( DB_MASTER );"
* convert "$skin =& $wgUser->getSkin();" --> "$skin = $wgUser->getSkin();"
For the time being have not changed the function definitions of wfGetDB() or User::getSkin() [i.e. they are still both return-by-ref], so as to ensure the interface does not change for extensions [some of which may still be trying to run on PHP4 environments]. However presumably at some point this can be changed too.
Also includes tiny tweak to newlines in parserTests - will show 1 rather than 2 newlines between the "Reading tests from" strings when in quiet mode.
