Make WordPress Core

Opened 10 years ago

Last modified 5 years ago

#27060 new defect (bug)

WP_User_Query using deprecated method of finding author

Reported by: ckeboss's profile Ckeboss Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Users Keywords:
Focuses: Cc:


WP_User_Query uses

 if ( isset( $qv['who'] ) && 'authors' == $qv['who'] && $blog_id ) {
    $qv['meta_key'] = $wpdb->get_blog_prefix( $blog_id ) . 'user_level';
    $qv['meta_value'] = 0;
     $qv['meta_compare'] = '!=';
    $qv['blog_id'] = $blog_id = 0; // Prevent extra meta query

When PREFIX_user_level is deprecated. A better check is checking to see if that user has the ability to edit_posts, as that would be one who can write.

Change History (3)

#1 @senlin
10 years ago

It looks like user_level is used on quite a few places: wp-admin/includes/deprecated.php (3x), wp-admin/includes/upgrade.php (4x), wp-includes/capabilities.php (5x), wp-includes/ms-functions.php (2x) and wp-includes/user.php (1x, the block mentioned by @Ckeboss).

It has also been described in detail in the Codex

Perhaps it's ok to use in WP_User_Query?

This ticket was mentioned in Slack in #core by jjj. View the logs.

9 years ago

#3 @kraftbj
9 years ago

  • Type changed from enhancement to defect (bug)
  • Version changed from 3.8.1 to 3.0

user_levels was deprecated in 3.0, adjusting version to match. I'm marking this as a bug because it can causes issues in cases where a custom role is defined in an atypical way. who => authors should be expected to find anyone with edit_posts caps, even if the cap->level conversion didn't successfully occur.

Last edited 9 years ago by kraftbj (previous) (diff)
Note: See TracTickets for help on using tickets.