Як структурувати плагін

Це не питання про те, як створити плагін 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
      • /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

IMHO, найпростіший, найпотужніший і найбільш досяжний шлях - це використовувати структуру 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

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

Як і багато хто з них вже відповів, це дійсно залежить від того, що плагін повинен робити, але ось моя базова структура:

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

Моя логіка, чим більший плагін, тим більше структури я використовую.
Для великих плагінів я, як правило, використовую 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/наприклад.