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

Это не вопрос о том, как создать плагин 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 состоит из трех частей:

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

Организованный по типу способ

  • /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
        • css/
        • images/
        • js/
        • my-admin.php
        • my-class.php
        • my-template.php
        • my-widget.php
        • my-plugin.php
Author: developdaly, 2012-04-08
Source

10 answers

Обратите внимание, что все плагины являются "контроллерами" по стандартам 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, изображения или то, как вы проектируете контейнер для крючков, менее важны. Я думаю, это вопрос личных предпочтений.

 18
Author: onetrickpony, 2012-04-09 13:21:26

Это зависит от плагина. Это моя базовая структура почти для каждого плагина:

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
 7
Author: chrisguitarguy, 2012-04-09 05:13:15

IMHO, самый простой, самый мощный и наиболее удобный в обслуживании маршрут - использовать структуру MVC, а WP MVC разработан для того, чтобы очень легко писать плагины MVC (я немного предвзят, хотя...). С WP MVC вы просто создаете модели, представления и контроллеры, а все остальное обрабатывается за кулисами для вас.

Отдельные контроллеры и представления могут быть созданы для общедоступных и административных разделов, и вся платформа использует преимущества многих встроенных функций WordPress. То структура файлов и большая часть функций точно такие же, как и в самых популярных фреймворках MVC (Rails, CakePHP и т.д.).

Более подробную информацию и учебник можно найти здесь:

 6
Author: Tom, 2012-04-14 14:29:44

Мы используем сочетание всех методов. Прежде всего, мы используем 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

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

 5
Author: Roman, 2012-04-13 08:51:01

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

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
Author: Bainternet, 2012-04-13 16:43:40

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

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, который сам содержит представления/контроллеры/модели.

 4
Author: mystline, 2012-04-13 06:02:48

По моей логике, чем больше плагин, тем больше структуры я использую.
Для больших плагинов я обычно использую 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
Author: janw, 2012-04-18 12:20:46

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

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().

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

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

 3
Author: shabushabu, 2012-04-13 10:28:34

Также смотрите этот замечательный шаблон виджета WP. Это дает отличные подсказки относительно структур (даже если для отдельных моделей нет ни класса, ни папки).

 1
Author: Cedric, 2013-06-17 08:42:52

Менее распространенным подходом к структурированию файлов и каталогов плагина является подход типа файла. Для полноты картины стоит упомянуть здесь:

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
Author: henrywright, 2015-11-07 23:40:00