Рекомендации для успешного размещения вашего плагина в хранилище WordPress.org

Первое действие – создать SVN-репозиторий через форму на make.wordpress.org/plugins. После ручной модерации приходит письмо. Не приходит? Проверьте папку спама. Без подтверждения доступа дальше двигаться бессмысленно.

Проект должен содержать файл readme.txt в строгом формате, принятом WordPress. Отсутствие валидного тега Stable tag приведет к тому, что в каталоге будет пусто. Хотите тестировать до релиза? Используйте trunk, но не публикуйте туда сырой код.

Важно помнить:

В загружаемом архиве запрещено наличие сторонних фреймворков, рекламных SDK и шпионских скриптов. Их наличие – гарантированный отказ.

Проверка лицензии – обязательна. Все файлы обязаны быть под GPL или совместимой лицензией. Нет лицензии – отказ. Лицензия не в корне – отказ. Копия GPL – да, требуется. Считаешь, что этого не нужно? Ошибаешься. Категорически.

Загрузка осуществляется по SVN-протоколу. SSH не поддерживается. GitHub не поможет. Используй следующую команду:

svn checkout https://plugins.svn.wordpress.org/название-директории локальная-папка

После этого перенеси файлы в trunk, проставь корректные теги, добавь changelog в readme.txt, затем коммить и пушь:

svn add * --force
svn commit -m \"Initial commit\"

Внимание!

Если после коммита вы не видите расширение в каталоге – проверьте, установлен ли тег и присутствует ли файл plugin-name.php с корректным заголовком.

Нет иконки? Значок по умолчанию – серый. Добавь изображение assets/icon-128x128.png. Используй SVG? Зря. Не поддерживается. Скриншоты называются строго screenshot-1.png, screenshot-2.png и так далее. Ошибешься в имени – не отобразится.

Модераторы вручную проверяют первые загрузки. Спешишь? Потеряешь время. Нарушишь правило – забанят. Используй plugincheck до отправки.

Поддержка старых версий WordPress? Укажи Requires at least и Tested up to. Пропустишь? Каталог обозначит расширение как неподдерживаемое. Потенциальные пользователи пройдут мимо.

Будь готов к неожиданному – модераторы могут удалить публикацию без объяснений. Есть вопросы? Пиши на plugins@wordpress.org. Слишком много жалоб – и твой проект исчезнет. Без права восстановления.

Как подготовить структуру плагина и файлы для отправки

Сразу – без readme.txt ничего не будет. Файл обязателен. Секция == Changelog == должна быть. Формат строго markdown-совместимый. Перепроверь: нет HTML-тегов, нет непарных заголовков, нет самопальных символов форматирования.

Главный PHP-файл обязан называться так же, как и каталог с кодом. В нём – заголовок с метаинформацией. Пример:


/*
Plugin Name: Example Tool
Plugin URI: https://example.com/tool
Description: Делает что-то конкретное
Version: 1.0.0
Author: Имя
License: GPLv2 or later
*/


Далее – структура. Простейшая допустимая:


/example-tool/
  example-tool.php
  readme.txt
  /assets/
    banner-772x250.jpg
    icon-128x128.png
  /languages/
    example-tool-ru_RU.po
    example-tool-ru_RU.mo


Каталог /assets/ – не внутри, а рядом с основными файлами. Он нужен для обложек и иконок. Размеры строго по инструкции. Не перепутай: баннер – 772×250, иконка – 128×128 или 256×256.

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

Внимание! Без локализации строк через __() или _e() модераторы отклонят проект.

Текстовый домен обязан совпадать с названием директории. Не plugin-text-domain, не my-cool-tool, а ровно как в названии папки.

Лицензия – только GPL. Указание её в комментарии – не формальность. Файлы сторонних библиотек тоже должны быть с открытыми лицензиями. Не уверен – не включай.

Подгрузка скриптов – только через wp_enqueue_script(). Никаких прямых вставок через <script>. Названия хендлеров уникальны. Очевидное script.js не прокатит, делай example-tool-admin-script и подобное.

Важно помнить: каждый файл должен проходить проверку линтером. Избавься от предупреждений до последнего байта.

Не добавляй .zip. Архив создаёт SVN. Твоя задача – структура, читабельность, валидность. Всё. Описание, лицензии, языковые файлы, стили, скрипты – в нужных местах и в нужном виде. Не усложняй, не выдумывай. Просто чистая структура, как на ладони.

Что указать в readme.txt, чтобы пройти модерацию

1. Правильная структура

В файле readme.txt необходимо строго соблюдать формат. Начни с правильных мета-данных. Это должны быть строки, описывающие версию, описание, авторство и другие параметры. Пример:

=== Название плагина ===
* Уникальное название плагина
* Версия: 1.0.0
* Автор: твое имя или псевдоним
* Авторский сайт: твой сайт или GitHub
== Описание ==
Это краткое описание плагина.

