プラグインを構成する方法

これは、WordPressプラグインの作成方法に関する質問ではありません。むしろ、もしあれば、プラグインのファイルアーキテクチャをまとめる方法に適用できるガイドがあります。

他のいくつかのプログラミング言語またはライブラリには、ディレクトリとファイルを整理する非常に制御された方法があります。これは迷惑で、PHPが提供する自由を際立たせることもありますが、一方で、WordPressプラグインは作成者が決めたように、あらゆる方法でまとめられます。

正しい答えはありませんが、私と他の人がプラグインをどのように構築して他の開発者がより使いやすく、デバッグしやすく、ナビゲートしやすく、おそらくより効率的にするかを改善することを望んでいます。

最後の質問：プラグインを整理する最良の方法は何だと思いますか？

以下にいくつかのサンプル構造を示しますが、決して完全なリストではありません。独自の推奨事項を自由に追加してください。

想定されるデフォルト構造

• /wp-content
  • /plugins
    • /my-plugin
      • my-plugin.php

モデルビューコントローラー（MVC）メソッド

• /wp-content
  • /plugins
    • /my-plugin
      • /controller
        • Controller.php
      • /model
        • Model.php
      • /view
        • view.php
      • my-plugin.php

MVCの3つの部分：

• モデルのデータベースとの相互作用、データを照会し、保存、およびロジックが含まれています。
• コントローラは、ビューが利用するであろうことを、テンプレートタグや機能が含まれています。
• ビューは、コントローラによって構成されたモデルによって提供されるデータを表示するために責任があります。

タイプメソッド別に整理

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • admin.php
      • /assets
        • css/
        • images/
      • /classes
        • my-class.php
      • /lang
        • my-es_ES.mo
      • /templates
        • my-template.php
      • /widgets
        • my-widget.php
      • my-plugin.php

WordPressプラグインボイラープレート

Githubで利用可能

プラグインAPI、コーディング標準、およびドキュメント標準に基づいています。

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • /css
        • /js
        • /partials
        • my-plugin-admin.php
      • /includes
        • my_plugin_activator.php
        • my_plugin_deactivator.php
        • my_plugin_i18n.php
        • my_plugin_loader.php
        • my_plugin.php
      • /languages
        • my_plugin.pot
      • /public
        • /css
        • /js
        • /partials
        • my-plugin-public.php
      • LICENSE.txt
      • README.txt
      • index.php
      • my-plugin.php
      • uninstall.php

緩やかに組織化された方法

• /wp-content
  • /plugins
    • /my-plugin
      • css/
      • images/
      • js/
      • my-admin.php
      • my-class.php
      • my-template.php
      • my-widget.php
      • my-plugin.php

プラグインはすべてWP標準の「コントローラー」であることに注意してください。

プラグインが何をするかによって異なりますが、すべての場合において、可能な限りPHPコードから画面出力を分離しようとします。

これを簡単に行う1つの方法を次に示します。まず、テンプレートをロードする関数を定義します。

function my_plugin_load_template(array $_vars){

  // you cannot let locate_template to load your template
  // because WP devs made sure you can't pass
  // variables to your template :(
  $_template = locate_template('my_plugin', false, false);

  // use the default one if the theme doesn't have it
  if(!_$template)
    $_template = 'views/template.php';

  // load it
  extract($_vars);        
  require $template;
}

プラグインがウィジェットを使用してデータを表示する場合：

class Your_Widget extends WP_Widget{

  ...      
  public function widget($args, $instance){

    $title = apply_filters('widget_title', $instance['title'], $instance, $this->id_base);

    // this widget shows the last 5 "movies"
    $posts = new WP_Query(array('posts_per_page' => 5, 'post_type' => 'movie')); 

    if($title)
      print $before_title . $title . $after_title;

    // here we rely on the template to display the data on the screen
    my_plugin_load_template(array(

      // variables you wish to expose in the template
     'posts'    => $posts,          
    ));

    print $before_widget;
  }
  ...

}

テンプレート：

<?php while($posts->have_posts()): $posts->the_post(); ?>

<p><?php the_title(); ?></p> 

<?php endwhile; ?>

ファイル：

/plugins/my_plugin/plugin.php           <-- just hooks 
/plugins/my_plugin/widget.php           <-- widget class, if you have a widget
/themes/twentyten/my_plugin.php         <-- template
/plugins/my_plugin/views/template.php   <-- fallback template

