Roots Bedrock или стандартный WordPress: выбор для команды

При одиночной разработке структура WordPress редко становится главным фактором: сайт можно развернуть из архива, настроить через wp-config.php и обновлять из панели администратора. В командной работе требования меняются. Разработчикам нужно одинаковое окружение, предсказуемый состав зависимостей, безопасное хранение секретов и понятный процесс доставки изменений на тестовый и рабочий серверы.

Roots Bedrock решает эти задачи за счёт Composer, переменных окружения и отделения публичного каталога от остальных файлов проекта. Стандартный WordPress проще поддерживается большинством хостингов и привычнее администраторам, но без дополнительных соглашений хуже контролирует изменения в ядре, плагинах и конфигурации.

Выбор между ними — не спор между «современным» и «устаревшим» WordPress. Это выбор модели эксплуатации. Bedrock подходит, если сайт рассматривается как программный продукт с Git, проверяемыми сборками и развёртыванием по окружениям. Стандартная структура удобнее, если приоритетом остаются совместимость, простое администрирование и возможность работать без Composer на сервере.

Чем Bedrock отличается от обычной установки WordPress

Стандартная установка обычно размещает ядро, wp-content, wp-config.php и входной index.php в каталоге, который веб-сервер публикует для посетителей. Упрощённо она выглядит так:

public_html/
├── wp-admin/
├── wp-content/
│   ├── plugins/
│   ├── themes/
│   └── uploads/
├── wp-includes/
├── wp-config.php
└── index.php

Такая структура поддерживается установщиками хостингов, панелями управления, системами резервного копирования и инструментами обслуживания WordPress. Большинство тем и плагинов тестируются прежде всего в этом окружении.

Bedrock меняет организацию проекта. Ядро WordPress становится Composer-зависимостью, каталог wp-content переименовывается в app, конфигурация выносится в отдельную директорию, а публичной остаётся только папка web:

project/
├── composer.json
├── composer.lock
├── config/
│   ├── application.php
│   └── environments/
├── vendor/
└── web/
    ├── app/
    │   ├── mu-plugins/
    │   ├── plugins/
    │   ├── themes/
    │   └── uploads/
    ├── wp/
    ├── wp-config.php
    └── index.php

Каталог web становится document root, то есть корнем сайта с точки зрения Apache, Nginx или другого веб-сервера. Файлы Composer, основная конфигурация и служебные зависимости располагаются выше публичного уровня. Сам WordPress находится в web/wp, а пользовательский контент — в web/app.

Это не отдельная CMS и не форк WordPress. Внутри продолжает работать обычное ядро, а темы и плагины используют стандартные API. Отличия сосредоточены вокруг управления кодом, конфигурацией и серверной структурой.

Composer: главное практическое различие

В Bedrock Composer является основой проекта. Через composer.json команда описывает версию ядра, плагины, темы и PHP-библиотеки. В composer.lock фиксируются точные версии разрешённых зависимостей. Если этот файл хранится в Git, разработчики, CI-система и сервер развёртывания могут получить одинаковый набор пакетов.

Принципиальная разница проявляется между двумя командами Composer:

• composer update пересчитывает допустимые версии и изменяет composer.lock;
• composer install устанавливает уже зафиксированные версии из lock-файла.

Поэтому обновление зависимости обычно выполняют в отдельной ветке, проверяют на локальном или тестовом окружении, а затем принимают через code review. При развёртывании запускается установка по готовому lock-файлу, а не бесконтрольный поиск свежих версий. Такой процесс снижает вероятность того, что два разработчика получат разные версии одного плагина.

У стандартного WordPress нет встроенной модели Composer-зависимостей. Ядро и расширения часто устанавливаются из панели администратора, ZIP-архивов или каталога плагинов. Состояние проекта при этом определяется не только Git-репозиторием, но и фактическими файлами на конкретном сервере.

Это не означает, что обычную структуру нельзя использовать с Composer. Команда может добавить собственный composer.json, подключить PHP-библиотеки или организовать установку плагинов в wp-content/plugins. Однако такую схему придётся проектировать и поддерживать самостоятельно. В Bedrock соответствующие соглашения уже являются частью архитектуры.

Не все плагины одинаково удобно управляются через Composer

