Освоение миграции — более быстрые, простые и безопасные способы перемещения вашего сайта из точки А в точку Б

Миграция может быть сложной! Всем нам знакомо это чувство разочарования (или крайнего страха), когда мы видим, что одна из них терпит неудачу, но мы также знаем чувство облегчения, когда миграция проходит успешно. Со всеми сложностями и нюансами миграции, как мы можем повысить уровень успеха и выиграть время, чтобы сосредоточиться на работе, которую мы действительно хотим делать?

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

Динамики:

• Кевин Хоффман, старший менеджер по продуктам в WP Engine
• Остин Вендт, старший менеджер по продуктам в WP Engine

Слайды сессии:

Стенограмма:

ОСТИН ВЕНДТ: Приветствую всех и спасибо, что присоединились. Мы рады видеть вас. И добро пожаловать на конференцию DE{CODE}.

Меня зовут Остин Вендт, я старший менеджер по продукту в WP Engine, работаю над созданием нашего местного продукта. И мой коллега Кевин и я, с которым вы встретитесь здесь через минуту, рады поговорить с вами сегодня о построении более разумного, особенно с точки зрения освоения ваших миграций. Поэтому мы расскажем о более быстрых, простых и безопасных способах перемещения вашего сайта из точки А в точку Б, чтобы вы чувствовали себя уверенно в этих рабочих процессах разработки, независимо от того, переносите ли вы сайт в локальную безопасную среду разработки или готов продвигать этот сайт в реальном времени.

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

Мы поговорим о первом развертывании — так что, когда вы запускаете свой сайт в первый раз, как это выглядит, и о нескольких способах его выполнения, а затем о синхронизации этих двух сред с течением времени. Итак, давайте погрузимся прямо в это.

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

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

А второй – простите, третий – дистанционно-удалённый. Мы не будем слишком углубляться в это сегодня, но это возможно с инструментами, о которых вы узнаете. Обычно вы используете это при смене хостинг-провайдеров, то есть при переходе с хоста A на хост B, или, возможно, при перемещении между средами разработки, промежуточной и производственной среды, где бы ваш сайт ни размещался.

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

КЕВИН ХОФФМАН: Эй, спасибо, Остин. Итак, меня зовут Кевин Хоффман, я менеджер по продукту WP Migrate. Сегодня я хочу начать с плана действий по типам миграций, к которым мы собираемся перейти. Поэтому каждый раз, когда вы переходите из удаленной среды на локальный компьютер и выполняете резервное копирование на удаленный хост, это может стать сложной задачей. Но мы хотим, чтобы вы закончили эту презентацию с планом решений, чтобы вы могли уверенно выполнять эти миграции самостоятельно.

И для начала мы хотим получить существующий сайт со старого хоста. Так что это будет включать полный экспорт сайта с помощью WP Migrate. Затем мы собираемся перейти в Local, где мы можем внести изменения в локальную разработку, а затем развернуть этот сайт на нашем новом хосте.

Итак, чтобы начать, я собираюсь перейти к полному процессу экспорта сайта с помощью WP Migrate. Вы можете спросить себя, почему мы используем полный экспорт сайта в этой ситуации? Почему бы не толкать или тянуть напрямую между двумя средами? Ну, на это есть несколько причин.

Для начала я буду использовать Pro-версию WP Migrate, но вы также можете воспользоваться WP Migrate Lite, бесплатной версией нашего плагина в каталоге плагинов WordPress.

Четыре основные причины, по которым мы используем полный экспорт сайта в этой ситуации, — это, во-первых, односторонняя миграция. Мы хотим уйти с удаленного хоста и не собираемся возвращаться. Также нет существующей локальной установки, в которую мы могли бы переместить сайт. Если бы это было так, мы могли бы использовать принудительную миграцию или миграцию по запросу, чтобы перенести сайт на локальный компьютер. Но поскольку существующей установки нет, наиболее целесообразным является импорт с помощью перетаскивания в локальный каталог.

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

