[WP-CLI]WordPressデータベースのURLを置換する

1. ドメイン変更時に起こる問題

WordPressのサイトを別のサーバーに移行したり、ドメインを変更した場合、サイト全体に思わぬ問題が発生することがあります。特に、サイト内に埋め込まれているリンクや画像のURLが古いドメインを参照し続けると、正常に表示されない部分が出てきます。 例えば、次のような問題がよく起こります:

• 画像が表示されない: 投稿やページに挿入されている画像が古いドメイン名を使用しているため、表示されなくなります。画像のリンクが正しく更新されないと、閲覧者には「画像が見つかりません」というエラーが表示されてしまいます。
• リンクが機能しない: サイト内や外部サイトへのリンクが古いドメインを使ったままになっているため、クリックしても目的のページに遷移できなくなります。これにより、ユーザー体験が損なわれ、SEO（検索エンジン最適化）にも悪影響を与えます。
• 管理画面にアクセスできない: WordPressの管理画面が古いドメインに基づいて動作している場合、移行後に正しいURLでアクセスできなくなることがあります。この問題が発生すると、サイトの設定変更やコンテンツの編集ができなくなるため、サイトの運営に支障が出ます。
• テーマやプラグインの設定が機能しない: 一部のテーマやプラグインは、URLをハードコードしている場合があります。これらの設定が更新されないと、テーマやプラグインが正常に機能しないことがあります。

これらの問題は、単にWordPressファイルを移動するだけでは解決できません。なぜなら、WordPressはデータベース内にURLを保存しており、これを適切に更新しなければならないからです。しかし、手動でデータベースを更新するのは非常に時間がかかり、間違いを起こしやすい作業です。 このような問題に対処するためには、効率的な方法が必要です。次に紹介するのが、WP-CLIというツールです。WP-CLIを使うことで、簡単にデータベース内の古いURLを新しいドメインに一括で置換することができます。しかし、記事のメインは独自スクリプトなので最後まで読んでいってくださいね。

2. WP-CLIとは？

移行時のドメイン変更による問題に対処するために役立つのが、WP-CLIというツールです。初心者の方でも「CLIって何？」「WP-CLIってどういうもの？」と思うかもしれませんので、順を追って分かりやすく説明します。

CLIって何？

まず、CLI（Command Line Interface）という言葉について少し触れましょう。CLIは「コマンドラインインターフェース」といって、画面にコマンドを入力してコンピューターに指示を出す仕組みです。普段、私たちはブラウザをクリックして操作したり、ボタンを押してアプリを動かしますが、CLIは「文字を入力して操作」します。 例として、フォルダを開いたり、ファイルを削除するような作業を、マウスではなくキーボードで行うようなイメージです。

WP-CLIとは？

では、WP-CLIについて説明します。WP-CLIは、WordPressをコマンドラインから操作できるツールです。通常、WordPressの管理はブラウザを使って行いますが、WP-CLIを使うと、コマンドを入力するだけでWordPressの様々な操作を簡単に行うことができます。 例えば：

• プラグインのインストールやテーマの更新をブラウザを開かずに一瞬で行えます。
• データベースの中のデータを一括で置換したり、特定の投稿を削除することもできます。

つまり、WP-CLIを使うことで、WordPressの管理作業を効率化できるわけです。特に、今回のようにドメインが変わった際にデータベース内のURLを一括で置換する作業に非常に便利です。

WP-CLIを使うメリット

初心者の方でも「これって本当に必要？」と思うかもしれませんが、WP-CLIを使うことで、次のようなメリットがあります。

• 高速: ブラウザから手作業で一つ一つ変更するのではなく、WP-CLIを使えば、コマンド一つで複数の作業を一気に完了できます。
• 正確: WP-CLIはシリアライズされたデータにも対応しているため、手作業では壊れやすいデータも安全に変更できます。つまり、データが破損するリスクが少なくなります。
• 自動化: 複数のサイトを管理している場合でも、同じコマンドを使って、他のサイトにも同じ操作を一気に適用できるため、効率が格段に上がります。

WP-CLIの具体的な使い方

では、WP-CLIをどのように使うのか、簡単な例を見てみましょう。

WP-CLIをインストールする

まずは、WP-CLIを使うためにインストールが必要です。ただし、サーバーの環境によってはWP-CLIがインストールされていない場合があるので、その場合はサーバー管理者に問い合わせるか、サーバーがWP-CLIに対応しているかを確認しましょう。 インストールする方法については、WP-CLIの公式サイトを参考にしてください。

WP-CLIのインストール方法

