【お久しぶり】眠ってたサイトの環境を一気に更新した話

かれこれサイト全体で3年ぶりの更新をします。別の人生を歩んでいたすのえです。

突然とあるメンバーが記事を書きたいと言い出してここの存在を思い出しました。

別に良いよと言おうとしたところ、サイトの動作にかかわるすべての環境が古くなっていました。

そりゃそうです。3年間放置してたんです。WordPressも、PHPバージョンも最新ではありません。

ですが私も一端のエンジニア。なんのケアもせずにボタンポチで3年分の更新はできません。

ということで、「Local」というソフトの力を借りて検証を行い、動作確認を経て更新をしました。

今回はその導入から実行までの記録をここにまとめていこうと思います。

まあ手順はほぼGeminiの言う通りなんですけど、まあ実行記録は聞いても復元できませんから。

最近はGeminiの更新に伴って会話ログが全部消えた悲しい報告も聞きますし、価値はあるでしょ。

状態と要求

ということで状態の整理です。

• 環境：XServer sv13001以前 (以降では新技術が提供されてる。これの更新もいつかやるか…)
• PHP Ver：7.4.33
• WordPress Ver：5.9.12
• データベース：MySQL5.7.x

で、2025年12月にDoragones君から導入したいと話のあったプラグインがこちら。

WordPressバージョンが対応してないです。そりゃそうだ。

導入提案から実際に更新する(翌年1月)までにまた更新が入る最新プラグインなんだしそうだよな。

でもさすがに、WordPressのメジャーバージョン更新を無策で通すのは怖い。

WordPressは多くの人に使われていて公式アップグレード手段がちゃんと用意されてるんだけど、

たくさんプラグインを挿していてそれも更新待機してるので、万が一事故が起きたらやばい。

テスト環境を用意しよう

まあそんなときは、壊してもいい環境でまずは試せってことだ。Geminiに聞いてみた。曰く。

1. ステージング環境の構築:
   ・「Local」（旧Local by Flywheel）などのツールを使い、ローカルPC上に本番環境の複製を作成してください。
2. 段階的アップデート:
   ・可能であれば、いきなり6.9へ行くのではなく、一度「6.0」または「6.2」あたりを経由させると、データベースの更新スクリプトが正しく走りやすいという知見があります（必須ではありませんが、安全策です）。

めんどくせぇがやるしかない。Localを入れてきましょう。

調べてみたけどこれすごいね。WordPress専用のテスト環境構築アプリらしいです。

Localでテスト環境を作る

インストール後、新しいテスト環境を作成します。Blueprintはよくわかんないので新規で。

次のサイト名入力は、自分が見てわかりやすければ何でも良し。

environmentは必ずCustomを選択して現在の環境に近しいものを選んでください。

Preferredにすると、現在の最新環境になります。こっちはプラグインの同居の確認に使えます。

Web Serverに関して聞き覚えの無い人は nginx(読み: エンジンエックス) のままで大丈夫です。

ここまで終わらすと環境のセットアップが自動で開始され、ローディングの表示が出ます。

初回は環境のためのインストールが必要で非常に時間がかかるため、しばらく放置しましょう。

終わると、左下のような状態になります。上のタブからデータベースの状態確認もできます。

“One click admin”オプションはデフォルトでオフになっていますが、オンにすると便利です。

今の状態で一度 “WP Admin” や “Open site” ボタンを押し、デフォルト表示を確認しましょう。

確認してみて下のようになっていたら、失敗です。はい。私は最初うまくいきませんでした。

これらのページは、うまくWordpressへの接続ができなかった際にnginxが提供する画面です。

なんか上手くいかないんですよね。出来てる人はそれでいいんですが、そうでない人のために。

左上のユーザーアイコンのボタンをクリックして、Preferences > Advancedと開いてください。

そしたらその中で一番上の「Router mode」を「localhost」に設定してApplyを押す。

×ボタンを押して戻ると「Warning!」と出るので、「Fix it」を押してまたしばらく放置。

ロードが終わり次第操作できるようになるので、改めてサイトを確認！

下のように、nginxのではなく、Wordpressのページっぽいのになったら成功です！

