@ライアン・エルキンズ:
答えは、各ユースケースをどのようにインポートするかにかかっていると思います。場合によっては、迅速かつ不潔なものが必要になることもあれば、より重要なユースケースになることもあります。ここに思い浮かぶ2つのことがあります:
WordPress Core内で代替フックを探す
時々手早く汚れている場合は、コアから他のダウンストリームフックを使用して必要なものを変更するか、ob_start()
/を使用してアップストリームフックとダウンストリームフックの両方を変更できますob_end_clean()
(@Todd Perkinsの「プラグインコードによる大きなHTML出力の処理」コード例の場合。)
フックを追跡するには、昨日投稿したInstrument Hooksプラグインを使用して、潜在的に使用できるフックを見つけるのに役立てることができます。
プラグイン開発者に目的のフックを備えたパッチを提出する
ユースケースがあなたまたはコミュニティにとってより重要な場合は、プラグインに必要なフックを追加することをお勧めします。次に、それをよくテストして、実際にユースケースに対応していることを確認した後、プラグイン開発者がパッチを適用することを期待して、プラグイン開発者にパッチを提出できるようにします。このように、テスト済みのコードを提供することで、それらを可能な限り簡単にし、ユースケースを自分で操作して、本当に必要なものであることを確認します。フックが必要だったが、最初に想定したものとは異なるものを実装しようとした後、特定のフックが必要だと思った頻度を説明することはできません。
パッチの作成に慣れていない場合は、プラグインのパッチ適用に最も当てはまるWordPressコアのパッチ適用に関する良い記事があります。
お役に立てれば?
PSちょっと残念なことと、あなたの質問の答えは、エンドユーザー専用に設計されたプラグインの割合です。つまり、独自のフックはありません。WordPressがほとんどのプラグインのように設計されていると想像してみてください?それは柔軟性に欠け、非常にニッチなソリューションです。
WordPressが他のプラグインが依存しているプラグインを自動インストールする機能を備えている場合、状況は異なるでしょうか?クライアントは特定の方法と使用可能なプラグインを必要とするため、通常はゼロから必要な多くの機能を作成する必要がありますが、残りの10%を90%更新する柔軟性はありません。
StackPressサイトで良い回答が報われるのと同じように、WordPressコミュニティのリーダーがベストプラクティス(他の開発者へのフックの追加など)に従ってプラグインが報われることを保証する方法を特定してほしいです。