WordPressを効率よく管理できるツールであるWP-CLIをインストールする方法を、初心者の方にもわかりやすく説明します。ここでは、基本的な手順として、Pharファイルを使ったインストール方法を紹介します。

1. 必要な動作環境を確認する

WP-CLIをインストールする前に、まず動作環境を確認しましょう。以下の条件が満たされていれば、WP-CLIをスムーズにインストールして使うことができます。

• UNIX系の環境（例：OS X、Linux、FreeBSD、Cygwin）: Windowsでも使用できますが、一部の機能に制限がある場合があります。
• PHP 5.6以上のバージョン: WP-CLIはPHPを使って動作するため、PHPがインストールされている必要があります。PHPのバージョンが古い場合は、PHPを最新バージョンにアップデートしてください。
• WordPress 3.7以上のバージョン: WordPressの古いバージョンを使用している場合、一部のWP-CLI機能が正しく動作しないことがあります。

2. WP-CLIをダウンロードする

WP-CLIをインストールするために、Pharファイル（実行可能なPHPアーカイブ）をダウンロードします。これを使えば、WP-CLIを簡単にインストールして使うことができます。 次のコマンドをターミナル（コマンドライン）で実行して、WP-CLIのPharファイルをダウンロードします。

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

curlというコマンドを使って、WP-CLIのPharファイルをインターネットからダウンロードしています。wp-cli.pharという名前で、現在のディレクトリにファイルが保存されます。

3. Pharファイルが動作するか確認する

次に、ダウンロードしたPharファイルが正しく動作するか確認します。以下のコマンドを実行してください。

php wp-cli.phar --info

このコマンドを実行すると、WP-CLIが動作しているかどうかを確認するための情報が表示されます。PHPのバージョンやWP-CLIのバージョンが正しく表示されれば、インストールがうまくいっていることを確認できます。しかし以下の表示されました。

コマンド 'php' が見つかりません。次の方法でインストールできます:
sudo apt install php8.3-cli # version 8.3.6-0ubuntu0.24.04.1, or
sudo apt install php-cli # version 2:8.2+93ubuntu1
sudo apt install php8.2-cli # version 8.2.12-1ubuntu2

WP-CLIの実行にはPHPが必要ですが、私の環境ではPHPがまだインストールされていないため、このメッセージが表示されています。Ubuntu 24.04での選択肢について説明します。 選択肢：

• php8.3-cli: PHP 8.3のコマンドラインインターフェース（CLI）をインストールするオプションです。PHP 8.3は最新のバージョンで、今後の更新やサポートが期待できます。ただし、一部のWordPressプラグインやテーマがまだPHP 8.3に対応していない可能性があります。
• php-cli（バージョン 8.2）: こちらはUbuntu 24.04で標準的に提供されているPHP 8.2のCLIをインストールするオプションです。PHP 8.2は、安定しており、WordPressや多くのプラグインが対応しているバージョンです。おすすめの選択肢として最適です。
• php8.2-cli: PHP 8.2のCLIのみをインストールするオプションで、php-cliとほぼ同じですが、特定のバージョンを明示的に指定してインストールする形になります。

おすすめ: php-cli（バージョン 8.2）が最も無難な選択です。PHP 8.2は安定しており、WordPressの多くのプラグインやテーマとの互換性も高いため、特にトラブルが少ないでしょう。つまり以下のコマンドを入力してインストールします。

sudo apt install php-cli

再度、php wp-cli.phar –infoコマンドで確認すると以下のようになり、これで大丈夫でしょう。

OS:     Linux 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  2 20:41:06 UTC 2024 x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php8.3
PHP version:    8.3.6
php.ini used:   /etc/php/8.3/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 8.0.39-0ubuntu0.24.04.2 for Linux on x86_64 ((Ubuntu))
SQL modes:
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /home/mamu/mysql
WP-CLI packages dir:
WP-CLI cache dir:       /home/mamu/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.11.0

いやいや、バージョン 8.2をインストールしたにもかかわらず、上の結果をみると8.3になっています。これについて調べてみました。 なぜ2番目のオプション（sudo apt install php-cli）を選択したにもかかわらず、PHPのバージョンが8.3として表示されるのかという疑問が残ります。

結論

php-cli パッケージをインストールすると、システムのデフォルトPHPバージョン（この場合はPHP 8.3）のCLIがインストールされるため、php コマンドを実行するとPHP 8.3が使用されます。

詳細な説明

php-cli パッケージについて

• php-cli は、Ubuntuにおける メタパッケージ であり、システムのデフォルトPHPバージョンのCLIを提供します。
• デフォルトPHPバージョンは、システムのリポジトリ設定やインストール状況によって変わります。