ちなみにRouter modeを変えるのは”個人設定”なので、次以降の作成ではしなくて大丈夫です。

Localのセットアップで入力したユーザー名とパスワードを使うと実際にログインもできます。

LocalのWordPressバージョンをダウングレード

Localのセットアップが終わってOverviewの各項目を見ていると気づくことがあります。

そういえばWordpressのバージョンは指定してないし、勝手に最新のが入ってる！

実は、こいつはGUI経由でダウングレードすることができないんです。直接やりましょう。

上の方に、「Site Folder」というボタンがあります。クリックしてエクスプローラーを出します。

app > public > と進むと、なんかいろいろある場所に出てきます。全部消しましょう。

ここにある奴は全部WordPress6.9に入ってるもので、ダウングレードするなら全削除してOKです。

で、現在動作しているバージョンと同じものを公式のリリース一覧から落としてきましょう。

それを解凍すると、wordpressフォルダ以下にさっき削除したのと似たのが並んでいるはずです。

これらをそのまま、今削除した app > public > の先に張り付けてください。

そこで一旦Localアプリを閉じてもう一回開き、WordPressバージョンの更新を確認しましょう。

閉じる際は右上の「Stop Site」を、開いた後は「Start Site」をすることを忘れずに。

ただ、この環境はそのままでは正しく動作しません。ここからはコマンドの時間だ！！！！

上の方に、「Site Shell」というボタンがあります。クリックして黒い画面を出しましょう。

そこで、以下のコマンドを入力することで、WordPressのセットアップが完了します。

前半はコンフィグファイルの作成、後半はデータベースの初期化コマンドです。

[Port]には、LocalのDatabaseタブから確認できる「Port」の右にある数字を入れてください。

>wp config create --dbname=local --dbuser=root --dbpass=root --dbhost=localhost:[Port]
>wp db reset --yes

ここまでできたら、Localから「WP Admin」を押して問題なく表示されることを確認しましょう。

データベースの初期化に失敗している場合は少し長いロードを経て右側の表示になります。

ただどちらが表示されたかは関係なく、これはWordPressが表示されることを確認する手順です。

404ページや真っ白なページが出てしまった場合は何かがおかしいので引き返してください。

なお、この先に進もうとするとページ更新のたびに結構なロード時間が発生するようになります。

これは、ローカル環境なのに毎回不要な通信をしていろんな情報を持ってこようとするからです。

app/public/wp-config.phpに対して以下の追記を行うとロードが短縮されることがあります。

// このコードはすでに90行目に定義されている
if ( ! defined( 'WP_DEBUG' ) ) {
	define( 'WP_DEBUG', false );
}

// cronの実行を無効化する
define( 'DISABLE_WP_CRON', true );

本番環境をテスト環境に持ってくる

次に、本番環境をテスト環境に導入して、Local上で本番環境を再現しましょう。

バックアッププラグインとしても有名な「All-in-One WP Migration」は本来このためにあります。

ただ無料版では制限が多くできないことも多いため、このためにわざわざ入れる物ではないです。

すでに導入されている場合は、管理者アカウントからバックアップサイズを確認してください。

こちらにある最新のバックアップを確認すると、1.65GBであることがわかります。

無料版ではアップロードサイズが300MBに制限されているため、それを超える場合は無理です。

ローカルに直接バックアップを配置して復元すれば行けるように見えます。有料版機能です。

は？

All-in-One WP Migrationを使わない方法

まあそもそも、WordPressを動作させるサーバーへのアクセス権限を持っているなら不要です。

XServerの場合の話ですが、ログイン手段があるのならばファイルマネージャーが存在します。

そこで、実際に動作している途中のWordPressの中身をそのまま圧縮してダウンロードします。

WordPressにおけるユーザーデータはデータベースとwp-contentフォルダ以下にあるので、

まずはwp-contentについて右クリックメニューから「圧縮」を選択して圧縮を実行できます。

適切なファイル名を指定して圧縮をすればいいのですが、ここで問題が発生することがあります。

詳細な上限値は公開されていませんが、圧縮サイズが3GBを超えると正常に終了しないようです。

私の場合、先ほどのバックアップデータが含まれており、それだけで4GBを超えました。

別の手段でデータを取得する必要がありそうです。

とりあえず、データベースのバックアップだけでも今のうちに取ってしまいましょう。

「データベース/MySQLバックアップ取得・復元/手動バックアップ」でダウンロードできます。

XServerファイルサーバーで圧縮をしない方法

ほぼすべてのレンタルサーバーでは、そこへsshによる接続を可能としていることが多いです。

sshアクセスならその環境でコマンドを実行することができるので、直接圧縮しに行きましょう。

今回はXServerにおける接続手法を紹介します。サーバーパネルからSSH設定に飛んでください。

ラベルには自分と判別できる名前を登録して、登録して秘密鍵をダウンロードしてください。

次に、エクスプローラーに移動し、ホームディレクトリ(自分の名前の場所)に移動してください。

ホームディレクトリ以下に「.ssh」というファイルがないなら作成して、.sshに移動してください。

そこに先ほどダウンロードした秘密鍵ファイルを移動し、id_ed25519_xserverに名前を変えます。

また、configという無拡張子ファイルがなければ作成し、メモ帳などで無理やり開きましょう。

そこに、以下のテキストを記入するか、すでに記入があればテキストを追記します。

Host xserver.jp
    HostName [host name]
    User [server id]
    Port [接続ポート]
    IdentityFile ~/.ssh/id_ed25519_xserver

[host name]は「サーバー/サーバー情報」から、[server id]はサーバーパネルから確認できます。

[接続ポート]は「サーバー/SSH設定/SSHソフト設定」にある同名のオプションにある数字です。

次に、コマンドプロンプト(Localから起動できるSite Shellでも可)を開いてください。

開くことができたら、 ssh xserver.jp と入力して実行しましょう。

入力欄の左にあった C:Users\user> みたいな表示が [svid@sv9999 ~]$ になっていれば成功です。

試しに ls -a という現在のディレクトリにあるものを表示するコマンドを打って確認しましょう。

WordPressの中身があるのは[server domain]/public_html/wp-content以下です。

以下のコマンドは、All-in-One WP Migrateのバックアップを含めない圧縮データを作成します。

$ cd [server domain]/public_html
$ tar -czvf wp-content.tar.gz --exclude='wp-content/ai1wm-backups' wp-content/

ちなみに上のコマンドは圧縮データに含めるすべてのファイルをログとして出力するので、

圧縮が終わるまでの間とんでもない量のログが出力され続けます。バグじゃないので落ち着いて。

その間wp-content/uploads/から始まるメディアのパス名を見て懐かしい気持ちに浸りましょう。

尚、終わってないのに特定のファイルで処理が止まった場合、クソデカファイルかもしれません。

しばらく待つ価値がないならCtrl+Cで実行を止めて除外設定を追加すると良いでしょう。

問題なく圧縮が終了したらXServerのファイルマネージャーから直接ダウンロードして完了です！

本番環境のバックアップデータで上書きする

ここまで来たら、手元にはデータベースとwp-contentのバックアップがそろっているはずです。

ということで、Local上のテスト環境に本番環境データを上書きして、現状の再現を行います！

まずはwp-contentの上書きなのでまた「Site Foler」を開いて既存のwp-contentを消しましょう。

手元に落としてきたwp-content.tar.gzを解凍したものを同じ位置に置いたら完了！

.tar.gzを解凍できない人はWindows標準劇遅解凍ツール使ってないでLhaForge入れてください。

データベースの復元にはコマンドを使います。app/public以下にsqlファイルを置いてください。

以下の五つのコマンドを、テスト環境に合うように適切に置き換えて順番に実行してください。

> wp db reset --yes
> wp db import [バックアップファイル名]
> wp search-replace "http://[ドメイン名]" "http://localhost:[Site Port]" --all-tables
> wp search-replace "https://[ドメイン名]" "http://localhost:[Site Port]" --all-tables
> wp rewrite structure "/%postname%/" --hard

データベース内には各所に自身のURLを参照する箇所があり、それを置き換える必要があります。

後半の3つのコマンドはそれを環境に合わせることで起動時に発生する問題を抑制しています。

また、search-replaceコマンドは実行終了後にいくつ文字列を置き換えたかを表示します。

