КАК СОЗДАТЬ ПЛАГИН ДЛЯ WORD PRESS ИНСТРУКЦИЯ И МИРОВАЯ ПРАКТИКА

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

Добавляйте префиксы

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

Организуйте файлы

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

Правилом хорошего тона и необязательным стандартом, считается назвать главный файл плагина также как называется папка плагина: например: plugin-name/plugin-name.php

Структурируйте папки

Четкая структура папок поможет вам и другим разработчикам лучше работать с плагином. Поэтому держите подобные файлы вместе. Например, разместите файлы JavaScript в папку /js, файлы стилей в /css, и изображения в папке /images.

Определитесь с архитектурой

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

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

Готовые шаблоны (макеты) для создания плагина

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

Обзор

Каждый, кто знаком с WordPress, пользуется плагинами с его репозитория, это очень простой и удобный способ расширить стандартный функционал. Если вы разрабатывали или кастомизировали тему, то сколько раз вы копировали один и тот же код с предыдущего сайта на новый? Сколько раз вам приходила в голову идея, что ваша текущая фича была бы полезна и другим? Если данные мысли появлялись у вас, то в данной статье я пошагово, на примере покажу, что публикация плагина — задача абсолютно не сложная. Те, кто уже публиковал плагины, могут использовать эту статью в качестве шпаргалки для себя, а также я поделюсь парой подводных камней, на которые стоит обратить внимание.

Часть 1. Создание плагина

Примечание. Если вы уже создавали WordPress плагин до этого (возможно для своих нужд, без публикации в репозитории), или знаете как это сделать, то смело пропускайте данный пункт.

В статья для примера я буду использовать свой плагин, ACF Views (помогает вывести ACF поля на фронт без кодинга). По ходу статьи не забывайте заменять это имя на имя вашего плагина.

Для тех кто абсолютно не знаком, расскажу вкратце — WordPress плагины вашего сайта находятся в директории /wp-content/plugins и каждый плагин имеет там свою папку. Для создания плагина вам необходимо проделать еще меньше действий, чем при создании темы, вам необходимо всего лишь создать новую папку в директории /wp-content/plugins и один файл в ней (обычно имя файла совпадает с именем папки). В нашем примере это будет acf-views/acf-views.php.

<?php
/*
Plugin Name: ACF Views
Description: The simplest way to display values from custom post fields anywhere on your site using shortcodes.
Version: 1.0.0
Author: WPLake
*/

(Каждая строка идет в формате  “Имя: Значение”, если копируете, не забудьте поменять значения на ваши). Список всех опций смотрите здесь.

Вот и все.

Часть 2. Подготовка плагина к публикации

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

Проверьте имя плагина

Вам необходимо подобрать уникальное имя, которые не используется другими плагинами. Чтобы проверить свободно ли имя, подставьте его в ссылку https://wordpress.org/plugins/search/my-plugin/ (вместо my-plugin) — если отобразится страница с результатами поиска (как в случае с my-plugin) — порядок, имя свободно. Если откроется страница плагина, как в случае с ACF Views — вам необходимо подобрать новое имя.

Заполните заголовки вашего главного файла

Заполните заголовки вашего главного файла по максимуму, требуемый минимум это : Имя плагина, Версия, и Автор. Список всех опций здесь.

<?php
/*
Plugin Name: ACF Views
Plugin URI: https://wplake.org/acf-views/
Description: The simplest way to display values from custom post fields anywhere on your site using shortcodes.
Version: 1.0.8
Author: WPLake
Author URI: https://wplake.org
*/

Создайте файл readme. txt

Этот файл — ваш главный способ предоставления информации о плагине людям. Данный файл будет парсится WordPress и именно его содержимое отображается на странице плагина (именно автоматический парсинг, у вас не будет панельки в wordpress.org где вы сможете править описание), т.е. все что вы запишите тут, будет отображаться на странице плагина, смотрите ACF к примеру.

Ниже пример readme.txt файла моего плагина, обязательные секции тут  :

главная (с именем вашего плагина и данными про него), description (описание плагина) и changelog (краткое описание всех обновлений, для начала будет лишь одна строка)

Лицензия

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

По правилам WordPress для плагинов (которые созданы чтобы уменьшить количество плагинов с уязвимостями, благодаря которым так часто взламывают сайты на WP) независимо от того, очистили ли вы переменную до вывода, или нет, вы ОБЯЗАНЫ ‘очищать’ переменную также и в самом выводе. Т.е. использовать функции esc_attr, esc_html, и в данном случае код вывода должен быть:

Composer пакеты

И еще одно правило, от меня лично. К сожалению WordPress на данный момент не предоставляет решения для общего использования composer зависимостей плагинами, таким образом один плагин может использовать одну версию какой-либо библиотеки, а второй плагин другую версию этой же библиотеки (и поверьте, это встречается чаще, чем вы могли бы предположить). В таком случае у пользователя будет критическая ошибка и сайт ляжет. Если вы используете composer пакеты в вашем плагине, то чтобы сделать использование вашего плагина неконфликтным, используйте PHP-Scoper.

Если вкратце, то это утилита которая добавит ваше пространство имен во все файлы ваших зависимостей, и вместо namespace DependencyFolder; будет namespace YourNamespaceDependencyFolder; Таким образом возможный конфликт исключается, и одна и та же библиотека может находится в разных плагинах даже с разными версиями. P HP Scoper делает все это за вас автоматически, его установка и настройка не составят большого труда. Подробнее об использовании данной утилиты для WordPress плагина вы можете почитать здесь.

Часть 3. Отправка заявки

Наконец-то мы добрались до самого торжественного и волнующего момента. Время штурмовать репозиторий WP отправлять заявку на размещение вашего плагина в WordPress.org. Это абсолютно бесплатно и довольно просто.

Тут вы загружаете архив с вашим плагином (обычный архив, но с папкой вашего плагина, а не просто файлы плагина без общей папки), WordPress сделает парсинг архива и выведет имя вашего плагина, которое плагин будет иметь в репозитории, (в моем случае acf-views) и выдаст предупреждение, что имя вашего плагина с момента одобрения НИКОГДА не может быть изменено. Поэтому подумайте дважды прежде чем нажимать кнопку submit.

После отправки плагин пройдет ручную модерацию (обычно в течении 1-5 рабочих дней) и вы будете уведомлены про одобрение/отклонения вашей заявки. На деле если ваш плагин не вредоносный, и качество кода не выходит за рамки приличия, то отклонение вам не грозит.

Если модераторы заметят нарушения какого-либо требования (например в моем случае это было про безопасный вывод, я очищал переменные только в момент получения, вывод был обычный) то вам об этом подробно напишут, с просьбой исправить и отправить им исправленную версию плагина. Если вы следовали всем пунктам про подготовку плагина из данной статьи, то вопросов к вам не возникнет. Также хочу вас успокоить, что в любом случае общение с WP модераторами — всегда праздник (по крайней мере для меня xD). А если без шуток, то я действительно редко встречал такой уровень поддержки, если у вашего плагина будут замечены несоответствия, то все эти моменты будут отписаны вам и очень подробно детализированы, так что вы сразу поймете в чем дело. Такого случая, когда вам откажут в публикации или приостановят рассмотрение без толкового объяснения причин я еще не встречал, за что отдельный респект сообществу WP.

Часть 4. Первый коммит

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

В письме будет указан адрес вашего svn репозитория (не стоит пугаться, svn практически тот же git в использовании) и ссылка на страницу вашего плагина в WordPress.org. Письмо вы можете сохранить (для истории), но не бойтесь его потери, все ссылки в WordPress.org одинаковые, вам необходимо лишь помнить имя вашего плагина, и вы всегда сможете получить эти ссылки подставив ваше имя в ссылки ниже:

Ну а имя вашей первой любви вашего первого плагина я убежден вы запомните на всю жизнь.

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

Скопируйте файлы

Скопируйте файлы вашего плагина (без папки) в директорию trunk , создайте папку с вашей версией (вероятно 1.0.0) в директории tags и добавьте файлы вашего плагина туда.

Выберите банер и иконку

Время задуматься про баннер (который отображается вверху страницы вашего плагина на WP.org) и иконку плагина (которая отображается в поиске WP.org возле имени вашего плагина). Это может быть любое изображение, на ваше усмотрение (в рамках приличия опять таки), вы можете добавить баннер в двух поддерживаемых разрешениях (772×250 и 1544×500) в папку assets с именем banner.

Это будут banner-772×250.png и banner-1544×500.png (или jpg). Иконка будет icon-128×128.png и icon-256×256.png (или jpg, svg).

Добавьте файлы в svn

Добавляем файлы в svn командами :

svn add trunk/*
svn add tags/YOUR_VERSION_HERE
svn add assets/*

Сделайте коммит

svn ci -m «v 1.0.0»

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

Вот и все! Теперь вы можете посетить страницу вашего плагина, она доступна для всех, и можете устанавливать ваш плагин на любые WP сайты прямо из админ панели (через Добавить новый — поиск).

Обновить файлы плагина

Обновите версию на новую в шапке вашего главного файла (“Version: X”) и обновите “Stable tag: YOUR_VERSION_HERE” в readme.txt на новую версию.

Обновить файлы в svn репозитории

Обновите файлы плагина в папке trunk, создайте новую папку с номером вашей версии в папке tags (1.0.1 вероятно) и скопируйте файлы плагина также туда.

Сделать коммит

Давайте сообщим svn про новые файлы и сделаем коммит:

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

Суммирую — в репозитории вы должны обновить директорию trunk (там всегда хранится последняя версия плагина) и добавить новую папку (с номером версии в качестве имени и файлами плагина внутри) в директорию tags.

В случае если вы хотите просто обновить информацию на странице плагина, новую версию можно не выпускать, а просто обновить readme.txt файл в trunk папке и сделать коммит.

Как вы заметили, svn репозиторий WordPress используется ТОЛЬКО для выпуска новых версий (т.е. является релиз репозиторием). Коммитить в него каждое ваше изменение, как в обычный git репозиторий нельзя! Подробнее про использование репозитория. Это приведет к тому, что ваш репозиторий станет очень медленным, и будет занимать много места на WP.org. Для разработки вашего плагина создайте свой личный git репозиторий, где сможете вести разработку и коммитить сколь угодно часто, а svn репозиторий мы используем только для выпуска новых версий.

Надеюсь данная статья была полезной для вас, и развеяла мнение о том, что публикация своего плагина в WordPress это трудоемкий и долгий процесс. Самое время сделать этот мир чуточку лучше и опубликовать свой плагин!

Вместо P.

В данной статье в качестве примера я использовал свой плагин ACF Views. Если кому-то интересно, продожайте чтение, ниже я вкратце расскажу про сам плагин. Это плагин-дополнение к Advanced Custom Fields (PRO версия ACF обязательна).

Вначале про проблемы, которые он решает.

Сам ACF очень удобный в использовании плагин, и уже стал по факту плагином, который по умолчанию входит в начальный пакет для разработки любого веб-сайта, однако каждый раз когда вы создаете новую группу и прикрепляете ее (в location) к какой-то странице или к CPT, то возникает вопрос, задача отобразить эти поля на фронте сайта.

Обычно это решается вручную (например в теме) — создается шорткод, который вставляет необходимые поля в разметку и выводит ее, и далее этот шорткод устанавливается на страницу/в CPT шаблон и все это стилизуется.

Однако есть ряд нюансов, таких как :

ACF Views упрощает жизнь и выводит ACF поля на фронт сам. После создания группы, вы создаете новое View, и выбираете какие поля вы хотите вывести, сохраняете View и получаете шорткод. Вставляете шорткод на страницу/CPT шаблон и вуаля, вывод готов.

Плагин автоматически генерирует разметку в зависимости от типа поля и его настроек (поддерживает множество типов и все return-форматы). Чтобы стилизовать вывод вы можете добавить стили прямо во View (есть специальное поле), эти стили будут выведены только на страницах, где есть данная View (не глобально), и разметка уже имеет классы по умолчанию (в BEM стиле), вы можете использовать их и даже не назначать свои классы (хотя такая опция тоже есть). Есть PRO версия, которая позволяет редактировать разметку (по прежнему не заботясь про типы полей и форматы), использовать repeater и создавать Gutenberg блоки c помощью View абсолютно без кодинга. ( Держите промокод, специально для читателей хабра — habr9, по нему вы получите 20% скидку)

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

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

Почему люди любят WordPress? Потому что с ним просто работать. В нём нет гибкости большущих CMS вроде Joomla и Drupal, — а значит, не запутаешься. И ещё он очень популярен — а значит, можно найти плагины на все случаи жизни.

В своих записях я очень часто ссылаюсь на чужие блоги. И мне пришла идея — а почему бы не показывать рядом с ником человека, на которого я ссылаюсь, ещё и значок его сервиса? Например, птичку из твиттера или букву B из блогспота? Похожий функционал есть, например, в Википедии, да и многие блогохостинги это позволяют (например, Dreamwidth).

Так и родился плагин для WordPress Rikki’s WP Social Icons. Позволяет за один клик мышкой добавить ссылку на эккаунт в каком-нибудь сервисе, от социальной сети до GitHub.

Зачем?

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

Во время работы я довольно много пользовался исходниками чужих плагинов, а также наработками Jenyay (ссылки на его цикл статей приведён в приложении). Но «кустарной» реализации было мало. Plugin тем и удобен, что каждый конечный пользователь может доработать его сам. А значит, нужно сделать так, чтобы добавить к нему поддержку нового сервиса было делом пяти минут и одной переустановки.

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

Программируем

Начнём с того, что писать плагины для WordPress не просто, а очень просто. Не нужно создавать ни классов, от чего-то там унаследованных, ни мудрить с форматами, ни следовать каким-то хитрым спецификациям. « События» вынесены в специальные объекты, которые работают примерно как event-ы в «больших» приложениях.

Для начала надо хорошенько обдумать, что нам нужно. А нужен нам способ маркировки отдельных слов, который был бы виден при редактировании, и автоматически переделывался в ссылку в постах, страницах и RSS.

Очень похоже работает shortcode — специальный тег, окружённый квадратными скобками и специально заточенные под обработку плагинами. Они появились ещё версии 2.5, которая вышла в далёком 2008 году, так особые проблемы с совместимостью нам не грозят.

Какой формат нам следует принимать от пользователя? Т.к. конечный HTML-код будет отличаться только иконкой и url-ом, было бы логично завести один shortcode и одну функцию, которая бы его обрабатывала. Дополнительные сведения можно передавать и через параметры, что очень удобно. К тому же, чем меньше shortcode-ов мы создадим, тем меньше шанс, что мы вступим в конфликт с каким-то другим плагином.

Пишем ядро

Теперь создаём структуру для нашего плагина (см. на GitHub) и набрасываем в rikkis-wp-social-icons.php наше миниатюрное ядро:

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

Если всё в порядке — мы добавляем новый shortcode, указывая для него в качестве обработчика функцию icon_func из этого же экземпляра класса.

icon_func — она очень короткая и очень интересная. В неё приходит 2 параметра:

$atts — массив атрибутов
$content — текст между тегами

Пользователь увидит вместо shortcode то, что вернёт ему эта функция. Именно здесь (в последнем return) и формируется окончательный код нашего блока.

По совету из комментариев, все пришедшие «на вход» строки проверяются через esc_url, чтобы не было дырок в безопасности.

Заслуживают внимания две строчки:

Получает url иконки по типу, относительно текущей директории. Именно для этого нужен атрибут __FILE__. Если же его нет (а авторы некоторых плагинов и примеров явно про него не слышали), то придётся вставлять имя директории плагина и всё равно это может не заработать.

Не менее важно сделать trim() для $id. Дело в том, что если дважды щёлкнуть по слову в editor-е WordPress-а, то он выделит слово вместе с пробелом после него. В результате мы получим имя учётной записи с совершенно неуместным пробелом и ссылка работать не будет.

В принципе, уже в таком виде (17 строк кода + 14 строк настроек) наш плагин можно ставить и использовать. Настоящий хакер презирает оконные интерфейсы :). Вы можете попробовать запаковать php и картинки в zip и установить их в wordpress, как устанавливают обычный плагин.

Очень рекомендую поставить для подобных экспериментов локальный Apache+PHP+mySQL, и к ним впридачу WordPress. Отладка пойдёт намного веселее — например, вместо установки-переустановки можно будет просто подменять файлы в соответствующем каталоге.

Добавляем кнопки

За редактирование постов и страниц в WordPress отвечает отдельный компонент tinyMCE. Чтобы его дёрнуть из основного PHP, нужно немного расширить нашу первоначальную форму:

Тут всё просто — mce_external_plugins подгружает JavaScript, в котором и будут генерировать кнопки, а mce_buttons кладёт туда все ключи из словаря options.

Теперь нам предстоит написать JavaScript для кнопочек. Увы, но tinyMCE вшит в WordPress настолько прочно, что стандартный способ передачи параметров из PHP в JavaScript для плагинов WordPress здесь не сработает. Конечно, можно было бы попытаться получить их через JSon и добиться, чтобы исправление нужно было вносить действительно только в одном месте. Но это тот самый случай, когда малозначительное удобство может вызвать значительные проблемы.

Обрамление у tinyMCE плагина довольно стандартное:

Добавление одной кнопки, которая обрамляет выделенный фрагмент текста каким-тегом нашего shortcode выглядит так:

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

И то верно — разве не должны за программиста работать роботы?

Если сгенерировать кнопки таким образом, а потом перейти на editor, то сразу почувствуешь гордость за своё мастерство. Кнопки, указанные в array-е, выстроились в ряд, и на каждой — та самая иконка, которую увидит посетитель сайта или читатель RSS-ленты. Очень удобно!

Добавляем в каталог

Остался последний шаг — добавление плагина в каталог WordPress, чтобы его можно было найти стандартным поиском.

Вся процедура подробно описана в большом англоязычном мануале.

А для тех, кому не терпится — вот короткое пошаговое руководство:

Если что-то не заработало — обратитесь к большому мануалу. Там всё очень подробно расписано.

Автор будет благодарен всем, кто возьмёт шефство над github-овской версией проекта и будет развивать его дальше.

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

Если вам требуется разработка плагина на заказ для WordPress или для WooCommerce, то я и моя команда будем рады вам помочь, для этого напишите нам.

Нельзя просто взять и написать плагин для WordPress?

Сначала может показаться, что создание плагина для WordPress — это что-то невероятно сложное и это нужно долго изучать, но на самом деле всё зависит от задач, которые выполняет плагин, понятно, что если вы разрабатываете «свой WooCommerce», то возможно вам будет мало и года разработки, но если ваш плагин просто добавляет несколько строчек CSS в админку, то это займёт от силы 5 минут.

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

Весь наш процесс мы разделим на шаги для удобства понимания.

Определиться с тем, какие задачи будет выполнять плагин

Скажу так, код, который находится в плагине, очень схож с тем кодом, который размещают в functions.php. То есть вы можете потренироваться с готовыми хуками.

По сути это готовый код и если вы отправите его в functions.php, то всё будет отлично работать.

Но мы же пишем плагин, поэтому этот код держим рядом и переходим ко второму шагу.

Есть два варианта:

В общем либо /wp-content/plugins/misha.php, либо /wp-content/plugins/misha/misha.php (рекомендуется).

Однако после того, как вы всего лишь создадите эти файлы, ничего не произойдёт, поэтому добавьте в главный файл плагина (ну он сейчас один) эти строчки:

<?php
/* Plugin name: Мишин плагин */

Поимимо «Plugin name» у плагинов есть и другие метаданные, давайте их разберём подробнее.

Метаданные плагина

В свой главный файл плагина теперь отправляем что-то в этом духе:

<?php
/*
* Plugin Name: Мишин плагин
* Plugin URI: https://misha.agency/wordpress/sozdai-svoi-plugin.html
* Description: Описание супер-плагина
* Version: 1.1.1
* Author: Миша Рудрастых
* Author URI: https://misha.agency
* License: GPLv2 or later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
*
* Text Domain: truemisha
* Domain Path: /languages
*
* Network: true
*/

После вставки всех этих параметров то, как плагин выглядит в админке, изменится:

Вот описание всех мета-параметров:

(единственный обязательный параметр!) Название плагина, как видите можно писать на русском.

Если у вашего плагина в интернете есть страница с описанием или документацией, то неплохо бы тут указать её URL.

Версия плагина. Да, туториал совсем для новичков, поэтому добавлю, что например вы запустили свой плагин с версией 1.0 и люди пользуются, а потом поменяли какой-то код внутри своего плагина, а значит и его версия изменилась, например на 1.1

Сам WordPress выпускается под лицензией GPL, возможно вы знаете, но также подразумевается, что все плагины и темы под WordPress тоже должны использовать эту лицензию.

Идентификатор перевода, который будет использовать в функции load_plugin_textdomain() при переводе плагина на другие языке, читайте руководство по локализации плагинов и тем WordPress.

Если файлы перевода вашего плагина находятся в папке languages внутри папки плагина, то значение Domain Path будет /languages. Если ваш плагин находится в официальном репозитории WordPress, то этот параметр можно не использовать.

Если ваш плагин предназначен для сети сайтов WordPress Мультисайт и должен активироваться сразу для всей сети, то укажите этот параметр в значение true.

Хуки в плагине

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

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

Register_activation_hook()

Функция register_activation_hook() позволяет привязать какую-то произвольную функцию к событию активации плагина.

Сразу давайте рассмотрим пример – например деактивируем плагин «Hello Dolly» функцией deactivate_plugins() при активации вашего плагина.

, ;

truemisha_activate // функция, срабатывающая один раз при активации плагина
;

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

Вплоть до версии WordPress 1.2 возможность изменения его функционала «под свои потребности» или расширение возможностей достигались путем редактирования исходного кода ядра платформы WordPress (грубо говоря, «хакинга» ядра). Но это создавало различные неудобства (например, при обновлении версий), и от такой практики вскоре отказались. Разработчики внедрили достаточно удобную, понятную и легкую в использовании программистами систему расширения функционала с помощью «плагинов». Основная идея использования новой системы расширения возможностей состояла в том, чтобы сохранять ядро целостным и неизменяемым и в то же время дать PHP-программистам возможность изменять его поведение с помощью специальных легко подключаемых (и отключаемых) скриптов-плагинов. Итак, что такое плагин WordPress?

Плагин WordPress — это программа или набор функций, написанных на PHP, добавляющих определенный набор возможностей или сервисов к блогу на WordPress, которые легко объединяются с системой управления и функционалом WordPress при помощи Plugin Application Program Interface (API).

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

Эта статья подразумевает, что вы уже знакомы с основами функциональности WordPress, а также с языком программирования PHP.

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

Имена, файлы и местоположения

Первая задача при создании плагина — подумать, что плагин будет делать, и придумать для него имя (желательно уникальное). Проверьте «Плагины» и другие хранилища, чтобы убедиться в том, что придуманное вами имя — уникальное; вы можете также погуглить по выбранному вами имени. Большинство разработчиков плагинов выбирают имена, которые отражают функциональность их плагина; например, плагин для отображения погоды может иметь в названии слово «погода». Название может состоять из нескольких слов.

Следующий шаг — создание файла PHP с именем, производным от названия плагина. Например, если ваш плагин будет называться Fabulous Functionality, вы можете назвать ваш файл fabfunc.php. Опять же, попробуйте создать уникальное имя. Люди, которые установят ваш плагин, положат этот файл в свою директорию для плагинов, wp-content/plugins/, и никакая пара используемых плагинов не должна иметь одинаковое имя файла.

Другой вариант — разбить ваш плагин на несколько файлов. Ваш плагин должен иметь как минимум один файл PHP; он также может содержать файлы JavaScript, CSS, изображения, языковые файлы и т.п. Если ваш плагин состоит из нескольких файлов, задайте уникальное имя для директории, в которой они лежат, и для главного файла PHP, такие как fabfunc и fabfunc.php в нашем примере, положите ваши файлы в эту директорию и дайте пользователям возможность устанавливать целую директорию в wp-content/plugins/.

В этой статье «PHP-файл плагина» означает главный PHP-файл, который находится в директории wp-content/plugins/ или в ее поддиректории.

Если вы хотите разместить ваш плагин на http://wordpress.org/extend/plugins/, вам необходимо создать файл readme.txt в стандартном формате и включить его в свой плагин. Смотрите http://wordpress.org/extend/plugins/about/readme.txt для получения разъяснений по формату.

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

Самое время внести некоторую информацию в ваш главный файл PHP.

Стандартная информация о плагине

Начало вашего файла должно содержать стандартный информационный заголовок. Этот заголовок позволяет WordPress понять, что ваш плагин существует, добавить его в панель управления плагинами, где он может быть активирован, загрузить его и запустить его функции; без заголовка ваш плагин никогда не будет активирован и запущен. Вот формат заголовка:

Минимальная информация, которая нужна WordPress, чтобы обнаружить ваш плагин — его название (Plugin Name). Остальная информация (если она есть) используется для создания таблицы плагинов на странице управления плагинами. Порядок строк неважен.