提示されたインストールオプション

1. sudo apt install php8.3-cli # version 8.3.6-0ubuntu0.24.04.1, or
2. sudo apt install php-cli # version 2:8.2+93ubuntu1
3. sudo apt install php8.2-cli # version 8.2.12-1ubuntu2

• 1番目: PHP 8.3 のCLIを明示的にインストールします。
• 2番目: php-cli メタパッケージで、システムのデフォルトPHPバージョンのCLIをインストールします。
• 3番目: PHP 8.2 のCLIを明示的にインストールします。

バージョン番号の混乱

• php-cli のバージョン番号 2:8.2+93ubuntu1 はパッケージ自体のバージョンであり、実際にインストールされるPHPのバージョンとは異なります。
• システムのデフォルトPHPバージョンが8.3であれば、php-cli をインストールするとPHP 8.3のCLIがインストールされます。

php コマンドの動作

• php コマンドはデフォルトのPHPバージョンを指します。
• したがって、php wp-cli.phar –info を実行すると、システムのデフォルトPHPバージョンであるPHP 8.3が使用されます。

なぜこのような結果になるのか

• システムのデフォルトPHPバージョンがPHP 8.3であるため、php-cli パッケージをインストールするとPHP 8.3のCLIがインストールされ、php コマンドもPHP 8.3を指します。

パッケージのバージョンとPHPのバージョンの違い

• パッケージのバージョン番号は、パッケージ管理システム内でのバージョン管理に使用され、ソフトウェア自体のバージョンとは直接対応しない場合があります。

対策や確認事項

• 現在の設定で問題がなければ、そのままご使用いただけます。
• PHP 8.3 が正常に動作し、WP-CLI も問題なく動作しているのであれば、特に変更の必要はありません。

特定のPHPバージョンを使用したい場合

PHP 8.2 を使用したい場合は、以下の手順で対応できます。

1. PHP 8.2 のCLIをインストール

   sudo apt install php8.2-cli

2. update-alternatives コマンドでデフォルトPHPを切り替える

   sudo update-alternatives --config php

   表示される一覧から、PHP 8.2 のパスを選択します。

補足情報

• update-alternatives コマンド 複数のバージョンのPHPがインストールされている場合、このコマンドでデフォルトのPHPバージョンを切り替えることができます。
• PHP のバージョン確認 php -v コマンドで現在のPHPバージョンを確認できます。

• php-cli パッケージはシステムのデフォルトPHPバージョンのCLIをインストールするため、PHP 8.3 が使用されます。
• 選択したオプションが期待したバージョンを提供しなかった理由は、php-cli がメタパッケージであり、実際のPHPバージョンを指定していないためです。
• 必要に応じて、特定のPHPバージョンのCLIパッケージをインストールし、update-alternatives コマンドでデフォルトを切り替えることができます。

4. WP-CLIをコマンドとして使えるようにする

Pharファイルが正しく動作することが確認できたら、WP-CLIを簡単に使えるように設定します。通常、wpというコマンドでWP-CLIを実行できるようにします。 まず、Pharファイルを実行可能にするために、次のコマンドを実行します。

chmod +x wp-cli.phar

次に、Pharファイルをシステムのパスに移動して、どこからでも実行できるようにします。

sudo mv wp-cli.phar /usr/local/bin/wp

これで、wpというコマンドを使ってWP-CLIを簡単に実行できるようになります。

5. WP-CLIが正しくインストールされたか確認する

WP-CLIが正しくインストールされたかどうか、以下のコマンドを実行して確認します。

wp --info

このコマンドを実行すると、PHPのバージョンやMySQLのバージョンなど、WP-CLIが使用する環境情報が表示されます。これでWP-CLIのインストールは完了です。

WP-CLIのアップデート

WP-CLIは定期的にアップデートされますので、最新の機能を使うためにも定期的な更新が必要です。WP-CLIをアップデートするには、次のコマンドを使います。

wp cli update

もしWP-CLIが管理者権限でインストールされている場合は、アップデート時にsudoを使う必要があります。

sudo wp cli update

また、開発者向けの最新バージョンを試したい場合は、次のコマンドで夜間ビルド版に更新することもできます。

wp cli update --nightly

これで、WP-CLIの最新バージョンを使って作業を進めることができます。

1. タブ補完を設定する

WP-CLIを使う際、コマンドを途中まで入力すると自動的に補完してくれる「タブ補完」機能を設定すると、より快適に作業ができます。Bashやzshを使っている場合、次のようにタブ補完を設定します。

Bashの場合

