Diego La Monica

WordPress: differences between update_user_meta and update_user_option

—

da

Diego La Monica
in ,

Today I was wondering about differences between update_user_meta and update_user_option methods, and Googling about them I didn’t discovered clear differences. In WordPress too the two methods sometimes overlap.

I think that a misunderstanding of those methods could cause an heavy headache!

All both write their data in the “usermeta” table. The behavior of the following calls is quite the same:

<?php
# Writes test_key_1 = test_value in the usermeta table
update_user_meta( 1, 'test_key_1', 'test_value');

# Wtrites test_key_2 = test_vakue in the usermeta table
update_user_option(1, 'test_key 2', 'test_value', true);
?>

Of course both of them has their specific fired hooks, but you’ll agree with me when I say: “they seems both the same”.

Indeed if you use the following query you can notice any difference between the two values except the meta_key that differ only for the digit char we’ve used as suffix for them:

SELECT * FROM wordpress.wp_usermeta where meta_value = 'test_value';

But you have to notice that, if the last (optional) parameter of update_user_option value is set to “false” (its default value), you will get the meta_key prefixed with the $wpdb->prefix value.

So the following calls will produce the same record into the database:

<?php
# Writes test_key_1 = test_value in the usermeta table
update_user_meta( 1, 'wp_test_key_1', 'test_value');

# Wtrites test_key_2 = test_vakue in the usermeta table
update_user_option(1, 'test_key 2', 'test_value');
?>

 

Side effects

If you’re thinking about how to move users meta and options between wordpress instances or how to apply the user’s meta to another user in another instance of wordpress, you have to take care about which of metadatas are options and which of them are settings. Because the options keep the wordpress table prefix. So, in example,the options prefixed with “wp_” will never work in another WordPress instance if you’ve configured the second one to have, in example, “mywp_” as table prefix.

But take care because it is not sure that the meta keys prefixed with the WordPress table prefix would  be an option.

My 2 cents

Real world

To make quite distinct options and settings to you or to your DBA, you should prefix however the options with “opt_“. It would be clear that the related record in the usermeta table will be an option otherwise it will be a setting.

In my dreams

It would be great if the usermeta table has another field that describes formally if the value is an option or if it is a setting (is_option).

Your contribution

And which is your best way to distinct against options and settings?