As far as I’m aware, all you can do is filter the display name via pre_user_display_name and check if it already exists. Unfortunately WP_User_Query doesn’t support querying by display_name, so we also have to add to the WHERE clause via pre_user_query. Additionally, there is no elegant way I can think of to handle the case … Read more
In layman terms there is no major difference! update_user_option() uses update_user_meta() internally. The only difference is update_user_option() prefix the option name with database table prefix + blog ID if you are in multisite and just table prefix if you are in single site installation. Take a look at the code of update_user_option() /** * Update … Read more
Hi @Carlos: Try adding the following to your theme’s functions.php file, or in a .php file within a plugin that you might be writing (which works for WordPress 3.1.x): add_action(‘pre_user_query’,’yoursite_pre_user_query’); function yoursite_pre_user_query($user_search) { $user = wp_get_current_user(); if ($user->ID!=1) { // Is not administrator, remove administrator global $wpdb; $user_search->query_where = str_replace(‘WHERE 1=1’, “WHERE 1=1 AND {$wpdb->users}.ID<>1”,$user_search->query_where); … Read more
I see two ways to solve this problem: changing the data that forms the author URL, or changing the author URL. You probably should handle redirects too, so old URLs to user archives keep working when a user changes their nickname. Changing the author URL There are two parts to this question: handle incoming links … Read more
I was sure that wp_update_user() should do this. It even gets user_login as param, but it looks like it ignores it, when you set this param. So this code looks OK, but it doesn’t work as you wish it did 🙁 : wp_update_user( [‘ID’ => $user_id, ‘user_login’ => $new_login] ); You have to call custom … Read more
user_nicename is url sanitized version of user_login. In general, if you don’t use any special characters in your login, then your nicename will always be the same as login. But if you enter email address in the login field during registration, then you will see the difference. For instance, if your login is [email protected] then … Read more
Firstly, you need to add the following capabilities to the Doctor and Receptionist role: list_users edit_users create_users delete_users Now we can get to work with controlling which users they can create/edite/delete. Let’s start with a “helper” function that will return which roles a user is allowed to edit: /** * Helper function get getting roles … Read more
This seems to do what you need. <?php global $current_user; wp_get_current_user(); ?> <?php if ( is_user_logged_in() ) { echo ‘Username: ‘ . $current_user->user_login . “\n”; echo ‘User display name: ‘ . $current_user->display_name . “\n”; } else { wp_loginout(); } ?>
You need to use the show_user_profile, edit_user_profile, personal_options_update, and edit_user_profile_update hooks. You can use the following code for adding additional fields in User section Code for adding extra fields in Edit User Section: add_action( ‘show_user_profile’, ‘extra_user_profile_fields’ ); add_action( ‘edit_user_profile’, ‘extra_user_profile_fields’ ); function extra_user_profile_fields( $user ) { ?> <h3><?php _e(“Extra profile information”, “blank”); ?></h3> <table class=”form-table”> … Read more
It’s actually pretty easy. You need to filter into map_meta_caps and stop editors from creating/editing admins, and remove the administrator role from the ‘editable roles’ array. This class, as a plugin or in your theme’s functions.php file would do it: class JPB_User_Caps { // Add our filters function __construct(){ add_filter( ‘editable_roles’, array($this, ‘editable_roles’)); add_filter( ‘map_meta_cap’, … Read more