私はWordPress用のプラグインを開発していますが、私が開発したほとんどのプラグインは2つか3つのクラスを使用しているので、BuddypressやWooCommerceほど大きくはありません。
私は2つのオープンソースプラグインを開発して、他の開発者が機能をカスタマイズできるような複雑なシステム(現時点では詳細を共有できないが開発中は後で)を提供するように計画しています。 。
私がそれらのプラグインファイルをチェックして、彼らが開発者が必要に応じて修正することができる彼ら自身の行動とフィルタを登録したと気づくので。しかし、私の問題は、他の人が機能をオーバーライドして独自の機能を追加する柔軟性を持つプラグインを作成する方法を完全に理解できないことです。
明確な答えを出すのは難しいことはわかっていますが、正しい方向に進むためには、ある種のスタートアップガイドが必要です。自分のアクションとフィルタを登録する必要がありますか?もしそうならどうですか?そうでなければ、私の選択肢は何ですか?
あなたのアドバイスは私に大いに役立ちます...ありがとう
プラグインまたはテーマで提供するAPIは、その特定のコードのロジックによって異なります。すべての状況に当てはまるガイドはおそらくないでしょう。
私は、APIを使った複数のプラグインの寄稿者です。これまでに学んだことは次のとおりです。
人々があなたのコードをどのように使用しているかが本当にわかるまで、APIを提供しないでください。
APIなしで最初の2つまたは3つのバージョンをリリースします。可能であれば、カスタムのアクションやフィルタ、パブリックなメソッドや関数(そしてグローバル変数)はありません。ユーザーからの要求を待ちますが、内部コード構造が長期的に機能するようになるまでコードを追加しないでください。
APIの後方互換性を維持するのは困難です 。それは他の場所で必要な改善を妨げるかもしれません。 WordPressが今日削除できないすべてのグローバル変数について考えてください。それは悪いAPIです、そして私達は何年もの間それを使い続けています、なぜなら人々 すでにそれを使っています 。
APIを他のコードから分離することを検討してください(アイデアについては前のリンクを参照してください)。
あなたのAPIはサードパーティの開発者だけでなくあなたにとっても役に立つはずです。あなたがする必要がない場合は、自分自身に制限を追加しないでください。
あなた自身のドッグフードを食べなさい。
カスタムフックを提供する場合は、それをコード内で使用してください。これは他の開発者に有用な例を与えるでしょう、そしてあなたは十分に早く潜在的な欠陥を見ることができます。
WordPressコアが内部でいわゆる 設定API を使用するのであれば、今日はこの混乱はありません。多分。
例によって導く。
あなたのプラグインでWordPressコアAPIの良い部分を使ってください。 匿名オブジェクト 、定数、グローバル変数、および 予測できないコード は避けてください。
一貫性のある命名規則( このような混乱 )を使用していないことを確認し、すべてを自分の名前空間の下に置いてください。
最初にドキュメントを書きます。後で新しい(の一部)APIをリリースしてください。
すべてに役立つ例を作りましょう。あなたはあなたが見つけることができる穴と冗長性の数を見ることに驚かれるでしょう。
コールバック地獄を避けてください。
問題を解決できない場合にAPIをデバッグするための特定のツールを提供します(縮小されていないスクリプトやスタイルシートを含む)。 debug AJAX の使い方の例を書きました。繰り返しますが、これらのツールは、リリースする前にあなたのドキュメントで説明されるべきです。
WordPressのコールバックパラダイムの代わりに Observer pattern を使うこともできます。これはサードパーティの開発者にとっての障壁を高めるでしょうが、それは両側でより良いコードをもたらす可能性があります。