Управление WordPress через Subversion (SVN) на Linux

Почему использовать SVN для WordPress

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

• нет доступа к панели управления хостингом или FTP;
• вы управляете сервером через SSH;
• хотите централизовать контроль версий на уровне файлов WordPress (темы, плагины, свои правки).

Важно: SVN управляет файлами — база данных WordPress остаётся вне репозитория и требует отдельного резервного копирования.

Список терминов в одну строку

• SVN — Subversion, система контроля версий.
• Тег (tag) — сохранённая версия кода в репозитории.

Требования и подготовка

1. Доступ по SSH к серверу с правами на создание/переименование папок.
2. Установленный Subversion (subversion).
3. Резервная копия wp-config.php, папки wp-content и базы данных.

Установка Subversion на популярных дистрибутивах:

# Ubuntu / Debian
sudo apt-get install subversion

# Fedora / Red Hat / CentOS
sudo yum install subversion

Примечание: команды требуют sudo или root-доступа. Проверяйте репозиторий WordPress на предмет нужной вам версии (тег).

Создание нового блога под контролем SVN

1. Подключитесь к серверу (например, PuTTY или любой SSH-клиент).
2. Перейдите в каталог, где хотите создать сайт:

cd /path/to/a/folder

3. Создайте папку и перейдите в неё:

mkdir blog
cd blog

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

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

Если доступна более новая версия, замените “3.2.1” на нужный тег. После завершения загрузки откройте в браузере URL сайта и пройдите стандартный установочный скрипт WordPress.

Миграция «традиционной» установки в SVN

Этот процесс создаёт новую папку с SVN-контролем и переносит в неё содержимое старой установки.

1. Предварительно сделайте полную резервную копию файлов и базы данных.
2. Перейдите в родительскую папку, где находится текущая установка (не заходите внутрь самой папки сайта):

# допустим, ваша старая папка называется blog
cd /path/to/parent

3. Создайте новую папку, провернув команду checkout нужного тега в папку blog-new (имя папки можно изменить):

svn co http://core.svn.wordpress.org/tags/3.2.1 blog-new

Скачивайте ту же версию WordPress, что стоит на текущем сайте. Если версия не совпадёт, могут возникнуть несовместимости.

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

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

Флаг -p сохраняет время модификации и права. Если .htaccess скрыт, убедитесь, что он скопирован.

5. Скопируйте весь wp-content (плагины, темы, загрузки):

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

6. Проверьте статус SVN в новой папке для обнаружения изменённых файлов (пользовательские файлы, загруженные вручную, будут отмечены как изменённые):

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

• Файл с меткой “M” — модифицирован и не соответствует чистому тегу.
• Если это системный файл WordPress-provided, лучше вернуть его к состоянию тега; если это ваш кастомный файл — оставьте или вынесите в специальную подпапку.

Откат модифицированных файлов к версии из репозитория:

svn revert ../blog-new/wp-content/some/file

7. Скопируйте дополнительные кастомные каталоги и файлы (при необходимости):

cp -rp images wp-digest ../blog-new

8. Проверьте, что всё корректно скопировалось (игнорируем скрытые .svn каталоги):

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

(На примере показан вывод после намеренного удаления некоторых файлов.)

9. Вернитесь в родительскую папку и переименуйте каталоги для окончательной переустановки:

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

Теперь ваш сайт должен работать из папки blog, которая контролируется SVN. Если что-то пошло не так — все старые файлы лежат в blog-old.

Обновление WordPress через SVN

Чтобы переключиться на другой тег/версию (обновить файлы), зайдите в папку сайта и выполните:

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

Замените 3.2.1 на нужный тег. После этого проверьте сайт и выполните обновление базы данных через админ-панель WordPress, если это требуется.

Точки отказа и когда подход не подходит

• Если у вас нет SSH-доступа или нет прав на установку subversion — этот подход неприменим.
• Если вы модифицируете ядро WordPress напрямую, то при переключениях SVN ваши изменения могут быть перезаписаны. Лучше выносить кастомизации в дочернюю тему или плагин.
• Если у вас сложные автоматические развертывания (CI/CD) под Git — возможно, лучше использовать Git-подход.

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

• Git + git-sftp/git-ftp: привычная модель для современных CI/CD.
• WP-CLI: позволяет управлять обновлениями и плагинами из CLI без SVN.
• Управление через панель хостинга (One-click upgrade) — если доступно, это быстрее для простых сайтов.

Риски и меры смягчения

• Потеря данных базы: всегда делайте дамп БД перед миграцией.
• Перезапись кастомных файлов: храните пользовательские модификации отдельно (например, child theme).
• Права файлов: проверяйте права и владельца веб-сервера после копирования.

Рекомендации по безопасности:

• Держите wp-config.php вне веб-доступа, если позволяет структура хостинга.
• Ограничьте доступ к .svn каталогам через веб-сервер (deny).
• Регулярно делайте резервные копии файлов и БД.

Откат и аварийный план

1. Если после переключения что-то не работает, остановитесь и не удаляйте blog-old.
2. Восстановление: переименуйте каталоги обратно:

mv blog blog-failed; mv blog-old blog

3. Проверьте логи веб-сервера и ошибочные плагины.
4. Если проблема в базе данных, восстановите дамп и проверьте таблицы.

Контроль качества и проверка после миграции

• Пройдите по основным страницам сайта, проверьте фронтенд и авторизацию.
• Проверьте работу поиска и ключевых плагинов.
• Просмотрите консоль браузера на предмет ошибок JS.

Чек-листы по ролям

Для администратора сервера:

• Есть SSH-доступ и права на mv/cp/svn.
• Установлен subversion.
• Настроены права и владелец файлов.

Для разработчика:

• Все кастомные изменения вынесены в темы/плагины.
• Есть тестовая копия сайта для проверки.

Для владельца контента:

• Сделан экспорт/резервная копия контента и базы данных.
• Проверены ключевые страницы после миграции.

Проверочные сценарии (test cases)

• Установка новой копии через svn co — сайт открывается и проходит установку.
• После копирования wp-content все темы и плагины отображаются корректно.
• Команда svn sw сменяет релиз, и сайт остаётся работоспособным.

Ментальная модель

Думайте о SVN-версии как о «чистой» копии релиза WordPress (теге). Ваши кастомные файлы — изменения, которые могут конфликтовать с релизом; лучше держать их изолированными.

Совместимость и советы локализации для России и СНГ

• Проверяйте кодировку файлов (UTF-8) после копирования.
• Если используются плагины локализации, не забудьте скопировать /wp-content/languages.

Заключение

Subversion — рабочий инструмент для тех случаев, когда нужно управлять файлами WordPress на сервере без привычных утилит хостинга. Он даёт простой способ контролировать версии и безопасно обновлять файлы. Миграция требует внимательности к конфигурации и резервным копиям, но в большинстве случаев проходит гладко.

Важно: если у вас комплексный workflow с CI/CD и тестированием, рассмотрите Git или WP-CLI как альтернативу.

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

Ключевые материалы по теме: официальное SVN-репозиторий WordPress для тегов — http://core.svn.wordpress.org/tags/

Резюме

• SVN позволяет обновлять файлы WordPress через checkout/switch.
• Миграция создаёт новую SVN-папку и переносит wp-content и конфигурацию.
• Всегда делайте резервные копии файлов и базы данных перед операциями.
• Рассмотрите Git или WP-CLI, если нужно интегрировать CI/CD.