Warum verliert mein Datenbankimport Text-Widget-Daten?

46

Ich habe eine Site in WordPress auf unserer Entwicklungsmaschine erstellt. In dem von uns verwendeten Design gibt es zahlreiche Widget-Bereiche, in denen Text angezeigt werden kann (Seitenleiste und Startseite). In all diesen Bereichen habe ich einfache Text-Widgets verwendet, um unsere Anzeigeinformationen zu platzieren.

Bei der Migration der Site zur Produktion habe ich das WP-DB-Backup-Plugin verwendet, um einen Snapshot der Datenbank zu erstellen. Anschließend habe ich die resultierende .sql-Datei bearbeitet, um alle Dateipfade und URL-Verweise zu aktualisieren, die auf unsere Produktionssite verweisen.

Nach dem Erstellen der Datenbank, der Website und dem Kopieren aller Dateien auf die Produktionssite führe ich die .sql-Datei an der mysql-Eingabeaufforderung aus, um die Daten in die neue Datenbank zu importieren.

Wenn ich jedoch zur Produktionsstätte gehe, wird ein Teil des Textes angezeigt und ein Teil nicht. Wenn ich in den Widgets-Bereich der Site schaue, fehlen die Text-Widgets in einigen Widget-Zonen. Die Text-Widgets sind nicht einmal in der Zone "Inaktives Widget" sichtbar, sie sind einfach nicht dort.

Ich habe sogar versucht, den Vorgang mit dem BackWPup-Plugin zu wiederholen, wobei ich bemerkte, dass die SQL-Syntax sich unterscheidet, wenn die Datenbank ausgegeben wird.

Warum verliere ich Text-Widget-Daten während des Imports?

Dillie-O
quelle
Unterwegs habe ich ein bisschen gegraben, und ich kann mir nur vorstellen, dass die Widget-Informationen in der Tabelle wp_options gespeichert werden, die einige ihrer Daten auf seltsame Weise zu codieren scheint. Ich habe es noch nicht mit einem anderen Thema versucht, um festzustellen, ob es mit dem Thema zusammenhängt.
Dillie-O

Antworten:

44

Hier liegt Ihr Problem:

Anschließend habe ich die resultierende .sql-Datei bearbeitet, um alle Dateipfade und URL-Verweise zu aktualisieren, die auf unsere Produktionssite verweisen.

Das kannst du nicht machen. WordPress speichert viele Optionen als "serialisierte Daten", die sowohl den Zeichenfolgeninhalt von Dingen als auch deren Länge enthalten . Wenn Sie also die URL ändern und die Länge ändert, sind die serialisierten Daten nicht mehr korrekt und PHP lehnt sie ab.

Das langfristige Problem ist, dass Sie es im Grunde falsch machen. Wenn Sie eine Entwicklungssite einrichten, deren Daten migriert werden sollen, sollte sie zunächst genau dieselbe URL wie Ihre Produktionssite haben. Sie können Ihre HOSTS-Datei manuell bearbeiten, um dieser Produktionsdomäne (wie example.com) eine andere IP-Adresse (wie 127.0.0.1) zuzuweisen. Auf diese Weise wird die "Produktions" -URL nur für Sie zur Entwicklungssite. Dann können Sie Ihre Daten und Links und alles andere unter Verwendung dieser Produktions-URL erstellen, und wenn Sie die Daten migrieren, muss nichts daran geändert werden.

Verwenden Sie jedoch kurzfristig keine einfache Textsuche / -ersetzung für die SQL-Datei. Wie Sie festgestellt haben, werden die Dinge dadurch zerbrochen.

Und während ich zögere, es vorzuschlagen, gibt es eine Möglichkeit, den WordPress-Kerncode zu ändern, um diese kaputten Serialisierungen zu handhaben. Sie müssen die Datei wp-includes / functions.php ändern und die Funktion maybe_unserialize () folgendermaßen ändern:

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

Dies ist KEINE praktikable langfristige Lösung. Es sollte nur verwendet werden, um Sie sofort zum Laufen zu bringen. Auf lange Sicht müssen Sie Ihren Entwicklungsprozess korrigieren, damit Sie diese Art von URL-Munging nicht von Anfang an ausführen müssen.

