Переключение основного сайта в WordPress Multisite
Мы управляем несколькими сайтами на поддоменах в среде WordPress Multisite и хотим переключить основной сайт с корневого домена на поддомен следующим образом:
Текущий сайт - example.com
с ID 1
(нельзя переименовать, так как поле установлено и недоступно для редактирования)
Новый сайт - new.example.com
с ID 15
(пытались переименовать в example.com
)
Я следовал некоторым инструкциям по переключению, которые включали переименование сайтов и обновление файла wp-config.php
для установки нового ID 15 для SITE_ID_CURRENT_SITE
и Blog_ID_CURRENT_SITE
. В результате главный сайт не изменился, а админка была нарушена.
Существует ли простой способ заменить главный сайт на сайт с поддомена без импорта записей/страниц и плагинов?
ОБНОВЛЕНИЕ:
Спасибо за эти советы. Мой вывод, исходя из того, что я увидел в базе данных, прочитал и получил от вас, заключается в том, что новый сайт на поддомене, который должен заменить главный сайт, должен иметь базовые имена таблиц и ID 1, обновленные пути и т.д. Моё единственное беспокойство заключается в том, что после переключения этих параметров могут возникнуть проблемы с сетевым администрированием -- поэтому мне нужно сравнить базовые таблицы (wp_options и т.д.) с эквивалентными (wp_x_options и т.д.), чтобы увидеть, есть ли что-то уникальное, связанное с сетевым администрированием в этих базовых таблицах.

Четыре года без ответа? Что ж, давайте разберёмся...
Возьмём следующую сетевую настройку в качестве примера (использую команду списка сайтов WP-CLI):
$ wp site list
+---------+--------------------+---------------------+---------------------+
| blog_id | url | last_updated | registered |
+---------+--------------------+---------------------+---------------------+
| 1 | http://wp.tmp/ | 2016-08-04 08:39:35 | 2016-07-22 09:25:42 |
| 2 | http://foo.wp.tmp/ | 2016-07-22 09:28:16 | 2016-07-22 09:28:16 |
+---------+--------------------+---------------------+---------------------+
Список сайтов сети будет выглядеть так:
Мы хотим использовать сайт с ID 2
в качестве нового корневого сайта с URL http://wp.tmp/
. Это та же самая проблема, что описана в вопросе, только с другими значениями ID и URL.
Часть wp-config.php
, относящаяся к мультисайту, вероятно, выглядит так:
const MULTISITE = TRUE;
const DOMAIN_CURRENT_SITE = 'wp.tmp';
const PATH_CURRENT_SITE = '/';
const SITE_ID_CURRENT_SITE = 1;
const BLOG_ID_CURRENT_SITE = 1;
const SUBDOMAIN_INSTALL = TRUE;
Обновление настроек сайта в базе данных
WordPress использует таблицы wp_*_option
и wp_blogs
для поиска соответствующего блога по заданному URL запроса и построения правильных постоянных ссылок для этого блога. Поэтому нам нужно изменить значения в следующих трёх таблицах (для данного примера):
- В
wp_options
ключиhome
иsiteurl
- В
wp_2_options
ключиhome
иsiteurl
(в вашем случае это будетwp_15_options
) - В
wp_blogs
столбецdomain
для обоих сайтов с ID1
и2
(соответственно15
)
Я использую Adminer для этого, но подойдёт любой другой инструмент управления БД (например, PhpMyAdmin). (Скриншоты показывают интерфейс на немецком языке, но, думаю, суть ясна.)
В wp_options
(таблица опций для сайта с ID 1
) я изменил значения обоих ключей home
и siteurl
с http://wp.tmp
на http://foo.wp.tmp
. (Скриншот выше показывает состояние до обновления.)
То же самое я сделал с таблицей wp_2_options
, но здесь я изменил значение с http://foo.wp.tmp
на http://wp.tmp
.
Следующий шаг — обновление таблицы wp_blogs
:
(Опять же, скриншот показывает таблицу до внесения изменений.) Здесь нужно просто поменять местами значения в столбце
domain
для обоих сайтов:
wp.tmp
меняем наfoo.wp.tmp
иfoo.wp.tmp
меняем наwp.tmp
Теперь нужно обновить wp-config.php
для корректной работы с новыми настройками:
const MULTISITE = TRUE;
const DOMAIN_CURRENT_SITE = 'wp.tmp';
const PATH_CURRENT_SITE = '/';
const SITE_ID_CURRENT_SITE = 1;
const BLOG_ID_CURRENT_SITE = 2; // Это новый ID корневого сайта
const SUBDOMAIN_INSTALL = TRUE;
На этом этапе у вас снова рабочая мультисайт-сеть WordPress, но с новым корневым сайтом:
$ wp site list
+---------+--------------------+---------------------+---------------------+
| blog_id | url | last_updated | registered |
+---------+--------------------+---------------------+---------------------+
| 1 | http://foo.wp.tmp/ | 2016-08-04 08:39:35 | 2016-07-22 09:25:42 |
| 2 | http://wp.tmp/ | 2016-07-22 09:28:16 | 2016-07-22 09:28:16 |
+---------+--------------------+---------------------+---------------------+
Помните: в процессе выполнения этих действий ваш сайт будет недоступен, а запросы будут завершаться ошибками, поэтому стоит настроить ответ 503 Service Unavailable
перед установкой WordPress. Это можно сделать с помощью .htaccess
.
Обновление содержимого базы данных
Теперь самая сложная часть. На данный момент все URL в таблицах содержимого по-прежнему указывают на ресурсы старых сайтов. Но замена их не так проста: если сначала заменить все http://foo.wp.tmp
на http://wp.tmp
, а затем все http://wp.tmp
на http://foo.wp.tmp
, в итоге все прежние URL будут указывать на сайт с ID 1 (http://foo.wp.tmp
).
Лучший способ — добавить промежуточный шаг:
- Найти
http://foo.wp.tmp
и заменить на уникальный слаг:http://3a4b522a.wp.tmp
- Найти
http://wp.tmp
и заменить наhttp://foo.wp.tmp
- Найти
http://3a4b522a.wp.tmp
и заменить наhttp://wp.tmp
Все эти команды поиска и замены должны игнорировать три таблицы (*_options
, *_blogs
), которые мы обновили ранее, иначе они нарушат конфигурацию. Также стоит вручную проверить URL в таблице wp_*_options
за пределами ключей home
и siteurl
.
Я рекомендую использовать команду search-replace в WP-CLI, так как она умеет работать с сериализованными данными и не имеет ограничений, которые могут быть у HTTP.

