23

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 user@example.com then you will have userexample-...


18

user_new_form is the hook that can do the magic here. function custom_user_profile_fields($user){ ?> <h3>Extra profile information</h3> <table class="form-table"> <tr> <th><label for="company">Company Name</label></th> <td> <input type="text"...


17

I think you should use wp-api functions which will do everything for you. get_users() function will get all users data just define fields which u require. get_user_meta() function will get usermeta data. $users = get_users( array( 'fields' => array( 'ID' ) ) ); foreach($users as $user){ print_r(get_user_meta ( $user->ID)); }


16

You have already found out that using update_user_meta() if the meta field for the user does not exist, it will be added. ie update_user_meta() can do the task of add_user_meta() However, the difference between them is the return values update_user_meta() returns False if no change was made (if the new value was the same as previous value) or if the ...


15

There are two ways I've discovered doing this: Author Page with a custom rewrite rule A custom template files paired with a rewrite rule The first is more simple to implement, but may not work in all circumstances (one of which I'll describe soon). Custom Rewrite Rule I found this solution a few days ago here: URL Rewriting And here's the code, with ...


15

If you plan to use this code on frontend, I would check if email is free to use. Otherwise, you are creating a security hole. if (isset( $_POST['email'])) { // check if user is really updating the value if ($user_email != $_POST['email']) { // check if email is free to use if (email_exists( $_POST['email'] )){ // ...


14

You worded it as you want to check if user has administrator role. It is considered more proper to check for capability, relevant to specific action. In practice this is usually expressed as current_user_can( 'manage_options' ) for current user. For arbitrary user it would be user_can( $user_id, 'manage_options' ). Of course this is capability that stands ...


13

I had the same need and created the following hack: <?php function hack_add_custom_user_profile_fields(){ global $pagenow; # do this only in page user-new.php if($pagenow !== 'user-new.php') return; # do this only if you can if(!current_user_can('manage_options')) return false; ?> <table id="...


11

You technically don't have to set a nickname, it will be filled with your username if you clear the field out. Display name is selectable between the user's username, first name, last name, first/last, or last/first, or nickname. The nickname exists to give you an option to set display name to something other than your username or real name.


9

You can use the just the meta_key argument, the result will be similar to using the EXISTS sql statement. <?php $users = get_users(array( 'meta_key' => 'your_meta_key', )); Alternatively, you can use an empty string for meta_value (the default) and > for meta_compare. The result is the same (probably because meta_value gets ignored if its ...


9

I think I figured this one out. I had misread this answer and hooked the function I wrote to wp_clear_auth_cookie (actually a function itself!) instead of clear_auth_cookie (the real hook), so that wasn't working. But now using the real hook, I think it might be. Correct me if I'm wrong. Below is the function with the hook. function users_last_login() { ...


8

You're close - just need to tweak your arguments: <?php echo get_user_meta( $customer_id, 'billing_phone', true ) ?> Just make sure $customer_id is the ID of the user - you probably want get_current_user_id() instead.


8

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 ...


7

Have you tried to go with the "Safe usage" alternative given in the commented section? I honestly don't have any experience with wp_get_current_user(), since I never use it, but anyhow, this ought to work: global $current_user; echo 'Username: ' . $current_user->user_login . '<br />'; echo 'User email: ' . $current_user->user_email . '<br /&...


7

wp_update_user & metadata wp_update_user updates records in the *_users table. It isn't meant to update custom metadata in the *_usermeta table. Hence your "problem" is actually expected behavior. The $userdata argument passed to wp_update_user can contain the following fields: ID, user_pass, user_login, user_nicename, user_url, user_email, ...


7

There are far better ways of doing this. Instead of modifying the user table, make use of User Meta. It has a dedicated table, and works the same way as post meta, but for users. add_user_meta get_user_meta update_user_meta There are many tutorials explaining how to add additional fields to the user profile using User meta to store them, and it's how a lot ...


7

Why don't use built-in functionality of PHP? Put the following line right before the foreach: usort($members, create_function('$a, $b', 'return strnatcasecmp($a->last_name, $b->last_name);')); References: usort create_function strnatcasecmp


7

UPDATE 2018-06-28 While the code below mostly works fine, here is a rewrite of the code for WP >=4.6.0 (using PHP 7): function add_course_section_filter( $which ) { // create sprintf templates for <select> and <option>s $st = '<select name="course_section_%s" style="float:none;"><option value="">%s</option>%s</...


7

Both write their data in the “usermeta” table. User options stored in the usermeta table retain the wordpress table prefix e.g. wp_ whereas the user meta also stored in the usermeta table doesn't. User options support blog-specific options, useful in multisite. The user meta is based on the user id specific meta data like profile information. The ...


6

The Native get_users() function returns an array of user objects and each on holds [ID] => 1 [user_login] => admin [user_pass] => $P$Bxudi6gJMk2GRt2ed3xvZ06c1BPZXi/ [user_nicename] => admin [user_email] => admin@host.com [user_url] => http://localhost/ [user_registered] => 2010-06-29 07:08:55 [user_activation_key]...


6

User passwords are stored in the database as what is called a hash. hashes are not reversible even if you know the hash and the mechanism used to create it. The only way to "decrypt" a hash is to take a password, hash it, compare it against the target hash, and try again... over and over until you get a match. If you think about that, you aren't really ...


6

Actually I found this to be more strait forward and simpler: //add columns to User panel list page function add_user_columns($column) { $column['address'] = 'Street Address'; $column['zipcode'] = 'Zip Code'; return $column; } add_filter( 'manage_users_columns', 'add_user_columns' ); //add the data function add_user_column_data( $val, $...


6

Simple difference, user_login is used to validate login to the site, while user_nicename is used to create Author Permalink, Post Permalink


6

If you check out the documentation for the update_user_meta() function, you'll note that the $meta_value parameter already accepts objects and arrays, so you can simply save a user's positions in an array without any additional effort: update_user_meta( 22, 'position_names', array( 'Khaleesi of the Great Grass Sea', 'Breaker of ...


6

Clients get added by admins, clients have a parent child relationship with employees which makes filtering easy. So all we need to do is remove anything that doesn't have to do with employees and filter for employees with a certain meta value. First thing's first, whenever a new user is registered on the admin side of our CMS we will assign it a parent of ...


6

You have to trigger the following hooks: user_register personal_options_update edit_user_profile_update add_action('user_register', 'addMyCustomMeta'); add_action('personal_options_update', 'addMyCustomMeta' ); add_action('edit_user_profile_update','addMyCustomMeta' ); function addMyCustomMeta( $user_id ) { update_user_meta( $...


5

A simple example would be to get all users for a specific role, iterate over the returned results and apply the delete_user_meta function for the given meta_key. Stir and let simmer for a fraction of a second and all user meta for that key shall be gone. function say_goodby_to_the_meta(){ $role = 'subscriber'; $users = get_users('role='.$role); ...


5

No. There are no hooks or filters to add an input field to the create user form. Maybe it is possible to add an input field via jQuery. I have not tested it. If it is pssible to add an input field, than it should be possible to save this information because the process of creating an user is the same as updating an existing user. Update Yes, it is ...


5

After examining the code and much trial and error, I have a solution: There is a filter - user_profile_update_errors - that is called in the file wp-admin/includes/user.php just after Wordpress does it's own input validation. This filter allows plugins to return their own errors by adding them to a referenced WP_Error class. If any errors exist after the ...


5

If it's information that logically belongs to a post/page - you store it in postmeta (with update_post_meta function). If it's something that pertains to a user - usermeta table is for you. More still, there's Settings API in case you have a plugin that needs to persist any settings. From your question it is somewhat unclear which of these would be best for ...


Only top voted, non community-wiki answers of a minimum length are eligible