Otto
quelle
@Otto ausgezeichnete Antwort. Kurze Frage, würde das Ändern einer nicht serialisierten Blob / Text-Tabelle wie wp_posts außerhalb von MySql die serialisierten Daten in wp_post_meta oder wp_options beeinflussen? Ich hatte das gleiche Problem mit dem Text-Widget, aber ich habe wp_options nicht berührt, sondern nur wp_posts geändert.
Chris_O
Wow, ich habe nie bemerkt, dass das mit den Daten passiert ist, aber es ist absolut sinnvoll! Danke vielmals!
Dillie-O
4
Eine andere Problemumgehung, die einige Leute verwenden, besteht darin, ihr Entwicklungssystem mit dem Domainnamen "example.dev" anstelle von "example.com" zu versehen. Auf diese Weise ändern sich die Längen für Zeichenfolgen nicht, wenn sie in die Produktion verschoben werden. Ich bevorzuge die HOSTS-Dateimethode.
Otto
3
2016 und wordrepss speichert noch serialisierte Daten in der Datenbank. most famous worst codePreis muss nicht weiter suchen.
Ejaz
1
DANKESCHÖN!!! Guter Punkt und toller Hack. Im Allgemeinen bekomme ich diesen Hack, um alle Daten zurück zu geben und danach einfach die vorhandenen Einstellungen erneut zu aktualisieren und wenn dieser Code entfernt wird, funktioniert er einwandfrei.
Ivijan Stefan Stipić
10

Um dieses Problem zu lösen, verwende ich immer das hier bereitgestellte WordPress Serialized Search & Replace Tool. Es funktioniert einwandfrei ohne Probleme. Ich verwende dies seit langer Zeit für alle meine Website-Migrationsanforderungen. Hiermit werden die Probleme bei der Migration der Entwicklungsdatenbank in die Produktion behoben.

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

Subharanjan
quelle
1
Ja,
ich
Hat die meiste Zeit für mich gearbeitet. Aber in dieser Woche , als ich ersetzt http://localhost/Me/site_namedurch http://site.dev(von einem lokalen Host zu einem anderen) mit v 3.0.0 Ich habe mein Widget und Menüpositionen seltsam genug verlieren. Vielleicht hängt dieses Problem auch mit der Saitenlänge zusammen.
rhand
Ich habe verwendet, aber noch nie mit dieser Situation konfrontiert. Können Sie die ältere Version dieses Skripts herunterladen und es erneut versuchen? Versuchen Sie ersetzen localhost/Me/site_namemit site.dev.
Subharanjan
Die URL wurde geändert (jetzt https statt http): interconnectit.com/products/…
Koryonik
Wunderschönes Skript. Ich habe eine MySQL-Datenbank von PHPMyAdmin von einer alten auf eine neue kopiert - keine Änderung der URLs - und bin dann in den Ordner der neuen Site gegangen, in dem sich die neuen WP-Dateien befanden (neben einer richtigen wp-config.php) neue DB-Anmeldeinformationen), fügte das Skript hinzu und kümmerte sich um alles. Serialisierte Daten werden entlang der normalen URLs aktualisiert. Einfach und schnell! Sehr empfehlenswert. Wichtig: Vergessen Sie nicht, das Skript nach der Verwendung zu entfernen, da es Zugriff auf Ihre DB-Details hat!
Erdnüsse
7

Ottos Antwort ist genau richtig. Ich habe das auch auf die harte Tour entdeckt.

Ich habe es jedoch geschafft, dies mit einem coolen Skript unter http://spectacu.la/search-and-replace-for-wordpress-databases/ zu umgehen.

Gehen Sie wie folgt vor, um WordPress und einen neuen URL / Domain-Namen zu migrieren:

  1. Nehmen Sie einen DB-Dump (z. B. mit phpmyadmin) des vorhandenen WordPress
  2. Stellen Sie den Speicherauszug wie er ist (keine Änderungen erforderlich) an Ihrem neuen Speicherort wieder her
  3. Entpacke das Skript von spectacu.la in deinen WordPress-Home-Ordner (es ist kein Plugin ...)
  4. Führen Sie das Skript auf Ihrer neuen Site aus, indem Sie Ihren Browser darauf verweisen, z. B. http: //new-website.url/searchreplacedb.php
  5. Vergiss nicht, das Skript aus deinem neuen WordPress-Zuhause zu löschen
