Миграция базы данных Wordpress

Question

Я просмотрел форумы Wordpress по этому поводу и ничего не нашел, поэтому подумал, что можно попробовать здесь.

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

Answer 1

У меня есть скрипт, который mysqldumps копирует мою производственную базу данных Wordpress, восстанавливает ее после моей тестовой установки Wordpress и затем исправляет все «производственные» настройки и URL-адреса в тестовой базе данных.

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

Вот мои сценарии:

overwrite_test.coach_db_with_coache_db.sh

#!/bin/bash 
dbUser="co*******"
dbPassword="*****"
dbSource="coach_production"
dbDest="coach_test"
tmpDumpFile="/tmp/$dbSource.sql"

mysqldump --add-drop-table --extended-insert --user=$dbUser --password=$dbPassword --routines --result-file=$tmpDumpFile $dbSource
mysql --user=$dbUser --password=$dbPassword $dbDest < $tmpDumpFile
mysql --user=$dbUser --password=$dbPassword $dbDest < /AdminScripts/change_coach_to_test.coach.sql

change_coach_to_test.coach.sql

-- Change all db references from @oldDomain to @newDomain

SET @oldDomain = 'coach.co.za';
SET @newDomain = 'test.coach.co.za';
SET @testUsersPassword = 'password';

UPDATE `wp_1_options` SET `option_value` = REPLACE(`option_value`,@oldDomain,@newDomain) WHERE `option_name` IN ('siteurl','home','fileupload_url');
UPDATE `wp_1_posts` SET `post_content` = REPLACE(`post_content`,@oldDomain,@newDomain);
UPDATE `wp_1_posts` SET `guid` = REPLACE(`guid`,@oldDomain,@newDomain);
UPDATE `wp_blogs` SET `domain` = @newDomain WHERE `domain` = @oldDomain;
UPDATE `wp_users` SET `user_pass` = MD5( @testUsersPassword );

-- Only valid for main wpmu site
UPDATE `wp_site` SET `domain` = @newDomain WHERE `domain` = @oldDomain;

Answer 2

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

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

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

Проблемы здесь были:

1. обозначение постоянной ссылки для все сообщения в блоге хранятся в базы данных, как они будут для онлайн версия, но моя оффлайн копия не по адресу домена, а это находится в каталоге localhost. Так когда я запускаю сайт локально, хотя форматирование CSS и изображения все на месте (изображение ссылки относительны), фактические сообщения в блоге не отображаются.
2. многие ссылки по всему ссылка на сайт обратно в интернет, так что если вы попытаетесь перейти к архивы или комментарии, или категории, или основные посты, вы получить обратно в Интернет вместо того, чтобы оставаться в базе данных на локальной машине.

Чтобы убедиться, что я все делал правильно, я сдул установку WordPress, установленную на моем локальном компьютере, и перезапустил ее с нуля.

После того, как у меня была чистая новая установка WordPress и новая только что созданная по умолчанию локальная база данных для нее, я открыл базу данных в phpMyAdmin и взглянул на wp_posts

таблица. Внутри каждой записи (другими словами, каждого сообщения) есть столбец с названием «guid», в котором указано местоположение этого сообщения. Например, первый в свежем, по умолчанию

install содержит это значение "guid":

http://localhost/wordpress/?p=1

Если вы посмотрите в таблице wp_posts вашей онлайн-версии, вместо этого вы увидите в этом месте URL-адрес вашего сайта в Интернете.

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

Итак, я создал резервную копию базы данных моего онлайн-сайта и сохранил ее локально в виде файла .sql. Затем я открыл этот файл в текстовом редакторе (я использовал notepad ++, отличную бесплатную программу, но вы могли использовать любой текстовый редактор). Вещи, которые мне нужно было посмотреть:

• По какой-то причине таблицы на моем Интернет-сайт не просто, например, "wp_posts" - они "wp_something_posts" ... есть некоторые дополнительные буквы там в имена таблиц.
• Любые ссылки на http: // ..., которые содержат мой онлайн-URL вместо localhost / wordpress

