Как перенести дочерний сайт с мультисайта разработчика на производственный мультисайт


12

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

Я уже перенес полную многосайтовую установку с первого дочернего сайта, который сейчас работает. Я бы предпочел разработать другие сайты на локальном сервере, поэтому я оставляю производственный сервер в покое, но, очевидно, я не могу снова выполнить полную миграцию.

Я искал решение, но все, что я нашел, - это перемещение одного сайта на мультисайт или наоборот, а не «перемещение дочернего сайта с мультисайта на мультисайт».

Я хотел бы сохранить все: настройки, виджеты и так далее.


1
Я думаю, что коммерческий плагин BackupBuddy способен сделать это, но мне было бы интересно увидеть более общие ответы на это.
Rarst

Из-за сериализованных строк в базе данных это не так просто сделать. До сих пор я не видел плагин для чистой миграции, но это абсолютно то, что должно быть сделано. Единственным переносом «большинства» частей одного блога в другой является механизм экспорта / импорта XML, но вам все равно придется исправлять множество путей впоследствии.
2ndkauboy

1
Лучший вариант, который у вас есть, это сделать с помощью прямого SQL-запроса. Я делал это не раз, и это работает просто отлично, если вы достаточно осторожны.
krembo99

@ krembo99, не могли бы вы рассказать немного больше о своей технике?
молоком

@Rarst, что касается BackupBuddy, это из их часто задаваемых вопросов: «Нет. Поддержка BackupBuddy Multisite является экспериментальной. Она не рекомендуется для производственных сайтов и официально не поддерживается».
молоком

Ответы:


4

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

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

Самое важное, что нужно сделать - это сделать резервную копию всей базы данных и файлов как для локального сайта разработчика, так и для нового местоположения на случай, если что-то пойдет не так. Ожидайте, что что-то пойдет не так. Будьте приятно удивлены, если это не так.

Перемещение файлов вашей темы должно быть довольно простым. Загрузите ваши файлы тем в каталог wp-content / themes и активируйте их как обычно. Я предполагаю, что это общая тема, к которой имеют доступ все блоги.

Загрузите файлы плагинов в wp-content / plugins в новом месте. Не активируйте их пока.

Обратите внимание, что любой контент, предназначенный исключительно для блога, который вы переносите, будет находиться в каталоге, который выглядит так, wp-content/blogs.dir/2/filesгде 2 - идентификатор сайта. Если возможно сохранить этот идентификатор сайта в новом местоположении, это должно помочь минимизировать конфликты в базе данных после миграции в новое местоположение. В противном случае вам придется обновить базу данных, чтобы отразить новый путь.

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

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

См. Обзор многосайтовой таблицы

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

Убедитесь, что новое местоположение использует тот же префикс базы данных, что и импортируемые таблицы. Префикс будет содержать идентификатор сайта для вашего блога и выглядеть примерно так wp_2_options, wp_2_posts, wp_2_postmeta.
См. Изучение WordPress Multisite от Лизы Сабин-Уилсон

Я предполагаю, что вы знаете, как импортировать / экспортировать через phpmyAdmin или с помощью команды mysqldump в вашем терминале. Это немного выходит за рамки этого поста, но вот пример экспорта, который должен помочь.

Из Как вы mysqldump конкретные таблицы? (Синтаксис отредактирован немного, чтобы быть более понятным.):

Если вы сбрасываете таблицы t1, t2 и t3 из базы данных с именем mydb

mysqldump -u <username> -p <password> mydb t1 t2 t3 > mydb_tables.sql

Прежде чем активировать плагины на новом сайте, перейдите к настройкам постоянной ссылки в административном каталоге и сохраните настройки, чтобы обновить файлы базы данных до нового URL сайта. Активируйте свои плагины и посмотрите, есть ли какие-либо проблемы.

Одна из проблем, с которой вы можете столкнуться, связана с сериализацией данных в ваших таблицах.

«[...] Ссылки на старое доменное имя или местоположение останутся в базе данных, и это может вызвать проблемы со ссылками или отображением темы.

Если вы выполняете поиск и замену всей своей базы данных, чтобы изменить URL-адреса, вы можете вызвать проблемы с сериализацией данных из-за того, что некоторые темы и виджеты хранят значения с длиной помеченного URL-адреса. " Когда ваше доменное имя или URL-адреса + Изменить

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

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


Спасибо! Так что, похоже, нет никакой реальной выгоды от такой работы: это мешок с обидой. Было бы лучше разработать локальный единый сайт и перейти на многосайтовую среду?
молоком

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

0

Не могли бы вы использовать встроенные функции экспорта и импорта WordPress? Тогда нужно просто перенести тему из одной установки в другую по FTP. Это происходит довольно быстро, и вы можете перенести сайт между установками менее чем за 5 минут.

Вы можете синхронизировать учетные данные пользователя, используя отличный плагин под названием User Syncronization .

Я не использовал его, но ManageWP имеет удобный инструмент развертывания и клонирования для перехода с существующего сайта на новый ... это стоит посмотреть.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.