• Skip to primary navigation
  • Skip to main content

RocketGeek

Home of WP-Members, The Original WordPress Membership Plugin

  • WordPress Plugins
    • WP-Members
      • FAQs
      • Quick Start
      • Documentation
      • Extensions
    • Advanced Options
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • Download Protect
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • Invite Codes
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • MailChimp Integration
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • PayPal Subscriptions
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • Salesforce Web-to-Lead
    • Security
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • Text Editor
      • Purchase the Plugin
      • Get the Pro Bundle
    • User List
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • User Tracking
      • Documentation
      • Purchase the Plugin
      • Get the Pro Bundle
    • Memberships for WooCommerce
    • WordPass
  • Store
    • Cart
    • Checkout
  • Blog
    • Basics [Free]
    • Tips and Tricks
    • Filters
    • Actions
    • Code Snippets
    • Shortcodes
    • Design
    • Release Announcements
  • Contact
  • Sign In
  • Show Search
Hide Search
Home » Filters » Adding the WP display_name field to the WP-Members user profile update form

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

Chad Butler · Jul 10, 2013 ·

Recent versions of the plugin have improved support for some of the WP native fields such as nickname, user_nicename, and display_name.  I will be continuing to improve support for these fields.  Currently, if you want to add something like the Display Name field to the front end of the plugin, you need a little customization.  This post will take you through adding that to the front-end user profile update.

This needs to be done in the user profile update and not at registration because WP bases these fields on data used in registration that is not available on the static form – the nickname, the username, and first/last name.  This tutorial focuses on adding it to the user profile update, much like WP’s backend (which doesn’t set this at registration, either). 

This article is only available to WP-Members Support Subscribers. If you have an existing subscription, please login below. If you do not have a current support subscription, you can purchase a support subscription here.

Already a Member? Log In Here
   
Forgot password? Click here to reset

To gain full access to WP-Members premium content, a current support subscription is required. You can purchase an annual support subscription for as little as $59, which provides you with access to priority support, a customer support forum, access to code snippets, and more.

Why wait? Choose your subscription option here.

[
Why join?]

Filters, Tips and Tricks filters, str_replace, tips, wpmem_register_data, wpmem_register_form_rows

Welcome to RocketGeek Interactive › Forums › Adding the WP display_name field to the WP-Members user profile update form

Tagged: filters, str_replace, tips, wpmem_register_data, wpmem_register_form_rows

  • This topic has 20 replies, 4 voices, and was last updated 2 years, 10 months ago by PGRNational.
