[wp-trac] [WordPress Trac] #14046: WP_User constructor not working as expected if called with 2 args or its phpdoc is not clear

[WordPress Trac]

#14046: WP_User constructor not working as expected if called with 2 args or its
phpdoc is not clear
-----------------------------+----------------------------------------------
 Reporter:  francescolaffi   |       Owner:                        
     Type:  defect (bug)     |      Status:  new                   
 Priority:  normal           |   Milestone:  Unassigned            
Component:  Role/Capability  |     Version:  3.0                   
 Severity:  normal           |    Keywords:  dev-feedback has-patch
-----------------------------+----------------------------------------------
 WP_User constructor can be called with only userid, with only username or
 with both of them, the bug I found if it's when calling it with only
 username.

 When calling with only username the constructor work only if the user_name
 is placed in the first arg, but it could not work if the first arg is
 leaved empty and username is placed in second arg.
 e.g.:
 I have the user with username 'foobar' and user id 14
 new WP_User(14) works
 new WP_User(14,'foobar') works
 new WP_User('foobar') works
 new WP_User(0,'foobar') works
 new WP_User(null,'foobar') doesn't work
 new WP_User(false,'foobar') doesn't work

 Probably the constructor is intended to be used only with the username in
 the first arg if the userid is not known (and its not really clear in the
 phpdoc that it should not be called with null,$username ), but the problem
 is that I found it called with null in the first argoument and the
 username in the second argoument in the wp3 core (i.e. is_site_admin
 doesn't work if called with the username as arg because of this bug, but
 of course I haven't checked all the references to the constructor in the
 core).

 I see 2 possible solutions:
 1) make WP_User constructor works if called with first argoument null and
 username in second argoument.
 2) decide this is the way it should work, clearify it's doc and search all
 the improperly calls of in the code and correct them.

 My 2 cents: go with 1) because so the constructor is more flexible and
 it's only a matter of adding a condition to an if statement, instead 2)
 means checking a lot of code (it's possible that the result it's that only
 is_site_admin improperly uses WP_User constructor, and btw is_site_admin
 doesn't actually need the WP_User obj, it could just get userdata with
 get_userdatabylogin ).

 I'm going to attach the 1-line diff for the 1st solution

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14046>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software