Warum verliert mein Datenbankimport Text-Widget-Daten?

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?

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.

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/

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

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

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.