Расширения из публичного каталога WordPress обычно можно подключать через совместимый Composer-репозиторий. С коммерческими продуктами ситуация зависит от поставщика. Одни предоставляют официальный Composer-репозиторий, другие требуют приватного хранилища пакетов или загрузки архива в процессе сборки. Плагин с персональным ключом скачивания нельзя считать обычной публичной зависимостью.

Перед выбором Bedrock агентству полезно проверить не только популярные бесплатные расширения, но и весь обязательный стек: интернет-магазин, формы, мультиязычность, SEO, интеграции с CRM, платёжные модули и плагины заказчика. Если значительная часть пакетов не поддерживает воспроизводимую установку, преимущество Composer будет реализовано лишь частично.

Как меняется работа с Git

В стандартном WordPress команды нередко выбирают одну из двух крайностей. В первом случае в репозиторий попадает почти весь сайт, включая ядро и сторонние плагины. История становится объёмной, а обновления создают большие изменения файлов, которые разработчики фактически не проверяют. Во втором случае сохраняется только собственная тема, из-за чего Git не описывает полный состав приложения.

Bedrock предлагает более явную границу. Обычно в Git хранят:

• composer.json и composer.lock;
• файлы конфигурации без секретных значений;
• собственные темы, плагины и mu-плагины;
• скрипты сборки, тесты и конфигурацию инструментов качества кода;
• пример набора переменных окружения без паролей и ключей.

Ядро WordPress, Composer-пакеты и управляемые через Composer расширения можно восстановить из lock-файла, поэтому хранить их исходники в репозитории обычно не требуется. Не должны попадать в Git и изменяемые данные: загрузки пользователей, кэш, журналы ошибок, резервные копии и локальные секреты.

Для команды это даёт важное свойство: Git описывает код проекта, но не пытается заменить резервное копирование сайта. Медиатека и база данных всё равно требуют отдельного хранения. Ни Bedrock, ни Composer не версионируют публикации, настройки плагинов, заказы и другие данные из базы.

Проблема изменений через панель администратора

Если один администратор обновил плагин непосредственно на рабочем сайте, а разработчик изменил его версию через Composer, возникает расхождение между сервером и репозиторием. При следующем развёртывании ручное обновление может быть отменено или заменено другой версией.

Поэтому стандартная конфигурация Bedrock ограничивает установку и обновление тем и плагинов из панели. Изменения проходят через Composer и Git. Это повышает управляемость, но меняет привычный порядок работы контент-менеджеров и владельцев сайта. Команда должна заранее определить, кто отвечает за зависимости и как быстро выпускаются критические обновления.

Стандартный WordPress лучше поддерживает сценарий, при котором доверенный администратор обслуживает расширения через интерфейс CMS. Для небольшого проекта это может быть преимуществом. Для агентства с несколькими разработчиками и несколькими окружениями тот же механизм часто становится источником неконтролируемых различий.

Переменные окружения и конфигурация

В обычной установке параметры базы данных, соли, адреса сайта и различные константы чаще всего находятся в wp-config.php. Для одного сервера это понятно и удобно. При появлении локальной разработки, staging и production файл начинает обрастать условиями, проверками домена и значениями, которые нельзя безопасно отправить в репозиторий.

Bedrock разделяет код и параметры окружения. Настройки подключения к базе, адреса сайта, тип окружения и секретные ключи передаются через переменные. Локально они могут загружаться из файла .env, который исключён из Git. На сервере значения могут задаваться системой развёртывания, панелью хостинга, контейнерной платформой или защищённым хранилищем CI/CD.

Это позволяет использовать один и тот же код на разных площадках:

• локальное окружение подключается к локальной базе и включает режим разработки;
• тестовый сервер получает отдельные URL, учётные данные и настройки журналирования;
• production использует рабочую базу, закрытые ключи и безопасный режим отображения ошибок.

В репозитории остаётся логика конфигурации, а конкретные секреты существуют только в соответствующем окружении. При правильной организации разработчику не нужно редактировать общий файл после каждого получения изменений из Git.

