Почему старый подход к WordPress уже не работает
Традиционная сборка WordPress, где ядро, темы и плагины лежат прямо в корне проекта, уже не отвечает современным требованиям разработки. Такой подход затрудняет контроль версий, усложняет развертывание и делает проект хрупким при обновлениях. Когда сайт растет, встает вопрос о повторяемости окружения, управлении зависимостями и разделении кода, конфигурации и данных.
В результате команды начали переносить практики из обычной веб‑разработки в мир WordPress: управление зависимостями через Composer, контейнеризация окружения с Docker и переосмысление структуры проекта с помощью Bedrock.
Эти инструменты позволяют стандартизировать процессы, повысить безопасность и упростить масштабирование.
Composer как основа управления зависимостями
Composer дает возможность объявлять зависимости проекта и устанавливать их предсказуемо.
Вместо ручной перетаскивания плагинов и тем в папку wp‑content, вы описываете нужные пакеты в composer. json. Это делает процесс установки и обновлений воспроизводимым: на любой машине, будь то локальная среда разработчика или CI/CD, команда получит одну и ту же наборку библиотек и расширений.
Кроме того, с Composer проще выбирать версии плагинов и библиотек, фиксировать совместимые сочетания и откатываться при необходимости.
Пакеты могут храниться в приватных репозиториях, что важно для коммерческих разработок. В итоге проект приобретает более строгую структуру и предсказуемые зависимости, что критично для стабильных релизов.
Docker - единое окружение для разработки и деплоя
Контейнеризация с помощью Docker решает проблему "работает на моей машине". С помощью Docker Compose создается набор сервисов: PHP‑фаст‑CGI, веб‑сервер, база данных, кеш и другие вспомогательные компоненты. Это дает одинаковое окружение для всех участников команды и CI, исключая несовместимости версий PHP, расширений или конфигураций.
Контейнеры также облегчают автоматизацию развертывания: образы можно билдить в CI, деплоить на сервер и масштабировать.
Использование томов и миграций базы позволяет сохранить данные отдельно от кода, а сетевые настройки контейнеров упрощают организацию внутреннего взаимодействия сервисов.
Bedrock - проектная структура под современный рабочий процесс
Bedrock предлагает переосмысленную структуру WordPress‑проекта. Вместо классического размещения файлов, Bedrock задействует более модульный подход: ядро WordPress управляется Composer, весь код приложения располагается в отдельной папке, конфигурация хранится в.
env. Такой расклад обеспечивает четкое разделение окружения и логики приложения. Преимущества Bedrock: упрощенная работа с переменными окружения, возможность хранить ключи и настройки вне репозитория, улучшенная совместимость с Composer и ясная структура для деплоя. Это делает проект более безопасным и удобным для командной разработки.
Организация конфигурации и секретов
Перенос конфигураций в. env исключает захламление кода секретами и упрощает смену настроек между окружениями. В продакшене файлы с чувствительной информацией не должны попадать в VCS, а Bedrock помогает внедрить эту практику по умолчанию.
При этом конфигурационные шаблоны можно хранить в репозитории, а реальные значения - в коммуникации с системой секретов или в окружении деплоймента.
Такой подход повышает безопасность и упрощает автоматизацию: CI/CD обращается к переменным окружения при сборке и развертывании, а разработчики получают предсказуемое окружение без риска утечки данных.
Как все это складывается в единую практику
В связке Composer + Docker + Bedrock проект превращается в модульную и воспроизводимую систему. Composer отвечает за пакеты и зависимости, Bedrock формирует порядок файлов и конфигураций, а Docker гарантирует идентичное окружение на каждой машине.
Вместе они устраняют множество проблем, присущих старому монолитному подходу: непредсказуемые обновления, "неработает у меня", утечки секретов и хаос в структуре кода.
Практическая реализация включает: репозиторий с Bedrock‑структурой, composer. json с зависимостями ядра, тем и приватных пакетов, Docker Compose‑файл для локальной разработки и CI‑скрипты для сборки образов и деплоя. Наличие шаблонов для миграций базы, бэкапов и мониторинга завершает картину зрелого процесса разработки.
Отрицательные стороны и как с ними бороться
Переход на новую архитектуру требует времени и дисциплины. Нужно обучать команду Composer, перенастраивать CI, создавать образы Docker и привыкать к новой структуре проекта. Иногда разработчики сопротивляются изменениям из‑за привычки работать с "чистой" установкой WordPress.
Эти риски нивелируются пошаговым внедрением: сначала интегрировать Composer, затем двигаться к Bedrock и только после этого внедрять Docker. Документация, шаблоны и привычные процессы CI помогают сгладить переход и сократить время адаптации.
Краткие рекомендации для старта
Начните с минимальных изменений: вынесите зависимости в composer. json и подключите управление версиями для сторонних расширений. Составьте Docker Compose для локальной среды и настройте. env по примеру Bedrock. Постепенно автоматизируйте сборку образов в CI и внедряйте деплой через контейнеры.
Такой последовательный переход позволит сохранить рабочие процессы и одновременно получить преимущества модульной, безопасной и предсказуемой архитектуры WordPress‑проекта.
В итоге вы получите проект, который легче поддерживать, масштабировать и развивать в составе команды.