wp-includes/post.php
( source )では、wp_insert_post()
の最後に、save_post
とwp_insert_post
の両方のアクションが、まったく同じパラメーターで次々に呼び出されることに気付きました。
3520 /**
3521 * Fires once a post has been saved.
3522 *
3523 * @since 1.5.0
3524 *
3525 * @param int $post_ID Post ID.
3526 * @param WP_Post $post Post object.
3527 * @param bool $update Whether this is an existing post being updated or not.
3528 */
3529 do_action( 'save_post', $post_ID, $post, $update );
3530
3531 /**
3532 * Fires once a post has been saved.
3533 *
3534 * @since 2.0.0
3535 *
3536 * @param int $post_ID Post ID.
3537 * @param WP_Post $post Post object.
3538 * @param bool $update Whether this is an existing post being updated or not.
3539 */
3540 do_action( 'wp_insert_post', $post_ID, $post, $update );
それらの間では何も起こらないので、どちらを使用しても違いはないようです。
同じ冗長性がwp_publish_post()
( source )でもう少し繰り返され、 最も古いファイルの追跡バージョン にも同じ2つのアクションがあります(thanks toscho これらを指摘するため).
私は何かが足りないのですか?なぜそれらは両方ともそこにあります、そして、私が使用する行動を選択しているならば、一方を他方を選ぶ理由はありますか?
wp_insert_post
チェンジセット2887で導入されました 、そして bug#1681 を修正することでした。私はsave_post
フックの元々の由来を見つけることができませんでしたが、最近では チケット#2063 に関連してコア チェンジセット3291 に追加されました。明らかにそれは1.5.2に存在していましたが(バージョン管理 この理論をサポートしていません )、バックコンパット用に追加し直す必要がありました。
したがって、 どうやら 、1.5.0でsave_post
が追加され、その後2.0開発ライフサイクルでなんらかの形で削除され、 その後 wp_insert_post
が2.0開発ライフサイクルで後で追加され、 finally 、save_post
は、2.0のライフサイクルの後半で、互換性を損なわないように、 back が追加されました。
そして、そのようなフックが真実であれば、廃止予定のフックではなく、開発者が使用する 事実上の デフォルトのフックになると期待していました。