プラグイン開発の客観的なベストプラクティスを収集するためのコミュニティWikiの開始。この質問は、wp-hackersに関する@EAMannのコメントに触発されました。

アイデアは、最終的に何らかのコミュニティコラボレーションレビュープロセスでそれらを使用できるように、客観的なベストプラクティスがどのようなものになるかについてコラボレーションすることです。

更新：最初の数件の回答を見た後、回答ごとにアイデア/提案/ベストプラクティスが1つだけ必要であることが明らかになり、投稿する前に重複がないことを確認するためにリストを確認する必要があります。

アクションとフィルターを使用する

人々がデータを追加または変更したいと思う場合：を返す前にapply_filters（）を提供します。

PS少し残念なことに、あなたの質問の答えは、エンドユーザー専用に設計されたプラグインの割合です。つまり、独自のフックはありません。WordPressがほとんどのプラグインのように設計されていると想像してみてください？それは柔軟性に欠け、非常にニッチなソリューションです。

WordPressが他のプラグインが依存しているプラ​​グインを自動インストールする機能を持つ場合、状況は異なるでしょうか？クライアントは特定の方法と利用可能なプラグインを必要とするため、通常はゼロから必要な多くの機能を作成する必要がありますが、残りの10％は、90％で更新する柔軟性を許可しません。

StackPressサイトで良い答えが得られるように、WordPressコミュニティのリーダーたちが、ベストプラクティス（他の開発者へのフックの追加など）に従うことでプラグインが得られることを保証する方法を特定してほしいです。

別の質問から例を見てみましょう：

例：誰かが記事をリツイートしたときにプラグインで何かをしたい。人気のあるリツイートプラグインにフックを付けて起動できるカスタムフックがあれば、それは素晴らしいことです。存在しないので、プラグインを変更して含めることができますが、それは私のコピーでのみ機能し、再配布を試みたくありません。

関連する

• 拡張可能なフォームを提供する

ロード・スクリプト/ CSS wp_enqueue_scriptとwp_enqueue_style

プラグインは、JS / CSSファイル、特にWPコアに含まれるjQueryおよびその他のJSファイルの重複バージョンをロード/ロードしようとしてはなりません。

プラグインは常にJSとCSSファイルをリンクするときに使用しwp_enqueue_script、タグwp_enqueue_styleを介して直接使用することはありません<script>。

関連する

• 既存の機能を再利用する

国際化のサポート

開発者が独自のプラグインの翻訳に関心がない場合でも、すべての出力文字列を適切なテキストドメインにリンクして、関係者による国際化を可能にする必要があります。

initユーザーがアクションにフックできるように、アクション中に言語ファイルをロードすることが非常に重要であることに注意してください。

Codex：WordPress開発者向けI18nをご覧ください

また、この記事：WP言語ファイルを正しく読み込みます。

WordPress 4.6以降

WP 4.6では、ロード順序とチェックされる場所が変更され、開発者とユーザーにとって非常に簡単になりました。

テキストドメイン「my-plugin」を持つプラグインを検討すると、WordPressはまず/wp-content/languages/plugins/my-plugin-en_US.moで翻訳ファイルを探します。

見つからない場合は、プラグインが表示するように指示しているものを探します（コーデックスの場合は通常、pluignsの「language」フォルダーにあります）：
/ wp-content / plugins / my-plugin / languages / my- plugin-en_US.mo

最後に、言語ファイルが見つからない場合、次のデフォルトの場所を確認します：
/wp-content/languages/my-plugin-en_US.mo

最初のチェックは4.6で追加され、ユーザーに彼らは、開発者が言語ファイルを追加した場所を知る必要があります以前のように、言語ファイルを追加するために定義された場所を与えた、今、ユーザーがちょうどプラグインのTEXTDOMAINを知っている必要があります： / WP-コンテンツ/ languages / plugins / TEXTDOMAIN-LOCAL.mo

以下は古い方法です（WP 4.6以降では関係ありません）

[...]
最後に、プラグインに同梱されている言語ファイルをロードする前に、WP_LANG_DIRからカスタムユーザー言語ファイルをロードすることが重要であることを指摘したいと思います。同じドメインに複数のmoファイルが読み込まれると、最初に見つかった翻訳が使用されます。このようにして、プラグインによって提供される言語ファイルは、ユーザーが翻訳していない文字列のフォールバックとして機能します。

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain( 
            $domain, 
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo' 
    );
    load_plugin_textdomain( 
            $domain, 
            FALSE, 
            dirname( plugin_basename(__FILE__) ) . '/languages/' 
    );
}

