Почему моя база данных импортирует текстовые данные виджета?

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

Когда я перенес сайт на производство, я использовал плагин WP-DB-Backup для создания моментального снимка базы данных. Затем я отредактировал полученный файл .sql, чтобы обновить все пути к файлам и ссылки на URL, чтобы указать на наш производственный сайт.

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

Однако, когда я иду на производственный сайт, некоторые тексты появляются, а некоторые из них не работают. Когда я просматриваю раздел виджетов сайта, в некоторых виджетных зонах отсутствуют текстовые виджеты. Текстовые виджеты даже не видны в зоне «Неактивный виджет», их просто нет.

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

Почему я теряю данные виджета во время импорта?

42 голоса | спросил Dillie-O 10 FebruaryEurope/MoscowbThu, 10 Feb 2011 18:35:10 +0300000000pmThu, 10 Feb 2011 18:35:10 +030011 2011, 18:35:10

5 ответов


40

Вот где ваша проблема:

  

Затем я редактировал полученный файл .sql   для обновления всех путей к файлам и   Ссылки на URL, указывающие на наш   производственная площадка.

Вы не можете этого сделать. WordPress хранит множество опций как «сериализованные данные», которые содержат как содержимое строки вещей , так и их длину . Поэтому, когда вы изменяете URL-адрес и изменяете длину, сериализованные данные больше не верны, а PHP отвергает его.

Долгосрочная проблема заключается в том, что в основном вы делаете это неправильно. Если вы создаете сайт разработки, на котором будут переноситься данные, он должен иметь тот же самый URL, что и ваш производственный сайт. Вы можете вручную отредактировать свой файл HOSTS, чтобы указать, что производственный домен (например, example.com) имеет другой IP-адрес (например, 127.0.0.1), и, таким образом, URL-адрес «production» станет для вас только сайтом разработки. Затем вы можете создавать свои данные и ссылки и все остальное, используя этот производственный URL, а когда вы переносите данные, ничего об этом не нужно изменять.

В краткосрочной перспективе, однако, не используйте простой текстовый поиск /замену в файле SQL. Как вы обнаружили, это нарушает все.

И хотя я не решаюсь предложить это, есть способ изменить основной код WordPress для обработки этих сломанных сериализаций. Вы должны изменить файл wp-includes /functions.php и изменить функцию maybe_unserialize () на это:

function maybe_unserialize( $original ) {
    if ( is_serialized( $original ) ) {
        $fixed = preg_replace_callback(
            '!(?<=^|;)s:(\d+)(?=:"(.*?)";(?:}|a:|s:|b:|i:|o:|N;))!s',
            'serialize_fix_callback',
            $original );
        return @unserialize( $fixed );
    }
    return $original;
}
function serialize_fix_callback($match) { return 's:' . strlen($match[2]); }  

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

ответил Otto 10 FebruaryEurope/MoscowbThu, 10 Feb 2011 21:45:26 +0300000000pmThu, 10 Feb 2011 21:45:26 +030011 2011, 21:45:26
10

Чтобы справиться с этой проблемой, я всегда использую WordPress Serialized Search & Замените инструмент , указанный здесь. Он отлично справляется с любыми проблемами. Я использую это в течение длительного времени во всех моих требованиях к миграции сайта. Это действительно позаботится о проблемах с миграцией базы данных разработки в производство.

https://interconnectit.com/products/search-and -replace-для-WordPress-баз данных /

ответил Subharanjan 28 MarpmThu, 28 Mar 2013 18:07:20 +04002013-03-28T18:07:20+04:0006 2013, 18:07:20
7

Ответ Отто - спот-он. Я также обнаружил это с трудом.

Однако мне удалось обойти это, используя классный скрипт в http: //spectacu.la/search-and-replace-for-wordpress-databases/

Чтобы перенести ваш Wordpress и новое имя /имя домена, выполните следующие действия:

  1. Возьмите дамп DB (например, используя phpmyadmin) существующего wordpress
  2. Восстановить дамп как есть, (нет необходимости в модификациях) в ваше новое местоположение.
  3. Разархивируйте скрипт из spectacular.la в свою домашнюю папку wordpress (это не плагин ...)
  4. Запустите сценарий на новом сайте, указав на него свой браузер, например. http: //new-website.url/searchreplacedb.php
  5. Не забудьте удалить скрипт из вашего нового homepress home
ответил Yoav Aner 17 PMpSun, 17 Apr 2011 20:21:25 +040021Sunday 2011, 20:21:25
2

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

Если вы переносите и меняете префикс и как более ручной подход, выполните следующие действия (это касается только проблем с OP и не связано с обновлением URL-адреса сайта)

  1. Резервное копирование и перемещение экспорта базы данных SQL в новую среду (в моем примере используется имя файла backup_YYYY-MM-DD.sql)
  2. Сделайте массовый поиск и замену на Файл SQL для изменения имен таблиц для использования вашего нового префикса (PRIOR to импортируя ваш файл SQL!). В одну сторону для этого было бы использовать Perl однострочный: perl -p -i.bak -e "Ы /` wp_ /`myprefix_ /г" backup_YYYY-ММ-DD.sql
  3. Импортируйте данные SQL в базу данных
  4. Обновить любые ключи в пределах _options, которые содержат префикс жестко закодированный: обновить набор myprefix_options option_name = CONCAT ( 'myprefix _', зиЬзЬг (имя_опции, 4)) где option_name как 'wp _%'
  5. Обновить все ключи в _user_meta которые содержат жестко запрограммированный префикс: обновить набор myprefix_usermeta meta_key = CONCAT ( 'myprefix _', зиЬзЬг (meta_key, 4)) где meta_key как 'wp _%'
ответил Tom Auger 24 Mayam11 2011, 03:12:52
0

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

/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;

Я также попытался с помощью инструмента «Поиск и замена» (v2.1), на который ответил @Yoav, но он по-прежнему разбивает мои сериализованные данные.

ответил Ricardo Martins 10 J000000Tuesday12 2012, 18:40:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132