Содержание статьи
Замените хаотичный набор хуков и шаблонов строгой логикой, где каждый компонент четко описан и предсказуем. Хватит мириться с разрозненными функциями и глобальными переменными. Создавайте контроллеры, сервисы, модели и маршруты в привычной архитектуре, как в Laravel, но в среде, где все завязано на WP.
Роутинг больше не через add_action(\'init\', ...). Настройка путей осуществляется в одном месте, декларативно:
Route::get(\'контакты\', \'Контроллер@метод\');
Именование понятно. Передача параметров – без лишних массивов и условий. Хотите AJAX? Маршруты можно создавать и для него:
Route::post(\'обратная-связь\', \'ФормаController@отправить\');
Важно: больше никаких admin-ajax.php с его бесконечными проверками и глобальными конфликтами!
Шаблоны не привязаны к названию файлов. Хотите создать представление product.show? Просто верните его из метода контроллера:
return view(\'product.show\', [\'product\' => $product]);
Контекст изолирован. Доступ к данным – через DI-контейнер. Устали от глобального $post? Забудьте. Никаких side effects. Только явные зависимости и четкое разделение ответственности.
Библиотеки подключаются через Composer. Работа с WP API – через фасады. Пример:
use Post;
$post = Post::type(\'article\')->slug(\'новость-1\')->first();
Внимание! Работаете с ACF? Поля доступны как свойства. Никаких
get_field()!
Расширения и хуки изолированы. Хотите фильтр для заголовка страницы? Создайте сервис и зарегистрируйте хук там. Без хаоса в functions.php.
Единственная сложность – придется думать. Это не набор костылей, а целостная архитектура. Без дисциплины – не взлетит. Без понимания структуры ядра WP – утонете.
Помните: здесь нет магии. Только строгие правила и ожидаемое поведение. Больше контроля, меньше хаоса. Именно этого не хватает типичному WP-проекту.
Подключение и конфигурация сервисов через контейнер зависимостей Themosis
Регистрируйте сервисы строго в файле resources/config/bindings.php. Не в functions.php, не в плагинах. Только там. Почему? Контейнер грузит этот файл автоматически при каждом запросе, не нарушая архитектуру ядра.
Минимальный синтаксис регистрации выглядит так:
use App\\Services\\MyService;
app()->bind(\'my.service\', function () {
return new MyService();
});
Вам нужен singleton? Не переплачивайте за каждую инициализацию:
use App\\Services\\MyService;
app()->singleton(\'my.service\', function () {
return new MyService();
});
Не изобретайте велосипед с глобальными переменными. Контейнер уже решает проблему внедрения зависимостей по-человечески.
Важно! Всегда используйте интерфейсы вместо конкретных классов при внедрении зависимостей через конструкторы. Это избавит от боли при рефакторинге.
Пример внедрения сервиса в контроллер:
use App\\Services\\Contracts\\MyServiceContract;
class ExampleController
{
protected $service;
public function __construct(MyServiceContract $service)
{
$this->service = $service;
}
}
Контейнер автоматически сопоставит контракт с реализацией, объявленной в bindings.php:
use App\\Services\\Contracts\\MyServiceContract;
use App\\Services\\MyService;
app()->bind(MyServiceContract::class, MyService::class);
Вас пугает циклическая зависимость? Замените bind на singleton или instance. Избавьтесь от скрытых багов в логи.
Внимание! Не передавайте замыкания с логикой в контроллеры или модели. Внедрение сервисов через контейнер делает код тестируемым и масштабируемым.
Хотите отловить конфликты зависимостей заранее? Используйте метод app()->make() в PHPUnit тестах. Так вы гарантируете корректную сборку дерева зависимостей до момента релиза.
Для регистрации провайдера создайте класс в src/Providers:
namespace App\\Providers;
use Illuminate\\Support\\ServiceProvider;
class MyServiceProvider extends ServiceProvider
{
public function register()
{
$this->app->singleton(\'my.service\', function () {
return new \\App\\Services\\MyService();
});
}
}
Добавьте провайдер в resources/config/app.php в секцию providers:
\'providers\' => [
App\\Providers\\MyServiceProvider::class,
],
Так вы сохраняете порядок, модульность и контроль над зависимостями.
Что дальше? Используйте resolve() вместо прямого вызова new для получения экземпляров:
$service = resolve(\'my.service\');
Никаких хаотичных include и require. Контейнер решит все за вас.
Создание и использование собственных хелперов и фасадов в Themosis
Сначала пишите хелпер как обычный PHP-класс. Минимум лишнего. Только логика.
namespace App\\Helpers;
class StringHelper
{
public static function slugify(string $text): string
{
$text = preg_replace(\'/[^a-z0-9]+/i\', \'-\', trim(strtolower($text)));
return trim($text, \'-\');
}
}
Регистрация происходит в файле app/routes/web.php или в сервис-провайдере. Используйте singleton или bind для внедрения зависимостей через контейнер.
app()->singleton(\'stringhelper\', function() {
return new \\App\\Helpers\\StringHelper();
});
Фасад – всего лишь класс-обертка. Минимум магии. Наследуемся от Facade, указываем алиас.
namespace App\\Facades;
use Themosis\\Support\\Facades\\Facade;
class StringHelper extends Facade
{
protected static function getFacadeAccessor()
{
return \'stringhelper\';
}
}
Теперь можете вызвать метод фасада откуда угодно:
use App\\Facades\\StringHelper;
$slug = StringHelper::slugify(\'Пример строки для ЧПУ\');
Внимание! Не плодите фасады ради удобства. Злоупотребление приведет к спагетти-коду, отладка станет пыткой.
Хотите автозагрузку без ручной регистрации? Добавьте алиас в конфиг config/app.php. Фасады станут доступны автоматически.
\'aliases\' => [
\'StringHelper\' => App\\Facades\\StringHelper::class,
],
Особенность: фасады – это просто ленивый доступ к сервисам через контейнер. Они не создают новые экземпляры, если используете singleton. Ошибка – регистрировать как bind, если нужен единый объект.
Для хелперов без зависимостей используйте static методы. Для сложных сервисов – полноценный класс с конструктором и внедрением зависимостей через app()->make().
Важно помнить: фасады удобны для чтения кода, но скрывают зависимости. В тестах используйте прямое внедрение через конструктор, избегайте фасадов в контроллерах и сервисах.
И напоследок. Не забывайте про кеширование. Частые вызовы тяжёлых хелперов через фасад без кеша – прямой путь к деградации производительности. Лечится – локальным кешем или store() в сервисе.
Реализация middleware в Themosis для обработки запросов до и после контроллера
Используйте посредники для предварительной проверки прав доступа, фильтрации данных или внедрения кэширования. Регистрация происходит через метод middleware маршрута. Пример:
Route::get(\'dashboard\', \'DashboardController@index\')->middleware(\'auth\');
Класс посредника должен находиться в каталоге app/Http/Middleware и реализовывать метод handle. Пример минимальной реализации:
namespace App\\Http\\Middleware;
use Closure;
class AuthMiddleware
{
public function handle($request, Closure $next)
{
if (!is_user_logged_in()) {
wp_redirect(home_url(\'/login\'));
exit;
}
return $next($request);
}
}
Важный нюанс: можно модифицировать ответ после обработки контроллером. Просто оберните $next($request) дополнительной логикой:
public function handle($request, Closure $next)
{
$response = $next($request);
// Пост-обработка ответа
$response->setContent(str_replace(\'foo\', \'bar\', $response->getContent()));
return $response;
}
Цепочку посредников формируйте осознанно. Сначала авторизация, потом логгирование, затем кеширование. Ошибочный порядок – катастрофа.
Регистрация собственных посредников осуществляется в конфигурационном файле app/config/middleware.php:
return [
\'auth\' => App\\Http\\Middleware\\AuthMiddleware::class,
\'log\' => App\\Http\\Middleware\\LogMiddleware::class,
];
Важно помнить: глобальные посредники подключаются через ядро приложения, а не маршруты. Они влияют на каждый запрос без исключения.
Помните! Использование middleware без учёта порядка исполнения хуков WordPress приведёт к конфликтам с плагинами. Тестируйте интеграцию в боевых условиях.
Хотите тонко контролировать каждый байт ответа? Заворачивайте финальный рендеринг в middleware-обёртку. Это последний шанс перехватить данные перед клиентом.
И наконец, не забывайте: посредники не заменяют хуки. Они работают параллельно, как хирургический инструмент – не вместо, а рядом с традиционными фильтрами и действиями.