¿Por qué mi importación de base de datos está perdiendo datos del widget de texto?

Aquí es donde está tu problema:

  

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

No puedes hacer eso. WordPress almacena muchas opciones como "datos serializados", que contiene tanto el contenido de cadena de las cosas como su longitud . Entonces, cuando modifica la URL y los cambios de longitud, los datos serializados ya no son correctos y PHP los 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, para empezar, debe tener exactamente la misma URL que su sitio de producción. Puede editar manualmente su archivo HOSTS para dar 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 migre los datos, no se debe modificar nada de ellos.

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

Y aunque vacilo en sugerirlo, hay una manera de alterar el código del núcleo de WordPress para manejar estas serializaciones rotas. Debe 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]); }  

Esto NO es una solución viable a largo plazo. Solo se debe usar para levantarte y trabajar ahora mismo. A largo plazo, necesita arreglar su proceso de desarrollo para que no tenga que hacer este tipo de munging de URL para empezar.

Para solucionar este problema, siempre uso WordPress Serialized Search & Reemplace la herramienta proporcionada aquí. Funciona perfectamente bien con cualquier problema. He estado usando esto durante mucho tiempo en todos los requisitos de migración de mi sitio. Esto realmente resuelve los problemas con la migración de la base de datos de desarrollo a la producción.

enlace

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

Sin embargo, me las arreglé para solucionar esto utilizando un guión genial en enlace

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

1. Tomar un volcado de base de datos (por ejemplo, usando phpmyadmin) de la wordpress existente
2. Restaure el volcado tal como está, (sin necesidad de modificaciones) a su nueva ubicación
3. Descomprima el script de spectacu.la en su carpeta de inicio de wordpress (no es un complemento ...)
4. Ejecute la secuencia de comandos en su nuevo sitio apuntando su navegador hacia él, por ejemplo. enlace
5. No olvide eliminar el script de su nueva página de inicio de wordpress

El OP fue demasiado entusiasta al realizar 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 le gustaría un enfoque más manual, haga lo siguiente (esto solo aborda las inquietudes de los OP y no trata de actualizar la URL del sitio)

1. Copia de seguridad y mueve la exportación de tu base de datos Archivo SQL al nuevo entorno (mi ejemplo asume un nombre de archivo de backup_YYYY-MM-DD.sql)
2. Haga una búsqueda y reemplazo masivos en el Archivo SQL para cambiar los nombres de las tablas. utilizar su nuevo prefijo (ANTES de importando su archivo SQL!). De una sola mano Para ello sería utilizar un Perl. una sola línea como: perl -p -i.bak -e "s / 'wp _ /' myprefix_ / g" backup_YYYY-MM-DD.sql
3. Importe sus datos SQL a la base de datos
4. Actualice las claves dentro de las opciones que contiene el prefijo codificado actualizar myprefix_options set option_name = concat ('myprefix _', substr (option_name, 4)) donde option_name le gusta 'wp_%'
5. actualiza cualquier clave dentro de _user_meta que contienen el prefijo codificado actualizar myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) donde meta_key como 'wp_%'

Usé el complemento WP Migrate , que reemplaza los parches de http y folder. Obtuve un solo problema al importar, pero resolví colocar 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 todavía rompe mis datos serializados.