Wordpress Bedrock: реквизиты в настройках сервиса и плагины в качестве зависимостей - D2C — Platform for configuring, deploying and scaling apps with Docker

В прошлой статье я рассказал о переносе проекта на 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. Это можно сделать двумя способами:

1. С помощью команды composer create-project roots/bedrock

2. Клонировать или скачать исходники к себе в папку и запустить 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 и сборке шаблона на этапе разворачивания приложения.