Как структурировать плагин

Это не вопрос о том, как создать плагин WordPress. Скорее, какие, если таковые имеются, руководства могут быть применены к тому, как собрать файловую архитектуру любого плагина.

Некоторые другие языки программирования или библиотеки имеют очень контролируемые способы организации каталогов и файлов. Иногда это раздражает и подчеркивает свободу, которую предлагает PHP, но с другой стороны плагины WordPress собираются любым способом, который определяется их автором.

Правильного ответа нет , но я надеюсь уточнить, как я и другие строим плагины, чтобы сделать их более дружественными для других разработчиков, удобнее в отладке, более удобными для навигации и, возможно, более эффективными.

Последний вопрос: как вы думаете, как лучше организовать плагин?

Ниже приведены несколько примеров структур, но ни в коем случае не исчерпывающий список. Не стесняйтесь добавлять свои собственные рекомендации.

Предполагаемая структура по умолчанию

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

Метод Model View Controller (MVC)

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

MVC три части:

• В модели взаимодействует с базой данных, запросов и сохранения данных, а также содержит логику.
• Контроллер будет содержать шаблонные теги и функции, вид будет использовать.
• Вид отвечает , чтобы отобразить данные , предоставленные моделью , как строится с помощью контроллера.

Организовано по типу метода

• /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 плагин Boilerplate

Доступно на 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.

Вот один из способов сделать это легко - сначала определите функцию, которая загружает шаблон:

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, а WP MVC разработан, чтобы сделать написание плагинов 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

Наши суб-плагины имеют одинаковую структуру с одним исключением. Мы углубляемся в папку vendor из-за разрешения конфликтов имен во время события автозагрузки. Мы также называем класс плагина boostrap 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в следующем выпуске.

Как многие здесь уже ответили, это действительно зависит от того, что плагин должен делать, но вот моя базовая структура:

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 

Мне еще предстоит создать плагин для WordPress, требующий архитектуры в стиле MVC, но если бы я это сделал, я бы выложил его с отдельным каталогом MVC, который сам содержит views / controllers / models.

Моя логика: чем больше плагин, тем больше структуры я использую.
Для больших плагинов я склонен использовать 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 обычно является классом, который загружает все необходимые файлы из ядра / папки. Чаще всего на крючке init или plugins_loaded.

Я также использовал префикс всех своих файлов, но, как заметил @kaiser выше, он действительно избыточен, и недавно я решил удалить его из любых будущих плагинов.

Библиотека / папка содержит все внешние вспомогательные библиотеки, от которых может зависеть плагин.

В зависимости от плагина, в корне плагина также может быть файл 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/.