web-dev-qa-db-ja.com

Save_postとwp_insert_postの両方のアクションがあるのはなぜですか?

wp-includes/post.phpsource )では、wp_insert_post()の最後に、save_postwp_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 これらを指摘するため).

私は何かが足りないのですか?なぜそれらは両方ともそこにあります、そして、私が使用する行動を選択しているならば、一方を他方を選ぶ理由はありますか?

7
Tim Malone

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 が追加されました。

そして、そのようなフックが真実であれば、廃止予定のフックではなく、開発者が使用する 事実上の デフォルトのフックになると期待していました。

6
John P Bloch