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

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?

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.

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 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

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_%'

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.