DDEV давно стал одним из самых удобных инструментов для локальной разработки на PHP, и с WordPress он дружит особенно хорошо. Вместо зоопарка из MAMP, Local и самодельных Docker-сборок здесь часто хватает пары команд, чтобы поднять чистое локальное окружение с PHP, базой данных и нормальной изоляцией.
Ниже собрана практическая шпаргалка именно под WordPress. Без теории ради теории: запуск проекта, работа с WP-CLI, импорт базы, перенос файлов, снапшоты и базовые команды, которые реально нужны в повседневной работе.
Инициализация проекта
Если папка с файлами WordPress уже лежит локально, переходите в неё и настраивайте DDEV.
cd ~/Projects/my-wordpress-site ddev config --project-type=wordpress ddev start ddev describe
После запуска удобно сразу открыть сайт в браузере.
ddev launch ddev launch /wp-admin/
Если это не новый сайт, а уже существующий WordPress-проект, помните о важной детали: DDEV пишет свои настройки в wp-config-ddev.php. Если у проекта уже есть свой wp-config.php, DDEV либо сам добавит нужное подключение, либо подскажет, что нужно поправить вручную.
Повседневные команды
Это тот самый набор, который закрывает почти всю ежедневную работу.
ddev start ddev stop ddev restart ddev describe ddev list ddev poweroff
Зайти внутрь web-контейнера и выполнить команду можно так:
ddev ssh ddev exec php -v ddev exec wp core version
Просмотр логов:
ddev logs ddev logs -s db ddev logs -f
WP-CLI внутри DDEV
Для WordPress есть удобный shortcut ddev wp. Работает быстро и без лишних танцев с путями и контейнерами.
ddev wp core version ddev wp plugin list ddev wp theme list ddev wp cache flush ddev wp rewrite flush --hard
При необходимости можно запускать команды и через ddev exec. Оба варианта рабочие, но ddev wp обычно удобнее в повседневке.
Работа с базой данных
Экспорт базы в файл:
ddev export-db --file=/tmp/db.sql.gz ddev export-db --gzip=false --file=/tmp/db.sql
Импорт базы:
ddev import-db --file=/tmp/db.sql.gz gzip -dc /tmp/db.sql.gz | ddev import-db
Если дамп не делает DROP TABLE, а вы импортируете его поверх уже существующей базы, можно случайно собрать винегрет из старых и новых данных. В таких случаях лучше сначала убедиться, что база чистая, а уже потом заливать импорт.
Импорт статических файлов
Для wp-content/uploads и других папок с медиа используйте штатную команду:
ddev import-files --source=/path/to/files.tar.gz
Тут есть важный момент: если директория назначения уже существует, DDEV очищает её и заменяет импортируемыми файлами. Команда полезная, но нежная она только на вид. По факту это маленький погрузчик, который сначала выносит старое, а потом завозит новое.
Snapshots как страховка перед правками
Перед крупным импортом, сменой темы, массовым search-replace или экспериментами с плагинами лучше сделать снапшот базы. Это занимает минуты, а экономит нервы очень хорошо.
ddev snapshot ddev snapshot --name before-theme-migration ddev snapshot --list ddev snapshot restore --latest ddev snapshot restore before-theme-migration ddev snapshot --cleanup
Если снапшотов накопилось много, их можно подчистить. Хранить мусор ради истории полезно только до того момента, пока он не начинает есть диск и раздражать.
Типичный сценарий переноса WordPress в DDEV
На практике перенос сайта в локальную среду обычно выглядит примерно так:
cd ~/Projects/wp-test ddev start ddev snapshot --name before-import ddev import-db --file=~/backups/krivoshein.sql.gz ddev wp search-replace 'https://krivoshein.site' 'https://wp-test.ddev.site' --skip-columns=guid --all-tables ddev wp cache flush ddev restart ddev launch
После импорта базы почти всегда нужен search-replace по URL. Иначе локальный сайт будет тянуть старые ссылки, медиа и иногда странно себя вести в админке. WordPress в этом плане консервативен: если ему один раз понравился старый домен, он будет цепляться за него до последнего.
Диагностика и восстановление
Если что-то пошло не так, не надо сразу устраивать ритуальные пляски вокруг Docker. Сначала проверьте статус проекта, логи и встроенную диагностику DDEV.
ddev describe ddev logs ddev logs -s db ddev logs -f ddev utility diagnose ddev restart ddev utility rebuild
Если проект внезапно перестал открываться, часто проблема не в WordPress, а в банальных вещах: контейнер не стартовал, база не поднялась, криво импортировались файлы или вылез конфликт в локальной среде. Логи в таких случаях полезнее любых догадок.
Корректная остановка
Просто остановить проект:
ddev stop ddev poweroff
Удалить данные проекта стоит только если вы точно понимаете, что делаете:
ddev stop --remove-data
Эта команда не про аккуратную паузу, а про полный снос локальных данных контейнеров. Иногда это полезно, когда всё развалилось окончательно. Но запускать её на автомате не стоит.
Короткая шпаргалка на каждый день
Если нужен совсем короткий набор команд, который стоит держать под рукой, то вот он:
ddev start ddev stop ddev restart ddev describe ddev launch ddev ssh ddev wp plugin list ddev import-db --file=backup.sql.gz ddev export-db --file=/tmp/db.sql.gz ddev import-files --source=files.tar.gz ddev snapshot --name before-changes ddev snapshot restore --latest ddev logs
Этого набора хватает для большинства повседневных задач в локальной разработке и при переносе WordPress-проектов. А главное, здесь нет лишней магии. Всё довольно прозрачно: поднял окружение, залил базу, поправил домен, проверил сайт и работаешь дальше.
Итог
DDEV хорош тем, что убирает из локальной разработки лишнюю возню. Не нужно каждый раз вручную собирать контейнеры, вспоминать параметры базы или плясать с конфигами ради очередного тестового сайта. Один раз нормально настроили проект, дальше работаете почти как человек.
Для WordPress это особенно удобно: есть быстрый доступ к WP-CLI, нормальный импорт базы и файлов, снапшоты перед опасными правками и понятные команды для диагностики. Когда таких проектов несколько, разница ощущается особенно хорошо. Нервов уходит меньше, а шансов случайно закопаться в локалке тоже становится заметно меньше.