У подхода есть и цена. Отсутствующая или неверно названная переменная может остановить приложение. Необходимо вести шаблон обязательных параметров, проверять их наличие при развёртывании и ограничивать доступ к значениям. Файл .env нельзя воспринимать как универсальный секретный сейф: его безопасность зависит от того, исключён ли он из репозитория, находится ли вне web root и кому доступна файловая система.

Стандартный WordPress также может читать системные переменные окружения, а wp-config.php можно разместить выше каталога ядра. Следовательно, различие заключается не в принципиальной возможности, а в соглашениях по умолчанию. Bedrock сразу подталкивает команду к разделению конфигурации и кода; в обычной структуре это решение нужно внедрять отдельно.

Web root и граница публичного доступа

В Bedrock сервер должен направлять домен в каталог web, а не в корень репозитория. Благодаря этому composer.json, composer.lock, vendor, основная конфигурация и локальный .env не оказываются среди файлов, которые веб-сервер потенциально может отдать посетителю.

Такое разделение соответствует распространённой архитектуре PHP-приложений: наружу публикуется только специально предназначенная директория. Оно уменьшает зависимость безопасности от запретов на доступ к каждому служебному файлу.

Однако наличие отдельного web root не делает проект автоматически защищённым. Сервер всё равно должен запрещать выполнение PHP-кода в каталоге загрузок, корректно обрабатывать маршрутизацию WordPress, скрывать журналы и резервные копии, использовать безопасные права доступа и не раскрывать служебные файлы из-за ошибочной конфигурации.

Стандартная структура тоже может быть безопасной. WordPress и веб-сервер позволяют ограничить доступ к wp-config.php, отключить редактор файлов и подобрать права на каталоги. Преимущество Bedrock заключается прежде всего в более чёткой физической границе, а не в замене остальных мер защиты.

Обновления ядра, плагинов и тем

В стандартном WordPress обновления обычно выполняются автоматически, вручную из панели или заменой файлов. Это удобно для сайтов, которые обслуживает администратор без участия разработчиков. Система сама показывает доступные версии, а многие хостинги добавляют централизованное управление и резервное копирование перед обновлением.

Недостаток проявляется в командной разработке. Обновлённые на production файлы могут отсутствовать на staging и локальных компьютерах. Репозиторий перестаёт отражать фактическое состояние сайта, а повторное развёртывание старой копии темы или плагина возвращает устранённую уязвимость или ошибку.

В Bedrock версия кода изменяется через Composer. Типичный процесс включает обновление ограниченного набора пакетов, анализ изменений lock-файла, автоматические проверки и тестирование на staging. После принятия изменений production получает уже проверенный состав зависимостей.

Composer при этом не отменяет риски обновлений WordPress. Новая версия плагина может изменить структуру таблиц, запустить процедуру обновления базы или потребовать ручного действия в панели. Откат файлов не всегда откатывает данные. Перед выпуском значимых обновлений необходима согласованная резервная копия файлов и базы, а также проверенный план восстановления.

Команде следует разделять два действия:

1. изменение разрешённых версий и пересчёт composer.lock в контролируемом окружении;
2. установку зафиксированных зависимостей при сборке или развёртывании.

Запуск общего composer update непосредственно на production разрушает значительную часть преимуществ Bedrock: сервер самостоятельно выбирает новые версии, а результат может не совпасть с проверенной сборкой.

Требования к PHP и Composer

PHP необходим в обоих вариантах, поскольку на нём работает WordPress. При выборе версии нужно учитывать одновременно требования ядра, темы, всех плагинов и вспомогательных библиотек. Для нового проекта разумно ориентироваться на современную поддерживаемую ветку PHP, которую рекомендуют WordPress и используемый релиз Bedrock, а не только на минимальную версию, при которой CMS ещё запускается.

Актуальные релизы Bedrock требуют PHP 8.3 или новее. Перед созданием проекта это ограничение следует сверить с composer.json выбранной версии, потому что требования могут повышаться. Обычный WordPress способен работать в более широком диапазоне окружений, но устаревшая версия PHP ухудшает безопасность и может ограничивать выбор современных плагинов.

Composer для Bedrock обязателен как часть процесса сборки зависимостей. Но он не обязательно должен быть установлен именно на production-сервере. Возможны две модели:

