web-dev-qa-db-fra.com

Quelle est la différence entre les hooks update_post_meta et update_postmeta?

Je travaille sur un système de révision amélioré, afin de créer un fichier journal pour toutes les modifications apportées par les utilisateurs et/ou les algorithmes concernant les métadonnées attachées à des types de publication spécifiques.

Bien que je sache parfaitement que update_post_meta fonctionne pour tous les types de publications, alors que update_postmeta fonctionne uniquement pour les publications, ma question ne dépend pas du type de publication et ne couvre pas seulement la partie update, car elle est identique pour updated, delete. , etc.

Après inspectiong wp-includes/meta.php, j’ai trouvé les crochets précédemment cités pour faire mon travail, mais cela m’a posé une question.

La section dans le noyau est celle-ci - ligne 215 de la 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 );
    }
}

Il y a donc un crochet pour update_post_meta, update_comment_meta et update_user_meta. Immédiatement après, un autre hook est appelé - pour la table posts, nommé update_postmeta, fonctionnant presque de la même manière, la seule différence étant que les données maybe_serialize() de la méta_value sont transmises.

Ligne 204:

$_meta_value = $meta_value;
$meta_value = maybe_serialize( $meta_value );

Au début, je pensais que le deuxième crochet était là pour la compatibilité ascendante, mais les deux ont été introduits dans la version 2.9.0. update_postmeta et update_{$meta_type}_meta

En regardant un peu plus loin, j'ai aussi trouvé une autre réponse, il y a trois ans, où ce sujet a également été abordé, mais ce n'était pas le point principal.

Est-ce que j'ai râté quelque chose?

Est-ce que cette compatibilité ascendante est après tout - et vient d'être déplacée vers meta.php dans 2.9.0? Ou y a-t-il une vraie raison d'avoir les deux? Pour moi, les actions rattachées à la fonction update_post_meta() pourraient facilement maybe_unserialize() les données, si nécessaire, donc je ne vois vraiment pas l'intérêt de disposer des deux.

Dans l'attente de vos commentaires!

hookspost-metacore
7
fischi

Ils ont tous deux été introduits dans la version 2.9, mais l'ont été dans des fichiers différents.

update_postmeta est entré dans /wp-admin/includes/post.php

Tandis que...

update_{$meta_type}_meta est entré dans /wp-includes/meta.php

Ce n'est que plus tard que update_postmeta a été déplacé dans /wp-includes/meta.php.

Donc, je pense que c'était pour la compatibilité avec les versions antérieures, où par parce que le hook update_postmeta recevait toujours la valeur de maybe_serialize(), il devrait continuer à le faire, même s'il a été déplacé plus tard dans /wp-includes/meta.php.

En outre, vous le savez peut-être déjà, mais pour le plaisir des autres lecteurs, le hook update_postmeta renvoie les données du super-global $_POST['meta'] et la clé qui contient les données du panneau des champs personnalisés .

Cela aurait-il pu être une mauvaise décision de conception? Ça y ressemble.

Je pensais avoir rappelé une autre raison entourant cette question en rapport avec la double sérialisation des données, mais je risquais de me perdre dans quelque chose d'autre.

Fait intéressant, si vous stockez des données déjà sérialisées dans la zone de texte de l'interface utilisateur de champ personnalisé, WordPress les sérialisera à nouveau avant de les stocker, ce qui prend en charge la notion de compatibilité avec les versions antérieures en ce qui concerne:

Remarque: cette réponse n’est pas nécessairement complète .

4
userabuser

Comme noté dans Wordpress Codex, add_post_meta insère un nouveau postmeta associé à une publication. Si le paramètre "unique" est défini sur true, vérifie si la clé existante porte le même nom. S'il existe, contournez-le, sinon, créez et affectez une valeur

update_post_meta mettra à jour les métadonnées et créera de nouvelles paires clé-valeur, si méta_key fourni n'existe pas.

Quel est le meilleur à utiliser? Cela dépend. update_post_meta convient à la plupart des situations, mais parfois, add_post_meta effectuera le travail si vous avez besoin d'ajouter des métadonnées dans des environnements restreints (hébergement partagé, par exemple).

S'il vous plaît lire pour plus d'informations: https://codex.wordpress.org/Function_Reference/update_post_meta et https://codex.wordpress.org/Function_Reference/add_post_meta

0
R. Simon