7

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!

4

They 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:

Note: this answer is not neccessarily complete.

0

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.org/Function_Reference/update_post_meta and https://codex.wordpress.org/Function_Reference/add_post_meta

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.