Свой плагин WordPress можно начать с отдельной папки и одного PHP-файла с заголовком Plugin Name. Дальше добавьте небольшой обработчик через hook WordPress, активируйте плагин на тестовом сайте и проверьте результат. Пример ниже не меняет данные и показывает уведомление только администраторам; пример требует проверки, готовым протестированным продуктом он не является.
Когда писать собственный плагин
Собственный код уместен, если требуется небольшая повторяемая функция, интеграция с внутренней системой или независимость от темы. Если задача целиком решается надёжным поддерживаемым расширением, сначала оцените готовое решение: собственный плагин нужно обновлять, тестировать и защищать в течение всего жизненного цикла.
Функции, которые должны переживать смену темы, разумно размещать в плагине, а не в functions.php активной темы. Но для чисто визуальной правки отдельный плагин необязателен.
Минимальная структура проекта
Создайте в тестовой установке WordPress такой каталог:
wp-content/
plugins/
wpr-starter-demo/
wpr-starter-demo.phpИмя папки должно быть уникальным в контексте сайта. Не копируйте демонстрационный код в системные файлы WordPress. Единственный файл с обязательным заголовком плагина — wpr-starter-demo.php.
Минимальный код с action hook
Следующий пример подключается к admin_notices и выводит безопасное текстовое уведомление только пользователю с правом manage_options. В нём нет записи в базу или пользовательских входных данных.
Пример требует проверки на вашей версии WordPress, PHP, теме и сочетании активных плагинов. Он предназначен только для staging.
<?php
/**
* Plugin Name: WPR Starter Demo
* Description: Minimal admin notice for a staging site.
* Version: 0.1.0
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_action( 'admin_notices', 'wpr_starter_demo_admin_notice' );
function wpr_starter_demo_admin_notice() {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
$message = 'Тестовый плагин активен.';
echo '<div class="notice notice-info"><p>'
. esc_html( $message )
. '</p></div>';
}Заголовок позволяет WordPress обнаружить плагин, add_action() регистрирует обработчик, current_user_can() ограничивает показ, esc_html() экранирует текст при выводе. Для такого минимального примера activation/deactivation hooks не обязательны: устанавливать или удалять данные ему нечего.
Риск: синтаксическая ошибка PHP или конфликт имён функций может привести к критической ошибке. Проверка: плагин обнаружен в списке, успешно активируется, администратор видит уведомление, а пользователь без необходимых прав — нет. После деактивации уведомление исчезает.
Как установить и проверить на staging
- Сохраните PHP-файл в кодировке UTF-8 без нежелательного вывода до открывающего PHP-тега.
- Поместите папку в
wp-content/plugins/на тестовом сервере или используйте пакет установки, подготовленный по правилам WordPress. - Откройте Плагины, найдите WPR Starter Demo и активируйте.
- Зайдите в админку под тестовым администратором и под пользователем без прав администратора; проверьте различие.
- Деактивируйте плагин и убедитесь, что уведомление не появляется. Просмотрите PHP error log.
Риск: тест под одним аккаунтом не подтверждает корректность разграничения прав. Проверка: выполнены отдельные тесты под ролями, а файлы и БД не изменены неожиданным образом.
Безопасность: capabilities, nonce, sanitization, escaping
В демонстрации есть лишь вывод фиксированной строки. Для настоящего плагина при добавлении форм, AJAX и обработчиков сохранения появятся дополнительные требования:
- Capabilities: проверяйте
current_user_can()перед привилегированной операцией. - Nonce: используйте механизм nonce для защиты соответствующего действия от CSRF; nonce не заменяет проверку прав пользователя.
- Sanitization: приводите недоверенный ввод к допустимому формату, например текст через
sanitize_text_field()там, где это уместно. - Escaping: экранируйте данные непосредственно при выводе с учётом контекста (
esc_html(),esc_attr(),esc_url()и другие). - Хранение: определите необходимость настройки/таблицы, миграцию, удаление данных и правила обработки персональной информации.
Риск: обработчик с одним nonce, но без capability-check, остаётся уязвимым по модели прав доступа. Проверка: тесты на отсутствие прав, неверный nonce, неожиданный ввод и безопасный вывод включены в план до разработки производственных функций.
Если код помогает писать coding agent
Сформулируйте задачу для Codex или другого агента так: «Создать отдельный WordPress-плагин с одной указанной функцией; не изменять ядро и тему; перечислить затронутые файлы; для операций записи проверять права и nonce; не добавлять зависимостей без согласования; вернуть diff, список рисков и команды проверки».
Просмотрите diff: нет ли скрытых сетевых вызовов, новых привилегий, обращения к секретам, чрезмерно широких хуков, опасной работы с SQL или обработки пользовательского ввода без проверок. Отсутствие замечаний агента не считается тестированием.
Риск: принятие сгенерированного кода без ревью может внести ненужные зависимости и уязвимости. Проверка: каждый изменённый файл понятен, код проходит синтаксическую проверку в выбранном окружении, ручные и автоматические тесты реально выполнены и их результаты зафиксированы.
Чек-лист перед применением на рабочем сайте
- Название, slug, глобальные функции и константы не конфликтуют с установленными расширениями.
- Есть сценарий отката и проверенная резервная копия.
- Задокументированы поддерживаемые окружения; совместимость не объявляется без реальных испытаний.
- Проверены роли, ввод, вывод, формы и критичные бизнес-сценарии.
- Не включены отладочные сообщения, секреты и ненужный сбор данных.
- Пройдена проверка diff и результата на staging.
Первоисточники: WordPress Plugin Basics, Plugin Handbook, Nonces, Sanitizing Data и Escaping Data.
Источник: https://developer.wordpress.org/plugins/plugin-basics/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.