Для простоты давайте делать только сообщения. В резервной копии .sql, которую вы сделали из своей онлайновой базы данных, найдите начало таблицы wp_posts. Это будет выглядеть примерно так:

--

-- Table structure for table `wp_posts`

--



DROP TABLE IF EXISTS `wp_posts`;

CREATE TABLE `wp_posts` (

... и так далее. Выделите все, что выше этого, чуть ниже комментария, отмечающего начало базы данных в верхней части файла (он скажет - База данных: «имя вашей базы данных»), и удалите его. Затем перейдите в конец таблицы wp_posts и удалите все, после чего завершите ее до конца файла. Теперь ваш файл содержит только ваши сообщения, и ничего больше.

Сохраните это как отдельный документ. Назовите это posts.sql или что-то в этом роде.

Теперь в этом файле posts.sql вам нужно выполнить два действия по поиску / замене.

1. Найти каждый экземпляр имени таблица wp_something_posts и замените его на wp_posts. Только ты нужно сделать это, если ваша резервная копия вашей онлайн-базы данных не соответствует вашей чистой локальной установке как насколько имена таблиц идут. Ты хочешь какое бы имя таблицы ни было в этом файл, соответствующий вашему локальномуустановленная база данных WordPress имеет как это имя таблицы. Если вы не делаете эти имена совпадают, вы просто собирается в конечном итоге импортировать сообщения в новую таблицу с другим именем, который будет бесполезен для вас в все.
2. Найти каждый экземпляр http: // ... (замените elipsis своим URL) и заменить его на http://localhost/wordpress (или независимо от локального URL вашего разработчика версия сайта есть)

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

Теперь, когда вы сделали это, используйте phpMyAdmin, чтобы войти в базу данных wordpress на вашем локальном компьютере, выберите вкладку «импорт» и перейдите к селектору к файлу posts.sql , который вы только что создали, а затем импортировать его. Это вытянет все данные в этом файле в вашу локальную таблицу wp_posts.

Когда это закончится, просмотрите ваш местный сайт WordPress. Вы увидите все свои сообщения там сейчас. Ура!

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

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

До тех пор я так и понял, как это сделать. Надеюсь, это поможет вам двигаться в правильном направлении.

Answer 3

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

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

Answer 4

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

Answer 5

Вам необходимо обработать сериализованные объекты. Вот клиентская утилита HTML5 для ее обработки. Поскольку это все JavaScript, это довольно быстро.

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

Answer 6

Это подводит итог проблем с архитектурой ядра WordPress ... но я написал плагин, который решает проблемы с доменными именами и абсолютными URL-адресами, хранящимися в базе данных:

http://wordpress.org/extend/plugins/root-relative-urls/

Это решит проблемы, описанные @oddbill. Хотя не стоит слишком беспокоиться о том, что URL находится в столбце GUID, так как это поле никогда не используется для генерации ссылок.

@ markratledge предоставляет пару ссылок на некоторые длинные документы, которые в основном говорят это:

// экспорт

mysqldump -u[username] -p[password] [database] > backup.sql

// импорт

mysql -u[username] -p[password] [database] < backup.sql

Вы захотите исключить таблицы comments / comments_meta, если перейдете к производству из постановки, чтобы не потерять все свои комментарии и трекбеки (подход @ DavidLaing уничтожит их). И это предполагает, что вы создаете только контент изменения в вашей постановочной среде. Если вы хотите внести изменения в производственную и промежуточную среду, вам нужно будет написать сценарии, которые синхронизируют данные, а не перезаписывают их полностью ... удачи в этой задаче, могу ли я предложить добавить столбцы создания и изменения временных меток, прежде чем инвестировать слишком много времени с текущей схемой.

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

Мой плагин позволяет разрабатывать и тестировать с http://localhost/ или http://staging.server.local/ или http://www.production.com без каких-либо обычных подводных камней. А затем для переноса данных это так же просто, как экспорт и импорт данных, не требуется никаких шагов поиска и замены или настройки параметров базы данных.

И не полагайтесь на инструмент импорта / экспорта, он не захватывает все в типичных установках WordPress и все еще требует ненужного шага поиска и замены.