
Настраиваем локальный сервер для разработки WordPress-сайта через wp-env
16 апреля 2026
Эта статья для тех случаев, когда WordPress-проект перерастает рамки «только темы» и превращается в полноценный сайт со своим набором плагинов, mu-плагинов, конфигом и данными. В этот момент локальный сервер становится инструментом повышения эффективности и качества разработки: он позволяет быстро поднимать одинаковое окружение, которое воспроизводимо у всей команды и снижает количество ошибок из-за различий в настройках.
Когда нужен локальный сервер
- Когда над проектом работает несколько разработчиков и важно, чтобы окружение было одинаковым.
- Когда в работе участвуют плагины, mu-плагины, CLI-команды, импорты и миграции, а не только код темы.
- Когда нужно воспроизводимо дебажить баги, завязанные на версии PHP, MySQL, конфиг и расширения.
- Когда не хочется поддерживать «ручную магию» настроек на каждом ноутбуке.
Стандартное решение wp-env
Для WordPress есть готовый, поддерживаемый сообществом инструмент: @wordpress/env.
wp-env позволяет поднимать окружение как на базе Docker, так и в облегчённом варианте через Playground на базе WASM. Дальше в статье разберём, как это устроено и как быстро запустить.
Простыми словами
По сути, вы описываете параметры проекта в
.wp-env.json, а дальше запускаете среду одной командой. На выходе получаете рабочий сайт, доступ к WP-CLI и предсказуемое поведение на любой машине с Docker.
Составляющие и особенности подхода WPCraft
- Docker как runtime
- Контейнеры изолируют окружение и убирают конфликт версий на хосте.
- Проект не привязан к локальным настройкам PHP/MySQL конкретного разработчика.
.wp-env.jsonкак source of truth- Фиксирует PHP-версию, порт, маппинги
wp-content, список подключаемых плагинов и флаги среды. - Из этого файла сразу видно, как именно должен запускаться проект.
- Фиксирует PHP-версию, порт, маппинги
- Маппинг рабочих директорий
- В контейнер пробрасываются
plugins,mu-plugins,themes,uploads. - Это позволяет работать с «живыми» файлами из репозитория и сразу видеть изменения в браузере.
- В контейнер пробрасываются
- WP-CLI внутри окружения
- В проекте есть отдельная команда
make cliдля входа в контейнер CLI (из темыapp). - Это удобно для миграций, поиска/замены, обслуживания контента и проверок в правильном окружении.
- В проекте есть отдельная команда
- Локальный режим разработки. Быстрее ловятся ошибки и проще дебажить проблему «на месте».

Пример структуры репозитория (на примере реального проекта)
В этом проекте WordPress ведется как цельный сайт, а не как отдельная тема/плагин:
public/— корень WordPress (ядро и служебные файлы)public/wp-config.php— конфиг сайтаpublic/wp-content/themes/app/— рабочая дочерняя темаblocksy/— parent-тема
public/wp-content/plugins/— проектные и внешние плагиныpublic/wp-content/mu-plugins/— must-use плагиныpublic/wp-content/uploads/— медиа и пользовательские файлы.wp-env.json— конфигурация локального Docker-окруженияMakefile— набор команд управления для удобства (start,stop,reset,destroy,cli)
Такой layout помогает мыслить проектом целиком: тема, плагины, контент и настройки развиваются согласованно.
Как быстро поднять локальное окружение для разработки
1) Предусловия
- Docker Desktop
- Node.js LTS
- Доступ к репозиторию
2) Пример .wp-env.json
{
"core": "./public",
"phpVersion": "8.2",
"testsEnvironment": false,
"plugins": [
"https://downloads.wordpress.org/plugin/woocommerce.zip"
],
"mappings": {
"wp-content/plugins": "./public/wp-content/plugins",
"wp-content/mu-plugins": "./public/wp-content/mu-plugins",
"wp-content/themes": "./public/wp-content/themes",
"wp-content/uploads": "./public/wp-content/uploads"
},
"phpmyadmin": false,
"config": {
"WP_DEBUG": true,
"WP_ENVIRONMENT_TYPE": "local"
},
"multisite": false,
"port": 8811
}
3) Проверка
Запускаем командой npx wp-env start
- Админка:
http://localhost:8811/wp-admin - Логин:
admin - Пароль:
password
4) Полезные команды в ежедневной работе
Собираем Makefile — для удобства и автодополнения в терминале
start:
wp-env start
start-update:
wp-env start --update
stop:
wp-env stop
restart:
wp-env stop
wp-env start
reset:
wp-env reset
cli:
npx wp-env run cli --env-cwd=wp-content/themes/app sh
destroy:
npx wp-env destroy
Пример команд:
make stop # остановить окружение
make restart # перезапуск
make start-update# старт с обновлением образов
make reset # сброс данных окружения
make destroy # полное удаление окружения wp-env
make cli # shell в wp-env CLI-контейнере
Преимущества такого подхода
wp-env— быстрый способ стандартизировать локальную WordPress-разработку через Docker.- Главная идея: один конфиг (
.wp-env.json) и воспроизводимый запуск у всей команды. - В сложных WordPress-проектах стоит мыслить не темой отдельно, а сайтом как системой.
- Критично маппить
wp-contentдиректории и работать с ними как с частью репозитория. Makefileповерхwp-envснижает порог входа и делает команды очевидными.- WP-CLI внутри контейнера — обязательная часть workflow для операционных задач.
- Типовая структура репозитория должна явно показывать, где код, где контент и где конфиг среды.
- Такой подход особенно полезен, когда на сайте много плагинов и есть зависимость от их взаимодействия.
- Следующий шаг эволюции: автоматизировать импорт данных и smoke-check после
make start.
Одно из главных преимуществ для меня — это позволяет собрать конфигурацию под любой хостинг. Хоть обычный виртуальный хостинг, хоть под выделенный сервер, хоть под облачные контейнеры.
Итого
wp-env хорошо работает как «инфраструктурный минимум»: быстро стартует, прозрачно настраивается и покрывает реальные задачи команды разработки. Даже для очень сложных проектов.
Если оформить вокруг него понятные правила (структура репозитория, команды, data-flow, CLI-практики), локальная разработка перестает быть источником случайностей и становится предсказуемой инженерной системой.
Ссылки
- Официальная документация @wordpress/env https://developer.wordpress.org/block-editor/reference-guides/packages/packages-env/
- npm: https://www.npmjs.com/package/@wordpress/env
- Docker Desktop — установка https://docs.docker.com/get-docker/

