質問: is_admin()はいつ利用可能になりますか? 同じファイル内でインスタンス化されたクラスからなるプラグインがたくさんあります。例えば:class my_plugin { function __construct() { add_action('init', array( __class__, 'baz' ) ); } static function baz() { // some stuff that should happen in admin } } new my_plugin(); それでは、各関数の内部の働きを条件付きで囲むようにしますが、代わりにadd_action()ステートメントをif( is_admin() )で囲み、サイトのそれぞれのフィルタリストを肥大化させないようにできますか。
回答: is_admin()はいつ利用可能になりますか? ほとんどどこでも。私がそれが利用できないであろう場所について考えることができる唯一の例は、wp-config.phpのようなファイル、およびいくつかのドロップインの超早い段階です。しかしmu-plugin、テーマ、またはプラグインがロードされるまでには存在します。 さて、各関数の内部動作を条件付きでラップするようにしますが、代わりにif(is_admin())でadd_action()ステートメントをラップし、サイトのそれぞれのフィルタリストを肥大化させないようにできますか はい、しかしあなたが与えた例では代わりにadmin_initにフックするほうが簡単です。フックに何かを追加することは高価ではありません、それはフックが起動して関数が実行されるときに起こることは高価です。いくつかの特別な注意 同じファイル内でインスタンス化されたクラスからなるプラグインがたくさんあります。例えば: これは悪い習慣です、あなたはそれを疑問視する権利があります、そしてコピーされるべきではありません。クラスが定義されているのと同じファイルにオブジェクトを作成しないでください。問題が発生します。 function __construct() { add_action('init', array( __class__, 'baz' ) ); } これは、あなたがこのオブジェクトを作成した瞬間、フックを登録して物事をやり始めることを意味します。これは煩わしいこともあれば、runまたはstart関数を持つことで簡単に回避できる問題を引き起こすこともあります。それはまた、単体テストを書くことを非常に難しくし、場合によっては不可能にします。コンストラクターはオブジェクトを作業用に準備する必要がありますが、作業は行わないでください。洗濯機を買うのと対比して服を洗うのと同じように考えてください。コンストラクタは、マシンを組み立てて準備するかもしれませんが、いつ実行されるのかを判断できると便利です。 add_action('init', array( __class__, 'baz' ) ); } static function baz() { 関数barは静的なので、このオブジェクトが複数作成された場合、bazは複数回実行されます。 new my_plugin(); ここにいくつかの問題があります。 ファイルをロードするとすぐにオブジェクトが作成され、処理が行われます。まだそのようなことをしたくないかもしれないので、あなたはそれの制御を失いました 作成されたオブジェクトは何にも割り当てられず、ぶら下がったままになります。これは匿名クラスになったため、スタックトレースとデバッグは非常に困難になります。 匿名であるため、そのアクションをフック解除することはできません。そのためにはオブジェクトへの参照が必要ですが、それはここでは不可能です 元の答えのtldrはあなたがis_adminが利用可能であることに頼ることができるということです、そしてあなたはそれが利用できない状況でプラグインやテーマに遭遇するべきではありません