Yoav Aner
quelle
1
Ich weiß, dass dies irgendwie alt ist, aber wo soll ich den neuen Datenbanknamen angeben, wenn ich den Speicherauszug wieder herstelle, wie er ist? sollte ich nicht wenigstens den neuen Datenbanknamen in den zweiten Schritt einfügen? Vielen Dank für diese Info
andresmijares
Ich bin nicht sicher, ob ich Ihre Frage vollständig verstehe. Das Wiederherstellen der Datenbank kann mit Tools wie phpmyadmin erfolgen und Sie können ihm einen neuen Namen geben oder den alten Namen verwenden. Das Skript, das ich erwähnte, ändert einfach Text in der Datenbank, nachdem es bereits wiederhergestellt wurde.
Yoav Aner
Hallo Yoav, danke für die Antwort, ich meine, wenn ich eine DB exportiere, ändere ich normalerweise den Datenbanknamen in den neuen und ändere die Domain-Links. Gesagt, in Ihrem zweiten Schritt, sagen Sie, stellen Sie den Dump unverändert ohne Änderungen wieder her. Ich wollte nur wissen, ob dies wörtlich ist, oder ich muss den Datenbanknamen zumindest ändern. Ich weiß, es kann eine Scheinfrage sein, ich bin nur irgendwie verloren, nochmals
vielen
Ich weiß nicht, wie Sie Ihre Datenbank sichern, aber wenn Sie das 'Export'-Tool von phpmyadmin verwenden, spielt es keine Rolle, um welchen Datenbanknamen es sich handelt. Sie können den Export verwenden und ihn wieder in eine andere Datenbank importieren. Im Allgemeinen halte ich es in Bezug auf Aufzählungspunkt 2 für in Ordnung, den Datenbanknamen zu ändern.
Yoav Aner
2

Das OP war beim Suchen und Ersetzen der Datenbank-Exportdatei übereifrig und änderte schließlich das Vorkommen von "wp_" in einigen der serialisierten Daten. Die Lösung besteht darin, beim Suchen und Ersetzen sparsamer zu sein, indem das Backtick in den regulären Ausdruck einbezogen und die verbleibenden Schlüssel in der Datenbank nach dem Import manuell aktualisiert werden.

Wenn Sie das Präfix migrieren und ändern und einen manuelleren Ansatz bevorzugen, gehen Sie wie folgt vor (dies behebt nur die Bedenken des OP und behandelt nicht die Aktualisierung der Site-URL).

  1. Sichern und verschieben Sie Ihre Datenbank-SQL-Exportdatei in die neue Umgebung (in meinem Beispiel wird der Dateiname backup_YYYY-MM-DD.sql angenommen)
  2. Führen Sie eine Massensuche und -ersetzung für die SQL-Datei durch, um die Tabellennamen zu ändern und Ihr neues Präfix zu verwenden (VOR dem Import Ihrer SQL-Datei!). Eine Möglichkeit, dies zu tun, besteht darin, einen Perl-Einzeiler wie den folgenden zu verwenden: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
  3. Importieren Sie Ihre SQL-Daten in die Datenbank
  4. Aktualisieren Sie alle Schlüssel in _options, die das fest codierte Präfix enthalten: update myprefix_options set option_name = concat ('myprefix _', substr (option_name, 4)) wobei option_name wie 'wp_%'
  5. Aktualisieren Sie alle Schlüssel in _user_meta, die das fest codierte Präfix enthalten: update myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) wobei meta_key wie 'wp_%'
Tom Auger
quelle
0

Ich habe das WP Migrate- Plugin verwendet, das http- und Ordner-Patches ersetzt. Beim Importieren ist ein einziges Problem aufgetreten, es wurde jedoch behoben, die folgenden Zeilen oben in die generierte SQL-Datei einzufügen:

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

Ich habe es auch mit dem Tool zum Suchen und Ersetzen (v2.1) versucht, das von @Yoav beantwortet wurde, aber meine serialisierten Daten werden trotzdem beschädigt.

Ricardo Martins
quelle
Hallo Ricardo, Willkommen bei WordPress Answers! Der Bereich, in dem Sie gepostet haben, ist für die Beantwortung der ursprünglichen Frage reserviert. Auch wenn Ihre Frage verwandt ist, sollten Sie sie als separate Frage veröffentlichen. Sie haben eine viel bessere Chance, dass es auf diese Weise beantwortet wird.
Chris_O