Qual é a diferença entre os ganchos update_post_meta e update_postmeta?

8

Estou trabalhando em um sistema de revisão aprimorado para criar um arquivo de registro para todas as alterações feitas por usuários e / ou algoritmos referentes a metadados anexados a tipos de postagem específicos.

Embora esteja ciente de que update_post_meta funciona para todos os tipos de postagem, enquanto update_postmeta apenas funciona na postagem, minha pergunta não depende do tipo de postagem e também não cobre apenas a parte update como é o mesmo para updated , delete , etc.

Após a inspeção em wp-includes/meta.php , encontrei os ganchos mencionados anteriormente para fazer minhas coisas, mas isso levantou algumas questões para mim.

A seção no núcleo é esta uma linha - 215 na Versão 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 );
    }
}

Portanto, há um gancho para update_post_meta , update_comment_meta e update_user_meta . Logo após, outro hook é chamado - apenas para a tabela de posts, chamada update_postmeta , funcionando quase exatamente da mesma maneira, com a única diferença sendo que o maybe_serialize() data do meta_value é passado.

Linha 204:

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

No começo eu pensei que o segundo gancho está lá para compatibilidade com versões anteriores, mas ambos foram introduzidos em 2.9.0. update_postmeta e update_{$meta_type}_meta

Olhando um pouco mais, também encontrei outra resposta minha, três anos atrás, em que esse tópico também surgiu, mas esse não era o ponto principal.

Estou faltando alguma coisa aqui?

Essa compatibilidade com versões anteriores é afinal - e acaba de ser movida para meta.php em 2.9.0? Ou há algum motivo real para ter os dois? Para mim, as ações ligadas à função update_post_meta() poderiam facilmente maybe_unserialize() dos dados, se necessário, então eu realmente não vejo o ponto de ter ambos.

Aguardamos a sua opinião!

    
por fischi 08.02.2016 / 07:01

1 resposta

4

Ambos foram introduzidos na versão 2.9, mas foram feitos em arquivos diferentes.

update_postmeta entrou em /wp-admin/includes/post.php

Enquanto ...

update_{$meta_type}_meta entrou em /wp-includes/meta.php

Foi apenas mais tarde que update_postmeta foi alterado para /wp-includes/meta.php .

Então eu acredito que foi para compatibilidade com versões anteriores, onde porque o update_postmeta hook estava sempre recebendo o valor de maybe_serialize() , então ele deveria continuar a fazê-lo, apesar de depois ser movido para /wp-includes/meta.php .

Além disso, o que você já deve saber, mas para a leitura de outras pessoas, o update_postmeta hook retorna os dados da% super_global% e da chave que contém dados do painel de campos personalizados .

Poderia isso ter sido apenas uma má decisão de design? Parece que sim.

Pensei ter relembrado alguma outra razão em torno dessa questão em relação à dupla serialização de dados, mas eu poderia estar me misturando a outra coisa.

Curiosamente, se você armazenar dados já serializados na área de texto UI do campo personalizado, o WordPress o serializará novamente antes de armazená-lo, o que suporta a noção de compatibilidade com versões anteriores em relação a:

Nota: esta resposta não está necessariamente completa .

    
por userabuser 08.02.2016 / 09:03