Переключение основного сайта в WordPress Multisite

12 июл. 2016 г., 09:40:55
Просмотры: 29.5K
Голосов: 10

Мы управляем несколькими сайтами на поддоменах в среде 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 и т.д.), чтобы увидеть, есть ли что-то уникальное, связанное с сетевым администрированием в этих базовых таблицах.

2
Комментарии

На всякий случай, если это не опечатка выше, должно быть с заглавной буквы BLOG_ID_CURRENT_SITE, и я думаю, что SITE_ID_CURRENT_SITE, вероятно, должен оставаться 1 (чтобы соответствовать таблице wp_site). Смотрите код в wp-includes/ms-settings.php, который использует это для настройки $current_site->blog_id — очевидно, вам нужно, чтобы были заданы DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE и т.д. Поможет ли правильная настройка этого, я не знаю. У меня нет мультисайта с поддоменами для проверки: также могут быть пути в wp_X_options, которые вам нужно изменить: возможно, вам придется отлаживать нерабочее состояние, чтобы понять, в чем проблема.

Rup Rup
12 июл. 2016 г. 12:19:17
Все ответы на вопрос 2
6
14

Четыре года без ответа? Что ж, давайте разберёмся...

Возьмём следующую сетевую настройку в качестве примера (использую команду списка сайтов 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 для обоих сайтов с ID 1 и 2 (соответственно 15)

Я использую Adminer для этого, но подойдёт любой другой инструмент управления БД (например, PhpMyAdmin). (Скриншоты показывают интерфейс на немецком языке, но, думаю, суть ясна.)

редактирование wp_options в adminer

В 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:

редактирование wp_blogs в adminer (Опять же, скриншот показывает таблицу до внесения изменений.) Здесь нужно просто поменять местами значения в столбце 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.

10 авг. 2016 г. 21:07:11
Комментарии

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

birgire birgire
10 авг. 2016 г. 22:35:24

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

David David
11 авг. 2016 г. 01:41:13

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

birgire birgire
11 авг. 2016 г. 01:53:01

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

Gyuri Gyuri
9 окт. 2018 г. 10:41:05

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

David David
10 окт. 2018 г. 18:02:56

Спасибо, это помогло мне с особенно сложным запуском сайта.

martinedwards martinedwards
14 нояб. 2018 г. 10:53:12
Показать остальные 1 комментариев
3

Более простое решение (не требующее изменения кода) — использовать плагин all-in-one-migration:

  1. экспортировать сайт new.example.com с ID 15 и
  2. импортировать его в example.com с ID 1
25 нояб. 2018 г. 16:43:45
Комментарии

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

Matt Beckman Matt Beckman
4 окт. 2019 г. 00:55:46

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

Alex Balcanquall Alex Balcanquall
15 янв. 2022 г. 21:15:05

Важно отметить, что плагин All-in-One Migration не поддерживает эту функцию без покупки Multisite Extension, которая "начинается от 199$".

Peter Højlund Andersen Peter Højlund Andersen
27 янв. 2022 г. 20:03:26