WP_DEBUGでプラグインがエラーを生成しないことを確認する

プラグインは常にWP_DEBUG有効にしてテストし、理想的には開発プロセス全体で有効にします。プラグインはWP_DEBUGonでエラーをスローしてはなりません。これには、非推奨の通知と未チェックのインデックスが含まれます。

デバッグをオンにするにはwp-config.php、WP_DEBUG定数がに設定されるようにファイルを編集しますtrue。詳細については、デバッグに関するコーデックスを参照してください。

WordPress Coreの既存の関数を最初に使用する

可能な場合：独自に作成する代わりに、WordPressコアに含まれる既存の関数を使用します。WordPressコアに適切な既存の関数がない場合にのみ、カスタムPHP関数を開発してください。

1つの利点は、「非推奨のログ」を使用して、交換する必要がある機能を簡単に監視できることです。もう1つの利点は、ユーザーがCodexの関数ドキュメントを表示し、経験豊富なPHP開発者でなくてもプラグインの機能をよりよく理解できることです。

関連する

• 国際化のサポート
• wp_enqueue_scriptおよびwp_enqueue_styleでScripts / CSSをロードする
• 拡張可能なフォームを提供する

アンインストールすると、プラグインのデータがすべて削除されます

プラグインは、WordPressインストールから削除されると、作成したすべてのファイル、フォルダー、データベースエントリ、およびテーブルと、作成したオプション値を削除する必要があります。

プラグインは設定をエクスポート/インポートするオプションを提供するため、削除する前に設定をWordPressの外部に保存できます。

関連する

• 非アクティブ化によりデータ損失が発生することはありません

入力データによるSQLインジェクションの防止

プラグインがなければならない （例えば介して直接的または間接的に取得されたすべてのユーザー入力サニタイズ$_POSTまたは$_GET MySQLデータベースを照会するために、入力値を使用する前に）を。

参照：SQLステートメントのフォーマット。

すべてのグローバルネームスペースアイテムのプレフィックス

プラグインは、すべてのグローバル名前空間項目（定数、関数、クラス、変数、カスタム分類法、投稿タイプ、ウィジェットなど）に適切にプレフィックスを付ける必要があります。たとえば、という関数を作成しないでくださいinit()。代わりに、のような名前を付けてくださいjpb_init()。

一般的には、名前の前に3文字または4文字のプレフィックスを使用するか、PHP Namespace Featureを使用する必要があります。比較：PHPクラス定数の1文字のプレフィックス？

関連する

• グローバル名前空間は限られたリソースです

クラスとオブジェクト指向のPHP5コードを使用する

クリーンでオブジェクト指向のPHP5コードを記述しない理由はありません。PHP4のサポートは、次のリリース（WP 3.1）後に廃止されます。もちろん、すべての関数名の前にendlessly_long_function_names_with_lots_of_underscoresを付けることもできますが、単純なクラスを記述してその中にすべてをバンドルする方がはるかに簡単です。また、クラスを別のファイルに入れ、それに応じて名前を付けて、簡単に拡張および保守できるようにします。

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP 
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions 
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

非アクティブ化によりデータ損失が発生することはありません

プラグインは 、非アクティブ化時にそのデータを削除しないでください。

関連する

• アンインストールすると、すべてのプラグインのデータが削除されます

必要なファイルのみを含める...

フロントエンドにいる場合は、管理領域に関連するコードを含めないでください。

プラグインのアンインストール時のデータ損失を発表

アンインストール時にはプラグインが必要があり 、データだ削除されることをユーザーに促し、ユーザーがそうする前にデータを削除して大丈夫ですとプラグインが確認受け取るべきでもユーザーデータを保持するオプションができ、アンインストール時に。（@EAMannからのこのアイデア。）

関連する

• アンインストールすると、すべてのプラグインのデータが削除されます
• 非アクティブ化はデータ損失を引き起こすべきではありません

プラグインのフォルダー名を変更してみましょう

/ plugins / pluginname / {various}

フォルダに使用される「プラグイン名」は常に変更可能である必要があります。

これは通常、定数を定義し、プラグイン全体で一貫して使用することで処理されます。

言うまでもなく、多くの人気プラグインは罪人です。

関連する：

• plugins_url() プラグインに含まれるリソースへの簡単なリンク。

WordPressを使用（組み込み）エラー処理

return;何らかのユーザー入力が間違っていただけではいけません。彼らにいくつかの情報を提供することは間違っていました。

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

すべてに対して1つのエラー（オブジェクト）

ブートストラップ中にテーマまたはプラグインのグローバルエラーオブジェクトを設定できます。

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