これがどちらも0を記録した場合、データベース周りの設定に異常があります。引き返しましょう。

ここまで適切に通過したならば、「WP Admin」で編集画面に移動すると下の画面になります。

何故データベースの更新が要求されるのかは謎ですが、とりあえず更新して次へして良いです。

親の顔より見た本番環境のダッシュボードが再現できているはずです。おめでとうございます。

「Open Site」でも本番と同じトップページが表示されることを確認しても良いですね。

本番環境を載せると全然動かなくなった

データベース側の問題は起きてないのにロードが長すぎるとか起動がうまくいかない場合は、

PHPサイドのエラーログを見つめるかAIに読んでもらうことで解決策が見つかるかもしれません。

app/public/wp-config.phpの定義に以下の行を追記することでログを閲覧しましょう。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true ); // ← 画面にエラーを表示
@ini_set( 'display_errors', 1 );    // ← PHPレベルでも強制表示

エラーログは、Localのアプリを止めた時(Stop Site)にlogs/php/error.logへと出力されます。

テスト環境でアップグレードしよう

ついに本番。この環境の上で全てをアップグレードしてみて、問題が起きないかどうか試します。

経るべき手順は以下の通り。

1. 更新できるプラグイン・テーマを全て更新する
   過去のWordPressでも動作する更新をしてくれている作者さんもいるので、できるならお得。
2. WordPress本体の更新をする
   本体が提供する適切なアップグレードをやってもらう。
3. 運用サーバーのPHPバージョンを更新する
   ただ最新版にすればいいわけではなく、WordPressの安定動作が報告されてるバージョンや、サーバーが推奨しているバージョンにするのが良い。
4. 最終確認
   無事に閲覧・編集ができれば良し。できなければ？やり直し。俺は最終4回やったぞ。

そして、この手順の合間合間に必ずサイトが動くかを確認しましょう。

実行ログを見るとエラーを出してないけど実は裏で死んでましたｗってことがよくあるんです。

逐一の確認は、「どの段階で失敗したのか」を明確にするためには必須のフェーズなんです。

実行する手続き

基本的には、各サイトが提供しているGUI機能によるアップグレードを試みて問題ありません。

ただし、問題が発生したときの原因を適切に提供してくれるかどうかはわかりません。

うまくいっていなさそうならコマンドによる実行とログの観察も視野に入れましょう。

プラグイン・テーマの更新

WordPressダッシュボード経由で行う場合は「更新」タブ内の最下部から実行してください。

コマンドなら「Site Shell」を用いてapp/public以下で次の二行を実行してください。

$ wp plugin update --all
$ wp theme update --all

WordPress本体の更新をする

WordPressダッシュボード経由で行う場合は「更新」タブ内の上部から実行してください。

コマンドなら「Site Shell」を用いてapp/public以下で次の二行を実行してください。

$ wp core update --locale=ja
$ wp core update-db

PHPバージョンを更新する

LocalのOverviewタブ内にある「PHP Version」を切り替えて、サイトを再起動してください。

更新の際は、最新版にすることが必ずしも最適であるわけではないことに気を付けましょう。

XServerは2026年1月現在、最新版のPHP 8.4.XではなくPHP 8.3.Xを推奨としています。

それに合わせてLocalでもPHP 8.4ではなく、最も近いバージョンを選択するのが良いでしょう。

LocalでPHP versionを選ぶと、右側に「Apply」と出るのでクリックしてしばらく待機します。

テーマの更新に失敗してしまう

現在ここのブログにおいてはわいひら氏のcocoon-masterテーマを利用しているのですが、

コマンドラインによって更新を行った場合のみエラーで更新が完遂しない問題が発生しました。

C:\Users\    \Local Sites\kleinsblog\app\public>wp theme upgrade cocoon-master
メンテナンスモードを有効化中...
https://wp-cocoon.com/download/791/ から更新をダウンロード中...
Using cached file 'C:\Users\    /.wp-cli/cache/theme/cocoon-master-2.6.1.6'...
更新を展開しています…
最新のバージョンをインストールしています…
旧バージョンのテーマを削除しています…
Warning: 旧バージョンのテーマを削除できませんでした。
テーマの更新に失敗しました。
メンテナンスモードを無効にします…
Error: No themes updated (1 failed).
+---------------+-------------+-------------+--------+
| name          | old_version | new_version | status |
+---------------+-------------+-------------+--------+
| cocoon-master | 2.3.8       | 2.6.1.6     | Error  |
+---------------+-------------+-------------+--------+