1. タブ補完用のスクリプトをダウンロードします。

   curl -O https://raw.githubusercontent.com/wp-cli/wp-cli/master/utils/wp-completion.bash

2. ダウンロードしたスクリプトを~/.bash_profileに読み込むよう設定します。

   source /FULL/PATH/TO/wp-completion.bash

3. 設定を反映させるために、次のコマンドを実行します。

   source ~/.bash_profile

zshの場合

zshでは、Bashのタブ補完機能を読み込むために追加の設定が必要です。以下のコードを~/.zshrcファイルに追加します。

autoload bashcompinit
bashcompinit
source /FULL/PATH/TO/wp-completion.bash

これで、タブ補完が有効になり、WP-CLIのコマンドを入力する際に途中まで入力した後、Tabキーを押すことでコマンドを補完できます。

2. コマンドを実行してドメインを置換する

WP-CLIを使えば、移行時にデータベース内の古いドメイン名を新しいドメイン名に一括で置換することができます。具体的には、次のコマンドを実行します。

wp search-replace 'http://古いドメイン.com' 'http://新しいドメイン.com' --all-tables

このコマンドを実行すると、データベース内のすべてのテーブルに対して、古いドメインを新しいドメインに一括で置換します。

実際のコマンド

wp search-replace '192.168.0.50' '192.168.0.91' --all-tables

• wp search-replace: この部分が「検索して置換する」命令です。
• ‘http://古いドメイン.com’: ここに、移行前の古いドメインを指定します。
• ‘http://新しいドメイン.com’: こちらに、新しく設定したドメインを入力します。
• –all-tables: これを追加することで、WordPressの全テーブルを対象に置換を実行します。

3. バックアップを取る

最後に、WP-CLIを使う前に必ずデータベースのバックアップを取ってください。万が一ミスがあった場合にも、元に戻せる安心感があります。 バックアップを取るコマンド例：

wp db export backup.sql

このコマンドを使うと、現在のデータベースをbackup.sqlというファイルにエクスポートして保存します。 WP-CLIは、初心者にも非常に便利なツールであり、特に移行時のドメイン変更などで大きな助けになります。初めて使うときは少し不安かもしれませんが、一度使ってみるとその便利さに驚くでしょう。データベースの一括操作やプラグイン管理などもすぐにできるようになるので、WordPressを効率よく管理したい方にはぜひ試してみてほしいツールです。

WP-CLIのwp db exportとは？

wp db exportは、WP-CLIが提供するデータベースのエクスポート機能です。これを使うと、mysqldumpを使わなくても簡単にWordPressのデータベースのバックアップが取れます。mysqldumpと同様の機能を持っていますが、WP-CLIを通じてWordPressに最適化された方法でデータベースを扱うことができます。

コマンドの解説

wp db export backup.sql

• wp db export: WP-CLIのデータベースエクスポートコマンドです。現在のWordPressインストールで使用されているデータベース全体をエクスポートします。
• backup.sql: エクスポートされたデータベースの保存先ファイル名を指定します。この場合は backup.sql というファイルに保存されます。

mysqldumpと異なり、WP-CLIのこのコマンドはWordPress環境に特化しているため、WordPressサイトの管理に慣れている方には使い勝手が良いです。

比較：mysqldumpとwp db export

• mysqldump: MySQLの汎用的なデータベースエクスポートツールです。WordPress以外のデータベースもエクスポートできるため、WordPressに特化していない一般的なデータベースバックアップツールとして使用されます。自分はこちらを使っています。

  mysqldump -u ユーザー名 -p データベース名 > backup.sql

• wp db export: WP-CLIを使って簡単にWordPressサイトのデータベースをエクスポートするコマンド。mysqldumpのように詳細な設定を行う必要がなく、WordPressの管理環境に統合されているため、手軽にバックアップを取ることができます。

利便性

• 初心者向け: wp db exportは、mysqldumpを使うよりも簡単に操作できるため、WP-CLIをインストールしている環境では、初心者にも使いやすいです。
• 統合されたツール: WP-CLIを使えば、他の管理作業と一貫して操作できるため、WordPressに慣れているユーザーには便利です。

もしWP-CLIが使用できる環境であれば、WordPressサイトのバックアップの際にこのコマンドを使うことで、手軽にデータベースのバックアップを取ることができます。

WP-CLIを使ったURL置換方法

WordPressサイトを移行したり、ドメイン名を変更した場合、データベース内のURLを一括で置換する必要があります。これを手作業で行うのは非常に大変ですが、WP-CLIを使うと簡単に、安全に、しかも効率よくURLを置換できます。 ここでは、WP-CLIを使って、古いドメインから新しいドメインにURLを置換する方法を詳しく説明します。

