Pourquoi mon import de base de données perd-il les données du widget texte?

Question

Pourquoi mon import de base de données perd-il les données du widget texte?

- 48
- 35687 2011-02-10
J'ai créé un site WordPress surnotremachine de développement. Dans lethème quenous utilisons,ilexiste denombreuses zones de widgets dans lesquelles afficher dutexte (barre latéraleet page d'accueil). J'ai utilisé des widgets detexte simples danstoutes ces zonespourmettrenosinformations d'affichage.

Lorsquej'aimigré le site vers laproduction,j'ai utilisé leplugin WP-DB-Backuppourprendre uninstantané de labase de données. J'aiensuite édité lefichier .sql résultantpourmettre àjourtous les chemins defichierset les références URLpourpointer versnotre site deproduction.

Après avoir créé labase de données,le site Webet copiétous lesfichiers sur le site deproduction,j'exécute lefichier .sql àpartir de l'invite de commandemysqlpourimporter les données dans lanouvellebase de données.

Cependant,lorsqueje vais sur le site deproduction,unepartie dutexte apparaîtet unepartienon. Lorsqueje regarde dans la section widgets du site,les widgets detexte sont absents de certaines des zones de widgets. Les widgets detextene sontmêmepas visibles dans la zone "Widgetinactif",ilsne sonttout simplementpas là.

J'aimêmeessayé de répéter leprocessusen utilisant leplugin BackWPup,remarquant que la syntaxe SQLest différente lors du vidage de labase de données.

Pourquoiest-ce queje perds les données du widgettexte lors de l'importation?

I've created a site in WordPress on our development machine. In the theme we're using there are numerous widget zones to display text in (sidebar and front page). I've used simple Text widgets in all of these zones to put our display information.

When I migrated the site to production, I used the WP-DB-Backup plugin to take a snapshot of the database. I then edited the resulting .sql file to update all of the file paths and URL references to point to our production site.

After creating the database, website, and copying all of the files over to the production site, I run the .sql file from the mysql command prompt to import the data into the new database.

However, when I go to the production site, some of the text shows up and some of it doesn't. When I look into the widgets section of the site, the text widgets are missing from some of the widget zones. The text widgets aren't even visible in the "Inactive Widget" zone, they simply aren't there.

I've even tried to repeat the process using the BackWPup plugin, noticing that the SQL syntax is different when it dumps the database out.

Why am I losing text widget data during the import?

database mysql import

- J'ai creuséen cours de route,et la seule chose à laquelleje peuxpenserest que lesinformations du widget sont stockées dans latable wp_options,qui cherche àencoder certaines de ses données demanière étrange.Jen'aipasencorepuessayer ceci avec unthème différentpour voir s'ilest lié authème.
  
  I've been doing some digging along the way, and the only thing I can think of is that the widget information is being stored in the wp_options table, which looks to encode some of its data in a weird way. I haven't been able to try this with a different theme yet to see if it is theme related.
  - 0
  - 2011-02-10
  - Dillie-O

5 réponses

votes

- 11
- 2013-03-28
Pour résoudre ceproblème,j'utilisetoujours WordPress Serialized Search & amp;Remplacez l’outil fourniici.Celafonctionneparfaitementbien sans aucunproblème.Je l'utilise depuis longtempspourtoutes lesexigences demigration demon site.Cela règle vraiment lesproblèmes liés à lamigration de labase de données de développement vers laproduction.

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

To deal with this issue I always use WordPress Serialized Search & Replace tool provided here. It works perfectly fine with out any issues. I have been using this for a long time on all my site migration requirements. This really take care of the issues with migrating development database to production.

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
- Oui,j'utilise ce script depuis des annéeset je le recommande vivement
  
  Yes been using this script for years and highly recommend it
  - 1
  - 2013-06-04
  - davemac
- Atravaillépourmoi laplupart dutemps.Mais cette semaine,lorsquej'ai remplacé `http://localhost/Me/site_name`par` http://site.dev` (d'un hôte local à un autre)en utilisant la version 3.0.0,j'aiperdu assez curieusementmespositions de widgetet demenu.Alorspeut-être que ceproblèmeest également lié à la longueur de la chaîne.
  
  Worked for me most of the time. But this week when I replaced `http://localhost/Me/site_name` by `http://site.dev` (from one local host to another) using v 3.0.0 I did lose my widget and menu positions oddly enough. So perhaps this issue is related to the string lenght as well.
  - 0
  - 2014-11-27
  - rhand
