Повествование ведется от лица Пиппина Вильямсона.

На сайте WordPress.org присутствует очень много плагинов (более 30 000), и каждую неделю в хранилище присылают массу новых плагинов. То, о чем вы, возможно, даже не догадывались – подавляющее большинство этих плагинов изучают всего два человека, я (Пиппин Вильямсон) и Мика Ипстену. Это означает, что очередь плагинов, поставленных на проверку, быстро увеличивается, если один из нас отправляется в поездку или не способен проанализировать добавленные плагины по тем или иным причинам.

Мика и я видим, что большинство плагинов легко проходит данную проверку, и мы, безусловно, можем отметить некоторые тенденции, которые связаны с отклонением, одобрением и доработкой плагинов. Сегодня вечером, к примеру, я рассмотрел список из 30 плагинов. Из этих 30 плагинов где-то 15 были одобрены, 2 были отклонены, и оставшиеся были отклонены для доработки (плагин нуждается в небольшой модификации). Десять из 13 плагинов, отправленных на доработку, имели одну и ту же причину отклонения.

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

1. Всегда задавайте префиксы при объявлении ваших функций и классов

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

function my_plugin_settings() {
	// Register a setting here
}
add_action( 'admin_init', 'my_plugin_settings' );

Это обычно происходит вследствие того, что автор плагина копирует и вставляет некоторый код из учебных руководств, в которых описывается, как сохранить опции плагина.

Совет: ваш плагин никогда не должен иметь префикс my_.

Вместо префикса “_my” используйте уникальный префикс, который будет связан с вашим плагином. К примеру, если ваш плагин носит название «Easy Content Types», используйте префикс “_ect”.

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

2. Всегда отправляйте zip-файл плагина.

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

Хотите верьте, хотите нет, но мы действительно изучаем каждую строчку кода каждого плагина, который был передан в хранилище. Если мы не видим ваш код, мы не можем одобрить ваш плагин.

3. Не стоит намеренно запутывать код.

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

4. Не совершайте «звонков домой» без разрешения пользователей.

«Звонки домой» – это практика передачи данных с сайта, на котором стоит плагин, назад на серверы разработчиков. Многие разработчики делают это, чтобы лучше проанализировать все типы сайтов, на которых стоят их плагины, либо как способ получения списка сайтов, на которых используется их плагин.

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

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

5. Не загружайте свою собственную копию jQuery.

Плагины не должны загружать свои собственные версии jQuery или любых других скриптов, которые включены в ядро WordPress.

Если плагины, которые отправлены нам на рассмотрение, загружают свои собственные версии jQuery, или загружают библиотеки с любых внешних CDN, мы будем отправлять такие плагины на доработку.

6. Включайте качественный файл ReadMe.txt

Файл readme.txt – это файл, который отвечает за вывод страницы плагина на WordPress.org. Требование не самое сложное. Важно, чтобы плагин имел валидный readme.txt файл. Стандартный readme.txt вы можете найти по ссылке. Также вы можете проверить правильность своего readme по следующей ссылке.

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

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

Источник: pippinsplugins.com