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

11 января 2018

Вы когда-нибудь задавались вопросом, как вы можете использовать Version Control с WordPress? Если вы предпочитаете работать над вашими проектами WordPress локально, но вам нужно синхронизировать их удаленно, этот учебник для вас. Вероятно, вы попытались синхронизировать между двумя настройками, вручную загрузив измененные файлы и используя PHPmyAdmin для экспорта и импорта вашей базы данных после ее изменения и (очень вероятно) что-то сломало в этом процессе. В этом уроке мы собираемся автоматизировать процесс синхронизации; поэтому вы можете сосредоточиться на том, что вы должны делать, а не на борьбе с бесконечными миграциями.


Проблема

Обычно мы запускаем разработку WordPress на наших локальных машинах. Это всегда быстрее и проще, особенно если у вас медленное подключение к Интернету. Но есть моменты, когда вам нужно работать удаленно. Возможно, вы захотите внести небольшие изменения, исправить некоторые дополнения или просто опубликовать новое сообщение. Изменения не сохраняются в вашей локальной установке WordPress, и именно тогда начинается беспорядок.

Беспорядок начинается, потому что вам может потребоваться выпустить новую версию, и поскольку вы работаете локально, изменения, которые вы сделали удаленно, необходимо отключить. Это настоящая боль. Вам нужно выяснить, какие файлы вы изменили и загрузить FTP. Иногда изменения происходят в базе данных, поэтому для внесения изменений вам понадобится специальный инструмент, например phpmyAdmin.

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


Шаг 1 Настройка фонда

Объяснение плана

Во-первых, позвольте мне объяснить, что мы будем делать. Наша цель - легко синхронизировать между удаленной и локальной версиями. Вы будете работать в той версии, которая вам нравится, а затем сделает ее идентичной. Для этого нам нужно сначала учитывать различия между удаленной и локальной настройками.

WordPress хранит информацию о вашем блоге как в статических файлах, так и в вашей базе данных. Часть этой информации относится к вашему текущему хостингу. Поэтому, когда вы загружаете весь каталог WordPress и заменяете удаленную версию, это не сработает.

Информация несчастливо разбита на две части:

Статические файлы: WordPress помещает информацию вашего сервера базы данных в файл wp-config.php. База данных: WordPress помещает URL сайта и домашнюю страницу в таблицу wp-options.

Для wp-config.php мы реализуем процесс, который обнаруживает, находятся ли мы на локальном или удаленном сервере. Таким образом, тот же файл будет работать в обеих средах. Для базы данных мы интегрируем ее с системой управления версиями и обновим ее в соответствии с локальными или удаленными настройками хоста.

Интеграция управления версиями

Я использую Mercurial для управления версиями. Git более популярен на арене веб-разработки, но в нашем случае они почти схожи: вам нужен инструмент управления версиями.

Выберите Mercurial, если вы находитесь на машине Windows. У этого есть Tortoise, удобный интерфейс, чтобы управлять Вашими репозиториями. Инструмент управления версиями должен быть установлен как на вашей локальной, так и на удаленной машине. При этом вам потребуется выделенный сервер или VPS для установки стороннего приложения.

Чтобы инициализировать репозиторий в Mercurial, введите в консоли следующее:

cd /mydev_directory
hg init
hg add
hg commit

В первой строке мы изменим наш рабочий каталог на папку, в которую мы хотим включить управление версиями. Это будет ваш каталог WordPress (где вы будете устанавливать WordPress). Следующая строка инициализирует репозиторий. Третья строка сообщает mercurial для управления версиями всех файлов в каталоге. Сюда также входят подпапки. Последняя строка создает новый набор изменений в каталоге; ваш текстовый редактор откроется, и вам будет предложено написать описание этого коммита.

В этом руководстве не рассматривается использование Mercurial. Если вы не знаете контроля версий, вам следует изучить его. Это важный инструмент для добавления в ваш набор навыков. Вот несколько руководств, которые я предлагаю:

Hginit: Определенно лучший учебник по Mercurial. Mercurial на Ubuntu: в этом учебнике показано, как настроить Mercurial на Ubuntu. Полезно, если вы запускаете Ubuntu на своем VPS или выделенном сервере.


Шаг 2 Настройка локального блога WordPress