Viewing 8 reply threads
  • Author
    Posts
    • July 10, 2013 at 10:43 am #2796
      Chad Butler
      Keymaster

      Recent versions of the plugin have improved support for some of the WP native fields such as nickname, user_nicename, and display_name.  I will be con
      [See the full post at: Adding the WP display_name field to the WP-Members user profile update form]

    • June 10, 2014 at 1:45 pm #5077
      klint01
      Participant

      I’ve followed the instructions above and the display_name is not getting populated from the data in wordpress when I access the user profile front-end page. Suggestions on what may be missing or incorrect?

      • June 10, 2014 at 10:59 pm #5082
        Chad Butler
        Keymaster

        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!

        • June 11, 2014 at 8:59 am #5085
          klint01
          Participant

          The new code snipet works. Took me a while to notice you updated it directly in the example.

          thanks!

          • June 11, 2014 at 4:37 pm #5088
            Chad Butler
            Keymaster

            Thanks for letting me know. I’m glad to hear that worked out!

    • June 13, 2014 at 8:41 pm #5115
      klint01
      Participant

      I found a new bug. With the ‘wpmem_register_data’ filter in place, a user is restricted from selecting a different “Display name publicly as” unless it is the designation set in the filter.

      For example, I changed mine to be $fields[‘display_name’] = $fields[‘first_name’] . $fields[‘last_name’];

      Users had informed me that they could select their username in the drop-down of their update profile page, but when they clicked on update profile, it would revert back to first_name last_name.

      For now, I have commented out the add_filter line so it can be updated, but it also takes 2 to 3 tries before it stays changed.

      • June 14, 2014 at 8:44 am #5118
        Chad Butler
        Keymaster

        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.

        • June 14, 2014 at 9:00 am #5121
          klint01
          Participant

          Thanks. That worked for the update, but I still need to attempt it 2-3 times before it applies.

          For example:
          username = abc
          first_name = John
          last_name = Doe

          If my default is username, the display_name is set to ‘abc’, which is great if I want my display name to be my username. When I go to the drop-down and select John Doe and click update, the screen refreshes and the display_name is still ‘abc’, so I have to select John Doe again and click update. After the second or third time of doing this, the display_name is now updated to ‘John Doe’.

          Thoughts on why it is not applying on the first update?

          • June 14, 2014 at 11:40 am #5124
            Chad Butler
            Keymaster

            There aren’t really any reasons why it would not apply on one update but would on another, so that is not exactly expected behavior – either it will update or it won’t.

            Are you using a cache plugin such as Total Cache or Super Cache? I could see instances where that might interfere with the process.

          • June 14, 2014 at 1:13 pm #5126
            klint01
            Participant

            No cache plugin used on the site, but I am using Cloudflare, which does perform caching so that may be the issue, but odd it would only happen to that field.

          • June 14, 2014 at 2:24 pm #5127
            Chad Butler
            Keymaster

            I’ve been looking at this a little more because I think that the update portion of the function could stand to be improved. The function tests each field to see if it is (1) excluded, (2) a WP native fields, (3) a password, and finally (4) a custom field.

            For #1 and #3, the field is skipped. But for #2 and #4, the process updates that info and continues looping through the remaining fields.

            While custom fields need to be done individually that way using update_user_meta, the native fields use wp_update_user, which can do a single update query by passing an array of fields to be updated.

            That change wouldn’t effect your problem that I can see. But it would improve the function’s efficiency, replacing a number of db writes with a single process.

            In testing this, I discovered something that I am wondering may be part of your issue.

            If the user updates information in their profile that is part of the display name (such as first name or last name), and ALSO at the same time updates their display name, it may *appear* that the display name is not being updated.

            In this case, where the display name is actually updated, there is no match in the dropdown because one of those values was changed from what was part of the original form.

            Here’s an example. Joe Smith, whose username is “jsmith”, goes to update his profile and selects “Joe Smith” from the possibilities in the dropdown. In the same action (same form at the same time), he changes his first name to “Joseph”.

            Now, in the database, his first name is recorded as Joseph. His display name is recorded as “Smith, Joe”, but looking at the user profile update it appears that his change did not take effect. His username is jsmith, his first name is Joseph, but the displayname dropdown is on his username jsmith, not his first name last name “Joeseph Smith”.

            At this point, it should be apparent why it appears that his display name was not updated – there is no match in the dropdown for what the currently stored value is. So in comparing to determine what should be selected, it defaults to the first value – the username, even though that is not the value that is currently stored in the db.

            Could this be what is happening in your situation?

          • June 14, 2014 at 2:38 pm #5128
            klint01
            Participant

            I could understand how that would result in the display name not showing correctly. But in the example I provided, the only change to the user profile was selecting a different display name and clicking on update profile.

    • July 23, 2014 at 2:23 pm #5406
      arthur6
      Participant

      Where is username actually stored in WordPress? There is no username in your users table so I guess it is a global variable that is stored outside wp-members? If so, you are saying that if a user changes their display name in the user settings, this will update the global user name? That is what I want. I log in with mk500 and I want the site to say “Hi Mike”.

      Why can’t we require this in the registration form, this way I can write my code knowing for sure they will have a unique display name that I can reference in my sql statements instead of having to get the global username.

      I will be using the display name a lot on every page for many things, so this variable is important that users can customize and that the variable is easy to reference and retrieve with mysql/php and wp

    • July 23, 2014 at 2:29 pm #5407
      arthur6
      Participant

      Also, as a follow up to my last post…if I create a custom field called “Alias” and then I want to use that everywhere in the site for the user, is it easy to get that as the username from the user_meta table to display for each user id? If so, I guess it is just a matter of me having to deal with the annoyance of quickly viewing this alias username for a userid in that user-meta table since there will be many records and there are so many records for just one user all clumped together there as it is…

      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…

      • July 23, 2014 at 3:00 pm #5408
        Chad Butler
        Keymaster

        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.

    • July 23, 2014 at 3:49 pm #5411
      arthur6
      Participant

      Well thanks a bunch for getting back so quickly. Yes, that clears some things up–just a few more questions for clarification if you don’t mind (sorry for the length):

      1) So you are saying with your hooks that I can take the user_login variable that is required at registration and convert that to display_name and then I can easily echo this display name using the WP global variable correct? That would be great, except that now display name is still user_login which is the clunky name users came up with to register. I am looking for a way for someone to register with user name (say, MK500) but also be required to enter an alias/artist name such as “Spike Lee” and have that be part of the WP global so I can easily display it without using the user_meta table.

      The way I am hoping this could be done is if I could require the first_name or display_name field the registration form in addition to the username (user_login). I could change the field name to show as “Alias” or the like and capture it right then. This way I don’t have to write if statements later to see if they set a first name or display name in user settings such as “if (display_name) use display name else use user_login” everytime I want to show their name. Do you know what I mean? Again, all problems are solved if I can add and require the users variable first_name in the reg form.

      2) As a final question, I also want to add a user bio. Should/could that then go in separate table I create called “user details” where I can just pull the bio and other custom user info without having to worry about user-meta? I can link it to user_id…
      OR would it make sense to create my

      The reason is I want the friendly user name to appear next to many works as the artist/producer whatever, and when people click on that person they can view their bio.

      • July 23, 2014 at 4:21 pm #5412
        Chad Butler
        Keymaster

        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.

    • July 23, 2014 at 10:17 pm #5414
      arthur6
      Participant

      Excellent. That’s all I was looking for regarding the display_name. Not sure how I missed that one…I was too hung up on using first name which is not in the users table. Very simple. And I can access that from the $wpdb global to display that name anytime right?

      As for other tables, I will need many and will need custom tables for the scope and complexity. But it doesn’t sound hard to relate them in queries.

      This is outside your script, but where can I find/access the native Biographical Info/description field in WP you mentioned? I didn’t see it in any tables in mysql. You think it would be easier to insert into and select from that for a user on a custom profile/bio page than creating my own user table with custom info such as this?

    • July 24, 2014 at 12:10 am #5418
      arthur6
      Participant

      Nevermind…I found the description and how to return it and I’m good with the display name as I mentioned before. Still need some custom tables for the meat of this site, but got all I need from your wonderful plugin. Keeping my auto-updates for this plugin off…it’s working perfect as is 🙂 Thanks!

      • July 24, 2014 at 9:14 am #5420
        Chad Butler
        Keymaster

        Sounds good!

    • April 29, 2018 at 8:42 am #14651
      PGRNational
      Participant

      Thanks for pointing this one out to me. Worked perfectly.

  • Author
    Posts
Viewing 8 reply threads
  • You must be logged in to reply to this topic.
Log In

Ready to get started?

Join Today!

© 2021 · butlerblog.com · RocketGeek is built using WordPress, WP-Members, and the Genesis Framework

  • butlerblog.com
  • WP-Members Support Subscription
  • Terms of Service
  • Refund Policy