Page MenuHomePhabricator

RenameUser should support wiki farm setups which use $wgShared* globals
Open, MediumPublic


Using $wgSharedDB, $wgSharedTables (and $wgSharedPrefix) is basically the recommended way to set up a wiki farm, especially when starting from scratch (see However, currently this means that users cannot be (easily) renamed since RenameUser operates only on the current database, no matter what. If you have, say, five wikis or so, it's probably relatively easy to run a bunch of SQL queries against all five DBs. This is not the case when you have thousands of wikis, as ShoutWiki has (currently almost 6k wikis).

This is and has been a non-issue for WMF wikis since WMF sites use the CentralAuth extension, which provides the global user renaming functionality. CentralAuth is not an acceptable solution for non-WMF wikis, as it's extremely complicated to set up and even CA's extension info page on recommends $wgSharedDB & $wgSharedTables instead.


Event Timeline

ashley raised the priority of this task from to Medium.
ashley updated the task description. (Show Details)
ashley added a project: MediaWiki-User-rename.
ashley added subscribers: ashley, Legoktm, lcawte and 2 others.

We could probably take most of the code from GlobalRename in CentralAuth and make it not-dependent upon CA. I think you'd still want to have a global renameuser_status table and use the job queue.

Just taking a quick look at the LocalRenameUserJob class (which is where most of the work is done), it's mostly not CA-specific, except for the promotetoglobal option which isn't needed, and CA cache invalidation, which also won't be needed.

It may make sense to wait for T100263: Refactor Special:RenameUser to use FormSpecialPage to be finished first, as it'll be easier to do once the backend is separated from the frontend.

Just adding my two cents here that as an external wiki farm, we'd also like to see user renaming support wiki farms properly, especially now that it is integrated into core. We use a fork of the Renameuser extension, but to upgrade to 1.40, it means that we're likely going to have to make patches to the core implementation instead.

Our fork code (which isn't exactly gold standard, but works) involves looping through $wgLocalDatabases and inserting a job for each. The job then updates tables on each wiki before finally moving the user page on each wiki.