DDEV и wp-env: выбор локальной среды разработки WordPress

DDEV и wp-env позволяют запускать WordPress локально, не устанавливая веб-сервер, PHP и базу данных непосредственно в операционную систему. Оба инструмента используют изолированное окружение, управляются из командной строки и подходят для разработки тем, плагинов и блоков. Однако общий контейнерный фундамент не делает их взаимозаменяемыми.

wp-env — специализированный инструмент экосистемы WordPress. Он быстро создаёт готовый сайт и автоматически подключает разрабатываемую тему или плагин. DDEV — более универсальный менеджер контейнерных сред для PHP- и Node.js-проектов. Он даёт разработчику больше контроля над веб-сервером, PHP, базой данных, дополнительными сервисами и жизненным циклом проекта.

Выбор зависит не столько от размера команды, сколько от единицы разработки. Если репозиторием является один плагин, которому нужен чистый WordPress для тестирования, обычно удобнее wp-env. Если команда работает с полноценным сайтом, нестандартной серверной конфигурацией или несколькими связанными сервисами, сильнее выглядит DDEV.

DDEV и wp-env следует рассматривать как локальные среды разработки и тестирования. Они не заменяют продакшн-хостинг, резервное копирование, мониторинг, защиту публичного сервера и отказоустойчивую инфраструктуру.

Главное различие в подходе

wp-env: WordPress как готовая тестовая установка

wp-env поставляется как пакет @wordpress/env и запускает окружение для создания и проверки тем и плагинов. Инструмент знает структуру WordPress и умеет определить, что текущий каталог содержит расширение. При запуске из каталога плагина или темы он может подключить этот каталог к созданному сайту и активировать расширение.

Для базового сценария достаточно установить пакет, запустить Docker и выполнить команду:

npx wp-env start

Если конфигурационного файла нет, wp-env создаёт стандартную установку WordPress с предсказуемыми параметрами доступа. Это особенно удобно при разработке отдельного расширения: репозиторию не требуется содержать ядро WordPress, базу данных или полноценный каркас сайта.

Настройки проекта хранятся в .wp-env.json. В нём можно указать версию PHP, источник ядра, подключаемые темы и плагины, порт, константы WordPress, сопоставление каталогов и команды жизненного цикла.

DDEV: контейнерная среда вокруг проекта

DDEV начинает не с отдельного расширения, а с проекта и его document root. Инструмент создаёт веб-контейнер, контейнер базы данных, маршрутизацию и локальный адрес. Для WordPress предусмотрен отдельный тип проекта и интеграция с WP-CLI, но DDEV не ограничивается этой CMS.

Основные настройки находятся в каталоге .ddev, прежде всего в файле .ddev/config.yaml. Через него задаются тип проекта, корневая веб-директория, версия PHP, тип веб-сервера и параметры базы данных. Конфигурацию можно дополнять PHP-настройками, собственными командами, хуками и контейнерами дополнительных сервисов.

Такой подход лучше соответствует репозиторию полноценного сайта. Если же репозиторий содержит только плагин, команде придётся отдельно определить, где брать ядро WordPress, как выполнять установку CMS и как подключать тестируемое расширение. Это можно автоматизировать, но начальная конфигурация будет сложнее, чем у wp-env.

Зависимости от Docker и инструментов на компьютере

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

У wp-env есть дополнительная явная зависимость от Node.js, поскольку сам инструмент распространяется как npm-пакет. Глобальная установка возможна, но для командного проекта надёжнее добавить пакет в devDependencies:

npm install --save-dev @wordpress/env

После этого команда запускает версию, зафиксированную в зависимостях проекта:

npx wp-env start

Её также можно скрыть за npm-скриптами, чтобы участникам команды не приходилось запоминать параметры:

{
  "scripts": {
    "env:start": "wp-env start",
    "env:stop": "wp-env stop",
    "env:reset": "wp-env reset all"
  },
  "devDependencies": {
    "@wordpress/env": "зафиксированная-командой-версия"
  }
}

В реальном package.json вместо текстового обозначения необходимо указать существующую версию пакета и зафиксировать её lock-файлом. Использование произвольного глобального wp-env повышает риск того, что два разработчика получат разное поведение команд.