- J'utilise ...maisje n'aijamaisfaitface à cette situationpour lemoment.Pouvez-voustélécharger l'ancienne version de ce scriptet réessayer.Essayez de remplacer `localhost/Me/site_name`par` site.dev`.
  
  I have been using.. but never faced this situation as of yet. Can you download the older version of this script and try with that again. Try replacing `localhost/Me/site_name` with `site.dev`.
  - 0
  - 2014-11-27
  - Subharanjan
- L'URL a changé (maintenant https à laplace http): https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
  
  Url has changed (now https instead http) : https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
  - 0
  - 2015-09-18
  - Koryonik
- Superbe script.J'ai dupliqué unebase de données MySQL de PHPMyAdmin d'une ancienne à unenouvelle -aucun changement d'URL que ce soit-,puisje suis allé dans le dossier dunouveau site où setrouvaient lesfichiers WPfrais (à côté d'un wp-config.php approprié,avec lenouvellesinformations d'identification DB),a ajouté le script,et il s'est occupé detout.Les données sérialisées sontmises àjour avec les URLnormales.Facileet rapide!Hautement recommandé.Important:n'oubliezpas de supprimer le script après son utilisation caril a accès aux détails de votrebase de données!
  
  Gorgeous script. I duplicated a MySQL database from PHPMyAdmin from an old one to a new one -no change of URLs whatsoever-, then went to the folder of the new site where the fresh WP files were (alongside a proper wp-config.php, with the new DB credentials), added the script, and it took care of everything. Serialized data is updated along the normal URLs. Easy and quick! Highly recommended. Important: don't forget to remove the script after it's been used as it has access to your DB details!
  - 0
  - 2018-02-08
  - Peanuts
- 7
- 2011-04-17
La réponse d'Ottoestjuste.J'ai aussi découvert cela à la dure.

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

Pourmigrer votre wordpresset vers unenouvelle URL/nom de domaine,procédez comme suit:

Effectuer un vidage de labase de données (parexempleen utilisantphpmyadmin) du wordpressexistant

Restaurez le vidagetel quel (aucunemodificationnécessaire) à votrenouvelemplacement

Décompressez le script de spectacu.la dans votre dossier d'accueil wordpress (cen'estpas unplugin ...)

Exécutez le script sur votrenouveau siteen pointant votrenavigateur dessus,parexemple http://new-website.url/searchreplacedb.php

N'oubliezpas de supprimer le script de votrenouvellepage d'accueil WordPress
Otto's answer is spot-on. I also discovered this the hard way.

However, I managed to work around this using a cool script at http://spectacu.la/search-and-replace-for-wordpress-databases/

To migrate your wordpress and to a new url / domain name, do the following:

Take a DB dump (e.g. using phpmyadmin) of the existing wordpress

Restore the dump as-is, (no need for modifications) to your new location