置換を始める前の準備

まず、データベースのバックアップを必ず取ってください。置換作業中に何か問題が発生した場合に備えて、データベースのバックアップがあれば、すぐに元に戻せます。 バックアップの方法は、前のセクションでも紹介しましたが、再度確認しておきましょう。

wp db export backup.sql

このコマンドを使うと、現在のWordPressのデータベースをbackup.sqlという名前で保存できます。これで万が一の時にも安心です。

注意点：

• wp db export backup.sql コマンドを実行した場合、バックアップファイルはコマンドを実行したディレクトリに作成されます。
• 例えば、現在の作業ディレクトリが/home/user/であれば、backup.sqlファイルは/home/user/backup.sqlとして保存されます。
• バックアップファイルを特定の場所に保存したい場合は、パスを指定することもできます。

例：

wp db export /home/user/backups/backup.sql

これで、指定した場所にバックアップファイルが作成されます。

エラーが発生した場合：

次のようなエラーが発生した場合：

Error: This does not seem to be a WordPress installation.
The used path is: /home/mamu/mysql/
Pass --path=`path/to/wordpress` or run `wp core download`.

このエラーメッセージは、コマンドを実行したディレクトリがWordPressのインストールされているディレクトリではないために発生しています。WP-CLIのコマンドは、WordPressのインストールディレクトリで実行する必要があります。

解決方法：

1. WordPressのインストールディレクトリで実行する
   • WordPressがインストールされているディレクトリに移動してからコマンドを実行します。
   • 例：cd /var/www/html/wordpress
   • その後、バックアップコマンドを実行：wp db export backup.sql
2. –pathオプションを使う
   • 現在のディレクトリから離れずに操作を行いたい場合、–pathオプションを使います。
   • 例：wp db export backup.sql --path=/var/www/html/wordpress

Docker環境での対応：

Docker環境でWordPressを運用している場合、ホスト上からWP-CLIを実行するのが少し複雑に感じられるかもしれませんが、適切な方法で対処することが可能です。

解決策：Dockerコンテナ内でWP-CLIを使う

1. コンテナ内でWP-CLIをインストールする
   • コンテナにログイン：docker exec -it <コンテナ名> bash
   • WP-CLIをダウンロードしてインストール：

     curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
     chmod +x wp-cli.phar
     mv wp-cli.phar /usr/local/bin/wp

2. WP-CLIを使ってバックアップを取る
   • コンテナ内でコマンドを実行：wp db export /var/www/html/backup.sql
3. ホストとコンテナ間でファイルを共有する
   • ホストにマウントしているディレクトリがある場合、そのマウントポイントを使ってバックアップファイルをホストに保存できます。

具体例：

docker exec -it <コンテナ名> wp db export /var/www/html/backup.sql

これで、ホストマシンにマウントされているフォルダにバックアップファイルが作成されます。

2. 置換の基本的な流れ

次に、古いURLを新しいURLに置換する基本的なコマンドを実行します。この操作を行うために使用するのが、WP-CLIのsearch-replaceコマンドです。 基本的なコマンド：

wp search-replace 'http://古いドメイン.com' 'http://新しいドメイン.com' --all-tables

3. コマンドの詳細説明

• wp search-replace: これは「検索して置換する」というWP-CLIのコマンドです。
• ‘http://古いドメイン.com’: これは、検索対象となる「古いURL」を指定する部分です。
• ‘http://新しいドメイン.com’: こちらには、新しいドメイン名を入力します。
• –all-tables: このオプションは、WordPressのデータベース内のすべてのテーブルを対象に置換を実行することを指定しています。

4. より安全に置換するためのオプション

置換を行う前に、実際にどの部分が置換されるのか確認したい場合は、–dry-runオプションを使うと良いです。

wp search-replace 'http://古いドメイン.com' 'http://新しいドメイン.com' --all-tables --dry-run

Docker環境の場合：

docker exec -it --user www-data wp wp search-replace '192.168.0.50' '192.168.0.91' --all-tables

5. 実際に置換を実行する

シミュレーションが問題なければ、実際に置換を行います。–dry-runオプションを外してコマンドを実行します。

wp search-replace 'http://古いドメイン.com' 'http://新しいドメイン.com' --all-tables

6. 置換が完了したら

置換が完了したら、WordPress サイトを再度確認して、すべての URL が正しく新しいドメインに変更されているか確認します。特に、以下の点に注意してください：

• 投稿内のリンク
• 画像の表示
• 管理画面へのアクセス

wp search-replace コマンドの詳細