DDEV устанавливается как отдельная программа для операционной системы. Node.js на хосте не является обязательным условием для управления средой: npm, Composer, PHP и ряд других инструментов доступны внутри веб-контейнера. Например, команду сборки фронтенда можно выполнять через DDEV:

ddev npm run build

Это снижает количество локальных зависимостей, но сам DDEV и поддерживаемый им контейнерный движок всё равно должны быть установлены у каждого разработчика. Команде также полезно согласовать версию DDEV или задать ограничение в конфигурации проекта, иначе обновление программы на одном компьютере может изменить создаваемое окружение.

Воспроизводимость окружения

Контейнеры сами по себе не гарантируют воспроизводимость. Для неё необходимо зафиксировать как минимум версию управляющего инструмента, PHP, ядро WordPress, зависимости Composer и npm, параметры базы данных и процедуру подготовки контента.

Что фиксирует wp-env

Минимальный файл для разработки плагина может выглядеть так:

{
  "phpVersion": "8.3",
  "plugins": ["."],
  "port": 8888,
  "config": {
    "WP_DEBUG": true,
    "SCRIPT_DEBUG": true
  }
}

Этот пример фиксирует основную версию PHP, подключает текущий каталог как плагин и задаёт параметры отладки. Конкретное значение PHP здесь приведено только как пример: проект должен выбирать его по заявленной совместимости расширения и по целевому серверному окружению.

Если источник ядра не задан, среда может использовать актуальный стабильный выпуск WordPress, определяемый инструментом. Это удобно для регулярной проверки совместимости, но результат запуска со временем способен измениться. Для строго воспроизводимой сборки следует закрепить источник или конкретную ревизию ядра и обновлять её осознанно.

Аналогичная проблема возникает с дополнительными расширениями. Запись, указывающая на изменяемую ветку удалённого репозитория, менее воспроизводима, чем конкретный тег или commit. При этом lock-файл npm фиксирует версию самого wp-env, но не заменяет фиксацию всех источников внутри .wp-env.json.

Что фиксирует DDEV

Пример базовой конфигурации полноценного WordPress-проекта:

name: wp-extension-dev
project_type: wordpress
docroot: .
php_version: "8.3"
webserver_type: apache-fpm
database:
  type: mariadb
  version: "10.11"

Такой файл предполагает, что WordPress находится в корне проекта. Если публичным каталогом служит web, public или другая директория, значение docroot нужно изменить. DDEV позволяет зафиксировать не только PHP, но и семейство веб-сервера, тип и версию базы данных. Это важно для проектов, где поведение зависит от различий между Apache и Nginx либо между MySQL и MariaDB.

При этом DDEV не хранит состояние базы в config.yaml. Чтобы новый участник получил не пустой WordPress, а согласованный набор страниц, настроек и тестовых пользователей, команде нужен безопасный дамп без персональных данных либо повторяемый сценарий инициализации. Загруженные файлы также передаются отдельно или генерируются автоматически.

DDEV предоставляет команды импорта, экспорта и снимков базы. Снимки удобны для локального отката, например перед миграцией схемы, но их не стоит автоматически считать переносимым командным источником данных. Они связаны с типом и версией СУБД. Для обмена исходным состоянием обычно понятнее документированный дамп и команда импорта.

Командная работа и хранение конфигурации в Git

У wp-env небольшая конфигурационная поверхность. В репозиторий обычно попадают .wp-env.json, package.json и lock-файл npm. Участник клонирует проект, устанавливает зависимости и запускает одну команду. Для библиотеки блоков, темы или плагина это даёт низкий порог входа.

Личные параметры можно вынести в .wp-env.override.json и исключить этот файл из Git. Важно учитывать правила объединения: не все поля базовой и локальной конфигурации сливаются. Например, локальный список плагинов может полностью заменить командный список. Поэтому override-файл лучше использовать для портов и действительно персональных настроек, а не для скрытого изменения состава тестовой среды.

В DDEV в Git хранится каталог .ddev с проектной конфигурацией, хуками и пользовательскими командами. Локальные исключения можно размещать в config.local.yaml, который обычно не включают в репозиторий. Это позволяет одному разработчику выбрать локальный режим повышения производительности, не меняя общие PHP, базу данных и веб-сервер.

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

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

Настройка PHP и близость к целевому серверу

