Wikimedia Bugzilla is closed!

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