+1 за хороший и детальный обзор. Было бы удобно иметь пользовательскую команду wp-cli для этого ;-) Вы ссылаетесь на вопрос "4-летней давности", но вопрос был задан 12.07.2016. PS: Вчера заметил, что Adminer больше не доступен в каталоге плагинов на wordpress.org.

Ха, надо бы перепроверять даты. Adminer на самом деле является автономным приложением, состоящим из одного PHP-файла. Нет необходимости использовать плагин в данном случае. Я написал плагин, который по крайней мере позволяет изменять URL сайта через WP-CLI: https://github.com/inpsyde/wp-cli-site-url

Да, я в курсе, несколько раз меня просили извлечь данные из заброшенных сайтов без какого-либо доступа по ssh/ftp/cpanel и т.д. В таких случаях версия в виде плагина становится удобной ;-) Спасибо за ссылку, выглядит как полезный плагин, который ты создал.

Отличный ответ, я просто в шоке, что никто не написал плагин для этого... Есть ли плагин для такого? 3 простых шага! И довольно предсказуемо. Как вы до этого додумались? :D

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

Более простое решение (не требующее изменения кода) — использовать плагин all-in-one-migration:
- экспортировать сайт
new.example.com
сID 15
и - импортировать его в
example.com
сID 1

Согласен. У нас был подсайт, который нужно было заменить на корневой. Импортировали напрямую поверх корневого сайта с помощью All-in-One Migration с мультисайтовым дополнением.

Хотя это переносит данные сайта, это не меняет главный сайт - ID1 это место, где находится все основное администрирование и мультисайтовые настройки, неясно, хотел ли автор вопроса перенести данные сайта или сделать другой сайт основным.