wp search-replace 'http://古いドメイン.com' 'http://新しいドメイン.com' --all-tables このコマンドは、WordPress のデータベース全体のすべてのテーブルを対象に、古いドメインの URL を新しいドメインに置換します。

置換対象

1. wp_posts テーブルの post_content カラム: 投稿やページの本文内にあるリンクや画像の URL も含まれます。
2. wp_options テーブルの siteurl および home カラム: WordPress の基本 URL やフロントページの URL も置換されます。
3. wp_posts テーブルの guid カラム: 投稿やページのパーマリンク（固定リンク）の URL も置換対象になります。
4. その他のテーブル: プラグインやテーマによって作成されたテーブルを含め、データベース全体が置換対象になります。

注意点

• このコマンドは、シリアライズされたデータも正しく処理します。
• 全テーブルが対象となるため、意図しない場所まで置換されるリスクもあります。
• 外部リンクや一部のプラグインの設定ファイルに保存された URL も変更される可能性があります。

wp search-replace コマンドは、データベース全体を対象に置換を行い、投稿本文（post_content）も含まれます。すべてのテーブルが対象になるため、慎重に使う必要があります。万が一に備えて、バックアップを取ってから実行することを強く推奨します。

WP-CLIを使用したデータベース内URLの一括置換

WP-CLIを使えば、データベース内のURLを安全かつ効率的に一括で置換することができます。以下のメリットがあります：

• 手作業での変更が不要で、作業時間が大幅に短縮
• シリアライズされたデータにも対応し、データ破損のリスクを最小限に抑制
• 初心者でも簡単に操作可能

注意： 作業前にバックアップを取り、–dry-runオプションを使用して安全に進めることを心がけてください。

WP-CLIのデータベースインポート機能

WP-CLIにはwp db importコマンドを使用したデータベースのインポート機能があります。

基本的な使用方法：

wp db import <ファイル名>.sql

使用例：

wp db import backup.sql

注意点：

1. インポート前に現在のデータベースをバックアップすること
2. wp-config.phpファイルに正しいデータベース接続情報が設定されていることを確認
3. WP-CLIを実行するユーザーが十分な権限を持っていることを確認

その他のデータベース関連コマンド

• wp db reset：データベースをリセットし、すべてのテーブルを削除
• wp db query：カスタムのSQLクエリを実行

WP-CLIが使えない場合の対処法

WP-CLIが使えないサーバーでも、独自のスクリプトを使ってURLを置換することができます。

Pythonスクリプトを使った対処法

準備：

1. Pythonがサーバーにインストールされているか確認
2. MySQL Connectorをインストール：pip install mysql-connector-python
3. その他必要なモジュールをインストール

独自スクリプトの作成

URLを置換するPythonスクリプトを作成します。

import mysql.connector
import logging
import os
import argparse
from dotenv import load_dotenv
from concurrent.futures import ThreadPoolExecutor, as_completed
from tqdm import tqdm
import phpserialize

# .envファイルから環境変数を読み込む
load_dotenv()

# ログファイルの設定
logging.basicConfig(
    level=logging.DEBUG,  # ログレベルをDEBUGに設定
    format='%(asctime)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('wpurl_replace.log', encoding='utf-8'),
        logging.StreamHandler()
    ]
)

# コマンドライン引数の解析
parser = argparse.ArgumentParser(description='WordPress URL置換スクリプト')
parser.add_argument('--dry-run', action='store_true', help='実際の置換を行わずに確認だけ行う')
parser.add_argument('--old-url', required=True, help='置換元URL')
parser.add_argument('--new-url', required=True, help='置換先URL')
args = parser.parse_args()
logging.debug(f"コマンドライン引数: {args}")

# データベース接続設定
db_config = {
    'user': os.getenv('DB_USER'),
    'password': os.getenv('DB_PASSWORD'),
    'host': os.getenv('DB_HOST'),
    'database': os.getenv('DB_NAME'),
}
logging.debug(f"データベース設定: {db_config}")

# 以降の関数定義（省略せずにすべて記載）

# テーブルごとの主キーを取得する関数
def get_primary_key(table_name):
    primary_keys = {
        'wp_options': 'option_id',
        'wp_postmeta': 'meta_id',
        'wp_users': 'ID',
        'wp_posts': 'ID',
        'wp_commentmeta': 'meta_id',
        'wp_comments': 'comment_ID',
        'wp_links': 'link_id',
        'wp_term_taxonomy': 'term_taxonomy_id',
        'wp_termmeta': 'meta_id',
        'wp_terms': 'term_id',
        'wp_usermeta': 'umeta_id',
    }
    return primary_keys.get(table_name, 'id')  # デフォルトは'id'

