WordPress.org

Make WordPress Core

Ticket #17924: Create_Role_Update_Actions_Filters_3.2.1.patch

File Create_Role_Update_Actions_Filters_3.2.1.patch, 4.8 KB (added by mobius5150, 7 years ago)

The second patch.

  • wp-admin/includes/user.php

     
    77 */
    88
    99/**
     10 * Sanitizes and checks for permissions when working with a role
     11 * string.
     12 *
     13 * @param type $role the role string to be sanitized
     14 * @param type $user_id the user id to sanitize the string for
     15 * @return type string
     16 */
     17function wp_sanitize_user_role( $role, $user_id ){
     18    global $wp_roles;
     19    if ( is_string( $role ) ) {
     20        $r = false;
     21        $new_role = sanitize_text_field( $role );
     22        $potential_role = isset($wp_roles->role_objects[$new_role]) ? $wp_roles->role_objects[$new_role] : false;
     23        // Don't let anyone with 'edit_users' (admins) edit their own role to something without it.
     24        // Multisite super admins can freely edit their blog roles -- they possess all caps.
     25        if ( ( is_multisite() && current_user_can( 'manage_sites' ) ) || $user_id != get_current_user_id() || ($potential_role && $potential_role->has_cap( 'edit_users' ) ) )
     26                $r = $new_role;
     27
     28        // If the new role isn't editable by the logged-in user die with error
     29        $editable_roles = get_editable_roles();
     30        if ( ! empty( $new_role ) && empty( $editable_roles[$new_role] ) )
     31                wp_die(__('You can’t give users that role.'));
     32       
     33        return $r;
     34    } else {
     35        //Can't do anything, so return the input
     36        return $role;
     37    }
     38}
     39
     40/**
     41 * Add the sanitize_user_role filter
     42 */
     43add_filter( 'sanitize_user_role', 'wp_sanitize_user_role', 5, 2 );
     44
     45/**
    1046 * Creates a new user from the "Users" form using $_POST information.
    1147 *
    1248 * It seems that the first half is for backwards compatibility, but only
     
    75111                $pass2 = $_POST['pass2'];
    76112
    77113        if ( isset( $_POST['role'] ) && current_user_can( 'edit_users' ) ) {
    78                 $new_role = sanitize_text_field( $_POST['role'] );
    79                 $potential_role = isset($wp_roles->role_objects[$new_role]) ? $wp_roles->role_objects[$new_role] : false;
    80                 // Don't let anyone with 'edit_users' (admins) edit their own role to something without it.
    81                 // Multisite super admins can freely edit their blog roles -- they possess all caps.
    82                 if ( ( is_multisite() && current_user_can( 'manage_sites' ) ) || $user_id != get_current_user_id() || ($potential_role && $potential_role->has_cap( 'edit_users' ) ) )
    83                         $user->role = $new_role;
    84 
    85                 // If the new role isn't editable by the logged-in user die with error
    86                 $editable_roles = get_editable_roles();
    87                 if ( ! empty( $new_role ) && empty( $editable_roles[$new_role] ) )
    88                         wp_die(__('You can’t give users that role.'));
     114                $user->role = apply_filters( 'sanitize_user_role', $_POST['role'], $user_id );
    89115        }
    90116
    91117        if ( isset( $_POST['email'] ))
  • wp-includes/user.php

     
    13441344 * set the user's preference on whether they want the rich editor on.
    13451345 *
    13461346 * Most of the $userdata array fields have filters associated with the values.
    1347  * The exceptions are 'rich_editing', 'role', 'jabber', 'aim', 'yim',
    1348  * 'user_registered', and 'ID'. The filters have the prefix 'pre_user_' followed
    1349  * by the field name. An example using 'description' would have the filter
    1350  * called, 'pre_user_description' that can be hooked into.
     1347 * The exceptions are 'rich_editing', 'jabber', 'aim', 'yim', 'user_registered',
     1348 * and 'ID'. The filters have the prefix 'pre_user_' followed by the field name.
     1349 * An example using 'description' would have the filter called,
     1350 * 'pre_user_description' that can be hooked into.
    13511351 *
    13521352 * The $userdata array can contain the following fields:
    13531353 * 'ID' - An integer that will be used for updating an existing user.
     
    15091509        }
    15101510
    15111511        if ( isset($role) )
    1512                 $user->set_role($role);
     1512                do_action( 'apply_user_role' , apply_filters( 'pre_user_role', $role ), $user );
    15131513        elseif ( !$update )
    1514                 $user->set_role(get_option('default_role'));
     1514                do_action( 'apply_user_role' , get_option('default_role'), $user );
    15151515
    15161516        wp_cache_delete($user_id, 'users');
    15171517        wp_cache_delete($user_login, 'userlogins');
     
    15251525}
    15261526
    15271527/**
     1528 * Hooks into the apply_user_role action to set the users role
     1529 *
     1530 * @param type $role the role to set
     1531 * @param type $user the user to set the role on
     1532 */
     1533function wp_apply_user_role( $role, $user ) {
     1534    if ( is_string( $role ) ) {
     1535        $user->set_role($role);
     1536    }
     1537}
     1538
     1539/**
     1540 * Register the action for the apply_user_role hook
     1541 */
     1542add_action( 'apply_user_role', 'wp_apply_user_role', 5, 2);
     1543
     1544/**
    15281545 * Update an user in the database.
    15291546 *
    15301547 * It is possible to update a user's password by specifying the 'user_pass'