I am working on an enhanced revisioning system, to create a log file for all changes made by users and/or algorithms concerning metadata attached to specific post types.
While I am perfectly aware that update_post_meta works for all post types, while update_postmeta just works on post, my question is not dependent on the post type, and it also does not just cover the update part, as it is the same for updated, delete, etc.
After inspectiong wp-includes/meta.php, I found the previously mentioned hooks to get my stuff done, but this raised a questions for me.
The section in the core is this one - line 215 in Version 4.4.2:
foreach ( $meta_ids as $meta_id ) {
/**
* Fires immediately before updating metadata of a specific type.
*
* The dynamic portion of the hook, `$meta_type`, refers to the meta
* object type (comment, post, or user).
*
* @since 2.9.0
*
* @param int $meta_id ID of the metadata entry to update.
* @param int $object_id Object ID.
* @param string $meta_key Meta key.
* @param mixed $meta_value Meta value.
*/
do_action( "update_{$meta_type}_meta", $meta_id, $object_id, $meta_key, $_meta_value );
}
if ( 'post' == $meta_type ) {
foreach ( $meta_ids as $meta_id ) {
/**
* Fires immediately before updating a post's metadata.
*
* @since 2.9.0
*
* @param int $meta_id ID of metadata entry to update.
* @param int $object_id Object ID.
* @param string $meta_key Meta key.
* @param mixed $meta_value Meta value.
*/
do_action( 'update_postmeta', $meta_id, $object_id, $meta_key, $meta_value );
}
}
So there is a hook for update_post_meta, update_comment_meta, and update_user_meta. Directly after that another hook is called - just for the posts table, named update_postmeta, working almost exactly the same way, with the only difference being that the maybe_serialize() data of the meta_value is passed.
Line 204:
$_meta_value = $meta_value;
$meta_value = maybe_serialize( $meta_value );
At first I thought that the second hook is there for backward compatibility, but both of those were introduced in 2.9.0. update_postmeta and update_{$meta_type}_meta
Looking a little bit further, I also found another answer by me, three years ago, where this topic also came up, but this was not the main point.
Am I missing something here?
Is this backward compatibility after all - and has just been moved to meta.php in 2.9.0? Or is there any real reason to have both of those? For me, the actions hooked to the update_post_meta() function could easily maybe_unserialize() the data, if needed, so I really do not see the point of having both.
Looking forward to your input!
I am working on an enhanced revisioning system, to create a log file for all changes made by users and/or algorithms concerning metadata attached to specific post types.
While I am perfectly aware that update_post_meta works for all post types, while update_postmeta just works on post, my question is not dependent on the post type, and it also does not just cover the update part, as it is the same for updated, delete, etc.
After inspectiong wp-includes/meta.php, I found the previously mentioned hooks to get my stuff done, but this raised a questions for me.
The section in the core is this one - line 215 in Version 4.4.2:
foreach ( $meta_ids as $meta_id ) {
/**
* Fires immediately before updating metadata of a specific type.
*
* The dynamic portion of the hook, `$meta_type`, refers to the meta
* object type (comment, post, or user).
*
* @since 2.9.0
*
* @param int $meta_id ID of the metadata entry to update.
* @param int $object_id Object ID.
* @param string $meta_key Meta key.
* @param mixed $meta_value Meta value.
*/
do_action( "update_{$meta_type}_meta", $meta_id, $object_id, $meta_key, $_meta_value );
}
if ( 'post' == $meta_type ) {
foreach ( $meta_ids as $meta_id ) {
/**
* Fires immediately before updating a post's metadata.
*
* @since 2.9.0
*
* @param int $meta_id ID of metadata entry to update.
* @param int $object_id Object ID.
* @param string $meta_key Meta key.
* @param mixed $meta_value Meta value.
*/
do_action( 'update_postmeta', $meta_id, $object_id, $meta_key, $meta_value );
}
}
So there is a hook for update_post_meta, update_comment_meta, and update_user_meta. Directly after that another hook is called - just for the posts table, named update_postmeta, working almost exactly the same way, with the only difference being that the maybe_serialize() data of the meta_value is passed.
Line 204:
$_meta_value = $meta_value;
$meta_value = maybe_serialize( $meta_value );
At first I thought that the second hook is there for backward compatibility, but both of those were introduced in 2.9.0. update_postmeta and update_{$meta_type}_meta
Looking a little bit further, I also found another answer by me, three years ago, where this topic also came up, but this was not the main point.
Am I missing something here?
Is this backward compatibility after all - and has just been moved to meta.php in 2.9.0? Or is there any real reason to have both of those? For me, the actions hooked to the update_post_meta() function could easily maybe_unserialize() the data, if needed, so I really do not see the point of having both.
Looking forward to your input!
Share Improve this question edited Feb 8, 2016 at 6:38 Pieter Goosen 55.5k23 gold badges117 silver badges211 bronze badges asked Feb 8, 2016 at 6:01 fischifischi 7,5492 gold badges30 silver badges44 bronze badges2 Answers
Reset to default 4They were both introduced in version 2.9, but were done so in different files.
update_postmeta went into /wp-admin/includes/post.php
While...
update_{$meta_type}_meta went into /wp-includes/meta.php
It was only later that update_postmeta was shifted into /wp-includes/meta.php.
So I believe it was for backward compatability, where by because the update_postmeta hook was always receiving the value of maybe_serialize() then it should continue to do so, despite later being moved into /wp-includes/meta.php.
Furthermore, which you may already know, but for the sake of others reading, the update_postmeta hook returns data from the $_POST['meta'] superglobal and key which holds data from the custom fields panel.
Could this just have been a poor design decision? Looks like it.
I thought I recalled some other reason surrounding this very question in relation to double serialization of data, however I could be getting mixed up with something else.
Interestingly, if you store already serialized data in the Custom Field UI textarea, WordPress will serialize it again before storing it, which supports the notion of backward compatability in relation to:
- https://core.trac.wordpress/ticket/12930
- https://nacin/2010/04/18/wordpress-serializing-data/
Note: this answer is not neccessarily complete.
As noticed in Wordpress Codex, add_post_meta inserts new postmeta associated to a post. If provided parameter "unique" as true, will check for existing key with same name. If exists, bypass it, if not, create and assign value
update_post_meta will update metadata and create new key and value pairs, if provided meta_key not exists.
What is the best to use? It depends. update_post_meta fits the most situations, but sometimes add_post_meta will get the work done if you need to add metadata in restrited environments (shared hosting, for example).
Please read for more info: https://codex.wordpress/Function_Reference/update_post_meta and https://codex.wordpress/Function_Reference/add_post_meta