Здесь все должно быть по полочкам. Никаких лишних символов или комментариев. Просто четко и ясно.

2. Описание функционала

Подробное описание работы расширения не менее важно. Опиши ключевые функции и особенности плагина. Это не просто набор строк, это объяснение, что именно твой инструмент делает, чем он полезен. Не ограничивайся шаблонами. Покажи реальную ценность!

== Описание ==
Этот плагин добавляет функционал…
- Добавление виджетов для отображения…
- Интеграция с … API
- Настройка шаблонов…

Кстати, никакого хлама! Если функционал плагина ограничен, не надо писать, что он делает \»все и сразу\». Будь честным.

3. Инструкции по установке и настройке

Тебе нужно объяснить, как установить и настроить твой продукт. Важно помнить, что если тут будут ошибки или неясности, плагин может не пройти проверку. Вот пример:

== Установка ==
1. Скачай архив с плагином
2. Разархивируй и загрузи в папку wp-content/plugins/
3. Активируй плагин через админку WordPress
4. Перейди в раздел настроек и выбери нужные опции

Не забудь про проблемы совместимости с различными версиями WP. Поддержи его установку в разных сценариях.

4. Лицензия и условия

Укажи, под какой лицензией распространяется твой код. Это стандарт: GPLv2 или выше. Важно! Если ты использовал сторонние библиотеки или ресурсы, не забудь их перечислить и указать соответствующие лицензии.

== Лицензия ==
Этот плагин распространяется под лицензией GPL v2 или выше.

5. Скриншоты и демонстрация

Скриншоты нужны, чтобы показать пользователю, как плагин выглядит в интерфейсе. Никаких грубых, невнятных изображений. Все должно быть четким, с понятным интерфейсом. Но помни! Платформа запрещает добавлять изображения с логотипами или рекламой. Внимание! Не забывай, что в readme.txt указывается путь к изображениям:

== Скриншоты ==
1. Снимок_экрана_1.jpg
2. Снимок_экрана_2.jpg

6. Чистота кода

Никто не будет долго мучиться с твоим кодом. Даже если функционал идеален, а код грязный – тебя заблокируют. Проверяй свою программу на соответствие стандартам кодирования WP. Если файлы содержат дублирующийся код или нестандартные структуры, плагин не пройдет. Внимание! Код должен быть аккуратным, и каждая строка – на своем месте.

7. Чистота описания

В текстах избегай ненужных слов и «воды». Пишем только по делу. Пример плохого описания:

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

Читаем: «мы», «работать», «повысьте», «новый уровень» – что это вообще? Это клише, которое не даст ничего полезного. Фокусируйся на том, что плагин реально делает. Всё.

Важно! Подробные описания и примеры функций ускоряют процесс проверки и принятия плагина.

8. Обновления и поддержка

Укажи, что твой проект регулярно обновляется и что поддержка будет предоставляться. В файле readme.txt это тоже обязательно:

== Поддержка ==
Для получения помощи, пишите нам на support@вашсайт.com.
Мы стараемся отвечать в течение 24 часов.

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

Помните! Чем более понятен и детализирован описание, тем выше шанс, что твой продукт пройдет проверку без проблем.

Не забывай: проверка – это не просто формальность, а процесс, который требует четкости, точности и внимательности. Следуя этим рекомендациям, ты минимизируешь риск отказа и увеличишь шансы на успех.

Как загрузить плагин в репозиторий через SVN

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

Важно! Убедитесь, что у вас установлена последняя версия SVN. Проверить можно с помощью команды svn --version. Если версия устарела, обновите её.

После того как вы скачали репозиторий на свой компьютер, создайте папку для проекта. Это будет ваша рабочая директория. Скопируйте файлы вашего проекта в эту папку. Не забудьте, что структура папок должна соответствовать стандарту – trunk, tags, branches.

Перейдите в папку trunk, где будут храниться основные файлы. Используйте команду svn add для добавления новых файлов. Пример:

svn add file1.php file2.css

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

После добавления файлов, перед тем как отправить изменения, выполните команду svn commit, чтобы сохранить изменения в репозитории. Пример:

svn commit -m \"Initial commit of plugin files\"

Внимание! Подготовьте описание изменений. Оно должно быть информативным и ясным. Описание должно содержать подробности, связанные с тем, что именно изменилось или добавилось в проект.

После того как вы отправили изменения, запустите команду svn update, чтобы синхронизировать вашу локальную версию с репозиторием. Это позволит вам убедиться, что все файлы синхронизированы и обновления не конфликтуют с другими версиями.

Когда ваш проект готов, не забывайте проверять статус проекта, используя команду svn status. Это поможет вам отследить любые изменения в файлах и убедиться, что всё правильно загружено.

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

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