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.

soxred93 wrote:

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

Amalthea.wikimedia wrote:

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