WordPress + Subversion: установка и миграция

Схема: WordPress управляется через Subversion на сервере

Введение

WordPress управляет миллионами сайтов. Одна из полезных возможностей — загрузка исходников через репозиторий Subversion, который поддерживает Automattic (команда WordPress). Это даёт простой способ обновлять файлы сайта без FTP: вы используете клиент SVN прямо на сервере.

Далее показаны три сценария:

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

Важно: мы не меняем базу данных — это про файловую структуру установки (копирование wp-config.php, папки wp-content и т.д.). Всегда делайте полную резервную копию файлов и базы данных перед началом.

Что нужно подготовить

Доступ к серверу по SSH (например, PuTTY или встроенный терминал).
Права на создание/переименование директорий и изменение файлов (пользователь, от имени которого вы запускаете команды).
Установленный клиент Subversion (SVN).

Установка SVN на распространённых дистрибутивах Linux:

# Debian / Ubuntu
sudo apt-get install subversion

# Fedora / RHEL / CentOS
sudo yum install subversion

Проверьте версию командой:

svn --version

Если команда возвращает версию — SVN установлен.

Создание нового блога под SVN

Подключитесь к серверу по SSH.
Перейдите в каталог, где будут храниться сайты:

cd /path/to/a/folder

Создайте новую папку для блога и перейдите в неё:

mkdir blog
cd blog

Загрузите файлы WordPress из официального SVN-репозитория. Замените 3.2.1 на нужную вам версию. Обратите внимание на точку в конце команды — она означает «в текущую директорию»:

svn co http://core.svn.wordpress.org/tags/3.2.1 .

Иллюстрация: загрузка WordPress из репозитория Subversion

Дождитесь окончания загрузки, затем откройте в браузере URL сайта и пройдите стандартный web-инсталлятор WordPress (подключение к БД, создание аккаунта администратора и т.п.).

Примечание: если хотите автоматически поддерживать последнюю ветку, используйте тег нужной ветки или trunk, но помните: trunk — это текущая стабильная разработка и может содержать изменения чаще, чем стабильные теги.

Конвертация существующего сайта в SVN-контролируемый

Этот процесс создаёт новую папку с файлами из репозитория и переносит туда ваши локальные данные (wp-config.php, wp-content и дополнительные файлы). Подготовьте резервные копии перед началом.

Шаги:

На уровень выше папки с текущим блогом. Предположим, что исходный блог находится в каталоге blog, а временный — будет blog-new.

# вы должны быть на один уровень выше каталога blog
svn co http://core.svn.wordpress.org/tags/3.2.1 blog-new

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

Скопируйте важные конфигурационные файлы в новую папку:

cd blog
cp -p wp-config.php .htaccess ../blog-new

Опция -p сохраняет метаданные (владельца/время модификации).

Скопируйте содержимое wp-content (плагины, темы, загруженные файлы):

