Статьи

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

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


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

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

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


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

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

Информация, к несчастью, разбита на две части:

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

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

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

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

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

1
2
3
4
cd /mydev_directory
hg init
hg add
hg commit

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

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

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

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

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

1
2
3
4
cd /testpress
Hg init
Hg add
Hg commit

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
// ** 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.
define(‘DB_COLLATE’, »);

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
// ** 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.
define(‘DB_COLLATE’, »);

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/*
 * 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.
define(‘DB_COLLATE’, $collate);

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

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


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

1
2
3
cd /apache
mkdir mywp_repo
cd mywp_repo

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

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

1
hg serve

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

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

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

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

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

1
hg push https://[email protected]/username/repository

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

1
2
hg clone https://[email protected]/username/repository
hg update

Клонирование скачать файлы в новый каталог (имя совпадает с именем вашего каталога репозитория); Вы можете переименовать этот каталог. Это сделает первый шаг в этом разделе (где мы создали каталог установки WordPress) довольно устаревшим.

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

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

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

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

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

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

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


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

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

Поскольку есть несколько строк, которые отличаются от хоста к другому (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. Сценарий извлечения также прочитает файл (/db/db_sync.sql) и заменит базу данных. Это обновит базу данных с версией, которую вы нажали. Поскольку у них разные имена хостов, скрипт извлечения изменяет необходимые поля, а именно URL сайта и URL домашней страницы.

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

1
2
3
4
mysqldump -u username -ppassword database_name > db/db_sync.sql
hg add db/db_sync.sql
hg commit
hg push https://[email protected]/username/repository

Вы можете удалить команду «hg add db / db_sync.sql» после первого запуска сценария. Это требуется только один раз.

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

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

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

1
2
3
4
5
hg pull https://[email protected]/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, которые внесут необходимые изменения в соответствии с настройками хоста. Вы можете добавить больше заявлений, если вам нужно.

1
2
3
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), который не должен добавляться в управление версиями. Теперь мы можем проверить нашу маленькую систему.

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