Итак, для начала давайте перейдем к WP Migrate и посмотрим, как это работает.

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

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

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

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

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

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

Аналогично с плагинами — я хочу экспортировать только свои активные плагины. И с основными файлами WordPress я хочу пойти дальше и включить их, потому что я хочу убедиться, что мое ядро ​​​​WordPress точно соответствует версии сайта, с которого я экспортирую.

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

На данный момент база данных и все файлы на сайте объединяются в один удобный zip-файл. Таким образом, всего за 18 секунд весь сайт был заархивирован.

Теперь я готов перейти в Local. И прежде чем я это сделаю, я хочу быстро заглянуть внутрь zip-файла, чтобы посмотреть, что там. Вы можете видеть, что у меня есть каталог файлов. Это включает в себя все файлы WordPress, включая мой контент WP, плагины, темы и загрузки. И у меня также есть дамп базы данных.

И еще один файл, который действительно важен и уникален для WP Migrate — JSON-файл экспорта WP Migrate содержит ключевую информацию об экспортированном сайте, такую ​​как версия PHP и версия MySQL, так что, когда Local позаботится об импорте , он может максимально точно соответствовать этой удаленной среде.

Итак, вы готовы к импорту в Local. И я отправлю его обратно в Остин.

ОСТИН ВЕНДТ: Отлично, спасибо, Кевин. Да, я рад рассказать, как упомянул Кевин, как мы можем импортировать этот zip-файл в Local и подготовить его к сборке. Но сначала я хочу представить, что такое Local. Если вы не знакомы, Local — это инструмент разработки WordPress номер один, созданный людьми здесь, в WP Engine, и мы очень рады поделиться с сообществом и предложить его бесплатно.

Так что это бесплатный инструмент разработчика. Если вы не слышали об этом, пожалуйста, проверьте это, localWP.com, мы бы хотели, чтобы вы использовали продукт. Но сегодня мы собираемся использовать Local для облегчения этого рабочего процесса.

А почему Местный? Как и в любой среде, специфичной для вашего компьютера, здесь очень низкий риск. И, как сказал Кевин, Local попытается сделать, когда вы импортируете этот экспорт из WP Migrate, мы собираемся точно имитировать производственную среду. Таким образом, насколько это возможно, версия WordPress, версия PHP, база данных, ваш локальный компьютер должны имитировать то, что происходит в производственной среде, чтобы, если вы устраняете неполадки или пытаетесь увидеть, что происходит не так, Local должен быть в состоянии сказать вам и быть как можно ближе к тому, что происходит в вашей размещенной среде.

Еще одно ключевое преимущество использования Local — рабочий процесс, о котором только что упомянул Кевин, не зависит от хоста. Таким образом, независимо от того, где вы размещаете, будь то с помощью Flywheel или WP Engine, вы сможете экспортировать этот сайт и очень быстро и легко перейти на локальный.

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

Круто, так что я уже сделал WP Migrate и сохранил этот zip на свой рабочий стол. И когда я перейду к созданию сайта в Local, появится эта новая зона перетаскивания, которая указывает, что вы можете перетаскивать сюда zip-файлы. Что еще хорошо в Local, так это то, что я могу делать это с любого экрана пользовательского интерфейса. Поэтому, если я перетащу этот zip-файл поверх Local, он предложит мне имя сайта из этого JSON-файла WP migrate export, о котором упоминал Кевин.

Он предварительно выбрал мой PHP, мой веб-сервер, мою базу данных. Затем я нажимаю «Создать», а Local позаботится обо всем остальном. Итак, Local активно распаковывает этот zip-файл, импортирует все эти файлы WordPress и настраивает этот сайт на моей машине в состоянии, максимально близком к рабочему, насколько это возможно.

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

Пока это заканчивается, я очень быстро выделю то, что вы можете увидеть слева — возможность группировать ваши сайты появилась в Local за последние пару недель. Итак, я перетащу Garrett's Grocery в свой демонстрационный раздел DE{CODE} — это хороший способ, который я рекомендую вам проверить, чтобы упорядочить свои сайты, возможно, сгруппировать их по клиенту или по версии, подключенной к WP. Двигатель или нет, что лучше для вас. Так что попробуйте.

