Last modified: 2011-03-01 19:03:47 UTC
During a usurp request, renaming the usurped user creates a redirect to User talk:Usurpee (usurped) which typically prevents the usurper's talk page being moved there unless it is first deleted. A checkbox to allow one to suppressredirect would be helpful.
Hm, I might have a look at this.. It sounds like a good idea.
Still hoping to see this feature created. As it stands now, I manually move the pages ahead of the rename; it would be nice to get it all wrapped up into one.
r74510
I've just tried testing this functionality at the prototype/release-en wiki and was given the following error: Invalid input Backtrace: #0 /srv/org/wikimedia/prototype/wikis/rc/extensions/CentralAuth/CentralAuthUser.php(861): CentralAuthUser::validateList(Array) #1 /srv/org/wikimedia/prototype/wikis/rc/extensions/CentralAuth/CentralAuthHooks.php(351): CentralAuthUser->adminUnattach(Array) #2 [internal function]: CentralAuthHooks::onRenameUserPreRename('45', 'About to be ren...', 'Renamed user') #3 /srv/org/wikimedia/prototype/wikis/rc/includes/Hooks.php(158): call_user_func_array(Array, Array) #4 /srv/org/wikimedia/prototype/wikis/rc/extensions/Renameuser/Renameuser_body.php(430): wfRunHooks('RenameUserPreRe...', Array) #5 /srv/org/wikimedia/prototype/wikis/rc/extensions/Renameuser/Renameuser_body.php(275): RenameuserSQL->rename() #6 /srv/org/wikimedia/prototype/wikis/rc/includes/SpecialPage.php(579): SpecialRenameuser->execute(NULL) #7 /srv/org/wikimedia/prototype/wikis/rc/includes/Wiki.php(250): SpecialPage::executePath(Object(Title)) #8 /srv/org/wikimedia/prototype/wikis/rc/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest)) #9 /srv/org/wikimedia/prototype/wikis/rc/index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest)) #10 {main} Not sure if this is a problem with the code itself, or something to do with the configuration of the wiki. Figured I'd better leave a note here in case. I note that a user was renamed on Feb 3 seemingly without issue. Meanwhile today, I wasn't able to get the rename to get through even unchecking the different options.
CentralAuth isn't properly enabled on the wiki, so we get stupid errors like this...
Ok, I have a real one now. We want to be able to pass a "suppressRedirect=1" to have the new box automatically ticked during usurp requests. Amalthea explained to me this this is not possible because of lines 49 to to 60 of r81598. ---Amalthea wrote the following--- // If nothing given for these flags, assume they are checked // unless this is a POST submission. $move_checked = true; $suppress_checked = false; if ( $wgRequest->wasPosted() ) { if ( !$wgRequest->getCheck( 'movepages' ) ) { $move_checked = false; } if ( $wgRequest->getCheck( 'suppressredirect' ) ) { $suppress_checked = true; } } It disregards any values for the options "movepages" and "suppressredirect" if they are passed in via url parameters. Why I don't know, they don't seem sensitive enough for that to me. The check was introduced by "Greg" in revision 20843 when he made the movepages checkbox remember its status after a form submit. When suppressredirect was added, the code for movepages was apparently simply copy&pasted (as you can see the comment is still wrong), and inherited that logic. In my opinion, that "wasPosted" check can be removed entirely here. ===ends=== Thanks for your swift attention to this.
r82804
Eh, I see now, having a checkbox default to 'true' isn't as straightforward. r82804 consequently changes the default value of 'movepages' to 'false'. Replacing $move_checked = $wgRequest->getCheck( 'movepages' ); by $move_checked = $wgRequest->getBool( 'movepages', !$wgRequest->wasPosted()); should be a good solution: defaults to true, and still allows to set either state via url parameter.
r83034