Можно ли за один день собрать рабочую кастомную WordPress-тему, развернуть её на шаред-хостинге, добавить мультиязычность и при этом не утонуть в ручной рутине? В моём случае ответ оказался положительным.
Я перенёс сайт-портфолио с тяжёлой темы Porto на собственную тему на базе WordPress Bedrock, собрал локальную среду в Docker, подключил Polylang для четырёх языков, выкатил всё на Hostinger и большую часть повторяемой работы отдал Claude Code.
Почему Bedrock, а не обычный WordPress
Bedrock превращает WordPress из набора файлов, которые правят через FTP, в нормальный проект с зависимостями, переменными окружения и воспроизводимой структурой. Для меня это было ключевым решением.
- Composer управляет ядром, плагинами и темами. Версии фиксируются, а деплой становится предсказуемым.
- Конфигурация вынесена в `.env` и `config/`. Секреты не лежат в репозитории, а dev и production разделены явно.
- Своя логика хранится в `web/app/`. Ядро WordPress живёт отдельно, а репозиторий содержит только то, что реально поддерживается.
- Безопасность лучше по умолчанию. Конфиг и `.env` лежат выше web root.
Локальная среда: Docker + Bedrock
Для локальной разработки я использовал Docker с двумя контейнерами: PHP/Apache и MySQL. Это даёт почти такую же среду, как на проде у Hostinger, и экономит время на неожиданных расхождениях между окружениями.
make init
make up
make down
make shell
make wp CMD="plugin list"Главный плюс здесь не только удобство, а повторяемость. Любой новый разработчик или AI-агент получает одинаковое окружение и одинаковое поведение проекта.
Кастомная тема без JavaScript-фреймворков
Причина отказа от Porto была простой: для сайта-портфолио она слишком тяжёлая. Много JavaScript, jQuery-зависимости, громоздкая вёрстка, лишние HTTP-запросы и слабый контроль над итоговым HTML.
Новая тема строилась вокруг принципа zero-JS where possible: современный CSS, минимальная разметка, локальные ресурсы, никакой зависимости от page builder’ов на фронте.
- `clamp()` для адаптивной типографики
- CSS variables для единой системы цветов
- Grid и Flexbox для сеток
- отключение jQuery и фронтенд-стилей, которые не используются
Как сделать весь текст редактируемым
Самая неудобная часть мультиязычного сайта — тексты. Если хранить строки прямо в шаблонах, проект быстро превращается в хаос. Поэтому я вынес все значения в единый конфиг для Customizer.
return [
'shared' => [...],
'en' => ['front' => [...]],
'ru' => ['front' => [...]],
'uk' => ['front' => [...]],
'es' => ['front' => [...]],
];Дальше тема использует helper-функции, которые собирают имя настройки на основе текущего языка Polylang и достают значение через `get_theme_mod()`.
Polylang и мультиязычность
С Polylang задача была не только в переводе контента, а ещё и в корректных URL. Нужны были чистые префиксы `/ru/`, `/uk/`, `/es/`, а английский должен был остаться языком по умолчанию без префикса.
Самый неприятный баг был связан с `redirect_canonical`, когда WordPress пытался упростить URL и ломал языковой корень. Это было исправлено небольшим must-use плагином, который отключает редирект для валидных языковых root-URL.
Как помог Claude Code
Я не отдавал AI архитектуру. Архитектура, ограничения и проверка были на мне. Но всё, что касалось большого объёма однотипной работы, Claude Code сделал заметно быстрее человека.
- вынес сотни строк в конфиг Customizer
- рефакторил несколько шаблонов сразу
- помог найти точку вмешательства в Polylang и канонические редиректы
- сгенерировал JSON-LD и техническую обвязку
Итоговая экономия времени была существенной. То, что раньше заняло бы несколько дней, уместилось примерно в шесть часов, потому что AI снимал механическую нагрузку, а не подменял инженерное мышление.
Деплой на Hostinger через Git
На проде всё оказалось довольно прямолинейно: SSH, `git pull`, `composer install –no-dev`, проверка сайта. Для Bedrock это естественный путь, потому что весь проект уже собран как приложение, а не как набор случайных правок в админке.
Результаты
- вес страницы снизился в разы
- Lighthouse вырос до высоких девяностых
- JavaScript почти исчез с фронта
- языки: английский, русский, украинский и испанский
- тексты стали редактируемыми из админки
Главный вывод для меня такой: в WordPress очень многое становится проще, если сначала продумать структуру проекта, а уже потом писать шаблоны.
Короткий гайд для старта
- Поставить Git, Docker и Composer.
- Создать проект на Bedrock или клонировать готовый репозиторий.
- Поднять локальную среду через `make init`.
- Сделать собственную тему в `web/app/themes/`.
- Подключить Polylang, настроить языки и проверить URL.
- Настроить деплой по SSH и Git вместо ручного FTP.
Вывод
AI-assisted WordPress development уже вполне практичен. Но хороший результат получается не из-за того, что AI «сам всё сделал», а из-за того, что у проекта есть ясная архитектура, понятные ограничения и человек, который умеет принимать технические решения.
Если делать похожий проект сегодня, я снова выбрал бы связку Bedrock, Docker, Polylang и AI-ассистента для рутинной реализации. Эта комбинация хорошо работает и на локальной разработке, и на проде.