後で、オンデマンドで無制限のエラーを追加できます。

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

その後、テーマの最後でそれらすべてを取得できます。このようにして、ページのレンダリングを中断せずに、開発用のすべてのエラーを出力できます

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

詳細については、このQを参照してください。関連のチケットはの「共同作業」修正するWP_Errorとwp_die()、そこからリンクされていると、別のチケットが続きます。コメント、批評家などに感謝します。

グローバル名前空間に追加される名前を最小限に抑える

プラグインは 、グローバル名前空間に追加する名前の数を最小限に抑えることで、影響を可能な限り減らす必要があります。

これは、プラグインの関数をクラスにカプセル化するか、PHP名前空間機能を使用して実行できます。すべてに接頭辞を付けることも役立ちますが、それほど柔軟ではありません。

関数とクラスの次に、プラグインはグローバル変数を導入しないでください。通常、クラスを使用するとクラスが廃止され、プラグインのメンテナンスが簡単になります。

関連する

• 正しくプレフィックス

PhpDocを使用してコメントする

ベストプラクティスはPhpDocスタイルに近いものです。「Eclipse」のようなIDEを使用しない場合は、PhpDocマニュアルをご覧ください。

これがどのように機能するかを正確に知る必要はありません。とにかくプロの開発者はコードを読むことができ、これを要約として必要とします。趣味のコーダーとユーザーは、同じ知識レベルで説明する方法を高く評価するかもしれません。

add_optionの前に設定APIを使用します

add_option関数を介してDBにオプションを追加する代わりに、すべてを処理するSettings APIを使用して、オプションを配列として保存する必要があります。

add_optionの前にテーマ変更APIを使用します

変更APIは非常にシンプル構造とオプションを追加して検索することができます安全な方法です。すべてがデータベースにシリアル化された値として保存されます。簡単、安全、シンプル。

プラグインユーザーのプライバシーを保護する

（以前：匿名API通信）

プラグインが外部システムまたはAPI（Webサービスなど）と通信する場合、匿名で行うか、プラグインのユーザーに関連するデータが制御されていない第三者に漏洩しないようにする匿名オプションをユーザーに提供する必要があります。

WordPress.orgのホストプラグイン

プラグインをホストするには、WordPress.orgで提供されているSVNリポジトリを使用します。これにより、ユーザーエクスペリエンスの更新が容易になり、SVNを使用したことがない場合は、それを正当化するコンテキストで使用することで、実際に理解することができます。

アクセス許可を使用してアクセス制御を提供する

多くの場合、ユーザーは、特に複数の複雑な操作を行うプラグインを使用して、プラグインによって作成された領域に誰もがアクセスすることを望まない場合があります。

少なくとも、プラグインを使用できるさまざまな種類の手順すべてに対して適切な機能チェックを行ってください。

プラグイン設定のインポート/エクスポート

これは、プラグインの間で、共通ではありませんが、あなたのプラグインが（一部）の設定を持っている場合、それがなければならない 設定とユーザーの入力などのデータのインポート/エクスポートを提供します。

インポート/エクスポートにより、プラグインの使いやすさが向上します。

このようなインポートおよびエクスポート機能（および元に戻すメカニズム）を備えたサンプルプラグインは、Breadcrumb NavXT（Wordpressプラグイン）です（完全な公開：そこに私が書いた小さなコードがあり、ほとんどはmtekkによって行われています）。

関連する

• アンインストールすると、すべてのプラグインのデータが削除されます
• 非アクティブ化によりデータ損失が発生することはありません

コードを整理する

実行される順序で書かれていないコードを読むことは常に困難です。最初にinclude / require、define、wp_enqueue_style＆_scriptなど、次にプラグイン/テーマに必要な機能、最後にビルダー（管理画面、テーマに統合するものなど）。

cssやjsのようなものを独自のフォルダーに分けてみてください。また、配列フラットナーなどのヘルパーのみの関数を使用してこれを実行してください。「メイン」ファイルをできる限りクリーンで読みやすいものに保つことは、1年で更新を試みてコードを長期間見なかった場合に、ユーザー、開発者、およびユーザーを支援する方法です。

頻繁に繰り返す構造にすることも良いので、常に通り抜けることができます。さまざまなプロジェクトで既知の構造で開発することで、時間をかけて改善できるようになり、クライアントが別の開発者に切り替えても、「彼は混乱を残した」とは決して聞きません。これはあなたの評判を構築し、長期的な目標でなければなりません。

スタイルで死ぬ

