03 Ноя
Создание собственного плагина для WordPress — это один из лучших способов глубже понять внутреннюю архитектуру CMS и создать инструмент, который расширяет её возможности. В этом материале рассмотрим первый шаг в разработке плагина с нуля: структуру файлов, базовые метаданные, систему безопасности и работу с хуками activation и deactivation.
Подготовка среды разработки
Для начала потребуется локальная установка WordPress. Это можно сделать с помощью Local WP, XAMPP, Laragon или любого другого окружения.
После установки убедитесь, что в файле wp-config.php включён режим отладки — это позволит видеть возможные ошибки:
define('WP_DEBUG', true);
Теперь WordPress будет отображать любые предупреждения или ошибки, что особенно полезно при разработке плагинов.
Создание структуры плагина
Все плагины WordPress хранятся в директории:
/wp-content/plugins/
Создайте в ней новую папку с уникальным именем, например:
alex-property/
Название папки будет служить идентификатором (slug) плагина, поэтому важно, чтобы оно не совпадало с уже существующими в официальном репозитории. Лучше заранее проверить уникальность через поиск на wordpress.org/plugins.
Внутри этой папки создаём основной файл плагина — с таким же именем, как и папка:
alex-property.php
Метаданные плагина
Чтобы WordPress “увидел” ваш плагин в админке, в начале основного файла нужно добавить блок с метаданными:
<?php
/**
* Plugin Name: Alex Property
* Plugin URI: https://example.com/alex-property
* Description: Система бронирования для аренды жилья.
* Version: 1.0
* Author: Alexandr Sochirca
* Author URI: https://genius.courses
* License: GPLv2 or later
* Text Domain: alex-property
*/
Эти комментарии интерпретируются WordPress как служебная информация. Без них плагин не появится в списке “Плагины → Установленные”.
Безопасность и защита от прямого доступа
Каждый файл плагина должен быть защищён от прямого открытия через браузер. Для этого добавляем проверку:
if (!defined('ABSPATH')) {
exit; // Защита от прямого доступа
}
Константа ABSPATH существует только при запуске WordPress. Если файл открыт напрямую — выполнение кода сразу прекращается.
Структура каталогов плагина
Чтобы проект был масштабируемым, стоит заранее продумать структуру. Пример базового каркаса:
alex-property/
│
├── alex-property.php # главный файл плагина
├── uninstall.php # выполняется при удалении плагина
├── assets/
│ ├── css/
│ │ ├── admin/
│ │ └── front/
│ ├── js/
│ │ ├── admin/
│ │ └── front/
│ └── images/
│
├── includes/ # PHP-классы и функционал
├── languages/ # языковые файлы (.mo, .po)
└── index.php # пустой файл для защиты директории
В каждом каталоге рекомендуется добавлять пустой index.php для предотвращения вывода списка файлов при прямом обращении к папке.
Создание хука активации и деактивации
WordPress предоставляет два специальных хука:
- register_activation_hook() — выполняется при активации плагина;
- register_deactivation_hook() — выполняется при его деактивации.
Создадим класс, который будет отвечать за эти события:
class Alex_Property {
public static function activate() {
// Например, обновим правила постоянных ссылок
flush_rewrite_rules();
}
public static function deactivate() {
// Очистим кэш ссылок при выключении плагина
flush_rewrite_rules();
}
}
Далее регистрируем хуки:
register_activation_hook(__FILE__, ['Alex_Property', 'activate']);
register_deactivation_hook(__FILE__, ['Alex_Property', 'deactivate']);
Теперь при активации и деактивации плагина WordPress автоматически вызовет соответствующие методы класса.
Хук удаления (uninstall)
Когда пользователь удаляет плагин через админку, может потребоваться выполнить дополнительные действия — например, очистить данные, созданные плагином.
Для этого создаётся файл uninstall.php в корне плагина:
<?php
if (!defined('WP_UNINSTALL_PLUGIN')) {
exit;
}
// Удаляем пользовательские таблицы, опции и записи
delete_option('alex_property_options');
WordPress автоматически вызовет этот файл при удалении плагина.
Что мы получили в итоге
На этом этапе создана базовая структура плагина с безопасностью и корректной обработкой хуков активации, деактивации и удаления.
Такой каркас является отправной точкой для дальнейшей разработки — например, создания кастомных пост-типов, административных страниц, REST API или интеграции с внешними сервисами.
Заключение
Мы подготовили основу для будущего WordPress плагина — с нуля до рабочей заготовки, готовой к расширению.
Следующий шаг — реализация функционала: регистрация кастомных постов, добавление форм бронирования и логики обработки данных.
В следующем уроке мы разберём, как организовать структуру классов, подключить стили и скрипты и начать реализацию логики для системы бронирования недвижимости.