wp-env позволяет выбрать версию PHP через phpVersion и переопределить константы WordPress в секции config. Этого достаточно для проверки большинства плагинов и тем на разных ветках PHP и с включённым WP_DEBUG.

Более глубокая серверная настройка возможна, но не является основной сильной стороной wp-env. Можно подключать дополнительные файлы через mappings и выполнять lifecycle-скрипты, однако выбор веб-сервера или точное моделирование конкретной СУБД не представлены как простые параметры верхнего уровня. Чем больше проект отклоняется от типового WordPress, тем больше вспомогательной конфигурации потребуется.

DDEV даёт больше элементов для приближения локальной среды к серверной:

• основная версия PHP;
• Apache с PHP-FPM или Nginx с PHP-FPM;
• тип и версия базы данных;
• дополнительные PHP-пакеты и расширения;
• проектные файлы конфигурации PHP;
• дополнительные контейнеры и фоновые процессы.

Пользовательские параметры PHP можно хранить в INI-файлах внутри .ddev/php. Например, отдельный файл может задавать лимит памяти для локального тестирования:

[PHP]
memory_limit = 256M

После изменения контейнерную среду необходимо перезапустить и проверить итоговое значение внутри неё, а не через PHP на хосте:

ddev restart
ddev exec php -r "echo ini_get('memory_limit'), PHP_EOL;"

Ни DDEV, ни wp-env не воспроизводят продакшн с точностью до каждой детали. Версия PHP обычно задаётся на уровне основной и дополнительной версии, а не конкретной patch-сборки. Отличаться могут операционная система контейнера, модули, прокси, TLS-терминация, кеши и настройки файловой системы. Локальную среду следует считать контролируемым приближением, а окончательную проверку выполнять в отдельном тестовом окружении, близком к рабочему. Для подготовки такого контура может пригодиться материал о staging для WordPress на VDS.

Удобство тестирования тем и плагинов

Быстрые функциональные проверки

wp-env особенно удобен для проверки расширения в чистом WordPress. Разработчик запускает среду непосредственно из каталога плагина или темы, открывает административную панель и получает подключённый код без ручного копирования в wp-content. Сброс базы выполняется отдельной командой:

npx wp-env reset all

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

В DDEV функциональная проверка удобнее, если полноценный WordPress уже является частью проекта. Среда сохраняет базу между запусками, предоставляет локальный домен и HTTPS, а команды WP-CLI выполняются через ddev wp. Если тестируется только плагин, потребуется подготовленный каркас WordPress или автоматический bootstrap.

PHPUnit и интеграционные тесты

wp-env позволяет запускать произвольные команды внутри контейнеров. В CLI-контейнере доступны WP-CLI, Composer и PHPUnit, поэтому тесты можно выполнять без локального PHP:

npx wp-env run cli phpunit -- --configuration=wp-content/plugins/example/phpunit.xml.dist

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

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

npx wp-env start --config=.wp-env.test.json

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

В DDEV PHPUnit обычно устанавливается как Composer-зависимость проекта и запускается внутри веб-контейнера:

ddev exec vendor/bin/phpunit -c phpunit.xml.dist

DDEV не создаёт WordPress-набор тестов специально для плагина, зато хорошо подходит для проекта, где Composer, тестовый bootstrap и база уже организованы командой. Пользовательские команды DDEV могут сократить длинный вызов до условного ddev test и гарантировать одинаковые параметры у всех участников.

Отладка и покрытие

wp-env может запускаться с Xdebug через параметр команды старта. Режим покрытия полезен для PHPUnit, но заметно снижает производительность, поэтому его не стоит постоянно держать включённым:

npx wp-env start --xdebug=coverage

DDEV устанавливает Xdebug в веб-контейнер и по умолчанию отключает его. Для пошаговой отладки расширение можно временно включить, а после завершения работы выключить:

ddev xdebug on
ddev xdebug off

Для IDE в обоих случаях нужно настроить сопоставление локального пути с путём внутри контейнера. У wp-env структура скрыта сильнее, что упрощает обычный запуск, но иногда усложняет диагностику путей. DDEV предоставляет больше средств для интеграции контейнерного интерпретатора с IDE.

Проверка матрицы совместимости

Один локальный сайт не подтверждает совместимость плагина со всеми заявленными версиями PHP и WordPress. Для матрицы нужны повторяемые конфигурации и автоматический запуск тестов.

