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?
Réponses:
C'est là que se situe votre problème:
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:
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.
la source
most famous worst code
le prix ne doit pas chercher plus loin.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/
la source
http://localhost/Me/site_name
parhttp://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.localhost/Me/site_name
parsite.dev
.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:
la source
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)
la source
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é:
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.
la source