WordPressは数十のデータベーステーブルに絶対URLを保存しているため、ドメインを変更したりSSLに移行したりすると、投稿、オプション、プラグインの設定のあちこちに古いアドレスが残ります。それらを安全に一掃する方法が検索と置換です。このガイドでは、KPanelでサポートされている2つの方法、よく使われる3つ目の方法がデータを破損させる理由、そして結果を検証する方法について説明します。
検索と置換が必要になるとき
- SSLを有効にした後、
http://からhttps://に移行するとき。 - ドメインを変更するとき(例:
old-brand.co.nzからnew-brand.co.nzへ)。 - ステージングを本番環境に反映した後、ステージングのホスト名がデータベースに残っているとき。
- 古いアセットホストを廃止し、すべての画像URLを一度に新しい場所へ向け直すとき。
- 古い電話番号や販売終了した製品名など、多数の投稿にまたがる同じ誤りを一括で修正するとき。
検索と置換は、すべてのテーブルの行を一度に書き換え、行単位で元に戻すことはできません。どんなにささいに見える変更であっても、毎回必ず開始前にバックアップを取得してください。以下で説明する組み込みのツールを使う場合はKPanelが自動的にバックアップを作成しますが、ご自身でコマンドを実行する場合はご自身の責任となります。バックアップの取得をご覧ください。
SQLのREPLACEをそのまま実行してはいけない理由
これはWordPressのデータベース作業で最も大きな被害をもたらす間違いなので、方法を選ぶ前に理解しておく価値があります。
WordPressは、プラグインの設定、テーマのオプション、ウィジェットのデータをPHPのシリアライズされた文字列として保存しています。シリアライズされた文字列には、次のように、内部の各値の長さが記録されています。
a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}
このs:26は、URLが26文字であることを示しています。単純なSQLのREPLACE()でhttp://をhttps://に置き換えると、テキストは27文字になるのに、保存されている長さは26のままです。するとPHPはそのオプション全体のアンシリアライズを拒否し、設定は何の警告もなく空に戻ります。テーマカスタマイザーの設定は消え、スライダーはスライドを失い、プラグインのライセンスは登録が解除されてしまいます。
KPanelが実行するWP-CLIのsearch-replaceは、各値をアンシリアライズし、その中で置換を行い、正しい長さで再シリアライズします。そのため、ここで説明するのはこの方法だけです。
WordPressのデータベースに対して、UPDATE wp_options SET option_value = REPLACE(...)やphpMyAdminでの同等の操作は絶対に実行しないでください。一見うまくいったように見え、影響を受けた行数も表示されますが、触れたすべてのシリアライズされた設定を静かに破壊します。バックアップから復元する以外に修復の方法はありません。
方法1: 検索と置換カード
ほぼすべての方にとって、これが正しい選択です。すべてのWordPressプランで利用できます。
- KPanelにサインインし、左サイドバーのウェブサイトをクリックします。
- 対象のサイトをクリックします。
- WordPressタブを開き、続けてクイックアクションセクションを開きます。
- 検索と置換カードを見つけ、設定するをクリックします。
- 検索(古い値)に既存のテキストを入力します。
- 置換後の値に新しいテキストを入力します。
- ドライラン(プレビューのみ、変更なし)にチェックを入れたまま、プレビューをクリックします。
ドライランでは、置換が何件行われるかが報告され、その件数がテーブルと列ごとに内訳表示されるため、実行する前に変更がどこに反映されるかを正確に確認できます。
プレビューの内容に問題がなければ、次の手順に進みます。
- ドライランのチェックを外します。
- 実行をクリックします。
- ダイアログで確定します。
置換が始まる前に完全なバックアップが自動的に取得され、プラグインが作成したテーブルを含むすべてのテーブルが処理対象になります。
できるだけ具体的な文字列で検索してください。old-domain.co.nzを置換すると、mail.old-domain.co.nzやstaging.old-domain.co.nzも書き換えられますが、それを望むことはまずありません。https://old-domain.co.nzのようにスキームを含めると、一致する範囲を絞り込めます。
方法2: コンソールからWP-CLIを使う
コンソールでは同じエンジンを使いながら、フラグをより細かく指定できます。コンソールはマネージドプランで表示されるセクションの1つです。それ以外のプランでは、タブの並びに代わりに+8 on Managedのリンクが表示されます。
サイトを開き、WordPress、コンソールの順に開きます。プロンプトはすでにwpで始まっているため、コマンドの残りの部分だけを入力します。
まずプレビューします。
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run
次に、実際に実行します。
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables
コンソールではバックアップは自動で取得されません。実行前の自動バックアップは、方法1の検索と置換カードを使う場合にのみ行われます。ここでコマンドを実行する場合は、先にサイトのバックアップページからご自身でバックアップを取得してください。
便利なフラグ:
| フラグ | 内容 |
|---|---|
--all-tables | WordPressのコアテーブルだけでなく、プラグインが作成したカスタムテーブルも対象に含めます |
--dry-run | 何が変更されるかを報告し、何も書き込みません |
--precise | 置換にSQLではなくPHPを使います。速度は遅くなりますが、扱いにくいシリアライズ構造にも対応できます |
--skip-columns=guid | 投稿のGUIDには手を加えません(下記参照) |
--report-changed-only | 出力を実際に変更されたテーブルだけに絞ります |
GUIDに関する注意
WordPressのすべての投稿にはguid列があります。URLのように見えますが、これはリンクではなく識別子で、フィードリーダーはこれを使って項目をすでに見たかどうかを判断します。これを書き換えると、フィード内のすべての投稿が新しい投稿として再表示されることがあります。
ドメインを恒久的に変更して新たに始める場合は、GUIDを書き換えてください。同じドメインでHTTPからHTTPSに移行するだけの場合は、--skip-columns=guidで除外してください。
ドメインを変更する場合: 代わりにサイトURLカードを使う
サイトを新しいドメインに移すことが目的なら、検索と置換から始めないでください。同じクイックアクションセクションにあるサイトURLを変更カードは、siteurlとhomeのオプションを更新し、すべてのテーブルに対する置換を1回の操作で正しい順序で実行します。逆の順序で行うと、WordPressが自身の管理画面を読み込めなくなることがあります。
置換の後で
完了とする前に、次のリストを順に確認してください。
- キャッシュをフラッシュします。 クイックアクションセクションでキャッシュをフラッシュを実行します。サイトでフルページキャッシュを使用している場合は、WordPress、キャッシュの順に開いてパージします。
- リライトルールをフラッシュします。 同じセクションでリライトをフラッシュを実行するか、wp-adminで設定、パーマリンクの順に開き、何も変更せずに変更を保存をクリックします。
- サイトでCDNを使用している場合は、パフォーマンス、Kapsule CDNの順に開いてCDNをパージします。Kapsule CDN のキャッシュをパージするをご覧ください。
- ブラウザのキャッシュに惑わされないよう、プライベートウィンドウでサイトを読み込みます。
- 鍵マークを確認します。 SSLへの移行後に鍵マークが表示されない、または警告が表示される場合は、URLが置換されずに残っています。混在コンテンツ警告の修正をご覧ください。
- 細かい設定の多いページをクリックして確認します。 ホームページのスライダー、ヘッダーのロゴ、ページビルダーで作成したページ、ストアのチェックアウトなどです。これらは、シリアライズされたオプションに保存されているURLを保持しています。
- キャッシュプラグインを使用している場合は、そのプラグインの設定画面からキャッシュをクリアします。
トラブルシューティング
ドライランで置換件数がゼロと表示される。 その文字列は、まったく同じ形ではデータベースに存在しません。末尾のスラッシュ、www.の接頭辞、スキームを確認してください。まずホスト名だけで検索して、そもそも存在するかどうかを確認してみてください。
ドメイン変更後に画像が表示されない。 メディアのURLはwp_postsとwp_postmetaにあり、--all-tablesで処理対象になりますが、CDNや画像最適化プラグインが独自に書き換えたコピーをキャッシュしている場合があります。CDNとプラグインのキャッシュをパージしてから、再読み込みしてください。
置換後に設定が消えた。 これはシリアライズの問題で、変更がここで紹介したツールではなく、生のSQLで行われたことを意味します。実行前に取得したバックアップから復元してください。バックアップからの復元をご覧ください。
ステージングのURLが何度も戻ってくる。 何かがそれらを再び書き込んでいます。通常は、スケジュールされた反映か、キャッシュされたオプションが原因です。ステージングの使い方: プッシュとプルでワークフローを確認し、反映時にURLを書き換えるにチェックが入っていることを確認してください。