Last modified: 2013-02-18 10:19:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21051, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19051 - userOptions.php is unable to access some options
userOptions.php is unable to access some options
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
1.16.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-02 01:13 UTC by Dan Jacobson
Modified: 2013-02-18 10:19 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-06-02 01:13:55 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.
Comment 1 Dan Jacobson 2009-06-07 01:21:24 UTC
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[].
Comment 2 Brion Vibber 2009-06-22 23:43:21 UTC
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.
Comment 3 Dan Jacobson 2009-06-23 16:22:15 UTC
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.

Comment 4 Chad H. 2012-02-08 03:28:12 UTC
$ 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?
Comment 5 Dan Jacobson 2012-02-08 06:13:14 UTC
I'll have to trust you, as my grasp of the issue is fading.
Comment 6 Dan Jacobson 2012-02-08 06:14:32 UTC
Wait, what about the wildcard I wanted?
Comment 7 Dan Jacobson 2012-02-08 06:17:28 UTC
select * from user_properties where up_property = 'timecorrection'; seems to say that '' is the same as '*' or something... bad.
Comment 8 Antoine "hashar" Musso (WMF) 2013-02-18 10:19:26 UTC
Looks like it is working properly.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links