Мы сделаем новую установку WordPress на нашей локальной машине. Загрузите последнюю версию WordPress, извлеките ее из пустого каталога по вашему выбору на своем веб-сервере и установите его из своего браузера или изменив файл wp-config.php.

Теперь мы будем активировать контроль версий в нашем каталоге WordPress

cd /testpress
Hg init
Hg add
Hg commit

Эти команды инициализируют репозиторий и создают первый набор изменений. Теперь мы можем просто клонировать этот репозиторий на нашем сервере, устанавливать WordPress и синхронизировать между локальным и удаленным дистрибутивом.

Однако существуют различия, как мы говорили ранее. Перед внедрением процесса синхронизации нам необходимо реализовать скрипт, который проверяет, где работает установка WordPress, и загружает правильные настройки. Параметры, которые необходимо изменить, - это информация о базе данных. Они находятся в файле wp-config.php, и WordPress загружает их из этого файла. Моя локальная версия выглядит так:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'test');
/** MySQL database username */
define('DB_USER', 'root');
/** MySQL database password */
define('DB_PASSWORD', 'xxxxx');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Обратите внимание, что я только скопировал часть, которая имеет значение. На моем удаленном сервере эта часть должна немного отличаться

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'user_blog');
/** MySQL database username */
define('DB_USER', 'root');
/** MySQL database password */
define('DB_PASSWORD', 'xyxyx');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Хитрость заключается в написании кода, который определяет, где находится WordPress. Используемой переменной является переменная PHP _SERVER ["HTTP_HOST"]. Код оценивает переменную и назначает параметры базы данных.

/*
 * Unified variables
 */
$user_name = 'root';
$hostname = 'localhost';
$charset = 'UTF-8';
$collate = '';
/*
 * Check for the current environment
 */
if ($_SERVER["HTTP_HOST"] === 'onlineqrlab.com') {
  $db_name = 'user_wordpress';
  $password = 'xyxyxy';
} else if ($_SERVER["HTTP_HOST"] === 'localhost') {
  $db_name = 'test';
  $password = 'xxxxxx';
}
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', $db_name);
/** MySQL database username */
define('DB_USER', $user_name);
/** MySQL database password */
define('DB_PASSWORD', $password);
/** MySQL hostname */
define('DB_HOST', $hostname);
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', $chartset);
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', $collate);

В приведенном выше примере у меня есть только два измененных параметра: имя базы данных и пароль. У вас может быть больше. Например, если вы размещаете mySql на внешнем сервере, вам нужно будет изменить имя хоста для настройки удаленного сервера. Вам лучше также ограничить доступ блога WordPress до уровня пользователя с ограниченными возможностями вместо уровня администратора.

Проверьте, что ваша локальная версия WordPress работает. Если да, то вы наполовину!


Шаг 3 Синхронизация Mercurial Repositories

Настройка репозитория удаленного сервера

Теперь вы можете начать работу с локальной установкой WordPress. Каждый раз, когда вы делаете крупную модификацию, совершайте комманду с Mercurial для отслеживания изменений. На удаленном сервере, предположив, что у вас установлен Apache, создайте новую папку, в которую вы будете загружать репозиторий WordPress.

cd /apache
mkdir mywp_repo
cd mywp_repo

Обратите внимание, что эти команды должны выполняться на удаленном сервере. Вам потребуется SSH-доступ и командная строка. Я использую Putty для Windows для подключения к моему серверу. Как только наш репозиторий будет инициализирован, мы можем нажать (загрузить) и вытащить (загрузить) наборы изменений из других репозиториев, чтобы поддерживать его в актуальном состоянии. Чтобы этот процесс произошел, вам понадобится локальный или удаленный сервер для публикации репозитория, чтобы вы могли нажать на него.

На веб-сервере Mercurial отсутствуют некоторые важные функции, такие как контроль доступа, аутентификация и SSL. Поэтому использовать его на удаленном сервере небезопасно. Предпочтительно, вам нужно запустить локальный веб-сервер Mercurial и вывести изменения с локального сервера на удаленный сервер. Чтобы запустить сервер Mercurial, введите следующее на своем локальном компьютере:

hg serve

Теперь вы можете получить доступ к своему репозиторию из своего браузера. Введите URL-адрес, который будет отображаться в командной строке. Обычно это localhost: 8000. Репозиторий также доступен в Интернете. Вы можете получить доступ к нему с любого компьютера, подключенного к Интернету, с помощью youripaddress: 8000.