# データベース接続を確立する関数
def connect_to_database():
    try:
        conn = mysql.connector.connect(**db_config, autocommit=True)
        logging.debug("データベースに接続しました")
        return conn
    except mysql.connector.Error as err:
        logging.error(f"データベース接続エラー: {err}")
        raise

# 全テーブルを取得する関数
def get_all_tables(cursor):
    cursor.execute("SHOW TABLES")
    return [table[0] for table in cursor.fetchall()]

# 特定のテーブルの全カラムを取得する関数
def get_columns(cursor, table_name):
    cursor.execute(f"SHOW COLUMNS FROM `{table_name}`")
    return cursor.fetchall()

# カラムがシリアライズされているかどうかを確認する関数
def is_column_serialized(table_name, column_name):
    serialized_columns = {
        'wp_options': ['option_value'],
        'wp_postmeta': ['meta_value'],
        # 他のシリアライズされたデータを含むテーブルとカラムを追加
    }
    return table_name in serialized_columns and column_name in serialized_columns[table_name]

# シリアライズされたデータのURLを置換し、再シリアライズする関数
def unserialize_replace_serialize(data, old_url, new_url):
    try:
        unserialized = phpserialize.loads(data.encode())
        if isinstance(unserialized, dict):
            for key, value in unserialized.items():
                if isinstance(value, bytes):
                    value_str = value.decode()
                    unserialized[key] = value_str.replace(old_url, new_url).encode()
        return phpserialize.dumps(unserialized).decode()
    except Exception:
        return data.replace(old_url, new_url)

# テーブル内の特定カラムに対してURLを置換する関数
def replace_url_in_table(table_name, column_name, old_url, new_url, dry_run):
    conn = connect_to_database()  # スレッドごとにデータベース接続
    cursor = conn.cursor()
    try:
        primary_key = get_primary_key(table_name)  # 主キーを取得
        if is_column_serialized(table_name, column_name):
            if dry_run:
                logging.info(f"Would replace serialized data in {table_name}.{column_name}")
                return 0
            else:
                sql = f"SELECT {primary_key}, `{column_name}` FROM `{table_name}` WHERE `{column_name}` LIKE %s"
                cursor.execute(sql, (f'%{old_url}%',))
                rows = cursor.fetchall()
                logging.debug(f"{table_name}.{column_name} で {len(rows)} 行が見つかりました")
                update_count = 0
                for row in rows:
                    id, data = row
                    new_data = unserialize_replace_serialize(data, old_url, new_url)
                    if new_data != data:
                        update_sql = f"UPDATE `{table_name}` SET `{column_name}` = %s WHERE {primary_key} = %s"
                        cursor.execute(update_sql, (new_data, id))
                        logging.debug(f"Updated row with ID {id} in {table_name}.{column_name}")
                        update_count += 1
                return update_count
        else:
            if dry_run:
                sql = f"SELECT COUNT(*) FROM `{table_name}` WHERE `{column_name}` LIKE %s"
                cursor.execute(sql, (f'%{old_url}%',))
                count = cursor.fetchone()[0]
                logging.info(f"Would replace {count} occurrences in {table_name}.{column_name}")
                return count
            else:
                sql_update = f"""
                UPDATE `{table_name}`
                SET `{column_name}` = REPLACE(`{column_name}`, %s, %s)
                WHERE `{column_name}` LIKE %s
                """
                cursor.execute(sql_update, (old_url, new_url, f'%{old_url}%'))
                affected_rows = cursor.rowcount
                logging.debug(f"Updated {affected_rows} rows in {table_name}.{column_name}")
                return affected_rows
    except mysql.connector.Error as err:
        logging.error(f"Error in {table_name}.{column_name}: {err}")
        return 0
    finally:
        cursor.close()
        conn.close()

