Стратегии разработки плагинов WordPress

 
Когда вы создаёте новый плагин WordPress, вам необходимо держать в уме множество вещей: функционал плагина, целевая аудитория, как он будет распространяться, как вы будете его поддерживать и т.д. С процессом разработки связана ещё одна деталь, которая часто отодвигается на задний план, а то и вовсе остаётся незамеченной: основные стратегии, которых вы будете придерживаться в ходе разработки.

 
Под «основными стратегиями» я подразумеваю подходы к таким вещам, как организация файлов/каталогов, схемы именования файлов и функций, принадлежность функций файлам, методы загрузки ресурсов и т.п. Было бы очень хорошо, если бы вы сохраняли эти подходы постоянными на протяжении всех ваших разработок. Применение одних и тех же стратегий для каждого из ваших проектов положительно скажется как на рабочем процессе, так и на качестве работы в целом.
 
Представьте, что вы пишете плагин, размер которого восходит к 10000 строк кода; какой плагин, по-вашему, будет проще дорабатывать и отлаживать: плагин, 10000 строк которого разнесены по понятно названным файлам и каталогам, или же плагин, содержащий все 10000 строк в одном файле? Если вы склоняетесь к единственному файлу, я настоятельно порекомендую вам пойти и написать очень большой плагин, поместив весь его код в один файл. Вы быстро заметите, что это крайне невыгодно.
 
