Many sites are using WordPress profile fields to add additional information about their users. WordPress profile fields can also be used in author boxes under each article. In this tutorial you will learn how to add them easily with object oriented programming and WordPress hooks.
How to extend the WordPress Profile
WordPress profile is a settings page in the admin area that is used to edit the user’s information. This can be done by an administrator or by the user. The user can only edit their own profile but the administrator can edit all of them of course. We will extend the WordPress profile page by using WordPress hooks:
Those hooks will show our own HTML at the bottom of the page. We will also need to save the information we want to enter so we will need to use two additional action hooks that are called upon saving the profile data:
Creating WordPress Profile Fields
For creating our profile fields we will use an abstract class that we have already coded in a previous tutorial where we have learned how to create WordPress menu pages with OOP. If you did not read that article I do advise you to read it so that you can understand the abstract class and how to use it.
We will create our own class for handling profile fields by extending the abstract class and modified a few methods. If you have the code for our abstract class jump to the next chapter below, but if you don’t have the code for the abstract class here you can copy it:
Extending our Abstract Class
First, we will create our class with some basic attributes and a constructor method. Once we understand what we do here, we will create the other methods for rendering the fields and saving them.
Our attribute $title will be used for the section title on the user’s profile page. The attribute $slug will be used as the id of our settings. This will be used to save the data and also to retrieve them as we want. In out constructor method we assign the passed parameters and hook our other methods that we will define next. You can see here that we are using the hooks that we have previously mentioned.
The attribute $settings_id is an attribute inherited from the abstract class. There will also be some other methods used here that we have inherited from the abstract class so if you still do not understand from where some methods or attributes come from, please do read the article mentioned before. If you don’t have time to read that, then just remember that everything that is used here and not defined in our class, we have inherited it from the abstract class.
Let’s now define the method to render the fields:
We are first setting the user ID. Once that is set we call an inherited method init_settings. Since the inherited method retrieves the settings using the function get_option we will need to modify it because we will work with the user meta table.
We are rendering our fields using the method render_fields by passing the parameter $tab with the value ‘general’. We are doing that because we do not have any additional tabs here and all our fields will be saved to the general tab once they get defined. If you want to use the tabs be sure to check the article mentioned before and see how to implement that.
Now that know how to render the fields, let’s modify the inherited method init_settings:
The whole method here is almost the same as the one inherited. The only difference are the first two lines where we set the user id and retrieve the field data from the user meta by providing the user id and the slug (settings_id) that we have provided in the contructor method.
So we know how to render the fields and also how to retrieve the data. The only thing left to define is how to save our profile data:
The method save_profile_settings is used to set the user id provided by the two hooks personal_options_update and edit_user_profile_update and to call the inherited method for saving the settings. The inherited method save_settings is using the function update_option to save the data which is not what we are using for storing the profile data.
The second method is the modified version of our inherited method. The only difference from the inherited method is the last line where we use the function update_user_meta to store our profile data by providing user ID, our slug (settings_id) and the data (settings).
Now we have a functional class that can be used to create various WordPress profile fields. The type of fields that can be defined is set in the abstract class.
Using our Class to create WordPress Profile Fields
To create our profile fields we have to instantiate our class and then add fields using the inherited method add_field from the abstract class:
Retrieving the data
It does not make sense to not be able to retrieve that data, right? So, here is a simple example on how to retrieve the Facebook link from the user’s profile:
Today we have learned two things: how to create custom profile fields and how to reuse an existing abstract class that was previously coded. By using the WordPress hooks we could use some other methods to display the settings fields and also save the fields. In some solution you will need to modify the inherited methods and there is nothing wrong with that.
Have you ever create custom profile fields? How did you do it? Share your experience with others in the comments below:)Become a Sponsor
I like this solution, but the code is not working for me, at least using checkbox controls. The values looks like are not stored in the database after updating the profile.
Weird. Have you tried debugging what is sent in the method ‘save_settings’ to check if such checkbox data is sent at all?