• Composer запускается на сервере развёртывания, если хостинг предоставляет SSH, подходящий PHP CLI и достаточные ресурсы;
• зависимости собираются в CI или другом доверенном окружении, после чего на сервер отправляется готовый артефакт.

Вторая модель подходит для хостинга без Composer, но требует настроенного конвейера доставки. Важно собирать проект под совместимую версию PHP и проверять реальные серверные расширения. Composer учитывает не только версию интерпретатора, но и платформенные зависимости вида ext-*. Перед публикацией полезно выполнять проверку соответствия платформенным требованиям, а не подавлять ошибки параметрами игнорирования.

На стандартном WordPress Composer не обязателен. Для простого сайта достаточно PHP, базы данных, веб-сервера и доступа к файлам. Это снижает порог входа, но лишает команду встроенного механизма фиксации полного набора программных зависимостей.

Совместимость с виртуальным хостингом и VPS

Виртуальный хостинг

Главный вопрос для Bedrock — можно ли назначить каталог web корнем домена. Некоторые панели позволяют выбрать document root при создании сайта или поддомена, другие жёстко привязывают домен к public_html. Перенаправление запросов из корня в web иногда возможно, но это компромисс: служебные файлы физически остаются внутри опубликованного каталога, а результат зависит от веб-сервера и правил хостинга.

Кроме document root необходимо проверить:

• наличие подходящей версии PHP для сайта и командной строки;
• доступ по SSH, если Composer планируется запускать на хостинге;
• возможность выполнять команды без интерактивного подтверждения при деплое;
• лимиты памяти и времени для Composer;
• поддержку нужных PHP-расширений;
• способ безопасно передавать переменные окружения;
• права на запись в каталог загрузок и другие изменяемые директории.

Пользователь виртуального хостинга не может рассчитывать на изменение системной конфигурации Apache, Nginx или PHP-FPM. Если панель не позволяет настроить корень сайта и хостинг не готов сделать это через поддержку, стандартный WordPress будет надёжнее. Для такого сценария подойдёт виртуальный хостинг с возможностью настроить document root в панели. Альтернативой остаётся сборка Bedrock вне сервера, но она не решает ограничение document root.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

VPS и выделенный сервер

На VPS Bedrock обычно размещается без архитектурных компромиссов: администратор может направить виртуальный хост в web, настроить правила маршрутизации и выбрать способ передачи переменных. Но свобода настройки означает и ответственность за PHP, веб-сервер, права доступа, резервное копирование и безопасность.

Наличие root-доступа само по себе не является причиной выбирать Bedrock. Если сервер администрируется вручную, а у команды нет надёжного процесса развёртывания, стандартная структура может быть проще и устойчивее. Bedrock приносит пользу тогда, когда серверная конфигурация дополняет Git и автоматизированную доставку, а не заменяет их набором ручных команд. Для команды, которой нужен контроль над document root и окружением, может быть подходящим вариантом VPS-сервер.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Управляемый WordPress-хостинг

Managed-платформы могут рассчитывать на стандартные расположения wp-admin, wp-includes и wp-content, самостоятельно обновлять ядро или анализировать плагины. Часть таких сервисов поддерживает Bedrock и позволяет изменить web root, часть — нет.

До заключения договора стоит уточнить, распознают ли инструменты резервного копирования, клонирования, staging, сканирования и кэширования изменённую структуру. Недостаточно проверить, что главная страница открывается: служебные функции платформы тоже должны корректно работать.

Совместимость тем и плагинов

Корректно написанные расширения используют константы и функции WordPress для определения путей и URL. Они обычно работают с Bedrock без изменений. Проблемы создаёт код, который жёстко предполагает наличие /wp-content/, строит путь относительно корня сайта или ожидает, что ядро расположено непосредственно в document root.

Особого внимания требуют:

• плагины резервного копирования и миграции, сканирующие файловую структуру;
• защитные решения, создающие правила в корневых конфигурационных файлах;
• кэш-плагины, записывающие drop-in-файлы и меняющие конфигурацию;
• расширения, устанавливающие собственные обновления вне Composer;
• плагины с путями к wp-content, прописанными строками;
• инструменты хостинга и WP-CLI-скрипты, рассчитанные на стандартный корень.

