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

43

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 el texto (barra lateral y página frontal). He utilizado widgets de texto simples en todas estas zonas para colocar nuestra información de visualización.

Cuando migré el sitio a producción, usé 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 los archivos y las referencias a las URL para que apunten a nuestro sitio de producción.

Después de crear la base de datos, el sitio web y copiar todos los archivos en el 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, parte del texto aparece y parte no. Cuando miro en la sección de widgets del sitio, los widgets de texto faltan 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 con el complemento BackWPup, dándome cuenta de que la sintaxis SQL es diferente cuando elimina la base de datos.

¿Por qué estoy perdiendo datos de widgets de texto durante la importación?

    
pregunta Dillie-O 10.02.2011 - 16:35

5 respuestas

41

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.

    
respondido por el Otto 10.02.2011 - 19:45
10

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

    
respondido por el Subharanjan 28.03.2013 - 15:07
7

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
respondido por el Yoav Aner 17.04.2011 - 18:21
2

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_%'
respondido por el Tom Auger 24.05.2011 - 01:12
0

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.

    
respondido por el Ricardo Martins 10.07.2012 - 16:40

Lea otras preguntas en las etiquetas