Чому імпорт моєї бази даних втрачає дані текстового віджета?

Я створив сайт у WordPress на нашій машині розвитку. У темі, яку ми використовуємо, є численні зони віджетів для відображення тексту (у бічній панелі та на головній сторінці). Я використовував прості текстові віджети у всіх цих зонах для розміщення відображуваної інформації.

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

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

Однак, коли я заходжу на виробничий майданчик, частина тексту з’являється, а частина - ні. Коли я переглядаю розділ віджетів на сайті, текстові віджети відсутні у деяких зонах віджетів. Текстові віджети навіть не видно в зоні "Неактивний віджет", їх просто немає.

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

Чому я втрачаю дані текстових віджетів під час імпорту?

Ось де ваша проблема:

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

Ви не можете цього зробити. WordPress зберігає багато варіантів як "серіалізовані дані", що містить як рядовий вміст речей, так і їх довжину . Отже, коли ви змінюєте URL-адресу і змінюється довжина, то серіалізовані дані більше не є правильними, і PHP відкидає її.

Довгострокова проблема полягає в тому, що, в основному, ви робите це неправильно. Якщо ви налаштовуєте веб-сайт для розробки, який буде переміщувати його дані, він повинен мати точно таку ж URL-адресу, що і для вашого виробничого сайту. Ви можете вручну відредагувати свій файл HOSTS, щоб вказати цьому виробничому домену (наприклад, example.com) іншу IP-адресу (наприклад, 127.0.0.1), і таким чином URL-адреса "виробництва" стане сайтом розробки лише для вас. Тоді ви можете створити свої дані та посилання та все інше, використовуючи цю виробничу URL-адресу, і коли ви переміщуєте дані, нічого про них не потрібно змінювати.

Однак у короткостроковому періоді не використовуйте простий пошук / заміну тексту у файлі SQL. Як ви виявили, це руйнує речі.

І хоча я не вагаюся запропонувати це, є спосіб змінити основний код WordPress для обробки цих порушених серіалізацій. Ви повинні змінити файл wp-include / функции.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-адрес для початку.

Щоб вирішити цю проблему, я завжди використовую тут інструмент для пошуку та заміни серіалізованих WordPress . Це прекрасно працює з вирішенням будь-яких питань. Я давно використовую це для всіх міграційних вимог мого сайту. Це дійсно вирішує проблеми із переміщенням бази даних розвитку у виробництво.

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Відповідь Отто точкова. Я також виявив це важким шляхом.

Однак мені вдалося вирішити це за допомогою класного сценарію на веб-сторінці http://spectacu.la/search-and-replace-for-wordpress-databases/

Щоб перемістити Wordpress та нове URL / доменне ім’я, виконайте наступне:

1. Візьміть дамп БД (наприклад, використовуючи phpmyadmin) наявного wordpress
2. Відновіть дамп як є (не потребує змін) до нового місця розташування
3. Розпакуйте скрипт з specu.la в домашню папку wordpress (це не плагін ...)
4. Запустіть скрипт на новому веб-сайті, вказавши на нього свій браузер, наприклад http: //new-website.url/searchreplacedb.php
5. Не забудьте видалити скрипт із нового будинку WordPress

ОП виявився надмірним, коли робив пошук та заміну файлу експорту бази даних, і в результаті зміни випадків "wp_" в межах деяких серіалізованих даних. Рішення полягає в тому, щоб бути більш неохайним у пошуку та заміні, включивши backtick у звичайний вираз, а потім оновити вручну решту ключів у базі даних після імпорту.

Якщо ви мігруєте та змінюєте префікс, і вам подобається більш ручний підхід, виконайте наступне (це стосується лише проблем, пов'язаних з ОЗ, і не стосується оновлення URL-адреси сайту)

1. Створіть резервну копію та перемістіть файл SQL для експорту вашої бази даних у нове середовище (мій приклад передбачає ім'я файлу backup_YYYY-MM-DD.sql)
2. Зробіть масу пошуку та заміни у файлі SQL, щоб змінити імена таблиць, щоб використовувати ваш новий префікс (PRIOR до імпорту файлу SQL!). Одним із способів зробити це буде використання одноколірного Perl типу: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
3. Імпортуйте свої дані SQL в базу даних
4. Оновіть будь-які ключі в межах _options, що містять префікс, жорстко кодований: оновіть набір myprefix_options option_name = concat ('myprefix _', substr (ім'я опції, 4)), де option_name типу 'wp_%'
5. Оновіть будь-які ключі в _user_meta, які містять жорстко кодований префікс: оновіть набір myprefix_usermeta meta_key = concat ('myprefix _', substr (meta_key, 4)), де meta_key, як 'wp_%'

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

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

Я також спробував за допомогою інструмента "Пошук і заміна" (v2.1), який відповів @Yoav, але він все ще порушує мої серіалізовані дані.