Вопросы Теги

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

Это не вопрос о том, как создать плагин 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
42
27.01.2019, 21:27
9 ответов

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

17
19.02.2020, 21:54

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

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. Если плагин делает чему-то нравятся включенные файлы темы замены, там возможно, a template или theme папка также.

Так, структура каталогов могла бы быть похожей на это:

my-plugin/
    inc/
    lib/
    admin/
    templates/
    css/
    js/
    images/
    lang/
    my-plugin.php
    readme.txt
6
19.02.2020, 21:54
  • 1
    Вы также включали бы CSS администратора и js файлы в / административной папке? Поэтому имея другую / CSS и/js в / администраторе? –  urok93 12.08.2012, 10:52

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

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

Больше информации и учебное руководство могут быть найдены здесь:

6
19.02.2020, 21:54

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

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
19.02.2020, 21:54

Мы используем соединение всех методов. В первую очередь, мы используем Платформу Зенда 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. У нас также есть a Webeo_CoreLoader класс в этом файле, который устанавливает некоторые сменные константы, инициализирует автопогрузчик класса и звонит методу установки Core.php класс в lib/Webeo папка. Это работает plugins_loaded рычаг действия с приоритетом 9.
  4. Core.php класс является нашим сменным файлом начальной загрузки. Имя основано на имени плагинов.

Как Вы видите, у нас есть подкаталог в lib папка для всех наших пакетов поставщика (Webeo, Zend). Все sub пакеты в поставщике являются структурой самим модулем. Для нового 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
19.02.2020, 21:54

Моя логика, чем больше плагин, тем больше структуры я использую.
Для больших плагинов я склонен использовать 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
19.02.2020, 21:54

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

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
19.02.2020, 21:54

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

plugin-folder/
    admin/
        css/
            images/
        js/
    core/
    css/
        images/
    js/
    languages/
    library/
    templates/
    plugin-folder.php
    readme.txt
    changelog.txt
    license.txt

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

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

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

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

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

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

3
19.02.2020, 21:54

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

1
19.02.2020, 21:54

Теги

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