回答:
一般的に:はい、専用フックが独自のコードを開始するのを待ちます。オブジェクトインスタンスをグローバルネームスペースにスローしないでください。しかしinit
、めったに必要ではありません。
あなたはできるだけ遅くフックインします。最初のコードが実行される場合wp_head
は、以前のフックを使用しないでください。フックをカスケードすることもできます:
add_action( 'wp_head', 'first_callback' );
function first_callback()
{
// do something
// then
add_action( 'wp_footer', 'second_callback' );
}
init
フックについて:wp_loaded
代わりに使用してください。それは呼び出されたinit
後 ms_site_check()
に実行されます。このようにして、マルチサイトインストールの無効なサブサイトでプラグインを実行することを避けます。他はすべて同じです。
次の理由により、この方法の大きな利点はわかりません。
add_action
そしてadd_filter
機能だけグローバル変数にエントリを追加し$wp_filter
、すべてのフィルタとアクションを保持しています。ソースを参照してください。関数を呼び出すことはありません。コードは、およびが(適切なフック名で)呼び出されたときにのみ実行されます。これは、これらのフックがある場所で非常に遅く発生します。do_action
apply_filters
そうすることで、グローバル変数$wp_filter
が大きくなる=>より多くのメモリが必要になると言うかもしれません。しかし、新しい関数を作成することにも同じ問題があると思います。
すべてを1つの関数に入れると、テーマ/プラグインのすべてのファイルのすべてのフックを思い出さなければなりません。あなたはこのようなことをしないでしょう:
header.php
:ヘッダーで発生したこと(メニュー、スクリプトの登録など)にフックとコールバック関数を追加するcontent.php
:コンテンツをフィルタリングするためのフックとコールバック関数を追加しますadmin-menu.php
:管理メニューを追加するためのフックとコールバック関数を追加します(これらのファイルがテーマ/プラグインに配置されていると仮定します)
その代わりに、次のことを行う必要があります。
header.php
、content.php
、admin-menu.php
=>これは、header.php
ファイルの内容を見るときに何が起こるかを知るのを難しくします。これらのコールバックがいつ起動されるかを知るために検索する必要があります。
テーマ/プラグインに複数のクラスがある場合の状況について考えてください。すべてのクラスのすべてのフックを1か所に配置しますか?または、各クラスにすべてのフックを保持するラッパー関数がありますか?冗長すぎる!
これらの理由の上で、それは個人的なスタイルだと思います:)。ハイブリッドのようないくつかのフレームワークがあなたが言ったことをしているのを見ます。時々それはそれらのフレームワークを掘り下げるのを難しくします!
wp_loaded
とMS情報。