Last modified: 2013-02-18 10:19:26 UTC
We find userOptions.php is unable to access some options, due to the difference in these two files, >perl -nwle 'for(/\$defaultPreferences\[\x27(\w+)\x27]/g){$h{$_}++};END{print for sort keys %h}' Preferences.php>/tmp/w1 >perl -nwle 'next unless /\$wgDefaultUserOptions = array\(/../\);/;/\x27(\w+)\x27/&&print$1;' DefaultSettings.php|sort>/tmp/w2 >comm -3 /tmp/w[12] editcount emailaddress emailauthentication language nickname nowlocal nowserver password realname registrationdate searchnamespaces timecorrection usergroups userid username variant watchcreations watchdefault watchdeletion watchmoves Also userOptions.php should accept a wildcard for --old. E.g., >I've had enough of signature abuse on my wiki. In LocalSettings.php I'm >now doing array_push($wgHiddenPrefs,'nickname','fancysig'); and with >userOptions.php I can zap fancysig, but I can't zap all their nicknames, >and even if I could touch them by adding >$wgDefaultUserOptions['nickname']='' there in LocalSettings.php, >userOptions.php doesn't allow me to zap all the nicknames in one shot, >because it doesn't accept wildcards. Alas, my only alternative is SQL... Sure, some of them shouldn't be tampered with, but in the above case, the administrator can freeze people's nicknames, but not clear them.
More ideas: When using just plain $ php userOptions.php --usage maybe a more efficient query would be >SELECT up_property,COUNT(*),up_value FROM user_properties GROUP BY up_property,up_value;... (if convertUserOptions.php has already been run.) Maybe add --remove-all-unknown-options (hmm, sounds dangerous, --dry first) that would DELETE all rows with options that have been retired from the code. Perhaps add a --delete-if-default, which would DELETE all rows where an option the corresponding $wgDefaultUserOptions[].
Bug summary doesn't clarify what's wrong or give a clear usage example leading to error with a description of the problem. Please list exact steps to reproduce and a clear description of the difference between actual and expected behavior.
Allow me to try again: With userOptions.php, one can, for example, set users' 'rememberpassword' value, but one cannot set their 'timecorrection' value, even though both are sitting there on Special:Preferences, and both live together in SELECT * FROM user_properties; +---------+------------------+--------------------------+ | up_user | up_property | up_value | +---------+------------------+--------------------------+ | 1 | rememberpassword | 1 | | 1 | timecorrection | ZoneInfo|480|Asia/Taipei | +---------+------------------+--------------------------+ Therefore Bug: userOptions.php is unable to access some options.
$ php userOptions.php timecorrection --old='' --new='ZoneInfo|480|Asia/Taipei' The script is about to change the skin for ALL USERS in the database. Users with option <timecorrection> = '' will be made to use 'ZoneInfo|480|Asia/Taipei'. Abort with control-c in the next five seconds....0 Setting timecorrection for WikiSysop from '' to 'ZoneInfo|480|Asia/Taipei'): OK Setting timecorrection for Demon from '' to 'ZoneInfo|480|Asia/Taipei'): OK Done. $ php sql.php > select * from user_properties where up_property = 'timecorrection'; stdClass Object ( [up_user] => 1 [up_property] => timecorrection [up_value] => ZoneInfo|480|Asia/Taipei ) stdClass Object ( [up_user] => 2 [up_property] => timecorrection [up_value] => ZoneInfo|480|Asia/Taipei ) WORKSFORME?
I'll have to trust you, as my grasp of the issue is fading.
Wait, what about the wildcard I wanted?
select * from user_properties where up_property = 'timecorrection'; seems to say that '' is the same as '*' or something... bad.
Looks like it is working properly.