У WordPress есть специальная сборка на базе Laravel, которая называется Roots (Bedrock + Acorn). Это такой тюнинг движка WordPress под большие проекты, с командной работой и тонким контролем логики. Но всем ли нужны такие гонки?
Типовой WordPress — это content-driven + low-code: максимум работы выполняется через CMS, плагины и простые автоматические обновления, а собственного кода минимум.
Roots / Bedrock — это условный «Laravel + WordPress», то есть code-driven подход: зависимости фиксируются в Composer, изменения проходят через Git, CI, автотесты и управляемый деплой. Он даёт максимальный контроль, но требует более высокой инженерной культуры, постоянного внимания к коду и обычно оправдан для проектов с бюджетом разработки и поддержки от 1 млн ₽ в месяц.
Что такое Roots (Laravel + WordPress)?
Когда говорят о Roots, обычно имеют в виду не один продукт, а стек:
- Bedrock — структура проекта и управление зависимостями через composer.json;
- Acorn — интеграция компонентов Laravel в WordPress: контейнер зависимостей, сервис-провайдеры, Artisan, Blade и другие инструменты;
- Sage — стартовая тема с современным фронтенд-стеком на базе Tailwind CSS & FSE WP (+ поддержка theme.json);
- Trellis — инфраструктура и деплой.
Два подхода к управлению сайтами на WordPress
Но сравнивать эти варианты как «плохой старый WordPress» и «хороший современный Roots» неправильно. Это две разные операционные модели. Выбор между ними зависит от характера проекта, роли контента и кода, бюджета и инженерной зрелости команды.
Подход 1. Типовой WordPress: content-driven + low-code
В типовой сборке ядро, плагины и темы управляются прежде всего через сам WordPress. Администратор обновляет их через панель управления, устанавливает расширения в пару кликов и собирает большую часть функциональности из готовых компонентов.
Центр проекта здесь — контент и бизнес-задачи, а не кодовая база. Страницы, публикации, формы, SEO и простые интеграции меняются через CMS. Обновления ядра и проверенных плагинов можно автоматизировать штатными средствами, а разработчика подключать только для нестандартных доработок.
Это не «упрощённая» или непрофессиональная версия WordPress, а рациональная low-code модель. Она особенно эффективна, когда:
- сайт в основном публикует и продвигает контент;
- функциональность закрывается зрелыми плагинами;
- изменения должны быстро вносить редакторы и маркетологи;
- нет отдельной продуктовой команды и постоянного бюджета на разработку;
- стоимость инженерного процесса будет выше риска от типовых обновлений.
Но у такой свободы есть цена:
- состояние продакшена постепенно расходится с локальной средой;
- непонятно, кто и когда обновил плагин;
- откат сводится к восстановлению бэкапа;
- нельзя нормально проверить обновление до того, как оно уже попало на боевой сайт;
- одинаково развернуть сайт на staging и production сложнее.
Ничего критичного в этом нет, пока сайт простой, один и его обслуживает один человек. Проблемы появляются, когда есть команда, несколько окружений, интеграции, WooCommerce или регулярные доработки.
Подход 2. Roots: «Laravel + WordPress» и code-driven разработка
Roots имеет смысл воспринимать как попытку применить к WordPress инженерные практики из экосистемы Laravel и современной backend-разработки. WordPress остаётся CMS и контентным ядром, но сам проект управляется как приложение.
Главное изменение в подходе даёт Bedrock. Он переносит WordPress из модели «зайти в админку и поставить плагин» в модель «описать зависимости в коде и воспроизводимо развернуть проект».
Bedrock использует Composer для управления зависимостями. В зависимости попадают не только PHP-библиотеки, но и само ядро WordPress, плагины и при необходимости темы. Это прямо предусмотрено в документации Roots. Bedrock: Composer
Например:
composer require wp-plugin/akismet
composer require roots/wordpress -W
В composer.json описывается, что требуется проекту, а composer.lock фиксирует точные версии, с которыми он был проверен. На сервере деплой устанавливает именно этот набор.
В результате WordPress становится ближе к Laravel-, Symfony- или Node-проекту:
Git → composer.lock → CI → staging → production
Не «на проде кто-то обновил плагин», а «обновление прошло ревью, тесты и было задеплоено».
Bedrock также меняет структуру каталогов: публичный web-root — web/, ядро обычно устанавливается в web/wp, а прикладная часть сайта находится в web/app. Конфигурация берётся из переменных окружения, а не хранит пароли и URL в репозитории. Bedrock: установка
Как обновляются ядро и плагины: автоматом или через код
Обновления — одно из самых наглядных различий между двумя подходами. В типовом WordPress они являются встроенной функцией CMS. В Roots обновление становится изменением кодовой базы: его нужно выполнить вручную через Composer либо построить отдельную инженерную автоматизацию.
Типовой WordPress: штатные автообновления
В обычном WordPress ядро, темы и плагины могут обновляться прямо из административной панели. Для доверенных компонентов можно включить автоматические обновления — CMS сама скачает и установит новую версию на сервер.
Типовой процесс выглядит просто:
- WordPress обнаруживает новую версию.
- Обновление устанавливается автоматически или одним кликом в админке.
- Администратор проверяет сайт; при проблемах используется резервная копия или механизм отката.
Такой подход требует минимального участия разработчика и хорошо соответствует content-driven + low-code модели. Его слабое место — обновление сразу изменяет состояние конкретного сайта, часто без предварительной проверки на staging и автотестов.
Roots / Bedrock: вручную или через сложную автоматизацию
В Roots-проекте ядро и плагины являются Composer-зависимостями. Поэтому их версии меняются не через админку WordPress, а в composer.json и composer.lock.
В актуальном Bedrock по умолчанию отключены фоновые обновления WordPress и модификация файлов через админку:
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
Config::define('DISALLOW_FILE_MODS', true);
Базовый вариант — обновлять зависимости вручную:
- Разработчик запускает обновление нужного пакета через Composer.
- Изменения
composer.jsonиcomposer.lockпопадают в Git. - Команда проверяет их локально или на staging.
- После ревью новая версия разворачивается на production.
Это даёт контроль, но требует регулярного внимания разработчика. Чтобы убрать ручную рутину, нужна более сложная автоматизация:
- Renovate или Dependabot обнаруживает обновление ядра или плагина.
- Бот создаёт pull request с изменениями
composer.jsonиcomposer.lock. - CI запускает линтеры, автотесты и smoke-проверки.
- После успешных проверок PR мержится вручную либо автоматически.
- Pipeline разворачивает изменения на staging или production.
Roots рекомендует Dependabot и Renovate для автоматизации обновлений Composer-зависимостей; сам репозиторий Bedrock использует Renovate для версий WordPress. Документация Roots об обновлениях
Не стоит одновременно управлять одними компонентами через Composer и обновлять их из админки. Иначе WordPress изменит файлы только на конкретном сервере, а composer.lock останется старым. Следующий деплой восстановит версии из lock-файла, и production начнёт расходиться с репозиторием.
Итог: в типовом WordPress обновления простые и могут работать полностью автоматически; в Roots они выполняются вручную через код либо автоматизируются с помощью более дорогой цепочки из dependency-бота, CI, тестов и деплоя.
Два подхода в сравнении
| Вопрос | Типовой WordPress | Roots / Bedrock |
|---|---|---|
| Основная модель | Content-driven + low-code | Code-driven |
| Центр управления и контроля | CMS и админ-панель | Репозиторий и pipeline |
| Основные участники | Контент-команда, маркетолог, администратор | Команда разработки и DevOps |
| Установка плагина | Через админку | Через Composer и Git |
| Версия ядра | Та, что сейчас на сервере | Зафиксирована в composer.lock |
| Обновление | Простое или автоматическое обновление в CMS | PR → автотесты → staging → деплой |
| Откат | Бэкап или ручная работа | Возврат к предыдущему релизу |
| Настройки | Часто в wp-config.php на сервере | Переменные окружения и конфиг в Git |
| Собственный код | Минимальный, точечный | Существенная часть продукта |
| Разработка | Возможны расхождения с production | Среды собираются из тех же зависимостей |
| Права редактора | Может управлять плагинами и контентом | Работает с контентом, но не с кодом |
| Требования к процессу | Регламент обновлений и бэкапы | Git-flow, CI/CD, code review и автотесты |
| Экономика | Подходит для ограниченного бюджета | Обычно оправдан при бюджете от 1 млн ₽ в месяц |
Где Roots подходит лучше всего
Roots оправдан, если WordPress — это продукт или часть продукта, а не просто CMS. Это сценарий, где стоимость ошибки, сложность интеграций и объём постоянной разработки уже требуют максимального контроля.
Плюсы
- Воспроизводимость. Любой разработчик или сервер получает один и тот же набор ядра и плагинов.
- Контроль изменений. Видно, какая версия обновилась, кто одобрил PR и что именно попало в релиз.
- Безопаснее деплой. На production можно запретить установку файлов из админки и оставить минимум прав.
- Предсказуемый откат. Если обновление сломало интеграцию, возвращается предыдущий релиз, а не вручную перебираются файлы на сервере.
- Нормальная работа с окружениями. Staging и production получают одинаковый код, но разные секреты, домены и подключения к базе.
- Подходит для инженерного процесса. Линтеры, статический анализ, тесты, deployment preview и dependency-боты становятся частью обычного pipeline.
Минусы
- Порог входа выше. Нужны Composer, Git и хотя бы базовый CI/CD.
- Админка теряет роль магазина плагинов. Редактор не сможет самостоятельно поставить плагин «на попробовать».
- Не все коммерческие плагины удобно пакуются. Иногда нужно настраивать приватный Composer-репозиторий, скачивание архива по лицензии или отдельный механизм поставки.
- Обновления нельзя воспринимать как бездумную рутину. Особенно для WooCommerce, платёжных модулей, кешей, мультиязычности и SEO-плагинов.
- База данных и медиа не становятся кодом. Bedrock дисциплинирует файловую часть проекта, но миграции, пользовательские данные и uploads всё равно требуют отдельных бэкапов и процесса переноса.
Хорошие сценарии для Roots:
- высоконагруженный корпоративный портал или медиа-платформа;
- крупный интернет-магазин на WooCommerce;
- сервис с личным кабинетом, API и внешними интеграциями;
- проект, над которым постоянно работают несколько разработчиков;
- агентство с унифицированной платформой и зрелым процессом эксплуатации;
- система, где критичны staging, наблюдаемость, контроль изменений и быстрый откат;
- проект с ежемесячным бюджетом на разработку и поддержку примерно от 1 млн ₽.
Порог в 1 млн ₽ — не техническое требование, а экономический ориентир. Roots начинает окупаться, когда проект может постоянно финансировать не только новые функции, но и инфраструктуру, code review, CI/CD, автотесты, обновление зависимостей и устранение технического долга.
Без этой культуры Bedrock легко превращается в усложнённую структуру каталогов. Сам по себе Composer не обеспечивает качество. Команда должна регулярно обслуживать pipeline, разбирать обновления, поддерживать тесты и не допускать обхода процесса ручными изменениями на production.
Где лучше типовой WordPress
Типовая сборка разумнее, если сайт работает прежде всего как контентная и маркетинговая система:
- сайт-визитка, блог, каталог или сайт локального бизнеса;
- контент регулярно меняют маркетолог, редактор или владелец;
- функциональность в основном покрывают готовые плагины;
- подходят простые автоматические обновления с резервным копированием;
- собственного кода мало, а изменения делаются эпизодически;
- нет постоянной команды, CI/CD и бюджета на их поддержку;
- скорость запуска и стоимость владения важнее максимального контроля.
В этом сценарии возможность самостоятельно менять контент, ставить проверенные расширения и включать автообновления — не недостаток, а преимущество. Главное — ограничить набор плагинов, настроить бэкапы, безопасность и мониторинг.
Не стоит внедрять Roots ради самого факта использования современного стека. Composer не делает сайт лучше автоматически; он делает процесс более строгим. Если процесса вокруг проекта нет, строгость начинает ощущаться как лишняя бюрократия.
Практическая рекомендация
Выбирать нужно не стек сам по себе, а модель эксплуатации.
Выбирайте типовой WordPress, если проект content-driven:
- основная ценность создаётся контентом и маркетингом;
- нужен low-code и минимальный объём собственного кода;
- обновления можно выполнять автоматически или по простому регламенту;
- сайт должен обслуживаться без постоянного участия разработчиков;
- бюджет лучше направить на контент, SEO, рекламу и развитие продукта.
Выбирайте Roots / Bedrock, если проект code-driven:
- WordPress является частью сложного приложения;
- изменения кода происходят постоянно;
- цена ошибки на production высока;
- команда уже умеет работать с Git, Composer, CI/CD и staging;
- есть ресурсы на code review, автотесты, мониторинг и технический долг;
- бюджет разработки и поддержки составляет ориентировочно от 1 млн ₽ в месяц.
Итоговая формула проста: типовой WordPress оптимизирует скорость работы с контентом и стоимость владения; Roots оптимизирует контроль над кодом и предсказуемость разработки. Это не уровни качества, а разные решения для разных стратегий.
