web-dev-qa-db-ja.com

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

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

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

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

しかし、私が本番サイトにアクセスすると、一部のテキストが表示され、一部のテキストは表示されません。私がサイトのウィジェットセクションを見ると、テキストウィジェットがいくつかのウィジェットゾーンからなくなっています。テキストウィジェットは「Inactive Widget」ゾーンにも表示されず、単に存在しません。

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

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

databasemysqlimport
44
Dillie-O

これはあなたの問題があるところです：

次に、作成した.sqlファイルを編集して、すべてのファイルパスとURL参照を更新して私たちの本番サイトを指すようにしました。

それはできません。 WordPressは多くのオプションを "シリアライズされたデータ"として保存します。これには、 の文字列の内容とそれらの長さ の両方が含まれます。そのため、URLを変更して長さを変更すると、シリアル化されたデータは正しくなくなり、PHPはそれを拒否します。

長期的な問題は、基本的に、あなたがそれを間違ってやっているということです。データを移行する開発サイトを設定する場合は、最初に本番サイトとまったく同じURLを使用する必要があります。 HOSTSファイルを手動で編集して、その本番ドメイン（example.comなど）に別のIPアドレス（127.0.0.1など）を指定すると、「本番」URLが開発サイトになります。そうすれば、その本番URLを使用してデータやリンク、その他すべてを作成できます。データを移行しても、それに関する変更は必要ありません。

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

そして私がそれを提案することを躊躇しながら、これらの壊れたシリアル化を処理するために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の変更を行う必要はありません。

43
Otto

この問題に対処するために、私はいつも WordPress Serialized Search＆Replace を使います。それはどんな問題もなく完全にうまくいきます。私はすべての私のサイト移行要件でこれを長い間使っています。これは実際に開発用データベースを本番環境に移行する際の問題を処理します。

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

10
Subharanjan

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

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

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

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

データベースエクスポートファイルで検索と置換を実行すると、OPが非常に面倒で、いくつかのシリアル化されたデータ内で "wp_"の出現箇所が変更されました。解決策は、正規表現内にバックティックを含めて、インポート後にデータベース内の残りのキーを手動で更新することによって、検索と置換をより節約することです。

手動でプレフィックスを移行したり変更したりする場合は、次の手順を実行します（これはOPの懸念事項にのみ対処し、サイトのURLの更新は扱いません）。

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

WP Migrate pluginを使用しました。httpとフォルダのパッチを魔女に置き換えました。インポート時に単一の問題が発生しましたが、生成された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で答えた検索と置換ツール（v2.1）を使っても試したが、それでもシリアル化されたデータは壊れる。

0
Ricardo Martins