Pourquoi l'importation de ma base de données perd-elle les données du widget texte?

43

J'ai créé un site WordPress sur notre machine de développement. Dans le thème que nous utilisons, de nombreuses zones de widgets permettent d'afficher du texte (barre latérale et page d'accueil). J'ai utilisé de simples widgets Texte dans toutes ces zones pour mettre nos informations d'affichage.

Lorsque j'ai migré le site vers la production, j'ai utilisé le plug-in WP-DB-Backup pour prendre un instantané de la base de données. J'ai ensuite modifié le fichier .sql résultant pour mettre à jour tous les chemins de fichiers et les références d'URL afin qu'ils pointent vers notre site de production.

Après avoir créé la base de données, le site Web et copié tous les fichiers sur le site de production, j'exécute le fichier .sql à partir de l'invite de commande mysql pour importer les données dans la nouvelle base de données.

Cependant, lorsque je vais sur le site de production, une partie du texte s'affiche et d'autres non. Lorsque je regarde dans la section des widgets du site, les widgets de texte sont absents de certaines des zones de widgets. Les widgets de texte ne sont même pas visibles dans la zone "Widget inactif", ils n'y sont tout simplement pas.

J'ai même essayé de répéter le processus à l'aide du plug-in BackWPup, en remarquant que la syntaxe SQL était différente lorsqu'elle vidait la base de données.

Pourquoi suis-je en train de perdre des données de widget texte lors de l'importation?

    
posée Dillie-O 10.02.2011 - 16:35
la source

5 réponses

41

C'est là que réside votre problème:

  

J'ai ensuite modifié le fichier .sql résultant   mettre à jour tous les chemins de fichiers et   Références d'URL pour pointer vers notre   site de production.

Vous ne pouvez pas faire ça. WordPress stocke de nombreuses options sous forme de "données sérialisées", qui contiennent à la fois le contenu sous forme de chaîne des éléments et leur longueur . Ainsi, lorsque vous modifiez l'URL et que la longueur change, les données sérialisées ne sont plus correctes et PHP les rejette.

Le problème à long terme est que, fondamentalement, vous le faites mal. Si vous configurez un site de développement dans lequel les données seront migrées, il doit alors avoir exactement la même URL que votre site de production. Vous pouvez modifier manuellement votre fichier HOSTS pour attribuer à ce domaine de production (tel que exemple.com) une adresse IP différente (telle que 127.0.0.1). Ainsi, l'URL "de production" deviendra le site de développement, pour vous uniquement. Vous pouvez ensuite créer vos données, vos liens et tout le reste à l’aide de cette URL de production. Lorsque vous migrez les données, vous ne devez rien y changer.

Cependant, à court terme, n’utilisez pas une simple recherche / remplacement de texte sur le fichier SQL. Comme vous l'avez découvert, cela casse les choses.

Et même si j’hésite à le suggérer, il existe un moyen de modifier le code principal de WordPress afin de traiter ces sérialisations cassées. Vous devez modifier le fichier wp-includes / functions.php et changer la fonction Maybe_unserialize () en ceci:

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

Ce n’est PAS une solution viable à long terme. Il ne devrait être utilisé que pour vous permettre de travailler maintenant. À long terme, vous devez régler votre processus de développement de manière à ne pas avoir à faire ce genre de conversion d'URL pour commencer.

    
réponse donnée Otto 10.02.2011 - 19:45
la source
10

Pour résoudre ce problème, j’utilise toujours WordPress Serialized Search & Remplacez l'outil fourni ici. Cela fonctionne parfaitement bien sans aucun problème. Je l'utilise depuis longtemps pour tous les besoins de migration de mon site. Cela règle vraiment les problèmes de migration de la base de données de développement vers la production.

enlace

    
réponse donnée Subharanjan 28.03.2013 - 15:07
la source
7

La réponse d'Otto est parfaite. J'ai aussi découvert cela à la dure.

Cependant, j'ai réussi à contourner ce problème en utilisant un script intéressant à l'adresse enlace

Pour migrer votre wordpress et vers un nouveau nom d'URL / domaine, procédez comme suit:

  1. Effectuez un dump de base de données (par exemple, avec phpmyadmin) de la wordpress existante
  2. Restaurez le dump tel quel, (aucune modification nécessaire) vers votre nouvel emplacement
  3. Décompressez le script de spectacu.la dans votre dossier personnel wordpress (ce n’est pas un plugin ...)
  4. Exécutez le script sur votre nouveau site en pointant votre navigateur sur celui-ci, par exemple. enlace
  5. N'oubliez pas de supprimer le script de votre nouvelle maison wordpress
réponse donnée Yoav Aner 17.04.2011 - 18:21
la source
2

Le PO était trop zélé lors d’une recherche-remplacement dans le fichier d’exportation de la base de données et a fini par changer les occurrences de "wp_" dans certaines des données sérialisées. La solution consiste à être plus parcimonieux dans la recherche et le remplacement en incluant le backtick dans l'expression régulière, puis en mettant à jour manuellement les clés restantes de la base de données après l'importation.

Si vous migrez et modifiez le préfixe, et si vous préférez une approche plus manuelle, procédez comme suit (cela ne concerne que les préoccupations des PO et ne traite pas de la mise à jour de l'URL du site)

  1. Sauvegardez et déplacez votre base de données exportée Fichier SQL dans le nouvel environnement (mon exemple suppose un nom de fichier de backup_AAAA-MM-DD.sql)
  2. Effectuez une recherche et un remplacement en masse sur le Fichier SQL pour changer les noms de table utiliser votre nouveau préfixe (AVANT le importer votre fichier SQL!). Une manière ce serait utiliser un Perl une ligne comme: perl -p -i.bak -e "s / 'wp _ /' myprefix_ / g" backup_AAAA-MM-JJ.sql
  3. Importez vos données SQL dans la base de données
  4. Mettez à jour les clés dans _options qui contient le préfixe codé en dur: mettre à jour myprefix_options set nom_option = concat ('myprefix _', substr (nom_option, 4)) où nom_option comme 'wp _%'
  5. Mettez à jour les clés de _user_meta qui contiennent le préfixe codé en dur: mettre à jour le jeu myprefix_usermeta meta_key = concat ('myprefix _', substr (meta_key, 4)) où meta_key comme 'wp _%'
réponse donnée Tom Auger 24.05.2011 - 01:12
la source
0

J'ai utilisé le plug-in WP Migrate , qui remplace les correctifs de dossier et de dossier http. J'ai eu un seul problème lors de l'importation, mais j'ai résolu de mettre les lignes suivantes en haut du fichier SQL généré:

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

J'ai également essayé avec l'outil de recherche et remplacement (v2.1) répondu par @Yoav, mais il casse toujours mes données sérialisées.

    
réponse donnée Ricardo Martins 10.07.2012 - 16:40
la source

Lire d'autres questions sur les étiquettes