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

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

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

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

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

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

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

  • /шр-контент
    • /плагины
      • /мой-плагин
        • мой-plugin.php

Метод управления представлением модели (MVC)

  • /шр-контент
    • /плагины
      • /мой-плагин
        • /контроллер
          • Controller.php
        • /модель
          • Model.php
        • /вид
          • view.php
        • мой-plugin.php

Три части MVC:

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

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

  • /шр-контент
    • /плагины
      • /мой-плагин
        • /админ
          • admin.php
        • /активы
          • CSS /
          • изображения /
        • /классы
          • мой-class.php
        • /языки
          • my-es_ES.mo
        • /шаблоны
          • мой-template.php
        • /виджеты
          • мой-widget.php
        • мой-plugin.php

Свободно организованный метод

  • /шр-контент
    • /плагины
      • /мой-плагин
        • CSS /
        • изображения /
        • JS /
        • мой-admin.php
        • мой-class.php
        • мой-template.php
        • мой-widget.php
        • мой-plugin.php
34 голоса | спросил developdaly 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

10 ответов


15

Обратите внимание, что плагины - это все «контроллеры» по стандартам WP.

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

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

  my_plugin_load_template (массив $ _vars) {

  //вы не можете позволить locate_template загружать ваш шаблон
  //потому что разработчики WP удостоверились, что вы не можете пройти
  //переменные в ваш шаблон :(
  $ _template = locate_template ('my_plugin', false, false);

  //используем значение по умолчанию, если тема не имеет его
  если (! _ $ шаблон)
    $ _template = 'views /template.php';

  //загружаем его
  экстракт ($ _ вары);
  требуется $ template;
}
 

Теперь, если плагин использует виджет для отображения данных:

  Класс Your_Widget расширяет WP_Widget {

  ...
  виджет публичной функции ($ args, $ instance) {

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

    //этот виджет показывает последние 5 "фильмов"
    $ posts = new WP_Query (array ('posts_per_page' => 5, 'post_type' => 'movie'));

    если ($ название)
      print $ before_title. $ title. $ After_title;

    //здесь мы полагаемся на шаблон для отображения данных на экране
    my_plugin_load_template (массив (

      //переменные, которые вы хотите открыть в шаблоне
     'posts' => $ сообщений,
    ));

    print $ before_widget;
  }
  ...

}
 

Шаблон:

  & lt;? php while ($ posts-> have_posts ()): $ posts-> the_post (); ? & GT;

<php the_title (); ? & GT; & Lt; /р & GT;

& lt;? php endwhile; ? & GT;
 

Файлы:

  /plugins/my_plugin/plugin.php <- просто перехватывает
/plugins/my_plugin/widget.php <- класс виджета, если у вас есть виджет
/themes/twentyten/my_plugin.php <- шаблон
/plugins/my_plugin/views/template.php <- резервный шаблон
 

Где вы помещаете свои CSS, JS, изображения или как вы создаете контейнер для крючков, менее важно. Думаю, это вопрос личного предпочтения.

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
6

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

  мой-плагин /
    вкл /
        Любые дополнительные файлы PHP, связанные с плагинами,
    Библиотека /
        Библиотечные классы, css, js и другие файлы, которые я использую со многими
        плагины идут сюда
    CSS /
    JS /
    изображений/
    языки /
        Файлы переводов
    мой-plugin.php
    readme.txt
 

Это будет то, что будет в папке lib .

Если это особенно сложный плагин с множеством функциональных возможностей админ-области, я бы добавил папку admin , чтобы содержать все эти файлы PHP. Если плагин делает что-то вроде замены файлов тем , возможно, template или тема .

Итак, структура каталогов может выглядеть так:

  мой-плагин /
    вкл /
    Библиотека /
    админ /
    шаблоны /
    CSS /
    JS /
    изображений/
    языки /
    мой-plugin.php
    readme.txt
 
ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
6

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

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

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

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
5

Мы используем сочетание всех методов. Прежде всего, мы используем Zend Framework 1.11 в наших плагинах, поэтому нам пришлось использовать аналогичную структуру для файлов классов из-за механика автозагрузки.

