Adding the WP display_name field to the WP-Members user profile update form

Some of the code in this post may need to be updated for the new 2.9 version. The current filter should still work, but it might be easier with some of the new filter hooks.

The new filter hook wpmem_register_form_rows allows a much more direct process that does not rely on str_replace. The problem with str_replace is that the search string must be an exact match. The change in wpmem_register_form_rows is a direct change.

Try out the new code snippet – I think that will work much better!

That’s not so much a bug as it is my lack of thinking through the logic.

The wpmem_register_data filter gets used in two places – both new registration and user update. I think my original thought with that was that it would make simple filters easier. In the end, it might have made more sense to have a separate filter for the update case. But this does address the need to pass another parameter in the filter so that it can be be determined which state we are in (new registration or user update).

Anyway… I didn’t really think of that when I wrote this. So what was happening is that the filter was being applied when the user registered, but ALSO when they updated; meaning whatever they chose in the dropdown was going to be changed by the filter.

I’ve been adding additional parameters in various filters throughout the plugin, and in an update, I’ll probably add one here so that ‘register’ or ‘update’ will be passed to the filter. But in the meantime, I’ve updated the filter function above with a logical test to only apply the default display_name to a new registration.

Hi Arthur,

WP-Members is great—almost perfect, but this one issue of first names or display names not being in the users table with user id and email etc is a big downer…

Since that issue is actually the way the WP database is built, does that move WP-Members up from “almost perfect” to “actually perfect”? 😉 (I guess if it were already perfect, I could stop further development… something that never quite seems to be done. 2.9.5 will be released this weekend, and I’ve already started development on 2.9.6 and 3.0.0.)

Actually, display_name is part of the wp_users table and not a user meta value, so you are OK there. And if you use display_name, that is a WP global variable for the user (see get_currentuserinfo).

With regards to first/last names, WP-Members default fields include the WP native first/last name fields because those are also retrieved by a number of user functions such as get_currentuserinfo. So as long as you stick with those and don’t create different custom fields for first and last names, these will generally be available to most WP functions that use the WP user object.

Yes, any custom fields will generally need to be retrieved with get_user_meta, but when using some of the WP default fields, the data is probably already there so don’t reinvent the wheel.

It’s probably important to point out that while WP-Members uses the term “username”, this is in fact “user_login” in WP parlance.

Hopefully that clarifies things for you a little. I have chosen to stick to the WP structure of things to ensure compatibility with both WP and other plugins rather than try to build a proprietary user data storage mechanism.

As far as displaying a user’s first name as greeting, as I mentioned you could use either display_name or first_name from the existing WP user object.

If you look toward the bottom of the above post, you can use the wpmem_register_data filter hook to change “display_name” at registration. By default, this would be the same value as username/user_login. But if you set up a filter you could easily make this the user’s first name or first & last name like this:

$fields['display_name'] = $fields['first_name'];

or this:

$fields['display_name'] = $fields['first_name'] . ' ' . $fields['last_name'];

Hope that helps clarify and gives you some ideas and direction. If you need clarification or have other questions, let me know.

On #1 (and this might get a little wordy…), there’s more than one approach, some more simple than other.

There is *always* going to be a value entered into the system for display_name. In a default configuration of the plugin, this will be whatever the user_login is (the user’s chosen username).

You can add display_name to the registration form (and user_nicename and nickname) and the plugin accounts for this – as long as you use the correct option name for the field. So in the WP-Members fields tab, if you create a custom field with a field label of “Alias” (or whatever you want to call it) and give it an option name of “display_name”, WP-Members will recognize that as the WP native field and act accordingly.

That’s the method I would use if you wanted users to “choose” a display name.

If you wanted to create a display name from something else the user supplies (such as first and last name), then you would implement a filter to take the supplied values for those fields and use them for the display_name value (as I mentioned earlier).

But it sounds to me like you might be thinking that you want users to create their own? If that’s the case, just add the display_name field to the registration form and you’ll be all set.

#2

Try not to do two things – reinvent the wheel and go outside of the WP construct.

If you want to add a bio field, there is actually a default WP field for that as well. This is the “Biographical Info / description” field and you will find it in list of fields that install with the plugin. I would suggest using this field rather than create something else. That way, if you use any other plugins that utilize WP native fields, this will match up without too much heavy lifting. If you create your own, that wouldn’t be the case.

I would highly advise against creating your own table to store anything. If you do, you’ll need to deal with your own queries and data management when there are already tools within WordPress itself to do that for you.

Any custom field you create in the WP-Members fields tab (and some default WP fields, too) will be stored as user meta. Don’t look at this as a burden because there are tools for handling and retrieving this information already in WP.

For example, if you create a custom field called “bio” and store it in your own table, you are going to need create a sql query to write that data separately during registration, a query to update it if the user updates their profile, and a query to retrieve it if you want to use that data somewhere. Every query you use is not only extra work you need to do, but also a possible security hole.

By contrast, if you just create this custom field through the construct that is already there, you only need to worry about retrieving the data when you want to display it which you can do without a query by using the get_user_meta function.

Hope that helps.

Sounds good!