適切な方法で死ぬ すべてのプラグイン（およびテーマ）機能はwp_die()、重要な場所で使用して、何が起こったのかをユーザーに少し情報を提供する必要があります。PHPエラーは迷惑でありwp_die、プラグイン（またはそれら）が何を間違えたかについて、素敵なスタイルのメッセージをユーザーに与えることができます。さらに、ユーザーがデバッグを無効にしている場合、プラグインは破損します。

を使用wp_die()すると、プラグイン/テーマがワードプレスのテストスイートと互換性があることにも役立ちます。

• WPエラー処理を使用する

ユーザーにヘルプ画面を提供する

質問に何度も答えるよりも、RTFM（ヘルプをクリック）を答えとして言う方がいいです。

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

更新/注：（kaiserのコメントを参照）：上記の例はクラスで使用されます

拡張可能なフォームを提供する

プラグインが入力データの可能性を提供する場合、開発者はフィールドだけでなくボタンでもフォームを簡単に拡張できるように、「送信」および/または「リセット」ボタンの直前に常に最後にフックが必要です。

参照：設定API

関連する

• アクションとフィルターを使用する
• 既存の機能を再利用する
• 国際化のサポート

直接ではなく、常にフックを介して関数を含めます。

例：

• フックなしの新しい経由でプラグインのクラスを含めるために使用しないでください

• フックplugins_loadedを使用します

  // add the class to WP                                   
  function my_plugin_start() {                                                               
      new my_plugin();   
  }                                                        
  add_action( 'plugins_loaded', 'my_plugin_start' );

更新： 小規模なライブ例：Plugin-svn-trunk-page および擬似例

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

また、アクションの参照のためのコーデックスを参照、インストールマルチサイト上mu_plugins_loaded経由で読み込むことができます：http://codex.wordpress.org/Plugin_API/Action_Referenceを ：ここでまた、このフックでWPをinlcudeどのように、あなたが見ています。http：// adambrown。 info / p / wp_hooks / hook / plugins_loaded？version = 2.1＆file = wp-settings.php 私はこれを非常に頻繁に使用しますが、それほど難しくなく早く、ハードな新しいclass（）として優れています。

GPL互換ライセンスのライセンスプラグイン

プラグインとテーマは、WordPress互換ライセンスの下でライセンスされる必要があります。これにより、WordPressを「プログラム」として再配布できます。推奨されるライセンスはGPLです。プラグインに含まれるすべてのコードライブラリが同じライセンスと互換性があることに注意してください。

（これは過去と現在の両方で問題と深刻な議論のポイントでした。）

プラグインの説明には、プラグインの機能を正確に詳述する必要があります。注目の投稿プラグインは10個あります。それらはすべて注目の投稿を表示しますが、多くは異なる機能を持っています。説明を読むことで、プラグインを類似のプラグインと簡単に比較できるはずです。

プラグインが非常に基本的でない限り、プラグインがどれほどシンプルであるかを自慢することは避けてください。設定へのリンクなどの説明に役立つリンクを含める必要があります。

リモートデータソースとWebサービスの副作用を最小限に抑える

プラグインは 、（遅い）Webサービス応答を待機するフロントリクエストを行わないように、Webサービスおよび/またはXMLRPC / SOAP要求をキャッシュ/データプロバイダーレイヤーを使用してキャッシュ/シールドする必要があります。

これには、RSSフィードや他のページのダウンロードが含まれます。バックグラウンドでデータを要求するプラグインを設計します。

可能なステップの1つは（例としてping.fmに投稿する）：バッファーテーブルを作成します。たとえば、ping_fm_buffer_post（date、time、message、submit_time、status）

1. ping.fmに更新を送信するたびに、このテーブルに追加します。
2. 次に、このデータを処理するプラグインを作成する必要があります。このプラグインはcrontabを介して実行され、まだ送信されていないすべての更新を確認します
3. このテーブルがあるため、ping.fmに送信されたすべてのメッセージをリストし、各投稿のステータスを確認することもできます。ping.fm側に問題がある場合に備えて、再送信できます。

プラグインをテストする

プラグイン開発環境にいくつかのテストツールを確実に用意する必要があります。

基づいて、この答えによって、イーサン・ザイフェルトのテストの質問に、これらは従うのは良いプラクティスは、次のとおりです。

• ユニットテストでは、クラスが実行できる最小の動作をテストする必要があります。
• 機能テストのレベルに達すると、Wordpressの依存関係を使用してコードをテストできます。
• プラグインの機能に応じて、IDを使用してDOM内のデータの存在をテストするSeleniumベースのテストの使用を検討してください