Как создать плагин для WordPress: руководство по разработке с нуля

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

Когда нужен собственный плагин

Прежде чем писать код, проверьте, нет ли готового решения. Но если для задачи вы подключаете три-четыре плагина, которые частично пересекаются, а нужна лишь часть их функций, свой плагин почти всегда выгоднее: он загружает только то, что нужно, и не расширяет поверхность атаки. Типичные примеры: бронирование с нестандартной логикой, интеграция с внешней CRM, расчёт стоимости, лицензирование, собственные типы записей. Заказать такую работу можно в рамках разработки плагинов WordPress.

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

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

Структура плагина и главный файл

Минимальный плагин — это папка в wp-content/plugins с главным PHP-файлом. В начале файла размещается заголовочный комментарий: Plugin Name, Description, Version, Author, Text Domain и Requires PHP. Именно по нему WordPress распознаёт плагин. Дальше рекомендуем сразу закладывать порядок:

• главный файл только подключает код и регистрирует хуки активации и деактивации;
• классы лежат в отдельной папке includes и загружаются автозагрузчиком с пространствами имён;
• админ-часть, публичная часть и REST-маршруты разделены по классам;
• стили, скрипты и переводы хранятся в assets и languages.

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

Версии PHP и WordPress, которые вы поддерживаете, укажите в заголовке (Requires at least и Requires PHP): WordPress не позволит установить плагин в неподходящей среде, и вы избежите «белого экрана» у клиентов. Хуки активации и деактивации (register_activation_hook и register_deactivation_hook) используйте для создания таблиц, значений по умолчанию и снятия расписаний. Данные пользователя при деактивации не удаляйте: чистка допустима только при удалении плагина.

Хуки: как плагин встраивается в WordPress

Вся архитектура WordPress построена на хуках двух видов. Экшены (add_action) выполняют код в определённый момент: при загрузке админки, сохранении записи, выводе подвала. Фильтры (add_filter) принимают значение, изменяют его и возвращают обратно: заголовок, содержимое, список меню. Никогда не правьте файлы ядра или темы: любое изменение через хук переживёт обновление.

Хорошая привычка: регистрируйте хуки в конструкторе или методе init класса и подписывайтесь на самое позднее событие, на котором код уже работает. Загружайте скрипты и стили только на тех страницах, где они нужны, через wp_enqueue_script и wp_enqueue_style. Так плагин не замедляет остальной сайт. Подробнее в разделе документации о хуках.

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

Безопасность: три правила, которые нельзя пропускать

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

1. Валидация и санитизация входных данных. Любое значение из формы, URL или API очищайте функциями sanitize_text_field, absint, sanitize_email и аналогами.
2. Экранирование при выводе. Всё, что выводится в HTML, проходит через esc_html, esc_attr, esc_url или wp_kses.
3. Nonce и проверка прав. Формы и AJAX-запросы защищаются одноразовыми токенами, а действие дополнительно проверяется через current_user_can.

Для работы с базой данных используйте wpdb->prepare, а не конкатенацию строк. Принципы защиты подробно описаны в разделе Plugin Security официальной документации.

Частые ошибки новичков

• обращение к $_POST и $_GET без санитизации и проверки nonce;
• подключение скриптов тегом script в шаблоне вместо wp_enqueue_script;
• запросы к базе в цикле вместо одного запроса с выборкой;
• большие массивы в автозагружаемых опциях, которые читаются при каждой загрузке страницы;
• отсутствие префиксов у функций, классов и опций;
• вывод данных через echo без экранирования.

REST API, настройки и данные

Для собственных настроек используйте Settings API: он берёт на себя сохранение, санитизацию и вывод ошибок. Для обмена данными с интерфейсом и внешними сервисами регистрируйте маршруты через register_rest_route с обязательным permission_callback. Для хранения сложных данных заводите собственную таблицу при активации и версионируйте схему, чтобы обновления плагина могли её мигрировать. При удалении плагина предусмотрите файл uninstall.php, который чистит за собой настройки.

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

Следите и за производительностью: не выполняйте тяжёлые запросы на каждой загрузке страницы, кэшируйте результаты через Transients API или объектный кэш, фоновые задачи выносите в WP-Cron или очередь, а плагин проверяйте инструментами вроде Query Monitor. Плагин, который замедляет сайт, удаляют первым, и подробнее о влиянии на скорость мы писали в статье «Как ускорить WordPress».

Тестирование, релиз и обновления

• включён WP_DEBUG, журнал чист от предупреждений и устаревших функций;
• код проверен по стандартам WordPress Coding Standards через PHPCS;
• плагин протестирован на минимальной и на последней поддерживаемой версиях PHP;
• проверены мультисайт, деактивация и полное удаление без ошибок;
• переводимые строки обёрнуты в функции локализации.

Перед релизом включите WP_DEBUG и проверьте журнал на предупреждения, пройдитесь по сценариям на последних версиях WordPress и PHP, проверьте совместимость с популярными конструкторами страниц. Для критичной логики пишите автотесты. Версионируйте плагин по semver и ведите changelog.

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

Поделиться:XLinkedInWhatsApp