Использование Git при работе с WordPress и перенос проекта в D2C

Кто работает с Git, уже оценил все преимущества такой организации разработки. Можно без проблем откатить вредные изменения, наладить коллаборацию между десятками разработчиками и прозрачно контролировать все изменения, которые происходят с кодом.

Так уж вышло, что подавляющее большинство разработчиков, использующих WordPress, этим инструментом пользуются относительно редко. Отчасти это связано с отсутствием встроенной модели “development staging production” внутри движка.

Артём Зайцев

Evilmarketer

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

Подробнее
о Bedrock

Перенос проекта в production вынуждает делать множество ручных действий, которые не позволяют полноценно интегрировать Git в цикл разработки. Грубо говоря, поменять на “локалке” и перезалить через FTP сильно проще. Проиллюстрирую к каким проблемам ведет подобная организация работы.

Стандартный метод разворачивания проекта на WP в Production.

У метода есть ряд недостатков:

  1. При необходимости развернуть копию сайта локально после запуска сайта придется заново выкачивать всю статику: изображения, документы и т.д.
  2. Актуальные изменения на FTP и в локальной копии невозможно контролировать. Особенно это осложняется, если к работе вы подключаете нескольких разработчиков. А это значит, что и исходники приложения придется тоже выкачивать каждый раз.
  3. Если произошло много изменений на локалке и при переносе файлов в рабочий проект появляются ошибки, сайт может очень долго простоять сломанным, пока разработчик поймет в чем дело. В случае с Гитом нет проблем откатить версию.

Разворачивание проекта на WP в Production из Git

Такой метод перечисленных выше недостатков лишен:

  1. Приложение организовано таким образом, что вся статика хранится на отдельном файловом сервере, её не нужно перекачивать с FTP и на FTP.
  2. Версия всегда актуальная, а её изменения находятся под контролем. Достаточно клонировать репозиторий новому разработчику, провести пару нехитрых действий и приступать к работе.
  3. Если произошли изменения, которые сломали проект в продакшене (ну, например, вы этакий бесстрашный тип, который выкатывает все без тестирования), откатить версию можно без проблем.

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

Создаем 2 версии конфигурации для разработки и продакшена

Чтобы пушить и разворачивать сразу из Гита, понадобится создать 2 конфига с разными реквизитами и настройками. Чтобы их сделать, возьмем за основу дефолтный.

Просто пару раз скопируем его и переименуем в “production-config” и “local-config”. Первый будет лежать в Гите, второй только локально.

Создадим проверку на наличие файла “local-config”. Если его не будет в наличии, будет использоваться “production-config”. Для этого удалим все, что есть в файле “wp-config” и напишем немного кода:

/* Переопледеляем конфиги, чтобы для локальной разработки и деплоя использовать разные файлы */

if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {

include( dirname( __FILE__ ) . '/local-config.php' );

define( 'WP_LOCAL_DEV', true );

} else {

include( dirname( __FILE__ ) . '/production-config.php' );

}

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

define('WP_DEBUG', true);

@ini_set('display_errors', 1);

error_reporting('E_ALL');

В обоих конфигах нужно прописать соответствующие реквизиты баз данных.

Production

Local

Чтобы не делать каждый раз замены адреса сайта в базе данных, пропишем адрес сайта и главной страницы жестко. Для локального сайта адрес будет http://wordpress, для продакшена, допустим, https://daisy-www.j17hxyfx1.at.d2c.io:

define('WP_HOME','http://wordpress');
define('WP_SITEURL','http://wordpress’);

define('WP_HOME','https://asdasd.d2c.io');
define('WP_SITEURL','https://asdasd.d2c.io’);

Чтобы корректно функционировал SSL, в “Production-config” укажем:

$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)

Чтобы в Гит попадали только нужные файлы, надо запретить индексировать ряд файлов в .gitignore:

local-config.php
wp-content/cache/*
wp-content/uploads/*

Готово. Теперь в Гите будет только приложение: без статики и без локального конфига.

Переносим всю статику на файловый сервер

Хранить статику желательно отдельно. Для этой цели подойдет AWS, так как есть готовый плагин. Как альтернативу я использую Selectel.

AWS

Чтобы использовать AWS для хранения файлом понадобится Offload S3 plugin. Чтобы настроить плагин на работу с вашими бакетами, нужно указать в wp-config.php реквизиты доступа к аккаунту амазона.

Access ID и Secret key можно получить в разделе My security credentials в личного кабинета.

После пройденных действий создать бакет можно прямо из плагина.

Либо можно выбрать из уже существующих.

После выбора Бакета активируется работа с AWS и страница с детальными настройкам. Я предпочитаю обычно не хранить статику на сервере приложения, поэтому активирую соответствующий пункт.

Все, теперь изображения и любые вложения будут храниться на удаленном сервере AWS. В этом можно убедиться.

Если необходимо пакетно загрузить существующие файлы на AWS понадобится купить платную версию плагина.

Selectel

Чтобы загружать статику на Селектел пригодится плагин “Selectel Storage Upload”. Для настройки понадобится создать публичный контейнер.

Затем создать пользователя с правами на запись в этот контейнер.

Логин и пароль пользователя, а также название контейнера нужно будет указать в странице настроек плагина.

Чтобы заменить все ссылки на сайте, нужно указать Full url-path. В вашем случае это будет https://your-acc-id.selcdn.ru/container-name. Как видно из названия ссылка, контент будет раздаваться через CDN.

Если нет необходимости хранить файлы на сервере приложения, отметьте галочку “Store files only in the Selectel Storage”.

В заключение

После описанных действий вы можете без проблем размещать проект в Git и разворачивать непосредственно оттуда. В D2C останется лишь указать адрес репозитория и ветку.

Теперь вся статика хранится на отдельном файловом сервере, а локальный и продакшн конфиги разделены. В следующий раз расскажу как использовать Bedrock и не хранить реквизиты базы в Git. Хороших всем коммитов!