CSS、JS、画像をどこに配置するか、フックのコンテナをどのように設計するかはそれほど重要ではありません。個人的な好みの問題だと思います。

プラグインに依存します。これは、ほぼすべてのプラグインの基本的な構造です。

my-plugin/
    inc/
        Any additional plugin-specific PHP files go here
    lib/
        Library classes, css, js, and other files that I use with many
        plugins go here
    css/
    js/
    images/
    lang/
        Translation files
    my-plugin.php
    readme.txt

これは、libフォルダーに入れられるものです。

それが特に複雑なプラグインであり、多くの管理領域機能を備えている場合、adminこれらすべてのPHPファイルを含むフォルダーを追加します。プラグインが含まれているテーマファイルを置き換えるような何かをする場合、templateまたはthemeフォルダもあるかもしれません。

したがって、ディレクトリ構造は次のようになります。

my-plugin/
    inc/
    lib/
    admin/
    templates/
    css/
    js/
    images/
    lang/
    my-plugin.php
    readme.txt

私見、最も簡単で、最も強力で、最もメンテナンスしやすいルートは、MVC構造を使用することです。WPMVCは、MVCプラグインを非常に簡単に作成できるように設計されています（少し偏っていますが...）。WP MVCを使用すると、モデル、ビュー、およびコントローラーを作成するだけで、他のすべては舞台裏で処理されます。

パブリックセクションと管理セクション用に別々のコントローラーとビューを作成でき、フレームワーク全体がWordPressのネイティブ機能の多くを利用します。ファイル構造と機能の多くは、最も一般的なMVCフレームワーク（Rails、CakePHPなど）とまったく同じです。

詳細情報とチュートリアルはここにあります：

• プラグインページ
• チュートリアル

すべての方法を組み合わせて使用​​しています。まず、プラグインでZend Framework 1.11を使用しているため、オートロードメカニズムのために、クラスファイルに同様の構造を使用する必要がありました。

すべてのプラグインがベースとして使用するコアプラグインの構造は次のようになります。

webeo-core/
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Core.php
        Zend/
            /** ZF files **/
        Loader.php
    views/
    readme.txt
    uninstall.php
    webeo-core.php

1. WordPressはwebeo-core.phpプラグインルートフォルダー内のファイルを呼び出します。
2. このファイルでは、PHPのインクルードパスを設定し、プラグインのアクティブ化フックと非アクティブ化フックを登録します。
3. またWebeo_CoreLoader、いくつかのプラグイン定数を設定し、クラスオートローダーを初期化しCore.php、lib/Webeoフォルダー内のクラスのセットアップメソッドを呼び出すクラスがこのファイル内にあります。これは、plugins_loadedアクションフックで優先度が指定されて実行され9ます。
4. Core.phpこのクラスは、私たちのプラグインのブートストラップファイルです。名前はプラグイン名に基づいています。

ご覧のとおり、libフォルダー内にすべてのベンダーパッケージ（Webeo、Zend）のサブディレクトリがあります。ベンダー内のすべてのサブパッケージは、モジュール自体の構造です。新しいMail Settings管理フォームの場合、次の構造になります。

webeo-core/
    ...
    lib/
        Webeo/
            Form/
                Admin/
                    MailSettings.php
                Admin.php
            Core.php
            Form.php

サブプラグインは、1つの例外を除いて同じ構造を持っています。自動ロードイベント中の名前の競合を解決するため、ベンダーフォルダー内のレベルをさらに深くします。また、フック内E.g. Faq.phpで優先的にプラグインboostrapクラスを呼び出します。10plugins_loaded

webeo-faq/ (uses/extends webeo-core)
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Faq/
                Faq.php
                /** all plugin relevant class files **/
    views/
    readme.txt
    uninstall.php
    webeo-faq.php

おそらくlibフォルダーの名前を変更し、vendorsすべてのパブリックフォルダー（css、images、js、languages）をpublic次のリリースで指定されたフォルダーに移動します。

多くの人がすでに答えているように、それは本当にプラグインが何をすべきかによって異なりますが、ここに私の基本構造があります：

