¿Por qué la importación de mi base de datos pierde datos de widget de texto?

He creado un sitio en WordPress en nuestra máquina de desarrollo. En el tema que estamos usando hay numerosas zonas de widgets para mostrar texto (barra lateral y portada). He utilizado widgets de texto simples en todas estas zonas para poner nuestra información de visualización.

Cuando migré el sitio a producción, utilicé el complemento WP-DB-Backup para tomar una instantánea de la base de datos. Luego edité el archivo .sql resultante para actualizar todas las rutas de archivo y referencias de URL para apuntar a nuestro sitio de producción.

Después de crear la base de datos, el sitio web y copiar todos los archivos al sitio de producción, ejecuto el archivo .sql desde el símbolo del sistema mysql para importar los datos a la nueva base de datos.

Sin embargo, cuando voy al sitio de producción, aparece parte del texto y parte no. Cuando miro en la sección de widgets del sitio, faltan los widgets de texto en algunas de las zonas de widgets. Los widgets de texto ni siquiera son visibles en la zona "Widget inactivo", simplemente no están allí.

Incluso he intentado repetir el proceso usando el complemento BackWPup, notando que la sintaxis SQL es diferente cuando descarga la base de datos.

¿Por qué pierdo datos de widget de texto durante la importación?

Aquí es donde está tu problema:

Luego edité el archivo .sql resultante para actualizar todas las rutas de archivo y referencias de URL para apuntar a nuestro sitio de producción.

No puedes hacer eso. WordPress almacena muchas opciones como "datos serializados", que contienen tanto el contenido de la cadena de cosas como su longitud . Entonces, cuando modifica la URL y la longitud cambia, los datos serializados ya no son correctos y PHP lo rechaza.

El problema a largo plazo es que, básicamente, lo estás haciendo mal. Si está configurando un sitio de desarrollo que tendrá sus datos migrados, entonces debería tener exactamente la misma URL que su sitio de producción, para empezar. Puede editar manualmente su archivo HOSTS para darle a ese dominio de producción (como example.com) una dirección IP diferente (como 127.0.0.1) y, por lo tanto, la URL de "producción" se convertirá en el sitio de desarrollo, solo para usted. Luego puede crear sus datos y enlaces y todo lo demás utilizando esa URL de producción, y cuando migra los datos, no hay nada que modificar.

En el corto plazo, sin embargo, no use una simple búsqueda / reemplazo de texto en el archivo SQL. Como has descubierto, esto rompe las cosas.

Y aunque dudo en sugerirlo, hay una manera de alterar el código central de WordPress para manejar estas serializaciones rotas. Tiene que modificar el archivo wp-includes / functions.php y cambiar la función maybe_unserialize () a esto:

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]); }  

Esta NO es una solución viable a largo plazo. Solo debe usarse para ponerlo en marcha en este momento. A la larga, debe corregir su proceso de desarrollo para que no tenga que hacer este tipo de combinación de URL para comenzar.

Para tratar este problema, siempre uso la herramienta de búsqueda y reemplazo serializada de WordPress que se proporciona aquí. Funciona perfectamente bien sin ningún problema. He estado usando esto durante mucho tiempo en todos los requisitos de migración de mi sitio. Esto realmente se ocupa de los problemas con la migración de la base de datos de desarrollo a la producción.

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

La respuesta de Otto es acertada. También descubrí esto de la manera difícil.

Sin embargo, me las arreglé para solucionar esto usando un script genial en http://spectacu.la/search-and-replace-for-wordpress-databases/

Para migrar su wordpress y a una nueva url / nombre de dominio, haga lo siguiente:

1. Realice un volcado de base de datos (p. Ej., Usando phpmyadmin) del wordpress existente
2. Restaure el volcado tal como está (sin necesidad de modificaciones) en su nueva ubicación
3. Descomprima el script de spectacu.la en su carpeta de inicio de WordPress (no es un complemento ...)
4. Ejecute el script en su nuevo sitio apuntando su navegador hacia él, por ejemplo, http: //new-website.url/searchreplacedb.php
5. No olvides eliminar el script de tu nuevo hogar de WordPress

El OP estaba demasiado celoso al hacer una búsqueda y reemplazo en el archivo de exportación de la base de datos, y terminó cambiando las apariciones de "wp_" dentro de algunos de los datos serializados. La solución es ser más parsimonioso en la búsqueda y reemplazo al incluir el backtick dentro de la expresión regular y luego actualizar manualmente las claves restantes dentro de la base de datos después de la importación.

Si está migrando y cambiando el prefijo, y como un enfoque más manual, haga lo siguiente (esto solo resuelve las preocupaciones de los OP y no trata de actualizar la URL del sitio)

1. Haga una copia de seguridad y mueva el archivo SQL de exportación de la base de datos al nuevo entorno (mi ejemplo supone un nombre de archivo de backup_YYYY-MM-DD.sql)
2. Haga una búsqueda y reemplazo masivo en el archivo SQL para cambiar los nombres de las tablas para usar su nuevo prefijo (¡ANTES de importar su archivo SQL!). Una forma de hacer esto sería utilizar una línea de Perl como: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
3. Importa tus datos SQL a la base de datos
4. Actualice cualquier clave dentro de _options que contenga el prefijo codificado: actualice myprefix_options set option_name = concat ('myprefix _', substr (option_name, 4)) donde option_name como 'wp_%'
5. Actualice cualquier clave dentro de _user_meta que contenga el prefijo codificado: actualice myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) donde meta_key como 'wp_%'

Utilicé el complemento WP Migrate , la bruja reemplaza http y parches de carpeta. Tuve un solo problema al importar, pero resolví poner las siguientes líneas en la parte superior del sql generado:

/*!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 */;

También probé con la herramienta Buscar y reemplazar (v2.1) respondida por @Yoav, pero aún así rompe mis datos serializados.