В wp-env удобно подготовить несколько JSON-файлов, каждый из которых задаёт свою комбинацию ядра, PHP и портов. Такой подход прозрачен для небольшого расширения, но число одновременно работающих окружений увеличивает нагрузку на Docker.

В DDEV можно менять версию PHP и базы в конфигурации, перезапуская проект между прогонами, либо использовать отдельные checkout-каталоги. DDEV лучше отражает различия серверного стека, но для широкой тестовой матрицы локальный запуск всё равно разумно дополнять CI. Локальная среда нужна для воспроизведения ошибки и интерактивной отладки, а CI — для обязательной проверки всех поддерживаемых комбинаций.

Сравнение по ключевым критериям

Скорость первого запуска

wp-env выигрывает, если в репозитории находится одна тема или один плагин. Инструмент сам предоставляет WordPress и подключает текущий каталог. DDEV потребует полноценной структуры сайта или дополнительного сценария установки CMS.

Глубина конфигурации

DDEV выигрывает, когда важны семейство веб-сервера, тип и версия базы, PHP-настройки, дополнительные сервисы и собственные команды. wp-env предлагает более узкую, но понятную WordPress-ориентированную модель.

Воспроизводимость

Результат зависит от дисциплины команды. У wp-env необходимо локально закрепить npm-пакет и явно определить источники WordPress и расширений. У DDEV — хранить каталог .ddev в Git, согласовать версию программы и документировать подготовку базы и файлов.

Командная разработка

wp-env удобнее для автономного расширения с небольшим количеством сервисов. DDEV удобнее для проекта сайта, где разработчикам нужен одинаковый серверный стек и автоматизированный onboarding.

Тестирование

wp-env быстрее предоставляет чистый WordPress и хорошо подходит для ручной проверки плагина на разных версиях ядра. DDEV лучше интегрируется с комплексным проектным тестовым контуром, Composer, IDE, дополнительными контейнерами и нестандартной серверной конфигурацией.

Работа с несколькими CMS

DDEV предпочтительнее для команды, которая параллельно поддерживает WordPress и другие PHP-приложения. Единые команды снижают стоимость переключения между проектами. wp-env рационален там, где задача ограничена WordPress.

Когда выбрать wp-env

• репозиторий содержит отдельную тему, плагин или набор блоков;
• нужно быстро получить чистую установку WordPress;
• требуется подключать текущий каталог без полноценного сайта в Git;
• основные проверки связаны с версиями WordPress и PHP, а не с веб-сервером и СУБД;
• команда уже использует Node.js и npm для сборки расширения;
• важна небольшая и понятная конфигурация рядом с кодом.

wp-env также удобен для открытого плагина: сторонний участник может клонировать репозиторий и запустить стандартный WordPress без изучения архитектуры отдельного демонстрационного сайта.

Когда выбрать DDEV

• репозиторий представляет полноценный WordPress-сайт;
• нужно приблизить PHP, веб-сервер и базу к целевому окружению;
• проект использует Composer, нестандартный document root или дополнительные сервисы;
• команде нужны импорт, экспорт и локальные снимки базы;
• требуются собственные команды и безопасные хуки инициализации;
• разработчики работают с несколькими PHP-платформами и хотят одинаковый интерфейс управления.

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

Можно ли использовать оба инструмента

Один репозиторий необязательно должен обслуживаться двумя средами, но на уровне организации сочетание бывает полезным. Например, команда разрабатывает плагин в wp-env, а затем проверяет его в составе клиентского сайта под DDEV. Первая среда отвечает за чистую установку и совместимость расширения, вторая — за интеграцию с реальным набором плагинов, темой, данными и серверным стеком.

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

Итоговый выбор

Для большинства автономных тем и плагинов разумной отправной точкой будет wp-env. Он ближе к структуре такого репозитория, требует меньше настроек и быстро создаёт чистый WordPress. Его ограничения становятся заметны, когда необходимо управлять серверным стеком, базой данных и дополнительными сервисами.

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

Краткая формула выбора такова: wp-env создаёт WordPress вокруг расширения, а DDEV создаёт инфраструктуру вокруг проекта. Первый подход оптимален для быстрой WordPress-ориентированной разработки, второй — для контроля окружения и долгосрочной командной работы.