my-plugin/
    admin/
        holds all back-end administrative files
        js/
            holds all back-end JavaScript files
        css/                    
            holds all back-end CSS files
        images/
            holds all back-end images
        admin_file_1.php        back-end functionality file
        admin_file_2.php        another back-end functionality file 
    js/
        holds all front end JavaScript files
    css/
        holds all fronted CSS files
    inc/
        holds all helper classes
    lang/                   
        holds all translation files
    images/
        holds all fronted images
    my-plugin.php               main plugin file with plugin meta, mostly includes,action and filter hooks
    readme.txt                  
    changelog.txt
    license.txt

私は次のプラグインレイアウトに部分的に取り組んでいますが、通常はプラグインの要件に応じて変化します。

wp-content/
    plugins/
        my-plugin/
            inc/
                Specific files for only this plugin
                admin/ 
                    Files for dealing with administrative tasks
            lib/
                Library/helper classes go here
            css/
                CSS files for the plugin
            js/
                JS files
            images/
                Images for my plugin
            lang/
                Translation files
        plugin.php 
            This is the main file that calls/includes other files 
        README 
            I normally put the license details in here in addition to helpful information 

MVCスタイルのアーキテクチャを必要とするWordPressプラグインをまだ作成していませんが、これを行う場合は、ビュー/コントローラー/モデルを含む別のMVCディレクトリでレイアウトします。

私のロジックは、プラグインが大きいほど、使用する構造が増えます。
大きなプラグインの場合、MVCを使用する傾向があります。
これを出発点として使用し、不要なものはスキップします。

controller/
    frontend.php
    wp-admin.php
    widget1.php
    widget2.php
model/
    standard-wp-tables.php // if needed split it up
    custom-tabel1.php
    custom-tabel2.php
view/
    helper.php
    frontend/
        files...php
    wp-admin/
        files...php
    widget1/
        file...php
    widget2/
        file...php
css/
js/
image/
library/  //php only, mostly for Zend Framework, again if needed
constants.php //tend to use it often
plugin.php //init file
install-unistall.php  //only on big plugins

すべてのプラグインはこの構造に従います。これは、他のほとんどの開発者が行っていることと非常に似ているようです。

plugin-folder/
    admin/
        css/
            images/
        js/
    core/
    css/
        images/
    js/
    languages/
    library/
    templates/
    plugin-folder.php
    readme.txt
    changelog.txt
    license.txt

plugin-folder.phpは通常、必要なすべてのファイルをcore /フォルダーからロードするクラスです。ほとんどの場合、initまたはplugins_loadedフックで。

以前はすべてのファイルにもプレフィックスを付けていましたが、上記の@kaiserで述べたように、これは本当に冗長であり、最近、将来のプラグインから削除することにしました。

library /フォルダーには、プラグインが依存する可能性のあるすべての外部ヘルパーライブラリーが含まれます。

プラグインによっては、プラグインルートにもuninstall.phpファイルが存在する場合があります。ただし、ほとんどの場合、これはregister_uninstall_hook（）で処理されます。

明らかに、いくつかのプラグインは管理ファイルやテンプレートなどを必要としないかもしれませんが、上記の構造は私のために機能します。最終的には、自分に合った構造を見つけて、それを使い続けるだけです。

上記の構造に基づいて、すべてのプラグインの開始点として使用するスタータープラグインもあります。私がする必要があるのは、関数/クラスプレフィックスの検索/置換を実行するだけです。まだファイルのプレフィックスを付けていたので、追加の手順を実行しなければなりませんでした（そして、非常に面倒でした）が、今はプラグインフォルダーとメインプラグインファイルの名前を変更するだけです。

また、このすばらしいWPウィジェットの定型文もご覧ください。構造に関する素晴らしいヒントを提供します（個別のモデル用のクラスやフォルダーがない場合でも）。

プラグインのファイルとディレクトリを構造化するあまり一般的ではないアプローチは、ファイルタイプアプローチです。完全を期すためにここで言及する価値があります。

plugin-name/
    js/
        sparkle.js
        shake.js
    css/
        style.css
    scss/
        header.scss
        footer.scss
    php/
        class.php
        functions.php
    plugin-name.php
    uninstall.php
    readme.txt

各ディレクトリには、そのタイプのファイルのみが含まれます。たとえば.png .gif .jpg、単一のディレクトリの下でより論理的にファイルされる可能性のある多くのファイルタイプがある場合、このアプローチは不十分であることに注意してくださいimages/。