web-dev-qa-db-ja.com

Update_post_metaファックとupdate_postmetaファックの違いは何ですか？

私は、ユーザーによって行われたすべての変更および/または特定の投稿タイプに添付されたメタデータに関するアルゴリズムについてのログファイルを作成するために、強化された改訂システムに取り組んでいます。

update_post_metaはすべての投稿タイプで機能することを私は完全に認識していますが、update_postmetaは単に投稿タイプで機能するのですが、私の質問は投稿タイプに依存せず、update部分もカバーしていません。 updated、deleteなどの場合.

wp-includes/meta.phpを調べた後、私は自分のものを完成させるために前述のフックを見つけました、しかしこれは私に質問を投げかけました。

コアのセクションは、バージョン4.4.2のこの1行215です。

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 );
    }
}

そのため、update_post_meta、update_comment_meta、およびupdate_user_metaのためのフックがあります。その直後に、update_postmetaという名前のpostsテーブル用の別のフックが呼び出され、ほぼ同じ方法で動作しますが、唯一の違いはmeta_valueのmaybe_serialize()データが渡されることです。

行204：

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

最初は2番目のフックが後方互換性のためにあると思いましたが、両方とも2.9.0で導入されました。 update_postmeta および update_{$meta_type}_meta

もう少し詳しく見てみると、私も3年前にこのトピックが出てきた別の答えを見つけましたが、これは重要な点ではありませんでした。

私はここに何かが足りないのですか？

この下位互換性は結局のところです - そして2.9.0でmeta.phpに移動したばかりですか？それとも、両方を持っている本当の理由はありますか？私にとっては、update_post_meta()関数にフックされたアクションは、必要に応じてデータを簡単にmaybe_unserialize()することができます。そのため、両方を持つことの意味はわかりません。

あなたの入力を楽しみにしています！

hookspost-metacore
7
fischi

それらは両方ともバージョン2.9で導入されましたが、異なるファイルでそうされました。

update_postmetaは に入った - /wp-admin/includes/post.php

ながら….

update_{$meta_type}_metaは に入った - /wp-includes/meta.php

update_postmetaが/wp-includes/meta.phpにシフトされたのはあとでです。

update_postmetaフックが常にmaybe_serialize()の値を受け取っていたため、後で/wp-includes/meta.phpに移動したにもかかわらず、引き続き互換性があるはずです。

さらに、あなたはすでに知っているかもしれませんが、update_postmetaフックは$_POST['meta']スーパーグローバルからのデータと カスタムフィールドパネルからのデータを保持するキー を返します。

これは単に設計上の不適切な決定だったのでしょうか。そのように見える。

データの二重シリアル化に関するこの問題を取り巻く他の理由を思い出しましたが、他のものと混同される可能性があります

興味深いことに、カスタムフィールドUIのtextareaにすでにシリアル化されたデータを格納している場合、WordPressはそれを格納する前に再度シリアル化します。

注： この回答は必ずしも完全ではありません 。

4
userabuser

Wordpress Codexで気づかれたように、 add_post_meta は投稿に関連した新しいpostmetaを挿入します。 trueとして「unique」パラメータを指定した場合、同じ名前の既存のキーを確認します。存在する場合はバイパスし、存在しない場合は値を作成して割り当てます。

update_post_meta 指定されたmeta_keyが存在しない場合、メタデータを更新し、新しいキーと値のペアを作成します。

何が一番いいの？ 依存します。 update_post_metaはほとんどの状況に適していますが、制限された環境（たとえば共有ホスティング）でメタデータを追加する必要がある場合、add_post_metaが作業を完了させることがあります。

詳細についてはお読みください： https://codex.wordpress.org/Function_Reference/update_post_meta および https://codex.wordpress.org/Function_Reference/add_post_meta

0
R. Simon