Я хотел бы поделиться с вами элементами моей собственной стратегии разработки. Некоторых из них следует придерживаться просто потому, что так требуют (по разумным причинам) Стандарты Написания Кода WordPress (http://codex.wordpress.org/WordPress_Coding_Standards). Остальные же — общепринятые подходы, которые я нахожу чрезвычайно полезными.
 
Всегда и везде используйте уникальный префикс
 
Это — одно из первых правил разработки и оно должно всегда беспрекословно выполняться. Когда вы пишете плагин, абсолютно всё должно иметь уникальный префикс, специфичный для этого плагина. Сюда относятся имена функций, классов, глобальных переменных, опций, таблиц в базе данных и т.д.
 
Главная причина использования префиксов — предотвращение конфликтов имён. Если два плагина (или плагин и тема) используют для функции одно и то же имя, и оба активны в одно и то же время, произойдёт фатальная ошибка, так как имена всех функций должны быть уникальны.
 
Например, в вашем плагине может быть такая функция:
 
load_plugin_scripts() {

    // загрузка скриптов происходит здесь

}

 
Но такое имя ужасно, потому что оно слишком общее. И если какая-либо тема или другой плагин имеет вдруг функцию load_plugin_scripts, всё закончится ошибкой.
 
Давайте представим на мгновенье, что наш плагин назван «Load Posts with Ajax» (Загрузка постов с помощью Ajax). Обычно я создаю префиксы из первых букв каждого слова в названии плагина, поэтому наш префикс будет «lpa_» или «lpwa_», а функция должна называться так:
 
lpa_load_plugin_scripts() {
 
    // загрузка скриптов происходит здесь
 
}
 
Определяйте константы для адресов и путей к файлам
 
Это относится скорее к большим плагинам, но может быть полезным и с плагинами поменьше. Абсолютный путь к каталогу нашего плагина можно использовать для подключения дополнительных файлов, загрузки шаблонов и т.п. Обычно я определяю константу с путём к директории плагинов так:
 
// путь к каталогу плагина
 
if(!defined(‘LPA_PLUGIN_DIR’)) {
 
    define(‘LPA_PLUGIN_DIR’, plugin_dir_path( __FILE__ ));
 
}
 
Здесь «LPA_» — префикс, созданный нами для нашего плагина чуть выше.
 
Также полезно будет создать константу для адреса каталога плагина. Она будет использована при загрузке таких ресурсов, как изображения, таблицы стилей или JavaScript-файлы.
 
// URL каталога плагина
 
if(!defined(‘LPA_PLUGIN_URL’)) {
 
    define(‘LPA_PLUGIN_URL’, plugin_dir_url( __FILE__ ));
 
}
 
Пока что эти константы не очень-то востребованы, но они упрощают жизнь в долгосрочной перспективе. Вместо построения пути или URL-адреса заново при каждой необходимости, мы просто используем константу. В больших плагинах это может сэкономить кучу времени.
 
Размещайте код плагина в разных файлах
 
При работе с большим плагином хорошим решением будет разнести его по нескольким файлам. Вам следует разделить код на «блоки», организованные по их функционалу. Например, все определения шорткодов могут быть помещены в «shortcodes.php». Весь код, относящийся к загрузке CSS или jQuery, следует поместить в файл, названный как-то вроде «scripts.php».
 
Разделяя ваш код на «блоки», каждый из которых находится в файле с понятным названием, вы делаете дальнейшую разработку гораздо более удобной. Становится проще находить код, особенно во время отладки. Если вы хотите расширить функциональность вашего плагина, добавив, например, ещё один шорткод, вы сразу понимаете, что новый код следует располагать в shortcodes.php.
 
Хотя с не очень большими плагинами это не всегда имеет смысл. Малый плагин, состоящий всего из 100 строк кода, может располагаться в одном файле и не вызывать никаких проблем, но даже в этом случае я всё же посоветовал бы вам разделить его на несколько файлов. Смысл тут заключается в заблаговременной подготовке к дальнейшей разработке и будущим расширениям. Гораздо проще организовать структуру плагина на ранней стадии — пока он мал — чем проводить реорганизацию программы в тысячи строк.
 
Как только ваш плагин разделён на множество файлов, вы подключаете их к главному файлу плагина таким образом:
 
include_once( LPA_PLUGIN_DIR . ‘includes/shortcodes.php’ );
 
Заметьте, что я также советую класть все дополнительные файлы в подкаталоги. Обычно я помещаю их в директорию «includes» (потому что они подключаются к главному файлу), и она часто содержит ещё и поддиректории.
 
Дерево каталогов в моих плагинах обычно выглядит как-то так:
 
my_plugin_folder_name
 
|-includes
 
| |-admin-pages
 
| |-templates
 
|-js
 
|-css
 
|-images
 
Форматируйте ваш код
 
Существует не так уж много вещей, расстраивающих разработчика больше, чем вид ужасно отформатированного кода. Неопрятный код — плохой код. Всё, что вы можете сделать — это аккуратно и единообразно отформатировать его, даже если это займёт некоторое время. Форматирование поможет не только вам, но и всем тем, кто будет работать с вашим плагином после вас.
 
Код должен иметь правильные отступы (я предпочитаю табы — не пробелы) и единообразные переносы строк. Фрагмент кода в условии, в операторе switch или где-либо ещё должен выделяться отступами. Вот пример плохого кода:
 
if( $conditional ) {
 
do_action(‘идентификатор_действия’);
 
execute_some_function();
 
}
 
Хоть по условию выполняются всего две строки, читать их гораздо труднее, чем код с правильными отступами:
 
if( $conditional ) {
 
    do_action(‘идентификатор_действия’);
 
    execute_some_function();
 
}
 
Только представьте, насколько трудно понять код плагина, состоящего из сотни или тысячи строк невыровненного кода. Отладка будет просто кошмаром.
 
Не изобретайте велосипед
 
Существует множество различных API, уже встроенных в WordPress и нацеленных на облегчение вашего труда как разработчика. Поэтому используйте лучше их и не создавайте себе проблем, придумывая новые решения.
 
Для работы с опциями плагина применяйте Settings API (http://codex.wordpress.org/Settings_API). Этот API, при первом знакомстве, может слегка сбить вас с толку, но как только вы его поймёте, он станет весьма простым и крайне эффективным. Tom McFarlin написал множество замечательных уроков по использованию Settings API, и если вы испытываете какое-либо затруднение — ознакомьтесь с ними
 
(http://wp.tutsplus.com/series/the-complete-guide-to-the-wordpress-settings-api/).
 
Для представления данных в вашем плагине в виде таблицы (как на экранах «Записи» и «Страницы») существует класс WP_List_Table (http://codex.wordpress.org/Class_Reference/WP_List_Table). Этот класс будет выполнять для вас всю тяжёлую работу, включая организацию страничности, фильтрацию и т.д. Единственное, что потребуется от вас — это предоставить классу массив с данными, предназначенными для заполнения таблицы.
 
При создании собственных экранов администрирования ориентируйтесь на встроенные в WordPress стили. Нет абсолютно никакого смысла писать десятки (или сотни) строк CSS-кода для стилизации вашей страницы настроек, когда вместо этого вы можете использовать стандартные стили панели управления WordPress.
 
Существует множество других стратегий, не менее полезных в процессе разработки. Но эти — основа. И они хорошо послужат вам, если вы возьмёте их на вооружение.
 

alphaland.in

Сообщество online- маркетологов

alphaland.in написал 409 поста

Навигация по постам


Комментарии

  • pillow

    Интересно получается, когда вроде и код по файлам распределил разным, и названия вроде бы уникальные, а в процессе случайно забываешь что и где у тебя лежит и что оно под собой подразумевает. Потом начинается веселье. Просмотреть кучу папочек с непонятными символами. Доводит до бешенства… Не повторяйте мои ошибки, товарищи программисты и разработчики 🙂

Добавить комментарий

Войти с помощью: