Когда вы приближаетесь к завершению своего плагина WordPress, пришло время задуматься о том, чтобы выпустить его для широкой публики. Подготовка к публикации плагина требует много полировки, тестирования и тонкой настройки, и некоторые этапы процесса легко забыть. Этот учебник проведет вас через публикацию плагина в каталоге плагинов WordPress и будет работать как контрольный список, чтобы помочь вам убедиться, что ваш плагин будет готов к прайм-тайму к моменту публикации.
Некоторые шаги, такие как настройка проекта, выполняются один раз за время существования каждого плагина, тогда как многие важны каждый раз, когда вы выпускаете новую версию вашего плагина. Вот почему может быть хорошей идеей добавить этот урок в закладки и вернуться к нему, когда придет время сделать следующее обновление.
Шаг 1. Введение в каталог плагинов WordPress
Каталог плагинов на WordPress.org для WordPress — это то же самое, что AppStore для iPhone: самый простой и быстрый встроенный способ поиска плагинов для WordPress. Хотя плагин можно публиковать в виде zip-файла, загруженного с вашего собственного веб-сайта, с каждым выпуском интеграция между WordPress и его каталогом плагинов становится все теснее.
Выпуская свой плагин через каталог плагинов, вы облегчаете потенциальным пользователям возможность поиска вашего плагина и его обновления при создании новых версий. Они смогут установить плагин, не выходя из панели администратора WordPress, и, естественно, большинство пользователей WordPress уже хорошо знают каталог плагинов и будут просматривать его при поиске плагинов, соответствующих их потребностям. Вы, с другой стороны, получите статистику загрузки, отзывы пользователей через страницу плагина в каталоге плагина и бесплатный репозиторий subversion для хранения файлов вашего плагина и истории версий.
Есть ли причина не размещать ваш плагин в каталоге плагинов? Если ваш плагин является коммерческим, вы можете разместить его в другом месте (на своем собственном сайте или на торговой площадке, например, в Envato ‘s Codecanyon ), поскольку каталог плагинов открыт и не поддерживает зарабатывание денег из ваших плагинов. Все, что размещено в каталоге плагинов WordPress, доступно для скачивания всем желающим.
Вот правила для плагинов, размещенных в каталоге, взятые из инструкции каталога плагинов:
Есть только несколько ограничений:
- Ваш плагин должен быть совместим с GPLv2 .
- Большинство плагинов не делают ничего противозаконного или морально оскорбительного (мы знаем, что это субъективно).
- Вы должны использовать репозиторий Subversion, который мы вам дадим, чтобы ваш плагин появился на этом сайте. Каталог плагинов WordPress — это хостинг, а не сайт со списком.
- Плагин не должен вставлять внешние ссылки на общедоступный сайт (например, ссылку «powered by») без явного запроса разрешения пользователя.
- Если вы не укажете v2-совместимую лицензию, то вы явно отметите GPLv2.
Шаг 2. Добавьте ваш плагин в каталог плагинов
Как только вы решили разместить свой плагин в каталоге плагинов WordPress, первым шагом будет создание учетной записи пользователя WordPress.org. Чтобы получить его, зайдите в каталог плагинов и нажмите ссылку «Зарегистрироваться» в верхней правой части страницы, рядом с приглашением для входа.
После регистрации вашей учетной записи вы можете запросить WordPress добавить свой плагин, перейдя по этой ссылке, ведущей на страницу, которая выглядит как на скриншоте ниже.
Заполните форму и кратко объясните, о чем ваш плагин. Будьте максимально конкретны, оставаясь в разумных пределах. Если у вашего плагина уже есть веб-сайт, введите URL в поле «URL плагина».
Перед созданием вашего проекта кто-то из сотрудников WordPress прочитает ваш запрос и одобрит его. В то время как WordPress не дает никаких обещаний относительно того, сколько времени это может занять, говоря, что они ответят вам в «некоторое неопределенное количество времени», время рассчитывается в часах или днях, а не в неделях — скорее всего, у вас будет плагин настроить в течение 24 часов с момента подачи запроса.
Как только ваш плагин будет одобрен, вы получите электронное письмо с веб-сайтом вашего нового проекта и URL-адресом SVN. Обратите внимание на URL хранилища, так как мы будем интенсивно использовать его на следующих шагах.
Шаг 3. Работа с репозиторием SVN
В следующих шагах я предполагаю, что вы хотя бы немного знакомы с SVN, поэтому, если вы не знаете, что такое SVN, просмотрите учебное пособие, прежде чем переходить к следующему шагу.
На Mac и в большинстве версий (если не во всех) Linux клиент командной строки SVN поставляется с операционной системой. В Windows вы можете установить клиент командной строки самостоятельно или использовать графический клиент, такой как Tortoise SVN . На Mac версии — очень хороший графический клиент.
Чтобы максимально использовать SVN-репозиторий, предоставляемый WordPress, мы настроим его так, чтобы версия разработки плагина сохранялась в <your plugin's SVN URL>/trunk а выпущенные версии копировались как теги SVN в <your plugin's SVN URL>/tags , каждая версия в качестве собственного тега. Таким образом, все ваши предыдущие версии могут быть загружены через каталог плагинов — очень полезно, когда вы выпускаете версию с ошибками: ваши пользователи могут вернуться к предыдущей версии, пока вы работаете над исправлением ошибки.
Каталог плагинов читает тег, из которого должен распространяться ваш текущий стабильный выпуск, проверяя файл readme.txt в trunk . Я расскажу об этом более подробно на следующем шаге, когда мы пройдемся по содержимому файла readme.txt который должен быть включен в плагин.
Однако сначала давайте пройдемся по командам SVN, которые вы будете использовать большую часть времени. Не беспокойтесь, если вам не нравится писать команды в терминале, просто используйте вместо этого ваш любимый графический клиент SVN.
Начнем с проверки проекта из SVN. В данный момент проект все еще пуст, поэтому на вашем компьютере не добавляется ничего, кроме пустой директории.
|
1
|
$ svn co http://[email protected]/your-plugin/trunk local-path
|
Скопируйте или переместите код вашего плагина в этот каталог (local-path), созданный командой svn, и добавьте файлы в SVN. Внутри каталога введите:
|
1
|
$ svn add file-path
|
file-path может быть путем к определенному файлу или подстановочным знаком, таким как *.php . Это пометит файлы, которые будут добавлены в репозиторий SVN при вашем следующем svn коммите — пока ничего не зафиксировано. Если вы не уверены, какие файлы вы уже добавили, вы можете проверить состояние SVN каждого файла в текущем рабочем каталоге:
|
1
|
$ svn status
|
Наконец, когда все будет готово для отправки в репозиторий SVN, зафиксируйте файлы. Не бойтесь часто делать коммиты: пока «стабильный тег» указывает на какой-то другой каталог, кроме транка, ваши коммиты не будут влиять на уже опубликованную версию. Делая это, вы в безопасности, если по какой-то причине вы потеряете локальную копию кода.
|
1
|
$ svn commit -m «A brief explanation of what was changed»
|
Прежде чем ваш проект будет показан в каталоге плагинов, вам все равно нужно будет добавить файл readme.txt. Но прежде чем мы углубимся в это, пришло время проверить ваш плагин.
Шаг 4. Проверьте ваш плагин
Даже если ваши пользователи не платят за использование вашего плагина, выпуск плагина без его предварительного тестирования никогда не будет хорошей идеей. В открытом исходном коде люди допускают несколько выпусков с ошибками время от времени, если вы быстро исправляете свои ошибки и быстро реагируете на их сообщения об ошибках, но если каждый отдельный выпуск выходит с серьезными ошибками, рано или поздно ваши пользователи перейдем к другим аналогичным плагинам.
В то же время мы должны помнить, что наши возможности тестирования ограничены как у отдельных разработчиков, так и у небольших команд. Если вам повезет, вы можете попросить кого-нибудь за пределами команды протестировать ваш плагин, но довольно часто, только вы, разработчик, проводите тестирование. Вот почему важно создать четкий и простой, действенный план тестирования.
Чтобы создать его, пройдите следующий совет, выберите подходящие вам советы и настройте его в соответствии со своим опытом и особенностями плагина, который вы собираетесь выпустить.
Тест на слабые места
Я первый, кто признает, что я не идеальный разработчик. Хотя я знаю свои слабые места, я склонен повторять свои ошибки. Вот почему в своей тестовой процедуре я стараюсь поддерживать актуальный список типов ошибок, которые чаще всего встречаются в моем коде, и тестов, которые мне нужно делать перед каждым выпуском, чтобы выявить наиболее распространенные ошибки.
Не забудьте проверить старые функции
Это называется регрессионным тестированием , и это одна из наиболее важных форм тестирования: как правило, новые функции тестируются довольно хорошо по мере их разработки, но в то же время вы можете вносить ошибки в другие части кода, которые вы уже использовали. считается завершенным.
Чтобы поймать эти ошибки, создайте список тестов для проверки основных функций вашего плагина и просматривайте список перед каждым выпуском, даже если ваши изменения не должны были затрагивать их.
Тест на разных установках WordPress
Некоторые из ошибок появляются только для новых пользователей, которые устанавливают плагин в первый раз, в то время как другие только беспокоят пользователей, которые обновляются с предыдущей версии. Некоторые ошибки появляются только в многопользовательской среде и так далее.
Чтобы убедиться, что вы уловили как можно больше проблем, рекомендуется создать разные тестовые среды, по крайней мере, одну с существующей версией вашего плагина, а другую — с чистой установкой WordPress.
Обратите особое внимание на изменения в структуре базы данных
Когда вы узнаете, что ваш следующий выпуск создает новые таблицы базы данных или изменяет существующие, внимательно проверьте, чтобы убедиться, что изменение, которое вы ожидаете, действительно произойдет, и база данных вернется в правильное конечное состояние. Моя процедура тестирования говорит о структуре базы данных:
Если структура БД изменилась:
- Тестирование обновления базы данных без деактивации плагина
- Тестирование обновления базы данных с деактивацией / повторной активацией
Не забудьте проверить на наличие пустых листов и ошибок
Это состояния, которые вы не замечаете, если просто запускаете плагин так, как было задумано, и поэтому может пройти много времени, прежде чем вы заметите ошибки, если вы не намеренно протестируете их.
Это не то, что вы хотите увидеть в фрагменте кода обработки ошибок, предназначенного для корректной обработки ошибки:
Всегда тестируйте с последней версией WordPress
Чтобы убедиться, что ваш плагин работает с изменениями, внесенными в последнюю версию WordPress, хорошо всегда обновлять свою тестовую среду до последней версии, прежде чем выполнять последний раунд тестирования.
Используйте помощь в тестировании, которую вы получаете от своих пользователей
Просмотрите отзывы пользователей и посмотрите, есть ли ошибки, к которым вы еще не обращались. Пока игнорируйте запросы функций (но запишите их, чтобы вы могли использовать их в качестве входных данных при планировании следующего выпуска), поскольку в любом случае вы не можете делать все в одном выпуске. Всегда верьте своим пользователям, когда они говорят, что нашли ошибку, но не бойтесь запрашивать дополнительную информацию, чтобы ее выяснить.
Тест на разных веб-браузерах
Если ваш плагин записывает какой-либо HTML или CSS, определитесь с набором браузеров, которые вы поддерживаете, и тестируйте ваш плагин на этих браузерах перед каждым выпуском.
Шаг 5. Двойная проверка на проблемы, которые легко пропустить
Некоторые потенциальные проблемы легче найти, посмотрев на код, чем через тестирование, поэтому, как и при тестировании, неплохо бы отследить ваши слабые места и записать список вещей для двойной проверки перед публикацией плагина. По мере того, как вы выпускаете больше версий, вы получаете больше знаний о том, что важно тестировать в этом самом проекте, поэтому продолжайте обновлять список по мере изучения, извлекать некоторые вещи и добавлять другие.
Вот некоторые идеи для двойной проверки, собранные из моего собственного опыта:
Проверка параметров
Когда вы обрабатываете формы, опубликованные пользователем, убедитесь, что вы правильно проверили атрибуты, в их самой простой форме, используя метод esc_attr .
|
1
|
$user_name = esc_attr($_POST[«username»]);
|
Наименование функций
если ваш плагин не написан с использованием объектов, каждая из ваших функций находится в одном пространстве имен с остальной частью кода в WordPress и установленных плагинов. Чтобы предотвратить совпадение имен ваших функций с именами из WordPress или других плагинов, добавьте перед ними краткое имя плагина.
|
1
2
3
4
5
6
7
8
9
|
function pluginname_print_error($message) {
…
}
// is safer than:
function print_error($message) {
…
}
|
Комментарии TODO и FIXME
Просмотрите все ваши комментарии TODO или FIXME, чтобы увидеть, что вы не пропустили ничего, что вы запланировали поработать позже.
локализация
Если ваш плагин поддерживает локализацию, перед каждым выпуском просмотрите все строки плагина, чтобы убедиться, что все они правильно помечены для локализации. Это легко забыть при добавлении новых строк в плагин.
|
01
02
03
04
05
06
07
08
09
10
11
|
// use
$text = __(«Hello, world», «my_plugin»);
// instead of just
$text = «Hello, world»
// and
_e(«Hello!», «my_plugin»);
// instead of
echo «Hello!»;
|
Следуйте стандартам кодирования
В Кодексе WordPress вы можете найти документ, в котором описывается стиль кодирования, которому следует следовать при разработке плагинов для платформы WordPress. Следование этому документу не является обязательным, но это поможет другим разработчикам помочь вам с плагином.
Включить лицензию GPL
Убедитесь, что каждый файл в вашем плагине содержит заголовок GPL и что файл license.txt лицензии GPL включен в основную папку вашего плагина.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
/*
Copyright (c) 2011, Your Name.
This program is free software;
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation;
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY;
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program;
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
|
Шаг 6. Документируйте свой плагин с readme.txt
Каждый плагин, добавленный в каталог плагинов WordPress, должен иметь файл readme.txt отформатированный в соответствии с правилами, определенными этим шаблоном . Важно следовать форматированию, как определено следующим образом: когда вы фиксируете свой плагин в каталоге плагинов, этот файл автоматически преобразуется в описание плагина, которое вы видите при просмотре плагинов в каталоге плагинов.
Например, посмотрите, как этот фрагмент из начала шаблона readme.txt преобразуется в информацию, представленную пользователю каталога подключаемых модулей:
|
1
2
3
4
5
6
7
|
=== Plugin Name ===
Contributors: markjaquith, mdawaffe (this should be a list of wordpress.org userid’s)
Donate link: http://example.com/
Tags: comments, spam
Requires at least: 2.8
Tested up to: 3.1.3
Stable tag: 1_5_4
|
Скопируйте шаблон в каталог плагинов и начните редактировать его с информацией, относящейся к вашему плагину. Если вы довольны своим файлом readme.txt, протестируйте его, используя валидатор readme.txt, предоставленный WordPress, прежде чем фиксировать его в SVN.
Когда вы видите это в верхней части страницы валидатора, вы готовы совершить:
Шаг 7. Сделайте релиз, обновив номер версии и стабильный тег
Я упомянул стабильный тег на шаге, где мы говорили о том, как правильно использовать SVN в разработке плагинов. Теперь пришло время начать его использовать: вы протестировали свой плагин, вы проверили свой код и написали документацию. Там ничего не осталось, кроме выпуска плагина:
Обновите номер версии плагина
Найдите основной файл PHP вашего плагина и обновите комментарий, введя номер вашей версии в поле "Version:" :
|
1
2
3
4
5
6
7
8
|
/*
Plugin Name: A Plugin
Version: 1.0
Plugin URI: http://wp.tutsplus.com
Description: My great plugin
Author: Jarkko Laine
Author URI: http://jarkkolaine.com
*/
|
Обновить историю версий
В readme.txt есть два раздела, посвященных документированию изменений вашей версии: « Changelog » и « Upgrade Notice ». Добавьте раздел для вашей новой версии в журнал изменений, предоставив подробную информацию о том, какие изменения и исправления ошибок включены в эту версию. Уведомление об обновлении — это более короткая (не более 300 символов) сводная информация о том, почему стоит обновить эту версию плагина.
Вот пример строки журнала изменений из моего плагина для пожертвований:
|
1
2
3
|
= 1.5.2 =
* Bug fix: Fixed a bug database upgrade bug introduced in previous version
* Bug fix: Fixed a bug related to passing the selected currency to PayPal
|
Обновить стабильный тег
Находясь в readme.txt , найдите строку (почти в верхней части файла) с надписью « Stable tag: » и обновите строку с именем тега, который вы будете использовать для следующей версии. Мое соглашение состояло в том, чтобы присвоить тегу имя, совпадающее с номером версии, при этом точки заменяются символами подчеркивания (например, тег для версии 1.0 будет 1_0). Это работает довольно хорошо, но еще лучше просто сделать его таким же, как номер версии:
|
1
|
Stable tag: 1.0
|
Таким образом, когда кто-то ищет более старую версию вашего плагина на странице «Другие версии», он легко выяснит, какой тег принадлежит какой версии, как в этом примере из самого популярного плагина в каталоге плагинов:
Создать тег
Зафиксируйте ваши изменения в основном PHP-файле плагина и readme.txt. Затем создайте тег, который вы выбрали для своего следующего «стабильного тега»:
|
1
2
|
$ svn copy http://[email protected]/your-plugin/trunk
http://[email protected]/your-plugin/tags/1.0 -m «Tagging a new version»
|
Вот и все: readme.txt в trunk указывает на правильный тег, и все, что вам нужно сделать, это подождать, пока автоматическое программное обеспечение в каталоге плагинов не заметит ваши изменения и не обновит каталог. Загрузка новой версии из каталога плагинов займет около получаса и еще пару часов, прежде чем ваш блог WordPress обнаружит, что для плагина доступно обновление (если это было обновление вместо первого коммита) ,
Как только вы заметите обновление в каталоге плагинов, загрузите его и протестируйте еще раз, чтобы убедиться, что каждое изменение и исправление правильно включены в релиз. Расскажите своим друзьям и подписчикам о плагине, затем подождите, пока откликнется, и наблюдайте, как растет ваша статистика загрузки.
После того, как вы начнете получать отзывы, или если у вас есть собственные идеи по улучшению плагина, будет полезно выпускать новые версии каждые несколько недель или около того. Это покажет вашим пользователям, что ваш плагин все еще жив и находится в активной разработке, и увеличит их шансы потратить на это свое время.
