Структура современного WordPress-сайта. Composer, Docker, Bedrock / Хабр

Десять лет спустя автор обновил разбор структуры WordPress-проекта. На Хабре вышла практическая статья, где движок пытаются привести в чувство через Composer, Bedrock и Docker — с прицелом на новостные ресурсы под нагрузкой до миллиона хостов в сутки.

Почему классический WordPress — это путь к падению прода

По словам автора, половина проектов до сих пор живёт по схеме «установил плагин через админку прямо на боевом сервере, поправил functions.php по FTP». На визитке держится. Как только проект начинает расти — прилетает: кто-то накатил плагин, кто-то правил тему, git про это не знает, бэкапов нет. «Катастрофа в 100% случаев» — прямая цитата из материала.

Отдельная боль — хранение всего в git. Ядро, плагины, темы — коммитится руками. Обновления выходят регулярно, репозиторий пухнет. Из коробки WordPress вообще не объясняет, как отделить своё от чужого. В документации это описано криво и одной строкой — сам автор на это жалуется.

Bedrock, Sandbox и нормальная жизнь с composer

Выход из коробки — Bedrock от roots. Ядро WordPress ставится как обычная composer-зависимость. Плагины и темы подтягиваются через composer.json, как в любом современном PHP-фреймворке. Vendor в репозитории больше не лежит. Обновление одной командой, откат одной командой. Никакой магии — просто нормальный дев-процесс.

Поверх Bedrock автор собрал Sandbox — песочницу для локалки. Под капотом Docker-конфигурация, Makefile,.env с параметрами LOCAL_UID и LOCAL_USER, чтобы пользователь внутри контейнера совпадал с хостовым. Без этого первый же docker compose up оставит вас с правами root на хосте и последующим кернел-паником в попытках их починить. На проде автор уходит с Docker на голое железо или LXC/LXD-контейнеры — меньше слоёв, проще дебажить. Образ из Sandbox на боевом сервере запускать можно, но потребует доработки, пусть и незначительной.

Что проверить у себя прямо сейчас

• Поднять проект на Bedrock. composer create-project roots/bedrock — и ядро больше не сидит в репе.
• Прописать в.env LOCAL_UID и LOCAL_USER под свою хост-машину, иначе права на файлы посыплются при первом маунте.
• На проде забыть про FTP и админку как страшный сон. Деплой — git pull плюс composer install, миграции скриптом, бэкапы по расписанию.
• В репе держать только своё: кастомную тему, конфиги, свои плагины. Стороннее — через composer, иначе vendor раздует историю до неприличия.

WordPress из индустрии никуда не уйдёт — на нём сидит половина СМИ, это факт. Но если вы до сих пор правите прод по FTP, у вас не сайт, а тикающая бомба. Composer, git, контейнеры, бэкапы по крону. Всё остальное — костыль на костыле.