Pourquoi mon importation de base de données perd-elle les données du widget texte?

46

J'ai créé un site dans 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é des widgets de texte simples dans toutes ces zones pour mettre nos informations d'affichage.

Lorsque j'ai migré le site en 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, je lance 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 apparaît 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 est différente lorsqu'elle vide la base de données.

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

Dillie-O
la source
J'ai fait quelques recherches en cours de route, et la seule chose à laquelle je peux penser, c'est que les informations sur les widgets sont stockées dans la table wp_options, qui cherche à coder certaines de ses données de manière étrange. Je n'ai pas encore pu essayer cela avec un thème différent pour voir si c'est lié à un thème.
Dillie-O

Réponses:

44

C'est là que se situe votre problème:

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.

Tu ne peux pas faire ça. WordPress stocke de nombreuses options sous forme de "données sérialisées", qui contient à la fois le contenu de la chaîne et sa 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, rien ne doit en être modifié.

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

Et bien que j'hésite à le suggérer, il existe un moyen de modifier le code principal de WordPress pour gérer 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.

Otto
la source
@ Otto excellente réponse. Question rapide: modifier une table de texte / blob non sérialisée comme wp_posts en dehors de MySql aurait-il une incidence sur les données sérialisées dans wp_post_meta ou wp_options? J'ai eu le même problème avec le widget texte mais je n'ai pas touché à wp_options, je n'ai modifié que wp_posts.
Chris_O
Wow, je n'avais jamais réalisé que c'était ce qui se passait avec les données, mais c'est tout à fait logique! Merci beaucoup!
Dillie-O
4
Certaines personnes utilisent une autre solution pour que leur système de développement ait un nom de domaine "exemple.dev" au lieu de "exemple.com". De cette manière, les longueurs ne changent pas pour les chaînes lorsqu'elles les déplacent en production. Je préfère la méthode du fichier HOSTS.
Otto
3
2016 et wordrepss continue d'enregistrer des données sérialisées dans la base de données. most famous worst codele prix ne doit pas chercher plus loin.
Ejaz
1
MERCI!!! Bon point et super bidouille. Généralement, je reçois ce hack pour renvoyer toutes les données et après cela, il suffit de mettre à jour les paramètres existants à nouveau et lorsque le code est supprimé, cela fonctionne parfaitement.
Ivijan Stefan Stipić
10

Pour résoudre ce problème, j'utilise toujours l' outil WordPress Serialized Search & Replace 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.

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

Subharanjan
la source
1
Oui,
j'utilise
Travaillé pour moi la plupart du temps. Mais cette semaine, lorsque j'ai remplacé http://localhost/Me/site_namepar http://site.dev(d'un hôte local à un autre) à l'aide de la version 3.0.0, j'ai perdu mon widget et les positions de menu assez étrangement. Donc, peut-être que ce problème est lié à la longueur des cordes.
Rhand
J'ai utilisé .. mais jamais fait face à cette situation pour l'instant. Pouvez-vous télécharger l'ancienne version de ce script et réessayer avec cela? Essayez de remplacer localhost/Me/site_namepar site.dev.
Subharanjan
L’url a changé (https à la place http): interconnectit.com/products/…
Koryonik le
Script magnifique. J'ai dupliqué une base de données MySQL de PHPMyAdmin d'une ancienne vers une nouvelle, sans aucun changement d'URL, puis je suis allé dans le dossier du nouveau site où se trouvaient les nouveaux fichiers WP (à côté d'un fichier wp-config.php, nouvelles références de la base de données), ajout du script, qui s’occupe de tout. Les données sérialisées sont mises à jour le long des URL normales. Facile et rapide! Hautement recommandé. Important: n'oubliez pas de supprimer le script après l'avoir utilisé car il a accès aux détails de votre base de données!
Arachides
7

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

Cependant, j'ai réussi à contourner cela en utilisant un script sympa sur http://spectacu.la/search-and-replace-for-wordpress-databases/

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

  1. Effectuer un dump de la base de données existante (par exemple, avec phpmyadmin)
  2. Restaurez le dump tel quel, (aucune modification requise) dans 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, http: //new-website.url/searchreplacedb.php.
  5. N'oubliez pas de supprimer le script de votre nouvelle maison wordpress
Yoav Aner
la source
1
Je sais que c'est un peu vieux, mais où devrais-je spécifier le nouveau nom de la base de données si je restaure le vidage tel quel? ne devrais-je pas au moins mettre le nouveau nom de la base de données dans la deuxième étape? Merci pour cette information
andresmijares
Je ne suis pas sûr de bien comprendre votre question. La restauration de la base de données peut être effectuée à l'aide d'outils tels que phpmyadmin. Vous pouvez lui attribuer un nouveau nom ou utiliser l'ancien nom. Le script que j'ai mentionné modifie simplement le texte de la base de données après sa restauration.
Yoav Aner
Bonjour Yoav, merci pour la réponse. Lorsque j'exporte une base de données, je modifie normalement le nom de la base de données par le nouveau et modifie les liens de domaine. Cela dit, lors de votre deuxième étape, vous dites de restaurer le cliché tel quel, sans modifications. Je voulais simplement savoir si, littéralement, ou si je devais au moins changer le nom de la base de données. Je sais que cela peut être une question fictive, je suis juste un peu perdu, merci encore pour votre réponse
andresmijares
Je ne sais pas comment vider votre base de données, mais si vous utilisez l'outil 'export' de phpmyadmin, le nom de la base de données importe peu. Vous pouvez utiliser l'exportation et l'importer dans une autre base de données. De manière générale, en ce qui concerne le point 2, je pense que vous pouvez modifier le nom de la base de données.
Yoav Aner
2

Le PO était trop zélé lors d’une recherche et 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 à faire preuve de plus de parcimonie 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 problèmes liés aux PO et ne traite pas de la mise à jour de l'URL du site)

  1. Sauvegardez et déplacez le fichier SQL d'exportation de votre base de données vers le nouvel environnement (mon exemple suppose un nom de fichier de backup_YYYY-MM-DD.sql).
  2. Effectuez une recherche et un remplacement en masse sur le fichier SQL pour modifier les noms de table afin d'utiliser votre nouveau préfixe (AVANT d'importer votre fichier SQL!). Une façon de le faire serait d’utiliser un Perl one-line comme: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
  3. Importez vos données SQL dans la base de données
  4. Mettez à jour toutes les clés de _options qui contiennent le préfixe codé en dur: update myprefix_options set nom_option = concat ('préfixe _', substr (nom_option, 4)) où nom_option comme 'wp_%'
  5. Mettez à jour les clés de _user_meta contenant le préfixe codé en dur: update myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) où meta_key ressemble à 'wp_%'
Tom Auger
la source
0

J'ai utilisé le plugin WP Migrate , qui remplace les correctifs http et les dossiers. J'ai eu un seul problème lors de l'importation, mais j'ai résolu de mettre les lignes suivantes en haut du 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 de remplacement (v2.1) répondu par @Yoav, mais il casse toujours mes données sérialisées.

Ricardo Martins
la source
Bonjour Ricardo, Bienvenue sur WordPress Answers! La zone dans laquelle vous avez posté est réservée aux réponses à la question d'origine. Même si votre question est liée, vous devriez la poster en tant que question distincte. Vous aurez une bien meilleure chance de recevoir la réponse de cette façon.
Chris_O