web-dev-qa-db-ja.com

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

これは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つの部分：

  • model はデータベースと対話し、データの照会と保存を行い、ロジックを含みます。
  • controller はビューが利用するテンプレートタグと関数を含みます。
  • view は、コントローラーによって構築されたモデルによって提供されたデータを表示します。

タイプメソッドで整理

  • /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
pluginsplugin-developmentcustomizationdirectorymvc
37
developdaly

プラグインは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、画像をどこに置きますか、またはどのようにしてフック用のコンテナを設計するかはそれほど重要ではありません。個人的な好みの問題だと思います。

16
onetrickpony

私見、最も簡単で、最も強力で、そして最も保守しやすい方法はMVC構造を使うことです、そしてWP MVCはMVCプラグインを書くことをとても簡単にするように設計されています。 。 WP MVCを使用すると、モデル、ビュー、およびコントローラーを作成するだけで済み、それ以外のものはすべて背後で処理されます。

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

詳しい情報とチュートリアルはここにあります。

6
Tom

プラグインによって異なります。これはほぼすべてのプラグインのための私の基本的な構造です：

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フォルダに置かれるものです。

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

そのため、ディレクトリ構造は次のようになります。

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

ここで多くの人がすでに答えたように、それは実際に 依存しています プラグインがするべきことに依存していますが、ここに私の基本構造があります：

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
5
Bainternet

私たちはすべての方法を組み合わせて使っています。まず第一に、私たちはプラグインで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クラスのsetupメソッドを呼び出します。これは、優先度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フックの内側の優先順位10でプラグインのブーストラップクラスplugins_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というフォルダーに移動する予定です。

5
rofflox

私の論理では、プラグインが大きければ大きいほど、私はもっと多くの構造を使用します。
大きなプラグインには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
4
janw

私は次のプラグインのレイアウトに偏っていますが、それは通常プラグインの要件が何であるかによって変わります。

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ディレクトリを使用してレイアウトします。

4
mystline

私のプラグインはすべてこの構造に従っています。他の開発者が行っていることと非常によく似ています。

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（）を介して処理されています。

明らかに、いくつかのプラグインは管理ファイルやテンプレートなどを必要としないかもしれませんが、上記の構造は私にとってはうまくいきます。最後に、あなたはただあなたのために働く構造を見つけてそれに固執する必要があります。

私はまた私がすべての私のプラグインのための出発点として使用する上記の構造に基づくスタータープラグインを持っています。私がする必要があるのはそれから関数/クラスの接頭辞のための検索/置換をすることと私が行くオフです。まだファイルに接頭辞を付けていたとき、それは私がしなければならなかった追加のステップでした（そしてそれをかなり面倒にしていました）が、今は単にプラグインフォルダとメインプラグインファイルの名前を変更する必要があります。

3
shabushabu

また、 このすばらしいWPウィジェット定型句を参照してください 。それは構造のように素晴らしいヒントを与えます（たとえ別のモデルのためのクラスやフォルダがなくても）。

1
Cedric

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

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/のファイルタイプが多数ある場合、このアプローチは不十分です。

0
henrywright