Unzip the script from spectacu.la into your wordpress home folder (it's not a plugin...)

Run the script on your new site by pointing your browser to it, e.g. http://new-website.url/searchreplacedb.php

Don't forget to delete the script from your new wordpress home
- Je sais que c'est unpeu vieux,mais où dois-je spécifier lenouveaunom de labase de données sije restaure le vidagetel quel?ne devrais-jepas aumoinsmettre lenouveaunom debase de données dans la deuxième étape?Mercipour cetteinformation
  
  I know this is kind of old, but where do I supposed to specify the new database name if I restoring the dump as it is? shouldn't I at least put the new database name in the second step? Thank you for this info
  - 1
  - 2012-01-05
  - andresmijares
- Jene suispas sûr debien comprendre votre question.La restauration de labase de donnéespeut êtreeffectuée avec des outilstels quephpmyadminet vouspouvez lui donner unnouveaunom ou utiliser l'anciennom.Le script quej'aimentionnémodifie simplement letexte dans labase de données après sa restauration.
  
  I'm not sure I fully understand your question. Restoring the database can be done with tools like phpmyadmin and you can give it a new name, or use the old name. The script I mentioned simply changes text inside the database after it is already restored.
  - 0
  - 2012-01-08
  - Yoav Aner
- Salut Yoav,mercipour la réponse,je veux dire,lorsquej'exporte unebase de données,je changenormalement lenom de labase de donnéespar lenouveauet change les liens de domaine.Dit ceci,à l'étapenuméro deux,vous dites restaurer le vidagetel quel sansmodifications,je voulaisjuste savoir si cela littéralement,ouje dois aumoins changer lenom de labase de données.Je sais que celapeut être une questionfactice,je suisjuste unpeuperdu,merciencorepour votre réponse
  
  Hi Yoav, thanks for the answer, I mean, when I export a DB I normally change the database name to the new one and changes the domain links. Said this, on ur step number two you say restore the dump as-is w/o modifications, I just wanted to know if that literally, or I have to change the database name at least. I know it can a be a dummy question, I'm just kind of lost, thanks again for ur answer
  - 0
  - 2012-01-08
  - andresmijares
- Jene saispas comment vous vider votrebase de données,mais si vous utilisez l'outil «export» dephpmyadmin,lenom de labase de donnéesn'apas d'importance.Vouspouvez utiliser l'exportationet la réimporter dansn'importe quelle autrebase de données.En règlegénérale,en ce qui concerne lepoint 2,je pense que vouspouvez changer lenom de labase de données.
  
  I don't know how you dump your database, but if you use phpmyadmin 'export' tool, then it doesn't matter which database name it is. You can use the export and import it back to any other database. Generally, regarding bullet-point 2, I think that's ok to change the database name.
  - 0
  - 2012-01-09
  - Yoav Aner
- 2
- 2011-05-23
L'OP étaittrop zélé lors d'une rechercheet remplacement sur lefichier d'exportation de labase de données,et afini par changer les occurrences de "wp_" dans certaines des données sérialisées. La solutionest d'êtreplusparcimonieux dans la rechercheet le remplacementen incluant lebacktick dans l'expression régulière,puisen mettant àjourmanuellement les clés restantes dans labase de données après l'importation.

Si vousmigrezet modifiez lepréfixe,et que vouspréférez une approcheplusmanuelle,procédez comme suit (celane résout que lespréoccupations des OPet netraitepas de lamise àjour de l'URL du site)

Sauvegardezet déplacez votreexportation debase de données Fichier SQL vers lenouvelenvironnement (monexemple suppose unnom defichierbackup_YYYY-MM-DD.sql)

Effectuez une rechercheet un remplacementen masse sur le Fichier SQLpourmodifier lesnoms detable pour utiliser votrenouveaupréfixe (AVANT importez votrefichier SQL!). Unemanière faire cela serait d'utiliser un Perl une ligne comme:perl -p -i.bak -e "s/` wp_/`monpréfixe_/g" backup_YYYY-MM-DD.sql

Importez vos données SQL dans labase de données

Mettez àjourtoutes les clés dans _options qui contiennent lepréfixe codéen dur: mettre àjour l'ensemble demyprefix_options nom_option= concat ('monpréfixe _',substr (nom_option,4)) oùnom_option comme 'wp_%'

Mettre àjourtoutes les clés dans _user_meta qui contiennent lepréfixe codéen dur: mettre àjour l'ensemblemyprefix_usermeta meta_key= concat ('monpréfixe _',substr (meta_key,4)) oùmeta_key comme 'wp_%'
The OP was overzealous when doing a search-and-replace on the database export file, and ended up changing occurrences of "wp_" within some of the serialized data. The solution is to be more parsimonious in the search-and-replace by including the backtick within the regular expression, and then manually updating the remaining keys within the database after import.

If you are migrating and changing the prefix, and like a more manual approach, do the following (this only addresses the OPs concerns and does not deal with updating the site URL)

Backup and move your database export SQL file to the new environment (my example assumes a filename of backup_YYYY-MM-DD.sql)

Do a mass search-and-replace on the SQL file to change the table names to use your new prefix (PRIOR to importing your SQL file!). One way to do this would be to use a Perl one-liner like: perl -p -i.bak -e "s/`wp_/`myprefix_/g" backup_YYYY-MM-DD.sql

Import your SQL data into the database

Update any keys within _options that contain the prefix hard-coded: update myprefix_options set option_name = concat('myprefix_',substr(option_name,4)) where option_name like 'wp_%'

Update any keys within _user_meta that contain the hard-coded prefix: update myprefix_usermeta set meta_key = concat('myprefix_',substr(meta_key,4)) where meta_key like 'wp_%'
- 0
- 2012-07-10
J'ai utilisé leplugin WP Migrate ,qui remplace httpet les correctifs de dossier. J'aieu un seulproblème lors de l'importation,maisj'ai résolu deplacer les lignes suivantesen haut du sqlgé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 aussiessayé avec l'outil Rechercheret remplacer (v2.1) répondupar @Yoav,maisilbrisetoujoursmes données sérialisées.
I used WP Migrate plugin, witch replaces http and folder patches. I got a single problem when importing, but resolved putting the following lines at the top of the generated sql:

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

I also tried with the Search And Replace tool (v2.1) replied by @Yoav, but it still breaks my serialized data.
- Bonjour Ricardo,Bienvenue sur WordPress Answers!La zone dans laquelle vous avezpostéest réservée aux réponses à la question d'origine.Même si votre questionest liée,vous devez lapublieren tant que question distincte.Vous aurez unebien meilleure chance d'obtenir une réponse de cettefaçon.
  
  Hi Ricardo, Welcome to WordPress Answers! The area you posted in is reserved for answers to the original question. Even though your question is related you should post it as a separate question. You'll get a much better chance of having it answered that way.
  - 0
  - 2012-07-11
  - Chris_O

Otto · Accepted Answer · 2011-02-10

45

2011-02-10

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

J'aiensuite édité lefichier .sql résultant pourmettre àjourtous les chemins defichierset Références URLpourpointer versnotre site deproduction.

Vousne pouvezpasfaire ça. WordPress stocke denombreuses options sousforme de "données sérialisées",qui contiennent à lafois le contenu de la chaîne des choses et leur longueur . Ainsi,lorsque vousmodifiez l'URLet que la longueur change,les données sérialiséesne sontplus correcteset PHP les rejette.

Leproblème àplus longtermeest que,fondamentalement,vous lefaitesmal. Si vous configurez un site de développement dont les données serontmigrées,il doit avoirexactement lamême URL que votre site deproductionpour commencer. Vouspouvezmodifiermanuellement votrefichier HOSTSpour donner à ce domaine deproduction (commeexample.com) une adresse IP différente (comme 127.0.0.1)et ainsi l'URL "production" deviendra le site de développement,pour vous seulement. Ensuite,vouspouvez créer vos données,vos lienset tout le reste à l'aide de cette URL deproduction,et lorsque vousmigrez les données,rien à ce sujetne doit êtremodifié.

À courtterme,cependant,n'utilisezpas une simple recherche/remplacement detexte sur lefichier SQL. Comme vous l'avez découvert,cela casse les choses.

Etbien quej'hésite à le suggérer,ilexiste unmoyen demodifier le code debase de WordPresspourgérer ces sérialisationsbrisées. Vous devezmodifier lefichier wp-includes/functions.php,et changer lafonctionpeut-être_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]); }

Cen'est PAS une solution viable à longterme. Ilne devrait être utilisé quepour vous aider àtravailler dèsmaintenant. À longterme,vous devez corriger votreprocessus de développement afin dene pas avoir àfaire cetype demunging d'URLpour commencer.

This is where your problem is:

I then edited the resulting .sql file to update all of the file paths and URL references to point to our production site.

You can't do that. WordPress stores many options as "serialized data", which contains both the string content of things and their length. So when you modify the URL and the length changes, then the serialized data is no longer correct, and PHP rejects it.

The longer term problem is that, basically, you're doing it wrong. If you are setting up a development site that will have its data migrated, then it should have the exact same URL as your production site to begin with. You can manually edit your HOSTS file to give that production domain (like example.com) a different IP address (like 127.0.0.1) and thus the "production" URL will become the development site, for you only. Then you can create your data and links and everything else using that production URL, and when you migrate the data, nothing about it has to be altered.

In the short term, however, don't use a simple text search/replace on the SQL file. As you have discovered, this breaks things.

And while I hesitate to suggest it, there is a way to alter the WordPress core code to handle these broken serializations. You have to modify the wp-includes/functions.php file, and change the maybe_unserialize() function to this:

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

This is NOT a viable long term solution. It should only be used to get you up and working right now. In the long run, you need to fix your development process so that you don't have to do this sort of URL munging to begin with.

@Ottoexcellente réponse.Question rapide,est-ce que lamodification d'unetableblob/textenon sérialisée comme wp_postsen dehors de MySql aurait uneffet sur l'une des données sérialisées dans wp_post_meta ou wp_options?J'aieu lemêmeproblème avec le widgettextemaisje n'aipastouché à wp_options,j'ai seulementmodifié wp_posts.

@Otto excellent answer. Quick question, would modifying a non serialized blob/text table like wp_posts outside of MySql effect any of the serialized data in wp_post_meta or wp_options? I had the same problem with the text widget but I didn't touch wp_options I only modified wp_posts.
- 0
- 2011-02-10
- Chris_O
Wow,je n'aijamais réalisé que c'était ce qui sepassait avec les données,mais c'esttout àfait logique!Mercibeaucoup!

Wow, I never realized that is what was happening with the data, but it makes complete sense! Many thanks!
- 0
- 2011-02-10
- Dillie-O
Cen'est PAS une solution viable à longterme.-mêmepaspeu detemps.

This is NOT a viable long term solution. - not even short time.
- 0
- 2011-02-11
- hakre
Intéressant;comment éditer lefichier hostspourpointerexample.com sur localhost 127.0.0.1?

Interesting; how does one edit the hosts file to point example.com at localhost 127.0.0.1?
- 0
- 2011-02-11
- markratledge
Si vous souhaitez lefaire sur votremachine locale,recherchez simplement votrefichier hostset ajoutez-y uneentrée (consultez superuser.compourtrouver les spécificités de votre système d'exploitation).Sinon,vous demandez à votre administrateur des opérations ou du réseau deplacer uneentrée sur le contrôleur de domaine.

If you want to do it on your local machine, simply find your hosts file and add an entry there (check superuser.com to find the specifics to your OS). Otherwise you have your Operations or Network administrator put an entry at the domain controller.
- 0
- 2011-02-11
- Dillie-O
Une autre solution de contournement que certainespersonnes utilisentest defaireen sorte que leur système de développement ait unnom de domaine «example.dev» au lieu de «example.com».De cettefaçon,les longueursne changentpaspour les chaînes lorsqu'elles les déplacenten production.Jepréfère laméthode dufichier HOSTS.

Another workaround that some people use is to make their development system have a domain name of "example.dev" instead of "example.com". That way, lengths don't change for strings when they move them to production. I prefer the HOSTS file method.
- 4
- 2011-02-11
- Otto
@songdogtech - Ajoutez unenouvelle ligne dans lefichier hosts `127.0.0.1example.com`,lefichier setrouve dans` C: \ WINDOWS \ system32 \ drivers \etc \ hosts` .. (en supposant le chemin d'installationpar défaut).Remarque: Xamppet les applications similaires ajoutentgénéralement des hôtes virtuels dans cefichier,vous aurez doncprobablement déjà quelquesentrées.

@songdogtech - Add a new line in the hosts file `127.0.0.1 example.com`, file is located in `C:\WINDOWS\system32\drivers\etc\hosts`..(assuming default installation path). Note: Xampp and similar apps usually add virtual hosts into this file, so you'll likely have a few entries there already.
- 0
- 2011-02-12
- t31os
Cen'estpas vraiment une solution,maisplutôt un hack!Ce sont également des scénarios quine vouspermettentpas demodifier lefichier hôte.Parexemple.derrière unproxy d'entreprise ou si vous avez httpsen productionet httpen développement.

This is not really a solution, but more of a hack! It's also scenarios which doesn't allow you to change the host file. E.g. behind a corporate enteprise proxy or if you have https in production and http on development.
- 0
- 2012-08-08
- grm
2016et wordpressenregistretoujours les données sérialisées dans labase de données.Leprix du «pire code leplus célèbre»ne doitpas chercherplus loin.

2016 and wordrepss is still saving serialized data in database. `most famous worst code` prize has to look no further.
- 4
- 2016-03-08
- Ejaz
JE VOUS REMERCIE!!!Bonpointet bon hack.Engénéral,je reçois ce hackpour renvoyertoutes les donnéeset après cela,il suffit demettre àjour ànouveau lesparamètresexistantset de supprimer ce codefonctionneparfaitement.

THANK YOU!!! Good point and great hack. Generaly I get this hack to return back all data and after that just update existing settings again and when remove this code work perfect.
- 1
- 2017-02-04
- Ivijan Stefan Stipić
wp-cli utilisant "wp dbimport" devraitgérer celapar défautpour autant queje sache,maispourmoi,je n'aitoujourspas affiché les données du widget.Est-ce quej'ai râté quelque chose?

wp-cli using "wp db import" should handle this by default as far as I know, but for me I still did not get the widget data displayed. Am i missing something here?
- 0
- 2018-06-21
- trainoasis