Hg pull  192.xxx.xxx.xxx:8000
Hg update

Но я не рекомендую этот метод, потому что он не безопасен. Это простой и безопасный способ сделать это. Это средний репозиторий, размещенный сторонней службой. Я использую BitBucket. Он имеет хорошее и надежное обслуживание, а также предлагает отслеживание ошибок и вики.

Зарегистрировать и создать учетную запись в BitBucket. Они предлагают неограниченные частные и общедоступные хранилища с до 5 пользователями бесплатно. Создайте новый репозиторий в BitBucket, и его следует перенести на эту страницу.

BitBucket поддерживает HTTPS и SSH. Если ваш репозиторий является приватным, как и в моем случае, вам необходимо пройти аутентификацию с вашим именем пользователя и паролем, чтобы иметь возможность нажать и вытащить из репозитория. Создав новый репозиторий в BitBucket, выполните следующие команды на вашей локальной машине

hg push https://username@bitbucket.org/username/repository

Вас попросят предоставить ваш пароль, и репозиторий будет загружен в BitBucket. После загрузки в BitBucket клонируйте репозиторий на ваш удаленный сервер.

hg clone https://username@bitbucket.org/username/repository
hg update
Cloning загружает файлы в новый каталог (с тем же именем, что и каталог вашего репозитория); вы можете переименовать этот каталог. Это сделает первый шаг в этом разделе (где мы создали каталог установки WordPress) довольно устаревшим.

Подумайте о BitBucket как о среднем человеке между вашим компьютером и вашим удаленным хостом. Возможно, на вашем удаленном сервере есть собственный безопасный сервер Mercurial, но это выходит за рамки данного руководства. Преимущество является независимым от среднего человека. Это позволяет нажимать изменения непосредственно на ваш веб-сервер.

Итак, как это лучше, чем FTP?

    Вам не нужно определять, какие файлы были изменены. Это более удобно и занимает меньше времени. Гораздо быстрее, поскольку Mercurial выталкивает только файлы, которые изменились.

Установка блога удаленного сервера

Уже устали? Не волнуйся, мы почти там. После вытаскивания репозитория с вашего локального компьютера или BitBucket вам нужно будет снова запустить WordPress; на этот раз на удаленном сервере. Убедитесь, что настройки, которые вы ввели в файл wp-config.php, который мы сделали ранее, верны и загрузите ваш удаленный сайт WordPress.

Вас попросят снова установить блог WordPress, потому что ваша база данных пуста. После установки ваш блог WordPress готов. Вы можете вносить изменения в удаленную или локальную версию и синхронизировать их с Mercurial.

Но есть еще одна важная проблема: база данных не синхронизируется с файлами. Это важно, потому что такие вещи, как сообщения в блогах, комментарии, настраиваемые таблицы плагинов... не будут одинаковыми в локальной и удаленной версии. WordPress имеет функцию экспорта импорта. Но это не полезно, поскольку он не выполняет настоящую синхронизацию. Вам нужно перейти на ваш phpmyadmin, экспортировать все ваши таблицы WordPress в одну сторону (удаленную или локальную), а затем перейти на другую сторону phpmyadmin и заменить таблицы.

После этого ваши базы данных WordPress станут такими же. Однако вам нужно изменить строку site_url в таблице wp_options. Этот процесс становится болезненным, поскольку база данных становится тяжелее.


Шаг 4 Синхронизация баз данных

Как мы видели ранее, база данных немного проблематична. Он не синхронизируется с файлами, сложнее достичь и требует обновления двух полей каждый раз при синхронизации. Это не весело делать это снова и снова. Автоматизация - это решение; на самом деле, это наша работа.

Нам нужен скрипт, который синхронизирует локальные и удаленные базы данных, не нарушая ничего. Идея, которая пришла мне в голову, - включить базу данных в элемент управления ревизией. Содержимое базы данных будет экспортировано в файл, который отслеживается с помощью элемента управления ревизией. Каждый раз, когда мы извлекаем изменения, содержимое базы данных будет заменено этим файлом, что сделает нашу базу данных актуальной.

