В прошлой статье я рассказал о переносе проекта на WordPress в Git и его разворачивании через панель D2C. Способ приемлемый. Однако, в нем есть ряд недостатков: приходится создавать 2 версии конфигурации, каждый раз обращаться к файловой системе, хранить реквизиты доступа к рабочей базе в репозитории, выгружать туда же все плагины и обновлять версию ядра вручную. Теперь расскажу, как эти недостатки разом устранить.
Артём Зайцев
Evilmarketer
Что понадобится
Для реализации задумки я воспользуюсь Bedrock, создам немного переменных в окружении сервиса (environment variables) и поработаю с файлом composer.json.
Почему Bedrock
Bedrock — это надстройка для разработки сайтов на WordPress. В нем улучшена структура проекта, изменяемые части приложения и ядро WordPress разделены, используется “Composer” для управления зависимостями, а вся конфигурация происходит с помощью переменных окружения.
Для нашей задачи и работы с D2C bedrock подойдет идеально. Нам не нужно будет хранить все плагины и ядро WordPress в репозитории с приложением, их мы будем подтягивать при каждом обновлении исходников, а хранить настройки будем непосредственно в сервисе, а не в Гите. Итак, поехали.
Шаг 1. Создаем dev-версию локально
Нам понадобится Composer, если таковой еще не стоит. Если вы работаете под Windows, достаточно будет воспользоваться инсталлером, для Mac OS и Linux придется установить из консоли.
Теперь создадим удаленный репозиторий и клонируем его в чистую папку с будущем проектом на локальной машине.
Я использую Bitbucket и Source Tree, мне так удобно. Если раньше с Гитом не работали, рекомендую пройтись по обучающему курсу о создании репозитория и работе с SourceTree на офф. Сайте.
Далее, в созданной пустой папке, нужно развернуть Bedrock. Это можно сделать двумя способами:
composer create-project roots/bedrock

composer install
.
Обратите внимание, во время установки Bedrock уже подтянул ядро WordPress и необходимые для своей работы плагины. Сама установка WP хранится в каталоге /web/wp, а в папке /web/app хранятся плагины, темы и загрузки.

Каталог mu-plugins расшифровывается как «must to use plugins». Здесь хранятся плагины, которые должны быть непременно активны на момент деплоя, их также будет не возможно деактивировать в админке. Все остальные расширения идут в папку plugins.
Чтобы прописать реквизиты доступа к базе и прочие настройки, надо создать файлик .env в корне с таким содержимым:
DB_NAME=database_name DB_USER=database_user DB_PASSWORD=database_password # Optional variables # DB_HOST=localhost # DB_PREFIX=wp_ WP_ENV=development WP_HOME=http://example.com WP_SITEURL=${WP_HOME}/wp # Generate your keys here: https://roots.io/salts.html AUTH_KEY='generateme' SECURE_AUTH_KEY='generateme' LOGGED_IN_KEY='generateme' NONCE_KEY='generateme' AUTH_SALT='generateme' SECURE_AUTH_SALT='generateme' LOGGED_IN_SALT='generateme' NONCE_SALT='generateme'
Шаг 2. Указываем необходимые плагины в качестве зависимостей приложения
Для начала определимся с плагинами, которые находятся в свободном доступе через каталог WordPress.com. Композер возьмет их из https://wpackagist.org. Для примера я добавлю плагин WP Supercache.
Для начала найдем пакет в каталоге, убедимся, что он там есть и посмотрим, какие версии доступны.

Пакет называется wp-super-cache, максимальная доступная стабильная версия 1.6.4
Добавим его в список зависимостей композера. Чтобы это сделать воспользуемся командой «require», имеющей следующий вид: composer require <namespace>/<packagename>:<version>
composer require wpackagist-plugin/wp-super-cache:^1.6.4
В данном случае при указании версии я поставил “^” и устанавливаться будут плагины без критических изменений вплоть до 2.0.
Если плагина нет в официальном каталоге, задача немного усложняется. Чтобы добавить в список зависимости свое расширение, недоступное для паблика, потребуется создать для него отдельный репозиторий и описать исходники файлом composer.json с примерно таким содержимым:
{ "name": "evilmarketer/projectbundle", "description": "Improve your work", "keywords": [ "wordpress", "project bundle" ], "homepage": "https://homepage", "license": "GPL-2.0-or-later", "authors": [ { "name": "YoYO", "email": "support@yoyo.com", "homepage": "https://youhomepage" } ], "type": "wordpress-plugin", }
В моем случае используется еще и приватное хранилище, поэтому дополнительную сложность добавит авторизация. Для неё создадим файлик auth.json в корне проекта на Bedrock со следующим содержимым:
{ "bitbucket-oauth": { "bitbucket.org": { "consumer-key": "YOURKEY", "consumer-secret": "YOURSECRET" } } }
Consumer key и secret можно получить в разделе Bitbucket settings/OAuth.
Добавим еще один репозиторий в composer.json к уже существующему “wpackagist”. На выходе должно получиться следующее:
"repositories": [ { "type": "composer", "url": "https://wpackagist.org" }, { "type": "vcs", "url": "https://bitbucket.org/evilmarketer/projectbundle" } ]
Теперь выполним команду require вида: <owner>/<repo>:<dev-master>
composer require evilmarketer/projectbundle:dev-master
Готово. Нужный плагин добавлен в список зависимостей.
Шаг 3. Пушим изменения в Git и разворачиваем проект в D2C
Основная работа у вас будет проходить в папке с темой web/app/themes. На первых порах я рекомендую работать непосредственно там. В теории, можно для шаблона создать отдельный репозиторий и указать в качестве зависимости, как и в примере с собственным плагином. Однако, такие телодвижения в большинстве будут лишними и добавят неудобств при деплое. Поэтому условимся на том, что пока наша тема лежит в папке web/app/themes
К изменениям в проекте нужно сделать коммит и отправить в удалённый репозиторий (bitbucket, в нашем случае). Теперь проект готов к деплою.
Разворачивается Bedrock очень легко. Для этого возьмем сервис “php-fpm”. В нем нужно будет указать:
1. Ссылку на репозиторий.

2. Команду ‘composer install’ в Local dependencies.

3. Похожим образом как и в файлике .env, указать Environment Variables. Получиться должно примерно следующее:

В переменной “WP_SITEURL”, надо обязательно указывать ссылку до папки /wp
4. В настройка NGINX в секции server > root также добавим путь до папки /web. Должно получиться так:
root /var/www/$serviceName/web;
Готово. Больше пароли не хранятся в нашем репозитории, а нужные плагины устанавливаются как зависимости и обновляются до нужной версии. Красота!
На этом все
В следующий раз расскажу о Sage и сборке шаблона на этапе разворачивания приложения.