データベースインポートでテキストウィジェットデータが失われるのはなぜですか？

開発用マシンのWordPressでサイトを作成しました。使用しているテーマには、テキストを表示するための多数のウィジェットゾーンがあります（サイドバーとフロントページ）。これらすべてのゾーンで単純なテキストウィジェットを使用して、表示情報を配置しました。

サイトを運用環境に移行したときに、WP-DB-Backupプラグインを使用してデータベースのスナップショットを作成しました。次に、結果の.sqlファイルを編集して、すべてのファイルパスとURL参照を更新して、運用サイトをポイントしました。

データベース、Webサイトを作成し、すべてのファイルを運用サイトにコピーした後、mysqlコマンドプロンプトから.sqlファイルを実行して、新しいデータベースにデータをインポートします。

ただし、本番サイトにアクセスすると、テキストの一部が表示され、一部は表示されません。サイトのウィジェットセクションを見ると、一部のウィジェットゾーンにテキストウィジェットがありません。テキストウィジェットは「非アクティブウィジェット」ゾーンにも表示されず、単に表示されません。

BackWPupプラグインを使用してプロセスを繰り返してみましたが、データベースをダンプするときにSQL構文が異なることに気付きました。

インポート中にテキストウィジェットデータが失われるのはなぜですか？

これが問題の原因です。

次に、結果の.sqlファイルを編集して、すべてのファイルパスとURL参照を更新して、運用サイトをポイントしました。

それはできません。WordPressは、多くのオプションを「シリアル化されたデータ」として保存します。これには、モノの文字列コンテンツとその長さの両方が含まれます。したがって、URLを変更して長さを変更すると、シリアル化されたデータは正しくなくなり、PHPはそれを拒否します。

長期的な問題は、基本的に、あなたが間違っていることです。データを移行する開発サイトをセットアップする場合、最初に運用サイトとまったく同じURLを使用する必要があります。HOSTSファイルを手動で編集して、その実稼働ドメイン（example.comなど）に異なるIPアドレス（127.0.0.1など）を与えることができるため、「実稼働」URLが開発サイトになります。その後、その実稼働URLを使用してデータとリンク、その他すべてを作成できます。データを移行する場合、変更する必要はありません。

ただし、短期的には、SQLファイルで単純なテキスト検索/置換を使用しないでください。あなたが発見したように、これは物事を壊します。

そして、私はそれを提案することをheしますが、これらの壊れたシリアル化を処理するためにWordPressコアコードを変更する方法があります。wp-includes / functions.phpファイルを変更し、maybe_unserialize（）関数を次のように変更する必要があります。

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

これは長期的な解決策ではありません。今すぐあなたを立ち上げて働かせるためだけに使用すべきです。長い目で見れば、この種のURL改thisを最初から行う必要がないように、開発プロセスを修正する必要があります。

この問題に対処するために、私は常にここで提供されるWordPress Serialized Search＆Replaceツールを使用します。問題なく完全に機能します。私はすべてのサイト移行要件でこれを長い間使用しています。これにより、開発データベースを実稼働環境に移行する際の問題に本当に対処できます。

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

オットーの答えはスポットオンです。私もこれを難しい方法で発見しました。

ただし、http：//spectacu.la/search-and-replace-for-wordpress-databases/にあるクールなスクリプトを使用して、この問題を回避することができました。

ワードプレスを新しいURL /ドメイン名に移行するには、次の手順を実行します。

1. 既存のワードプレスのDBダンプを取得します（phpmyadminなどを使用）
2. 新しい場所にダンプをそのまま（変更の必要なし）復元します。
3. スクリプトをspectacu.laからwordpressホームフォルダーに解凍します（プラグインではありません...）
4. ブラウザを指定して、新しいサイトでスクリプトを実行します（例：http：//new-website.url/searchreplacedb.php）
5. 新しいワードプレスのホームからスクリプトを削除することを忘れないでください

OPは、データベースエクスポートファイルで検索と置換を行うときに熱心であり、シリアル化されたデータの一部で "wp_"の出現を変更することになりました。解決策は、正規表現内にバックティックを含め、インポート後にデータベース内の残りのキーを手動で更新することにより、検索と置換をより節約することです。

プレフィックスを移行および変更する場合、およびより手動のアプローチが必要な場合は、次の手順を実行します（これはOPの懸念事項にのみ対応し、サイトURLの更新は扱いません）

1. データベースのエクスポートSQLファイルを新しい環境にバックアップおよび移動します（私の例では、backup_YYYY-MM-DD.sqlのファイル名を想定しています）
2. SQLファイルを一括検索して置換し、新しいプレフィックスを使用するようにテーブル名を変更します（SQLファイルをインポートする前に！）。これを行う1つの方法は、perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sqlのようなPerlワンライナーを使用することです。
3. SQLデータをデータベースにインポートします
4. ハードコードされたプレフィックスを含む_options内のキーを更新します。update myprefix_options set option_name = concat（ 'myprefix _'、substr（option_name、4））where option_name like 'wp_％'
5. ハードコードされたプレフィックスを含む_user_meta内のすべてのキーを更新します。update myprefix_usermeta set meta_key = concat（ 'myprefix _'、substr（meta_key、4））where meta_key like 'wp_％'

私はWP Migrateプラグインを使用し、httpとフォルダーのパッチを置き換えます。インポート時に1つの問題が発生しましたが、生成された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 */;

また、@ Yoavが応答するSearch And Replaceツール（v2.1）を試しましたが、シリアル化されたデータが破損します。