WordPress
WordPress データベースで検索と置換を実行する
WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…
WordPressデータベースで検索と置換を実行する
WordPressは数十のデータベーステーブルに絶対URLを保存しているため、ドメイン変更またはSSL移行により古いアドレスが投稿、オプション、プラグイン設定全体に散在します。検索と置換はこれらを安全にクリーンアップする方法です。このガイドでは、KPanelでサポートされている2つの方法、なぜ一般的な第3の方法がデータを破損するのか、そして結果を検証する方法をカバーしています。
必要になるケース
http://からSSLを有効にした後に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検索置換は各値をアンシリアライズし、その内部で置換し、補正された長さで再シリアライズします。これがここで唯一記述されている方法である理由です。
WordPressデータベースに対してUPDATE wp_options SET option_value = REPLACE(...)またはphpMyAdminの同等のコマンドを実行しないでください。動作しているように見え、影響を受けた行を報告しますが、それが触れたすべてのシリアライズ設定を静かに破壊します。バックアップを復元する以外に修復方法はありません。
方法1: 検索と置換カード
これはほぼすべてのユーザーに適切な選択です。すべてのWordPressプランで利用可能です。
- KPanelにサインインし、左サイドバーのWebsitesをクリックします。
- サイトをクリックします。
- WordPressタブを開き、その後Quick Actionsセクションを開きます。
- Search & Replaceカードを探してConfigureをクリックします。
- **Find (old value)**に既存のテキストを入力します。
- Replace withに新しいテキストを入力します。
- Dry run (preview only, no changes)にチェックが入ったままにしてPreviewをクリックします。
ドライラン実行は行われる置換の数を報告し、テーブルと列ごとに分類したカウントを表示するため、コミットする前に変更がどこに適用されるかを正確に確認できます。
プレビューが正しく見える場合:
- Dry runのチェックを外します。
- Runをクリックします。
- ダイアログで確認します。
完全なバックアップが置換開始前に自動的に作成され、実行はプラグインによって作成されたテーブルを含むすべてのテーブルをカバーします。
できるだけ最も具体的な文字列を検索します。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、その後Consoleを開きます。プロンプトは既に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の検索と置換カードを使用する場合にのみ発生します。ここでコマンドを実行する場合は、最初にサイトのBackupsタブからバックアップを自分で作成してください。
便利なフラグ:
| フラグ | 動作 |
|---|---|
--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でそれらをスキップします。
ドメイン変更: 代わりにChange Site URLカードを使用します
全体的な目的がサイトを新しいドメインに移動することの場合、検索と置換で開始しないでください。同じQuick Actionsセクション上のChange Site URLカードはsiteurlとhomeオプションを更新し、正しい順序で1回の操作ですべてのテーブル全体の置換を実行します。別の方法で実行するとWordPressが独自の管理画面を読み込めなくなる可能性があります。
置換後
完了する前にこのリストを確認してください。
- キャッシュをフラッシュします。 Quick ActionsセクションでFlush Cacheを実行します。サイトが全ページキャッシュを使用する場合、WordPressからCachingをパージします。
- 書き換えルールをフラッシュします。 同じセクションでFlush Rewritesを実行するか、wp-adminでSettings、その後Permalinksを開き、何も変更せずにSave Changesをクリックします。
- サイトがそれに含まれている場合、CDNをパージします。PerformanceからKapsule CDNを参照してください。CDNキャッシュのパージを参照してください。
- プライベートウィンドウでサイトを読み込みます。 ブラウザキャッシュが誤解を招く可能性がないようにするためです。
- パドロックを確認します。 SSL移行後に欠落または警告パドロックは左されたURLを意味します。混合コンテンツ警告の修正を参照してください。
- 扱いにくいページをクリックして確認します。 ホームページスライダー、ヘッダーロゴ、ページビルダーで構築されたページ、およびストアのチェックアウト。これらはシリアライズオプションで生存するURLを保有しています。
- キャッシングプラグインをクリアします。 独自の設定画面から。
トラブルシューティング
ドライランはゼロの置換を報告します。 文字列はその正確な形式でデータベースに含まれていません。末尾のスラッシュ、www.プレフィックス、またはスキームを確認してください。まずベアホスト名のみで検索して、まったく存在することを確認してください。
ドメイン変更後に画像が壊れています。 メディアURLはwp_postsとwp_postmetaにあり、--all-tablesによって検出されますが、CDNまたは画像最適化プラグインは独自の書き直されたコピーをキャッシュする可能性があります。CDNとプラグインのキャッシュをパージしてから、リロードしてください。
置換後に設定が消えました。 それはシリアライズ問題であり、変更がここのツール以外のプレーンSQLで行われたことを意味します。実行前に作成されたバックアップを復元します。バックアップから復元を参照してください。
ステージングURLが戻り続けます。 何かがそれらを再度入力しています。通常、スケジュールされたプッシュまたはキャッシュオプションです。ステージングの使用: プッシュとプルでワークフローを確認し、プッシュ時にRewrite URLsにチェックが入っていることを確認してください。