cp -rpfu wp-content/* ../blog-new/wp-content

Параметры cp: r — рекурсивно, p — сохранить атрибуты, f — перезаписать, u — копировать только если файл новее.

Проверка статуса SVN в новой папке — файлы, которые отличаются от исходников WordPress, будут помечены:

svn status ../blog-new/wp-content

Флаги SVN:

M — файл изменён
? — неотслеживаемый файл (новые, локальные)
A — файл добавлен в индекс

Если вы видите M для файлов, которые должны оставаться изменёнными (напр., кастомные темы), оставьте их — SVN показывает различия между скачанным исходником и вашими файлами. Для файлов, которые не должны быть под версионным контролем, используйте svn revert или удалите их из рабочей копии.

Примеры команд для отката изменений или управления файлами:

svn revert ../blog-new/wp-content/some/file
cp -rp images wp-digest ../blog-new

Сравните директории, чтобы убедиться, что всё скопировано:

diff -rq blog/ blog-new/ | grep -v svn

Результат: пример удалённых файлов после намеренного удаления

Когда всё готово, перейдите на уровень выше и переименуйте папки:

cd ..
mv blog blog-old; mv blog-new blog

Теперь текущая рабочая папка blog — это SVN-контролируемая копия. Сохраните blog-old на случай необходимости восстановления.

Важно: проверьте права владельца и групп на файлы после перемещения — веб-сервер (www-data, apache, nginx и т.п.) должен иметь нужные права на чтение/запись для директорий uploads и т.п.

Обновление сайта через SVN

Когда выходит новая версия WordPress, вы можете обновить файлы через SVN, оставаясь в каталоге сайта:

svn sw http://core.svn.wordpress.org/tags/3.2.1/ .

Здесь svn sw (switch) переключает вашу рабочую копию на указанную метку. Всегда заменяйте номер версии на требуемый.

После обновления файлов может потребоваться запуск страницы /wp-admin/ для обновления схемы БД, если обновление включает изменения в базе.

Критерии приёмки перед переключением на production

Есть полная резервная копия файлов и дамп базы данных.
Тестовая копия сайта успешно открывается в браузере без ошибок PHP/500.
Папка wp-content содержит все необходимые темы и плагины, и плагины активны в тестовой среде.
Проверены права доступа и владение файлами (веб-сервер имеет доступ к uploads).

План отката и экстренный runbook

Если после mv blog-new blog сайт не работает — немедленно верните старую папку:

mv blog blog-new-failed; mv blog-old blog

Восстановите права, если они были изменены, и откатите изменения базы данных из дампа (если было применено изменение схемы).
Логируйте все шаги и диагностируйте ошибки в логах веб-сервера и PHP.

Роли и чеклисты

Администратор сервера:

Резервное копирование файлов и базы.
Проверка прав и владельца файлов.
Установка клиента SVN.

Владелец сайта / контент-менеджер:

Проверка контента после миграции.
Тестирование загрузки файлов в медиатеке.

Разработчик:

Проверка совместимости активных плагинов и тем.
Тесты функциональности (форма, вход, корзина и т.д.).

Сценарии тестирования и критерии приёмки

Тест 1 — Базовая загрузка:

Открыть главную страницу; статус 200; отображение контента.

Тест 2 — Логин в админку:

Войти под администратором; перейти в раздел Плагины; убедиться, что плагины видимы.

Тест 3 — Загрузка файла:

Загрузить изображение в Медиафайлы; убедиться, что файл появился в папке uploads.

Тест 4 — Обновление темы/плагина:

Активировать тему; проверить отсутствие ошибок PHP.

Критерии приёмки: все тесты — пройдены, логи ошибок чисты.

Безопасность и рекомендации по жёсткой настройке

Ограничьте доступ к svn-командам пользователям, которые действительно нуждаются в них.
Установите корректные права для wp-config.php (600 или 640) и .htaccess (644).
Не храните секреты в публичных репозиториях.
Настройте регулярные резервные копии файлов и БД на отдельном хранилище.
Для публичных серверов рассмотрите использование HTTPS и отключение root-доступа по SSH (используйте sudo).

Частые ошибки и как их исправить

Пропущена точка в команде svn co — файлы загрузятся в папку с именем тега вместо текущей директории. Решение: повторите команду с точкой либо переместите файлы в нужную директорию.
Неправильные права доступа — сайт выдаёт ошибки при загрузке файлов. Решение: исправьте владельца на пользователя веб-сервера и присвойте корректные права.
Неправильная версия SVN — если репозиторий и ваша версия WP отличаются, плагины могут конфликтовать. Решение: используйте ту же версию, что и в старой установке, либо обновляйте плагины совместимо.

Дополнительные советы и альтернативные подходы

Альтернатива: использовать Git вместо SVN. Git удобнее для локальной разработки и ветвления, но официальная инфраструктура WordPress использует SVN, поэтому интеграция требует дополнительных шагов.
Для автоматизации можно написать скрипт deploy.sh, который будет выполнять backup -> svn switch -> проверка -> уведомление.
Для сайтов с частыми изменениями контента (медиа, загрузки) держите uploads вне версионного контроля и резервируйте отдельно.

Небольшая методология миграции (мини-план)

Резервная копия (файлы + БД).
Создание рабочей копии из SVN (blog-new).
Копирование wp-config.php и wp-content.
Проверка локально/на тестовом субдомене.
Переключение директорий и финальная проверка.
Мониторинг логов 24–48 часов.

Примеры команд и шпаргалка

Скачать конкретную версию в текущую папку:

svn co http://core.svn.wordpress.org/tags/3.2.1 .

Переключиться на другую метку:

svn sw http://core.svn.wordpress.org/tags/3.2.1/ .

Проверить статус в директории:

svn status path/to/dir

Откатить изменения в файле:

svn revert path/to/file

Совместимость и нюансы

Используйте ту же версию WordPress, что и в исходной инсталляции, при конвертации: разница в версиях может требовать обновления структуры БД.
Плагины и темы, не входящие в ядро WordPress, остаются вашими локальными файлами — они не загружаются из core-репозитория и будут показаны как изменённые или неотслеживаемые.

Короткое резюме

Subversion — удобный способ управлять файловой частью WordPress на серверах без FTP. Конвертация — безопасный процесс, если вы делаете резервные копии и проверяете версии. После миграции можно удобно переключаться между релизами через svn switch.

Важно: всегда тестируйте изменения в тестовой среде и имейте план отката.

Ключевые ссылки и команды на память: