プラグイン用のAPIを作成する方法は？

私はWordPress用のプラグインを開発していますが、開発したほとんどのプラグインは2つまたは3つのクラスを使用しているため、BuddypressやWooCommerceほど大きくはありません。

他の開発者が機能をカスタマイズでき、それらのシステムがBuddypressおよびWooCommerceと同じである必要があるような複雑なシステム（現時点では詳細を共有できませんが、開発中に後で）を提供する2つのオープンソースプラグインを開発する予定です。

これらのプラグインファイルを確認すると、開発者が必要に応じて変更できる独自のアクションとフィルターが登録されていることがわかります。しかし、私の問題は、他の人が機能をオーバーライドするだけでなく、独自のプラグインを追加する柔軟性を持つプラグインをどのように書くべきかを完全に理解できないことです。

明確な答えを出すのは難しいことは知っていますが、正しい方向に進むには、何らかのスタートアップガイドが必要です。独自のアクションとフィルターを登録する必要がありますか？はい、どうですか？そうでない場合、私のオプションは何ですか？

あなたのアドバイスは私を大いに助けます...ありがとう

プラグインまたはテーマで提供するAPIは、その特定のコードのロジックによって異なります。すべての状況に当てはまるガイドはおそらくないでしょう。

私はAPIを使用した複数のプラグインの寄稿者であり、これまでに学んだことは次のとおりです。

1. 人々があなたのコードをどのように使用するかを本当に理解するまで、APIを提供しないでください。

   APIなしで最初の2つまたは3つのバージョンをリリースします。可能な場合、カスタムアクションやカスタムフィルタ、パブリックメソッドやパブリック関数はありません（グローバル変数もありません）。ユーザーからの要求を待ちますが、内部コード構造が長期的に機能することがわかるまでコードを追加しないでください。

   APIの後方互換性を維持するのは困難です。他の場所で必要な改善を妨げる可能性があります。WordPressが現在削除できないすべてのグローバル変数について考えてください。それは悪いAPIであり、人々はすでにそれを使用しているので、長年それを使い続けています。

2. APIを残りのコードから分離することを検討してください（アイデアについては前のリンクを参照してください）。
   APIは、サードパーティの開発者だけでなく、あなたにとっても役立つはずです。必要がない場合は、自分で制限を追加しないでください。

3. 自分のドッグフードを食べます。
   カスタムフックを提供する場合は、コードで使用してください。これにより、他の開発者に有用な例が提供され、潜在的な欠陥をすぐに確認できます。
   WordPressコアがいわゆる設定APIを内部で使用する場合、今日はこの混乱はありません。多分。

4. 例でリード。
   プラグインでWordPressコアAPIの優れた部分を使用します。匿名オブジェクト、定数、グローバル変数、およびあらゆる種類の予測不可能なコードを避けてください。

5. 一貫した命名スキーム（このような混乱ではない）を使用していることを確認し、すべてを独自の名前空間の下に置いてください。

6. 最初にドキュメントを書きます。後で新しい（の一部）APIをリリースします。
   すべての有用な例を作成します。どれだけ多くの穴と冗長性が見つかるか、驚くでしょう。

7. コールバック地獄を避けてください。
   物事が正常に機能しない場合にAPIをデバッグするための特定のツールを提供します（縮小されていないスクリプトやスタイルシートを含む）。AJAXをデバッグする方法の例を作成しましたが、ここでどのように創造できるかを示しています。繰り返しますが、これらのツールはリリースする前にドキュメントで説明する必要があります。

8. WordPressのコールバックパラダイムに代わるものは、Observerパターンです。これにより、サードパーティの開発者にとって障壁が高まりますが、その結果、双方のコードが改善される可能性があります。