WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 4 months ago

#27060 new defect (bug)

WP_User_Query using deprecated method of finding author

Reported by: Ckeboss Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Users Keywords:
Focuses: Cc:
PR Number:

Description

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
6 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 https://codex.wordpress.org/Class_Reference/WP_User_Query#Who_Parameter

Perhaps it's ok to use in WP_User_Query?

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


5 years ago

#3 @kraftbj
4 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 4 years ago by kraftbj (previous) (diff)
Note: See TracTickets for help on using tickets.