Но Local заканчивает здесь, он меняет домен сайта. И что это собирается сделать, так это настроить его на моей машине, чтобы он был доступен, как вы можете видеть здесь, на mysite.local. Если я нажму «Открыть сайт», я увижу Garrett's Grocery. Таким образом, я фактически вышел из своей размещенной среды и перетащил ее в локальную, и она заработала на моей машине менее чем за две минуты, что потрясающе.

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

Теперь вопрос в том, как только я получу его в Local, я буду готов начать вносить изменения. Как мне вернуть его обратно и снова запустить в Интернете? Чтобы перенести ваш сайт с Local и вернуть его на ваш хост, мы будем использовать Local Connect для развертывания на WP Engine или на Flywheel. Как при полной миграции сайта, так и при частичной миграции.

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

Таким образом, используя Local, это довольно легко сделать. И я покажу вам демонстрацию того, как это выглядит. Итак, у меня здесь Garrett's Grocery, и я внес ряд изменений на веб-сайт, которые готов продвигать. Теперь у Local есть концепция Local Connect, как я уже упоминал — слева есть значок облака для Connect. В правом нижнем углу также есть «Подключиться к хосту», который позволит мне подключить либо WP Engine, либо маховик.

Сегодня я сделаю это, перейдя на вкладку «Подключение» и нажав «Подключиться к платформе». Я войду в свою учетную запись WP Engine, которую я избавил вас от наблюдения за тем, как я вхожу в систему. Вы можете видеть, что Local Connect извлекает все сайты, к которым у меня есть доступ на WP Engine. Теперь, что я сделаю, так это вернусь к Garrett's Grocery в своем обзоре. В правом нижнем углу я выберу «Подключиться к WP Engine».

Local собирается проверить, совместим ли этот сайт с инфраструктурой WP Engine. Итак, используя новейшие версии WordPress и PHP, а затем я могу нажать кнопку Push.

Push позволит мне выбрать прицел, который я хочу перезаписать на WP Engine. Это позволит мне выбрать окружение. Так что я выберу сайт Остина Вендта и выберу производство. И то, что вы увидите в правой части экрана, это то, что Local определяет список файлов.

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

Затем я нажимаю «Отправить в WP Engine», и Local начинает заботиться обо всем остальном. Все это видео длится около четырех минут — я избавлю вас от просмотра вместе со мной, пока я сижу здесь. Происходит то, что Local упаковывает эти файлы. Он начинает загружать эти файлы в WP Engine. И начинаю анализировать, как я уже сказал, различия между тем, что у меня на машине, и тем, что на сервере WP Engine.

Тот же рабочий процесс будет применяться и к Flywheel, если вы размещаете там. Мы будем следовать тому же принципу, вводя разницу в файлах между вашей машиной и сервером.

Итак, теперь Local начинает упаковывать базу данных. Это также подталкивает к WP Engine. Таким образом, он удаляет все существующие таблицы, существующие на удаленном сервере, и заменяет их теми, которые приходят с моей машины.

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

Так что он обновит эти префиксы таблиц для меня. И вот так мой сайт был перенесен на WP Engine.

Итак, начиная с этого снова, Garrett's Grocery все еще на моей машине. Но также, если я перейду на вкладку «Подключение», я увижу тот сайт Остина Вендта, на который я нажал справа, он говорит, что он подключен к Garrett's Grocery. И если я нажму на это название сайта, Остин Вендт, он откроется в браузере, чтобы показать мне этот новый контент в Интернете.

Итак, теперь, когда мы понимаем, как использовать Local для полного развертывания сайта, я хотел бы рассказать, как мы можем использовать Local для синхронизации сред с помощью функции, известной нам как MagicSync.

Таким образом, MagicSync — это еще одно название инкрементной миграции. Поэтому перемещайте только небольшие фрагменты кода между вашей локальной средой и удаленным сервером. А зачем вам это?

Так что, возможно, вы не хотите заменять весь сайт. Вы внесли лишь небольшие частичные изменения в существующий сайт, которые готовы запустить. Что также хорошо в Local — Local позволит вам, как я уже упоминал, использовать эту функцию сравнения, выбирать файлы, которые вы хотите включить, или даже исключить. Таким образом, большой общий случай использования здесь: возможно, я сделал много вещей на своей машине, но я хочу исключить отправку и извлечение мультимедиа, потому что это очень тяжелая и интенсивная часть моего сайта. Я могу просто отменить выбор носителя.

Итак, мы погрузимся в демонстрацию того, как выглядит MagicSync. Итак, еще раз, у меня есть Garrett's Grocery — скажем, на этот раз я внес еще один небольшой набор изменений, и я готов увидеть, как это отразится вживую на WP Engine. Здесь тот же рабочий процесс — в правом нижнем углу экрана я возвращаюсь, чтобы нажать на WP Engine. Он уже выбрал для меня сайт Остина Вендта и окружающую среду, помня с того момента, когда я делал это в последний раз.

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

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

Такой же рабочий процесс здесь — мы на самом деле проследим этот процесс, потому что он не займет много времени. Потому что дифференциал меньше. Итак, мы загрузим базу данных в WP Engine. Местные, опять же, пойдут вперед для меня и сделают этот поиск и замену. Таким образом, он обнаружит, изменились ли префиксы таблиц, URL-адреса, которые были другими на моей машине, должны быть отражены на удаленном хосте.

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

Таким образом, сайт был перемещен в WP Engine, и если я вернусь в браузер, вы увидите, что сайт обновлен и отражен там. Итак, теперь, когда мы понимаем, как использовать Local для выполнения инкрементной миграции, я хотел бы передать это Кевину, чтобы показать вам другой способ выполнить это с помощью инструмента WP Migrate.

КЕВИН ХОФФМАН: Эй, спасибо, Остин. Я ценю, что вы провели нас через рабочий процесс Local to WP Engine, но мы знаем, что вы не всегда имеете контроль над своим хостинг-провайдером. Итак, следующий рабочий процесс покажет вам, как мигрировать между любыми двумя средами WordPress. В этом случае переход с локального на любой другой веб-хост.

Чтобы сделать это, мы собираемся использовать концепцию под названием push and pull, используя WP Migrate. Теперь, почему бы вам сделать толчок или тянуть? Теперь, в отличие от полного экспорта сайта, это двусторонняя миграция. Это означает, что оба сайта уже существуют, и для более долгосрочной окупаемости требуется немного больше первоначальных инвестиций.

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

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

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

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

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

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

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

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

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

Итак, это полное развертывание сайта с сохранением профиля в WP Migrate. Но вам может быть интересно, а как насчет развертывания добавочных изменений? Итак, как показал вам Остин, используя MagicSync в Local, это еще один способ сделать это с помощью WP Migrate. Итак, я собираюсь создать еще один push-профиль, ввести ту же информацию о подключении, но на этот раз, когда я выберу свои медиа-загрузки, я буду только загружать новые и обновленные медиа-загрузки.

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

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

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

На этом наши рабочие процессы завершаются с использованием локального и WP Migrate для перехода от удаленного к локальному и обратно к удаленному.

Итак, как вы можете видеть, теперь наш план игры завершен, у нас есть решения для перемещения с удаленного сайта с использованием полного экспорта сайта из WP Migrate, перетаскивания, импорта этого в локальный, а затем загрузки в WP Engine или Flywheel, или любой другой хост. Так что это только верхушка айсберга, когда речь заходит о решениях для миграции и о том, что возможно, когда вы используете WP Migrate и Local вместе.

Поэтому мы надеемся, что это даст вам план игры в следующий раз, когда вам нужно будет запускать собственные миграции. С нетерпением ждем ваших сообщений в наших учетных записях Twitter для WP Migrate и Local, и мы надеемся, что вам понравится остальная часть DE{CODE]. Спасибо, что присоединились к нам.