また、これ以降サイトを開くとほとんど真っ白になってしまう問題に悩まされました。

これログを確認すると分かることなのですが、「旧版削除の途中にエラーで落ちている」ので、

削除が途中まで進んで新しい版を導入・展開できていないのでテーマファイルが空になってます。

WordPressのGUI上で更新したらうまくいったんですが、CLIも万能ではないということです。

PHPの更新をしたらロードが劇長に

PHPの更新直後、管理ページやサイトの閲覧に非常に長いロードを要するバグが発生しました。

原因はよくわかってないんですが、以下の二点を実行したら直りました。

• Site-Shellを開き直して php -v を実行する
• app/public/wp-config.php に追記した 'DISABLE_WP_CRON'の設定行を削除する

なんで？

編集ができるかどうかまで確かめよ

ページが閲覧できるところまでを確認してもまだ問題点が残っている可能性があります。

プラグインの動作を確かめるために、記事の作成・編集から上書き保存まで通るか試しましょう。

本番環境を更新しよう

ということで様々な問題が起きた中ついにアップグレードが通ることが確認できました！

今までの手順をなぞって、本番環境の更新を試みます！改めて手順は以下の通り！

1. 念のためもう一度バックアップを取っておく
   作業開始から3日経過してたので、失敗するとそれまでに来てたコメントが消えちゃいます。
2. プラグインとテーマの更新
   失敗してないならWordPress管理画面からやっても大丈夫だと思う。
   自分はcocoonテーマだけ失敗したので、それ以外を管理画面からアップグレードしました。
3. WordPress Coreの更新
   sshで接続してコマンドを叩きます。自分はその後テーマを手動で上書きしました。
4. PHPバージョンの切り替え
   サーバー管理画面からPHPバージョンを推奨のものへ変更します。
5. 最終確認
   いろんなページを確かめて問題が起きてないか再確認！
   そのためのテスト環境での検証なので問題あったらダメなんですけど。

改めて実行する手続き

基本的にはひとつ前の章の「実行する手続き」と変わりません。

バックアップの取得

XServerで「サーバーパネル/サーバー/手動バックアップ作成」にて改めてバックアップする！

ホームディレクトリ/[domain名]以下にあるpublic_htmlを全部バックアップするのがベストです。

最初のtar -czvfコマンドでやってもいいのですが、本番環境なので念には念を入れましょう！

All-in-Oneプラグインのバックアップデータも入っちゃうのも最後なのでお愛嬌と吞んでください。

次にXServerで「サーバーパネル/データベース/MySQLバックアップ取得・復元」に移動して、

データベースのバックアップも再び作成しておきましょう。

プラグイン・テーマ更新

WordPressダッシュボード経由で行うか、以下のコマンドを実行してください。

$ wp plugin update --all
$ wp theme update --all

WordPressの更新

WordPressダッシュボード経由で行うか、以下のコマンドを実行してください。

$ wp core update --locale=ja
$ wp core update-db

PHPバージョンの切り替え

XServerで「サーバーパネル/PHP/PHP Ver. 切り替え」からサーバーの編集をにて切り替えです。

テスト環境で行った変更に合わせた適切なバージョンに切り替えて作業終了です！

WordPressの更新でエラーが出た　その1

私はWordPressの更新をWordPressダッシュボード経由で行おうとしたのですが、問題発生！

更新ボタンを押して10分ほど待ってもWordPressの更新が終わる気配がありません。

こういう時は、サーバーのファイルマネージャーからpublic_htmlを閲覧します。

そこに.maintenanceフォルダがなければ、すでに更新作業が行われていないことを示しています！

原因調査のためコマンドによるWordPressの更新を試したところ、こんなエラーが。

[xxx@svXXXX public_html]$ wp core update --locale=ja

Your server is running PHP version 5.4.16 but WordPress 5.9.12 requires at least 5.6.20.