Структура нашего основного плагина (который используется всеми нашими плагинами в качестве базы) выглядит примерно так:

  webeo-ядро /
    CSS /
    изображений/
    JS /
    языки /
    Библиотека /
        Webeo /
            core.php
        Zend /
            /** ZF-файлы ** /
        Loader.php
    Просмотры/
    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 admin, у нас будет следующая структура:

  webeo-ядро /
    ...
    Библиотека /
        Webeo /
            Форма /
                Администратор /
                    MailSettings.php
                admin.php
            core.php
            form.php
 

Наши суб-плагины имеют одну и ту же структуру с одним исключением. Мы выходим на уровень ниже внутри папки поставщика из-за конфликтов конфликтов имен во время события автозагрузки. Мы также вызываем плагин boostrap class например. Faq.php в приоритетном 10 внутри plugins_loaded .

  webeo-faq /(использует /расширяет webeo-core)
    CSS /
    изображений/
    JS /
    языки /
    Библиотека /
        Webeo /
            Вопросы-Ответы/
                faq.php
                /** все соответствующие файлы классов plugin ** /
    Просмотры/
    readme.txt
    uninstall.php
    webeo-faq.php
 

Я, вероятно, переименую папку lib в vendors и переместим все общие папки (css, images, js, languages) в папку с именем public code> в следующей версии.

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
5

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

  мой-плагин /
    админ /
        содержит все вспомогательные административные файлы
        JS /
            хранит все исходные файлы JavaScript
        CSS /
            содержит все внутренние файлы CSS
        изображений/
            содержит все обратные изображения
        Файл функциональных возможностей admin_file_1.php
        admin_file_2.php другой файл функциональных возможностей
    JS /
        содержит все файлы JavaScript переднего конца
    CSS /
        хранит все файлы CSS
    вкл /
        содержит все вспомогательные классы
    языки /
        содержит все файлы переводов
    изображений/
        хранит все образы
    my-plugin.php файл основного плагина с метафоном плагинов, в основном включает в себя действия и фильтры
    readme.txt
    changelog.txt
    license.txt
 
ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
4

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

  сор-содержание /
    плагины /
        мой-плагин /
            вкл /
                Конкретные файлы только для этого плагина
                админ /
                    Файлы для решения административных задач
            Библиотека /
                Библиотеки /вспомогательные классы идут здесь
            CSS /
                Файлы CSS для плагина
            JS /
                Файлы JS
            изображений/
                Изображения для моего плагина
            языки /
                Файлы переводов
        plugin.php
            Это основной файл, который вызывает /включает другие файлы
        ПРОЧТИ МЕНЯ
            Я обычно размещаю данные о лицензии здесь, кроме полезной информации
 

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

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
4

Моя логика, чем больше плагин, тем больше структура я использую.
Для больших плагинов я склонен использовать MVC.
Я использую это как отправную точку и пропускаю то, что не нужно.

  Контроллер /
    frontend.php
    сор-admin.php
    widget1.php
    widget2.php
модель/
    standard-wp-tables.php //если необходимо разделить его
    заказ tabel1.php
    заказ tabel2.php
Посмотреть/
    helper.php
    внешний интерфейс/
        файлы ... PHP
    сор-админ /
        файлы ... PHP
    WIDGET1 /
        файл ... PHP
    WIDGET2 /
        файл ... PHP
CSS /
JS /
образ/
library ///php only, в основном для Zend Framework, если необходимо
constants.php //часто используют его
Файл plugin.php //init
install-unistall.php //только для больших плагинов
 
ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
3

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

  плагин-папка /
    админ /
        CSS /
            изображений/
        JS /
    ядро /
    CSS /
        изображений/
    JS /
    языки /
    библиотека/
    шаблоны /
    плагин-folder.php
    readme.txt
    changelog.txt
    license.txt
 

plugin-folder.php обычно является классом, который загружает все необходимые файлы из основной папки. Чаще всего на крюке init или plugins_loaded.

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

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

В зависимости от плагина в корне плагина может быть файл uninstall.php. Однако большую часть времени это обрабатывается через register_uninstall_hook ().

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

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

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
1

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

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46
0

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

  плагин имя /
    JS /
        sparkle.js
        shake.js
    CSS /
        style.css
    СКС /
        header.scss
        footer.scss
    PHP /
        class.php
        functions.php
    плагин-name.php
    uninstall.php
    readme.txt
 

Каждый каталог содержит только файлы этого типа. Стоит отметить, что этот подход не подходит, если у вас есть много типов файлов .png .gif .jpg , которые могут быть более логически поданы в рамках одного каталога, например images /.

ответил getWeberForStackExchange 26 Mayam12 2012, 02:44:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132