Несовместимость не всегда означает полный отказ от плагина. Иногда достаточно правильной настройки путей или отказа от одной вспомогательной функции. Но агентству важно учитывать стоимость такого сопровождения: каждый локальный патч нужно документировать, тестировать после обновлений и воспроизводить при новой сборке.

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

Сильные и слабые стороны Bedrock

Преимущества

• Воспроизводимые зависимости. Lock-файл фиксирует версии ядра и Composer-пакетов.
• Чистый репозиторий. В Git хранится собственный код и описание зависимостей, а не копии всего стороннего проекта.
• Разделение конфигурации и кода. Секреты и параметры окружений не требуется записывать в общий конфигурационный файл.
• Контролируемые обновления. Изменения можно проверять через ветки, code review, CI и staging.
• Отдельный web root. Служебные файлы проекта располагаются вне публичной директории.
• Удобство для нескольких окружений. Один код получает разные параметры локально, на staging и production.

Ограничения

• команде необходимо понимать Composer и различие между install и update;
• требуется современная версия PHP, совместимая со всеми зависимостями;
• хостинг должен поддерживать отдельный document root либо готовый артефакт и подходящую схему публикации;
• часть плагинов и инструментов управления предполагает стандартные пути;
• установка расширений через панель перестаёт быть нормальным рабочим процессом;
• развёртывание требует большей дисциплины, чем копирование файлов по FTP.

Сильные и слабые стороны стандартной структуры

Преимущества

• Максимальная совместимость. Эту структуру ожидают большинство хостингов, установщиков и плагинов.
• Простой запуск. Для базового проекта не нужны Composer и отдельная сборка.
• Удобство администрирования. Темы, плагины и ядро можно обслуживать из панели WordPress.
• Поддержка на типовом хостинге. Обычно не требуется менять корень домена или конфигурацию веб-сервера.
• Ниже порог передачи проекта. Сайт проще отдать владельцу или подрядчику, знакомому с обычным WordPress.

Ограничения

• без дополнительных правил Git не описывает полный и точный состав зависимостей;
• обновления на разных окружениях могут расходиться;
• секреты и настройки часто смешиваются в одном wp-config.php;
• служебные и публичные файлы по умолчанию находятся ближе друг к другу;
• ручные изменения на production труднее обнаруживать и воспроизводить;
• современный процесс CI/CD приходится проектировать поверх стандартной структуры.

Что выбрать агентству или команде

Bedrock обычно оправдан, если проект разрабатывают несколько специалистов, изменения проходят review, существуют как минимум staging и production, а обновления должны быть воспроизводимыми. Особенно полезен он для долгосрочной разработки, где состав зависимостей меняется регулярно и сервер не должен становиться единственным источником актуального кода.

Выбор в пользу Bedrock логичен, когда команда может утвердительно ответить на следующие вопросы:

• все разработчики готовы работать с Composer и lock-файлом;
• для проекта определён единый процесс обновления зависимостей;
• хостинг позволяет направить домен в web;
• Composer доступен на этапе сборки локально, в CI или на сервере;
• обязательные коммерческие плагины можно воспроизводимо доставлять;
• администраторы не будут менять управляемый код в обход Git;
• команда умеет резервировать и восстанавливать не только файлы, но и базу.

Стандартный WordPress практичнее для небольшого сайта на виртуальном хостинге, разовой разработки, проекта с обслуживанием через панель или передачи заказчику без собственной технической команды. Он также предпочтительнее, если хостинг жёстко ограничивает document root, а значительная часть критичных плагинов зависит от стандартных путей.

Между вариантами существует промежуточный подход. Можно сохранить обычную файловую структуру, но добавить Git для собственной темы, автоматические проверки, переменные окружения в wp-config.php и Composer для PHP-библиотек. Такой проект не получит все соглашения Bedrock, зато команда сможет внедрять инженерные практики постепенно.

Итог

Roots Bedrock лучше отвечает задачам командной разработки: фиксирует зависимости через Composer, разделяет код и конфигурацию, упрощает работу с несколькими окружениями и задаёт безопасную границу web root. Его преимущества заметны только при дисциплинированном процессе — с Git, CI/CD, staging и запретом несогласованных изменений на production.

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

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