サーバーのPHPバージョンが5.4.16だと！？　運用バージョンは7.4のはずでは…

調べてみたところ、実はXServer環境にはほぼすべてのPHPがインストールされているとのこと！

運用バージョンに従って毎回バージョン指定でPHPを実行しているらしく、なるほど…。

ということでサーバー上で実行したホントのコマンドはこちら。

もちろん、ホームディレクトリ/[domain名]/public_htmlで実行してください。

$ /usr/bin/php7.4 $(which wp) core update --locale=ja

最初が、phpのバージョン指定。次が、wpコマンドをパスで直接実行。まあ、そのままです。

WordPressの更新でエラーが出た　その2

[xxx@svXXXX public_html]$ /usr/bin/php7.4 $(which wp) core update --locale=ja
Updating to version 6.9 (ja)...
PHP Warning:  Declaration of WP_CLI\Core\CoreUpgrader::download_package($package, $check_signatures = true) should be compatible with WP_Upgrader::download_package($package, $check_signatures = false, $hook_extra = Array) in phar:///usr/bin/wp/vendor/wp-cli/core-command/src/WP_CLI/Core/CoreUpgrader.php on line 30
Warning: Declaration of WP_CLI\Core\CoreUpgrader::download_package($package, $check_signatures = true) should be compatible with WP_Upgrader::download_package($package, $check_signatures = false, $hook_extra = Array) in phar:///usr/bin/wp/vendor/wp-cli/core-command/src/WP_CLI/Core/CoreUpgrader.php on line 30
https://downloads.wordpress.org/release/ja/wordpress-6.9.zip から更新をダウンロード中...
更新を展開しています…
強制終了

「強制終了」！？　ログも何もなく！？　そんなことされたら原因がわかりません！

調べてみると、XServer側のメモリ上限を突破してしまったことで強制終了されたらしいです。

XServerは過度なリソース消費を避けるため、一つのプロセスが過度にメモリを占有した場合に

このように「強制終了」とだけ表示してプロセスを殺す機能があるらしいです。

wpコマンドがPHPプロセス内でzipデータを解凍しようとしてメモリ使用量が爆破したとのこと。

ということで、手動で実行していきました。これもpublic_htmlで実行。

# 更新作業中に生成されるメンテナンス用フォルダを削除する
$ rm -f .maintenance

# 最新版を直でダウンロード
$ wget https://ja.wordpress.org/latest-ja.zip

# 解凍するとwordpressというフォルダに全部が入ってる
$ unzip -q latest-ja.zip

# "wordpress/*" の中身をここにコピー
$ cp -rf wordpress/* .

# 最新版zipと展開したフォルダを削除
$ rm -rf wordpress latest-ja.zip

# データベースの構造を更新
$ /usr/bin/php7.4 $(which wp) core update-db

# 最新版だから大丈夫だと思うけど、念のため翻訳ファイルの更新
$ /usr/bin/php7.4 $(which wp) language core update

各自心配なら途中でlsコマンドとかで状態確認はしていいです。

更新、完遂

ということで、すべての更新作業を無事完了して現在問題なく稼働している当ブログがあります！

環境構築もめんどくさかったし原因調査もめんどくさかったし、本当にだるかった！！！

この記事に書いてない謎原因でのやり直しをここに書いたことの3倍くらいやりました。

それでいてあまり本質的じゃない根本的な勘違いだったからちょっとの但し書きにしかならない。

というかもうしばらくブログから離れていたせいで書き方全部忘れててそれも大変でした。

でも、覚えてるうちに書かなきゃ～ってやってるうちにだんだん自分の中のハードルが下がって、

過去の勢いを取り返して2日で書き上げられたんで、やる気って本当やり始めなきゃ湧かないなと…

今までまた書き始めるのがだるくて手を付けてなかっただけで記事のアイデアは沢山ある！実は！

でも今は！！もうしばらく記事書くのはめんどくさい！！今後のすのえさんにご期待！！！

そもそもこの作業はDoragones君が新しいジャンルの記事書きたいって言ったのが発端なので、

次は彼がすごいのを近いうちに投稿してくれると思います。楽しみ～～～