Converting user meta fields into a readable format
The Users Insights plugin can be used to read your custom user meta fields from a wide range of plugins. The problem is that not all plugins will store your data in a human-readable format. We do have modules for some plugins and they will to do this conversion and show you your data in a way that it makes sense for you. But for the plugins that we don’t have modules for it’s still possible to read your data.
Today we are going to show you how you can do this for a few different data types. In particular, we’ll focus on data that can be converted in a child theme or a custom plugin. In this way you can add your custom code and you don’t need to worry about losing these changes in future updates.
Therefore we’ll dive into how to create a child theme and what data types we’ll convert. We’ll also briefly cover the development point of view and mention why they are unreadable in the first place.
Our goals for today are:
- Applying your custom code
- The usin_user_db_data filter
- Converting PHP serialized data
- Human-readable dates
- Making sense of JSON data
- Data reference stored as IDs
Let’s dive right into it!
Applying your custom code
When applying custom code to change a plugin’s functionality, it is important to do it in a way so it will remain saved after updating the plugin. We recommend one of the following two methods to apply the code snippets provided in this tutorial:
- Using a child theme
- Creating a custom plugin
Using a child theme is the more convenient method, since most of the installations already use one. If you don’t have a child theme installed, the easiest way to create one is by using a plugin, such as One Click Child theme. Once you install the plugin and create your child theme you’ll get a new functions.php and a style.css file. When using a child theme, you can add your custom code to the functions.php file of the child theme.
One downside of the child theme method is that it is dependant on your theme. If you change your main theme, you would have to adjust your child theme to work with your new theme. If you don’t change your themes often, that shouldn’t be a problem, otherwise creating a custom plugin might be a better option for you.
For instructions on how to create your custom plugin, we recommend checking the official WordPress plugin guide.
The usin_user_db_data filter
The usin_user_db_data filter of Users Insights can be used to change how each value is represented in the user table and the export file. This filter is applied to the user data just after it is loaded from the database. The filter has one argument – a user data object. You can access the different fields by using $data->fieldname .
function my_format_fieldname($data){
$data->fieldname = "my value";
return $data;
}
add_filter('usin_user_db_data', 'my_format_fieldname');
Please note that user meta fields, created from the Custom Fields section, are prefixed with usin_meta_. For example, if your custom field key is “age”, it will be available under the usin_meta_age property:
$data->usin_meta_age;
For this tutorial we’ll assume that you are working with user meta fields, since the default Users Insights fields are already formatted.
Converting PHP serialized data
Sometimes a single field might not contain just a simple value, but a more complex PHP value. For that to be saved in your DB using WordPress, the value needs to be serialized so it can be stored in a text format.
The process of serializing will allow you to store multidimensional data in a simple text field. For example, you may have a field called “languages” that contains a PHP array of the languages that each user speaks. For example the list of the following languages:
- French
- Italian
will be stored like this when serialized:
a:2:{i:0;s:5:"Fench";i:1;s:7:"Italian";}
As you can see, the above serialized data isn’t so easy to read. And sometimes when you access the custom user meta fields directly you may bump into serialized data.
But fear no more, we’ll show you how you can convert this into a human-readable format.
You can use the above-mentioned usin_user_db_data filter to change the value of the field. In the following code snippet we assume that your data is stored as a serialized PHP array.
function my_format_fieldname($data){
if(!empty($data->usin_meta_fieldname)){
//format the data in the way you need
$formatted = implode(', ', unserialize($data->usin_meta_fieldname));
//apply the new format
$data->usin_meta_fieldname = $formatted;
}
return $data;
}
add_filter('usin_user_db_data', 'my_format_fieldname');
What this code does is to:
- Check if the field isn’t empty
- If it isn’t empty, unserialize the data to get the actual PHP array and join the values of the array with a comma delimiter. If your data is stored in a different format, you can apply a different formatting method.
- Return the data with the new user field formatting
Just don’t forget to replace “fieldname” with the key of the custom user field (make sure to replace in all 5 occurrences).
With our example above, after applying the custom code snippet and replacing the “fieldname” text with “languages” ($data->usin_meta_languages ), we now have the following result:
Human-readable dates
It’s pretty hard to do math with dates in the way we humans use them. Additionally, we have many different date formatting standards across different countries. The solution for this is the UNIX time. In short computers store dates, hours, minutes and seconds as a single number, the number of seconds since January, 1st 1970.
This may seem even harder, but from a computer’s point of view it’s much easier to process 1494325580791 – 1489213540791 than it is to do something like 01/01/1990 – 12/03/1984.
But again this creates another problem for us, we have no idea what 1494375560791 means. Some plugins may store your user date fields in this format and in this case, it will be much easier to be able to read the data in the user table.
In order to achieve that we can use the following snippet:
function my_format_timestamp($data){
if(!empty($data->usin_meta_fieldname)){
//apply the new format
$data->usin_meta_fieldname = date(
get_option('date_format'),
intval($data->usin_meta_fieldname)
);
}
return $data;
}
add_filter('usin_user_db_data', 'my_format_timestamp');
For this snippet you’ll need once again to replace the “fieldname” text with your custom field name.
The actions performed in this code are:
- Check if there is data for fieldname
- Replace the old fieldname value with a formatted version of it, following the date formatting options set in your WordPress install
Making sense of JSON data
JSON is another format for storing more complex data in a single text field. If you are familiar with HTML or XML code, JSON is very similar and can be used in a wide array of applications, most commonly for front-end scripting as it is natively supported by JavaScript.
Similarly to the process of serializing data, this user meta format is not easy to read. Here is an example of a JSON data that stores the names of a user’s friends with their IDs.
{
"John": 203,
"Joseph": 387,
"Bill": 87
}
We can format this particular data like this:
function my_format_json($data){
if(!empty($data->usin_meta_fieldname)){
//apply the new format
$json = $data->usin_meta_fieldname;
$json = json_decode( $json, true );
$json = implode( ',' , $json );
$data->usin_meta_fieldname = $json;
}
return $data;
}
add_filter('usin_user_db_data', 'my_format_json');
This function will get only the values for your data fields and return a simple list for them. In our example, these values are actually references to users (IDs) but it could be also posts or other type of data. Although this function will present you a simple list of the IDs it won’t actually give you the username of your friends. The next section will shed some light on ways of solving this issue.
Data reference stored as IDs
In order to have an efficient database, we can’t store duplicated instance of your data. As in our friends example usually, we store just a reference to the complete dataset, which will be in another place so the data is always unique. So we just store the ID for that element and will collect the actual data when we need it.
This is important because when you update the original data all the references will be updated since they are getting the data from the same source. Otherwise, each write function you have would need to check all possible references your data has in order to keep them all updated.
For this example, we’ll explore the possibility of having a post ID stored in a custom user field. This could be for order ID, product ID, course ID and many many other applications.
So your user meta field value is something simple, such as 3289. But we need to show in our user table the actual post name related to this data. This snippet will do it:
function my_format_title($data){
if(!empty($data->usin_meta_fieldname)){
//apply the new format
$title = $data->usin_meta_fieldname;
$title = get_the_title( $title );
$data->usin_meta_fieldname = $title;
}
return $data;
}
add_filter('usin_user_db_data', 'my_format_title');
This code is quite simple but can be extended in many ways. For example, you could use this in combination with the code before to return the usernames from each user. It’s also possible to even get custom fields from references – if you store a product in the user meta you could show the price in your user list.
The code above will:
- Check if there’s data in your field
- Get the title from a post, based on their ID
- Return the title instead of the ID
Just make sure you replace “fieldname” with the actual key of your custom fields. Also, you can use any function instead of the get_the_title , including custom functions if you want to.
Conclusion
Today we covered a lot of different snippets that can be used to format your custom fields. These codes can be used as they are or extended and used in many other interactions. This can be helpful when you combine the Users Insights plugin with other plugins.
We hope you enjoyed it and see you next time!