Создаем свой собственный функциональный плагин

Распространенная (и довольно неудачная) практика, укоренившаяся в сообществе WordPress, состоит в «накачивании» файлов functions.php различными настройками и функциональными возможностями, играющими ключевую роль для сайта. Причина, по которой стоит избегать указанного подхода, заключается в том, что он связывает важную функциональность сайта с темой, которая, в свою очередь, может постоянно меняться. К счастью, стоит заметить, что существует более продуманное, альтернативное решение: написание функционального плагина. Именно этот аспект мы и рассмотрим в представленной статье.

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

Что такое «функциональный плагин» и почему мы должны его использовать?

Первое, что необходимо знать, работая с плагинами, это то, что при реализации любых пользовательских требований или целей они ведут себя аналогично файлу темы functions.php. Я не буду говорить, что нет абсолютно никаких различий между плагином и файлом functions.php — они, безусловно, присутствуют, — однако файл плагина не должен обрабатываться как нечто незнакомое и странное. Если вы когда-либо редактировали файл functions.php – даже если вы просто размещали в нем фрагменты PHP кода, найденные посредством онлайн поиска, – вы обладаете достаточным опытом для управления собственными плагинами.

Когда я веду разговор о функциональных плагинах, я подразумеваю определенный тип плагинов, принадлежащих конкретному веб-сайту. Вы можете представить его себе как портативный functions.php файл, который всегда можно переместить при смене темы.

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

Давайте посмотрим на некоторые примеры. Довольно часто к файлу functions.php добавляется функция register_taxonomy, которая отвечает за создание произвольной таксономии, призванной организовать контент. Эта функция может выглядеть следующим образом:

function people_init() {
  register_taxonomy(
     'people',
     'post',
     array(
       'label' => __('People'),
       'sort' => true,
       'args' => array('orderby' => 'term_order'),
       'rewrite' => array('slug' => 'profiles'),
     )
   );
 }add_action( 'init', 'people_init' );

Если мы добавим этот код в файл functions.php своей WordPress темы, то в дальнейшем мы можем столкнуться с одним неприятным сюрпризом: при смене темы наша произвольная таксономия может попросту исчезнуть из Консоли. Чтобы сохранить нашу таксономию, нам понадобится до смены темы пробежать весь файл functions.php, чтобы узнать, не пропустили ли мы чего-либо важного.

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

Что оставить в функциональном плагине?

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

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

1. register_post_type() и register_taxonomy(), для создания различных типов контента и произвольных таксономий.
2. add_shortcode(), для создания шорткодов, позволяющих облегчить публикацию разнообразных видов контента.
3. add_theme_support( ‘post-thumbnails’ ) и add_image_size(), для подключения миниатюр записей и установки определенного размера изображений.

Давайте возьмем первый пункт списка, register_post_type() и register_taxonomy(). Понадобятся ли вам через пять лет различные типы контента, доступные через Консоль? Бесспорно, да, ведь они составляют основной контент сайта. Ваш контент и его доступность не должны диктоваться темой, которую вы выбрали. Приведенные функции, а также другие, похожие на них, должны быть обязательно включены в функциональный плагин.

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

Третий пункт списка, add_theme_support( ‘post-thumbnails’ ) и add_image_size(), позволяет подключить миниатюры записей и установить определенный размер изображений. Здесь ситуация складывается более сложная, поскольку представление миниатюр записей во многом может зависеть от отображения самого сайта. В моем случае я определяю миниатюры записей в плагине, однако имеются аргументы, говорящие в пользу включения их в файлы темы. Здесь все зависит от разработчика.

Что оставить в файле functions.php?

Файл functions.php необходим для размещения функций и объявлений, отвечающих за представление вашей темы. Как уже было сказано выше, все, что каким-либо образом связано с контентом, нужно вынести за пределы этого файла.

В качестве примера можно привести множество функций, которые должны присутствовать в файле functions.php. Мы остановимся на следующих трех:

1. register_nav_menus()
2. register_sidebar()
3. wp_enqueue_script() и wp_enqueue_style()

Первая из них, register_nav_menus(), добавлена в файл functions.php, поскольку размещение навигационных меню зависит от темы, которую вы используете. Хранение этой функции в плагине привело бы к отображению в Консоли настроек расположения меню, которое не будет фактически выводиться где-либо в теме.

Функция register_sidebar() также должна присутствовать в файле functions.php, поскольку повторная регистрация сайдбаров в плагине может означать, что у вас в Консоли имеются активные плагины, которые фактически нигде не используются на сайте. Это было бы довольно глупо.

Функции wp_enqueue_script() и wp_enqueue_style() похожи между собой; их размещение зависит от ситуации. Если вы создаете дочернюю тему, они должны находиться в functions.php. Если вы используете их в других целях (к примеру, для изменения панели администратора WordPress), то в таком случае оправданным шагом было бы создание плагина. Как и в некоторых наших прошлых примерах, здесь все зависит от контекста применения.

Как создать свой первый функциональный плагин?

Создание функционального плагина отличается необычайной легкостью, особенно если вы рассматриваете его как расширение вашего functions.php файла. Любой плагин должен начинаться с закомментированного заголовка:

/*
 Plugin Name: Your Site's Functionality Plugin
 Description: All of the important functionality of your site belongs in this.
 Version: 0.1
 License: GPL
 Author: Your Name
 Author URI: yoururl
 */

Сохраните его в файле с расширением .php и поместите в отдельную папку внутри директории с плагинами вашего сайта. Я также рекомендую вам включить базовый readme.txt файл. Поверьте, через пять лет вы поблагодарите меня за то, что сделали сегодня. Задокументируйте изменения, которые выполняет ваш функциональный плагин.

Если вы хотите, вы можете загрузить заготовку функционального плагина.

Теперь перейдите к странице с WordPress плагинами и активируйте созданными нами плагин. Поздравляю вас: вы только что активировали ваш собственный функциональный плагин, пускай пустой, но все же свой собственный! Он ничего не будет делать, поскольку состоит из одного комментария. Теперь у нас есть файл плагина, расположенный на сайте, который будет обладать поведением, похожим на functions.php. Вместо того чтобы «откармливать» functions.php, вы можете теперь использовать свой функциональный плагин.

Что входит в наш плагин?

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

В каждом конкретном случае определение «фундамента» сайта будет различаться. В следующей таблице я собрал некоторые популярные функции и указал, где они, по моему мнению, должны находиться:

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

Создание плагинов в будущем

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

По материалам сайта: http://wpcandy.com.