Поскольку существует несколько строк, которые отличаются от хоста к другому (URL-адрес сайта и URL главной страницы), нам нужен еще один скрипт mysql, который обновляет эти значения с правильными значениями. Еще одна важная вещь - конфликты. Если вы работаете и вносите изменения (коммиты) в удалённую и локальную версию, это создаст конфликт. Типичный сценарий - это когда вы работаете и выполняете свою локальную версию, а кто-то (онлайн) добавляет новый контент в ваш блог. Я не могу помочь в этой ситуации, вам нужно узнать о слиянии Mercurial (или вашей системы контроля версий) и совместной работе.

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

Этот шаг немного чувствителен, поэтому убедитесь, что вы внимательно следите за шагами. Во-первых, я расскажу, как работает конечное решение. У вас будет два сценария: push и pull. В зависимости от вашей операционной системы это будут push.sh и pull.sh (Linux) или push.bat или pull.bat (Windows). Я использую Windows локально, а Linux (Ubuntu) удаленно, поэтому этот учебник будет охватывать обе операционные системы.

Первый скрипт будет вызывать изменения на сервере Bitbucket. Когда вы делаете некоторые изменения в базе данных, используйте push-скрипт для загрузки изменений в репозиторий BitBucket. Push будет сбрасывать текущую базу данных в файл (db db_sync.sql), который отслеживается системой управления версиями. Файл будет перемещен вместе с другими файлами и загружен в BitBucket.

Второй скрипт вытащит изменения с сервера Bitbucket. Сценарий pull также прочитает файл (db db_sync.sql) и заменит базу данных. Это приведет к обновлению базы данных с помощью указанной вами версии. Поскольку они имеют разные имена хостов, сценарий pull будет изменять необходимые поля, а именно URL-адрес сайта и URL-адрес главной страницы.

Нажатие на BitBucket

На удаленном и локальном сервере создайте новый каталог под названием «db». Файл экспортируемой базы данных будет сохранен там. На вашем локальном сервере (я предполагаю, что вы используете Windows) создайте новый файл с именем push.bat. Неважно, где вы помещаете файл (просто убедитесь, что вы используете правильные пути). Я помещаю файл в корневую директорию моего репозитория WordPress.

mysqldump -u username -ppassword database_name > db/db_sync.sql
hg add db/db_sync.sql
hg commit
hg push https://username@bitbucket.org/username/repository
Вы можете удалить команду «hg add db db_sync.sql» после выполнения сценария в первый раз. Это требуется только один раз.

На стороне сервера (Linux Ubuntu) все совсем не так. Расширение файла изменяется с.bat на.sh и, возможно, на имя пользователя, пароль и имя базы данных mySql. Содержимое файла точно такое же.

Вытягивание с BitBucket

Тяга немного сложнее. Он требует импорта файла SQL, а также изменения некоторых критических полей, которые отличаются от среды к другой.

На вашей локальной машине создайте файл с именем pull.bat

hg pull https://username@bitbucket.org/username/repository
hg update
cd db
mysql -u username -ppassword testpress < db_sync.sql
mysql -u username -ppassword testpress < db.sql

В папке db добавьте файл под названием «db.sql». В этом файле содержатся инструкции SQL, которые будут выполнять необходимые изменения в соответствии с настройками хоста. Вы можете добавить больше заявлений, если вам нужно.

USE testpress;
UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="siteurl";
UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="home";

Помимо расширения файла, настройки mySql и базы данных на самом деле не изменяются на удаленном сервере. Это происходит потому, что мы выполняем команды программ. Команды и их использование являются агностиками платформы. Убедитесь, что вы ввели правильные значения для URL-адреса веб-сайта в файле «db.sql». Они должны соответствовать URL вашего блога, если вы не уверены, что можете проверить значения в таблице wp_options.

Чтобы запустить сценарии, в Windows дважды щелкните файл «.bat», а на удаленном терминале сервера запустите команду «sh script_name.sh».

Процесс

Теперь у вас должно быть 2 исполняемых файла в каждой среде (pull и push). Вы также должны иметь sql-скрипт (db.sql), который не должен быть добавлен в управление версиями. Теперь мы можем протестировать нашу небольшую систему.

    На вашем локальном компьютере добавьте новое сообщение в блоге. Нажмите на изменения с локальной машины. Перетащите изменения на удаленном компьютере. Проверьте, работает ли блог правильно и добавлено сообщение в блоге.