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

46

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?

Dillie-O
fuente
He estado cavando un poco en el camino, y lo único que puedo pensar es que la información del widget se almacena en la tabla wp_options, que busca codificar algunos de sus datos de una manera extraña. Todavía no he podido probar esto con un tema diferente para ver si está relacionado con el tema.
Dillie-O

Respuestas:

44

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.

Otón
fuente
@Otto excelente respuesta. Pregunta rápida, ¿modificar una tabla de blob / texto no serializado como wp_posts fuera de MySql afectaría alguno de los datos serializados en wp_post_meta o wp_options? Tuve el mismo problema con el widget de texto pero no toqué wp_options, solo modifiqué wp_posts.
Chris_O
Wow, nunca me di cuenta de que eso era lo que estaba sucediendo con los datos, ¡pero tiene mucho sentido! ¡Muchas gracias!
Dillie-O
44
Otra solución alternativa que utilizan algunas personas es hacer que su sistema de desarrollo tenga un nombre de dominio "example.dev" en lugar de "example.com". De esa manera, las longitudes no cambian para las cadenas cuando las mueven a producción. Prefiero el método de archivo HOSTS.
Otto
3
2016 y wordrepss todavía está guardando datos serializados en la base de datos. most famous worst codeEl premio no tiene que buscar más.
Ejaz
1
¡¡¡GRACIAS!!! Buen punto y gran truco. En general, obtengo este truco para devolver todos los datos y después de eso solo actualizo la configuración existente nuevamente y cuando elimine este código funciona perfectamente.
Ivijan Stefan Stipić
10

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/

Subharanjan
fuente
1
he
Trabajó para mí la mayor parte del tiempo. Pero esta semana, cuando he sustituido http://localhost/Me/site_namepor http://site.dev(desde un host local a otro) usando v 3.0.0 me he perdido mis posiciones de menú de widgets y por extraño que parezca. Entonces, quizás este problema esté relacionado con la longitud de la cadena también.
Rhand
He estado usando ... pero nunca enfrenté esta situación hasta el momento. ¿Puedes descargar la versión anterior de este script e intentarlo de nuevo? Intenta reemplazar localhost/Me/site_namecon site.dev.
Subharanjan
La URL ha cambiado (ahora https en lugar de http): interconnectit.com/products/…
Koryonik
Guión magnífico Dupliqué una base de datos MySQL de PHPMyAdmin de una antigua a una nueva -sin cambio de URL en absoluto-, luego fui a la carpeta del nuevo sitio donde estaban los archivos WP nuevos (junto con un wp-config.php adecuado, con el nuevas credenciales de base de datos), agregó el script y se encargó de todo. Los datos serializados se actualizan a lo largo de las URL normales. ¡Fácil y rápido! Muy recomendable. Importante: ¡no olvide eliminar el script después de haberlo utilizado, ya que tiene acceso a los detalles de su base de datos!
Cacahuetes
7

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
Yoav Aner
fuente
1
Sé que esto es algo antiguo, pero ¿dónde se supone que debo especificar el nuevo nombre de la base de datos si restauro el volcado tal como está? ¿No debería al menos poner el nuevo nombre de la base de datos en el segundo paso? Gracias por esta información
andresmijares
No estoy seguro de entender completamente tu pregunta. La restauración de la base de datos se puede hacer con herramientas como phpmyadmin y puede darle un nuevo nombre o usar el nombre antiguo. El script que mencioné simplemente cambia el texto dentro de la base de datos después de que ya está restaurado.
Yoav Aner el
Hola Yoav, gracias por la respuesta, quiero decir, cuando exporto una base de datos, normalmente cambio el nombre de la base de datos a la nueva y cambia los enlaces de dominio. Dicho esto, en su paso número dos usted dice restaurar el volcado tal como está sin modificaciones, solo quería saber si eso literalmente, o tengo que cambiar el nombre de la base de datos al menos. Sé que puede ser una pregunta tonta, estoy un poco perdido, gracias de nuevo por su respuesta
Andresmijares
No sé cómo volcar su base de datos, pero si usa la herramienta 'exportar' phpmyadmin, entonces no importa qué nombre de base de datos sea. Puede usar la exportación e importarla nuevamente a cualquier otra base de datos. En general, con respecto al punto 2, creo que está bien cambiar el nombre de la base de datos.
Yoav Aner el
2

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_%'
Tom Auger
fuente
0

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.

Ricardo Martins
fuente
Hola Ricardo, ¡Bienvenido a WordPress Answers! El área que publicó está reservada para las respuestas a la pregunta original. Aunque su pregunta esté relacionada, debe publicarla como una pregunta separada. Tendrás muchas más posibilidades de que se responda de esa manera.
Chris_O