def main():
    try:
        logging.debug("main関数を開始します")
        conn = connect_to_database()
        cursor = conn.cursor()

        tables = get_all_tables(cursor)
        logging.debug(f"取得したテーブル: {tables}")
        total_updates = 0

        with ThreadPoolExecutor(max_workers=5) as executor:
            futures = []
            for table_name in tables:
                columns = get_columns(cursor, table_name)
                logging.debug(f"テーブル {table_name} のカラム: {columns}")
                for (column_name, column_type, _, _, _, _) in columns:
                    if 'char' in column_type or 'text' in column_type or 'varchar' in column_type:
                        logging.debug(f"{table_name}.{column_name} の処理を開始します")
                        future = executor.submit(
                            replace_url_in_table,
                            table_name,
                            column_name,
                            args.old_url,
                            args.new_url,
                            args.dry_run
                        )
                        futures.append(future)

            with tqdm(total=len(futures), desc="Processing") as pbar:
                for future in as_completed(futures):
                    try:
                        result = future.result()
                        total_updates += result
                        pbar.update(1)
                    except Exception as e:
                        logging.error(f"Error during URL replacement: {e}", exc_info=True)

        print(f"Total updates: {total_updates}")
        if args.dry_run:
            print("Dry run completed. No changes were made.")
        else:
            print("URL置換が完了しました。")

    except Exception as e:
        logging.error(f"予期せぬエラーが発生しました: {e}", exc_info=True)
    finally:
        if 'conn' in locals() and conn.is_connected():
            cursor.close()
            conn.close()
            logging.debug("データベース接続を閉じました")

if __name__ == "__main__":
    main()

スクリプトの主な機能

• 詳細なログ出力

必要な環境と準備

必要なPythonパッケージ：

• Python 3.7以上
• mysql-connector-python
• python-dotenv
• tqdm
• phpserialize

パッケージのインストール：

pip install mysql-connector-python python-dotenv tqdm phpserialize

.envファイルの作成：

スクリプトと同じディレクトリに.envファイルを作成し、以下の内容を記載：

DB_USER=あなたのデータベースユーザー名
DB_PASSWORD=あなたのデータベースパスワード
DB_HOST=データベースサーバーのホスト名またはIPアドレス
DB_NAME=データベース名

スクリプトの使用方法

コマンドライン引数：

• --old-url：置換したい古いURL（必須）
• --new-url：新しいURL（必須）
• --dry-run：ドライランモードを有効にする（オプション）

実行例：

実際にデータを置換する場合：

python wpurl_replace.py --old-url http://oldsite.com --new-url http://newsite.com

ドライランモードで実行する場合（変更は行われません）：

python wpurl_replace.py --old-url http://oldsite.com --new-url http://newsite.com --dry-run

注意事項

• バックアップの取得： スクリプトを実行する前に、必ずデータベースのバックアップを取得してください。
• テスト環境での検証： 最初にテスト環境でスクリプトを実行し、期待通りに動作することを確認してから本番環境で実行してください。
• 適切な権限： データベースに対して読み書きの権限があるユーザーで接続してください。
• ログの確認： スクリプト実行後、wpurl_replace.logファイルを確認してエラーがないかチェックしてください。

コマンドラインが苦手な方向けの代替方法

コマンドラインに慣れていない方には、PhpMyAdminやAdminerなどのウェブベースのデータベース管理ツールがおすすめです。

PhpMyAdminでのデータベースインポート方法

3. 「インポート」タブをクリック
4. ファイルの選択
5. オプションの設定
6. 実行

PhpMyAdminのメリット

• ユーザーフレンドリー： 直感的なインターフェースで、コマンドを覚える必要がありません。
• 即時フィードバック： 操作結果がすぐに画面に表示されるため、作業の進行状況を把握しやすいです。
• 多機能： インポート以外にも、テーブルの編集やクエリの実行など、多彩な機能を備えています。

注意点

• 大容量データのインポート： サーバーの設定によっては、アップロードできるファイルサイズに制限がある場合があります。
• セキュリティ： PhpMyAdminは強力なツールであるため、不正アクセスを防ぐために適切なセキュリティ対策が必要です。

代替ツールの紹介

• Adminer： シングルファイルで動作する軽量なデータベース管理ツールです。
• MySQL Workbench： デスクトップアプリケーションとして提供される公式のMySQL管理ツールです。

まとめ

データベース内のURL置換には、以下の方法があります：

1. WP-CLI： コマンドラインに慣れている方向け。効率的で安全な方法。
2. 独自のPythonスクリプト： WP-CLIが使えない環境で、プログラミングスキルがある方向け。
3. PhpMyAdminなどのGUIツール： コマンドラインが苦手な方や、視覚的な操作を好む方向け。

ポイント

• 自分に合ったツールを選択： 作業内容や自身のスキルレベルに応じて、最適なツールを選びましょう。
• バックアップの重要性： どのツールを使用する場合でも、データベースのバックアップは必ず取得してください。
• セキュリティ対策： ウェブベースのツールを使用する際は、セキュリティに十分注意しましょう。

以上の方法を参考に、自分に最適な方法でWordPressデータベース内のURLを安全に置換してください。不明な点がある場合は、専門家に相談することをおすすめします。

GitHub - superdoccimo/wprep

Contribute to superdoccimo/wprep development by creating an account on GitHub.

github.com