ねこの手ラボ 
2016年頃（9年前）に制作した古いWordPressのサイト（オリジナルテーマ）をリニューアルすることになりました。
クライアントからのご依頼です。
今回、リニューアルと並行して、下記の修正も一緒に行うことになりました。（クライアント了承済）
- PHP7（7.4） → PHP8（8.3）へ
- テーマ内の古いコードの修正
- 動かなくなったプラグインの棚卸し・入れ替え
- エディタ移行（クラシックエディタ → ブロックエディタ）
クライアントからは、サイトをあと5年程度使う予定との話をいただいており、最低5年間は維持する必要があります。
WordPressはバージョンが上がるたびにPHPの最低動作要件も引き上げられており、PHP 7.2と7.3はWordPress 7.0（2026年5月リリース予定）でサポートが終了します。
すでに管理画面にPHP7.4のエラーが表示されている状態で、どうせリニューアルするなら、このタイミングでまとめて片付けてしまった方がいい。という判断から、内部のリニューアルも行うことにしました。
しかし、必要以上に手を入れても費用対効果が合いません。
「動いているものは極力触らない、必要なところだけ直す」
という方針で進めることにしました。
1. まず現状を把握する
9年前に自分が作ったテーマとはいえ、久しぶりに中身を確認すると構成をほぼ忘れています。まずは現状把握から始めました。
確認したポイントはこのあたりです。
- 現在のPHPのバージョン → PHP7.4
- WordPressのバージョン → 最新
- テーマの構成とファイル数 → 60ファイル
- 使用中のプラグインとその役割
- それぞれの記事数（投稿、固定ページ、カスタム投稿） → 約540記事
- functions.phpに何が書かれているか → ざっくり把握
- カスタム投稿タイプの定義方法 → functions.phpに直書き
当時はページの種類ごとにテンプレートを分けて作っていたので、ファイルが細かく分かれている状態です。（かなり多いです）
プラグインも長年の運用でそれなりの数が入っており、PHP8環境に移行したとき何が動いて何が動かないか、この時点ではまだわかりません。
2. LOCALにPHP8環境を作って現サイト環境を放り込み、エラーを洗い出す
現状把握ができたところで、まずローカル環境（LOCAL）に現在のサイトをそのまま放り込みます。
今回は、移行後PHP8系にするので、
- まずLOCALでPHP8環境のWPを作成し
- そこに、All in one WP MigrationでPHP7の本番データを移行
してみました。
もちろん、なんの準備もなくPHP8の環境に放り込むと、基本的にエラーが出ます。
これをひとつづつ修正していきます。
3. 画面TOPに出るエラーを修正し、まずは動く状態にする
まず、画面TOPに出るエラーから修正します。
はじめに致命的なエラーだけ対処して動く状態にし、詳細はあとからじっくり修正していく流れで進めます。
今回はプラグインと、functions.phpのエラーが出たのでそれぞれ対処していきます。
functions.phpのエラーを修正
functions.phpのエラーを修正します。今回は2つ出ていました。
どちらもWarning止まりで動作は続きますが、PHP8系から検出が厳しくなってるので放置しないほうがいいエラーのため、修正します。
修正についてはAIに手伝ってもらいました。（エラーや修正内容は状況により異なるので詳細は割愛します）
エラーを起こしているプラグインの停止（まだ削除はしない）
functions.phpのエラー修正が完了したら、続いてプラグインのエラーを対応します。
エラーをAIに投げ込み、該当プラグインを特定して、一旦停止します。
プラグインについてはテーマ側の修正が終わってから対応するので、この段階では一旦停止にして保留しています。
4. PHP8対応：テーマのコードを修正する
さて、エラーを一旦落ち着かせたあとは、テーマの修正を行います。
PHP7からPHP8に対応できるように、AIと相談しながらコードの修正を行いました。
functions.phpの整理
まずfunctions.phpを一通りAIに見てもらい、指摘されたものを修正していきます。
今回行ったのは、
- 古いコードの書き換え
- エラーを起こすコードを修正
- 重複があったものを削除または整理
- プラグインで対応できるものを削除し、プラグイン利用へ（今回はぱんくずが該当※別記）
です。
functions.php関連の修正は、「古いコードの書き換え」「エラーを起こすコードを修正」「重複があったものを削除または整理」さえできていれば十分です。
functions.php対応メモ
今回のfunctions.phpの修正の備忘録です。
functions.phpのパンくずをBreadcrumb NavXTに切り出す
パンくずリストはfunctions.phpに自前で実装していましたが、このタイミングでBreadcrumb NavXTプラグインへ切り替えました。
自前実装のパンくずは動いてはいましたが、PHP8対応の修正が必要な箇所もあり、「どうせ直すなら専用プラグインに任せた方がいい」という判断です。
Breadcrumb NavXTは設定の自由度が高く、カスタマイズの幅も広いので、オリジナルテーマとの組み合わせでも使いやすいプラグインです。
自前実装をメンテし続けるより、長期的に見ても安心感があります。
カスタム投稿タイプはCPT UIへの移行を断念、functions.phpに残す
カスタム投稿タイプもこのタイミングでCPT UIプラグインに移行しようと試みました。
プラグインで管理できれば、後からの変更もやりやすくなるためです。
ところが、functions.phpに書かれた設定が思ったより複雑で、CPT UIに移したとたんに動作がおかしくなってしまいました。
自分で9年前に書いたコードなのに、読み解くのに思いのほか時間がかかるという状況です。
原因を追いかけてみたものの、解決までの道筋が見えにくかったため、今回はCPT UIへの移行を断念。
functions.phpに残したまま、PHP8で動作する状態に修正するだけにとどめました。
「完璧な構成にしたい」という気持ちはありましたが、動いているものを無理に触ってトラブルを増やすより、動く状態を維持することを優先するというのが今回の基本方針です。
テーマファイルの修正
続いて、テーマファイルの古いコードを全て修正します。
AIに投げてチェックしてもらい、該当部分を書き換えました。
AIにファイル丸投げしてまるっと書き換えしてもらってもいいのですが、AIに丸投げすると、たまに頼んでないコードに書き換えられることがあります。（動きはするが自分が書いたものと違うコードになることがある）
そうなると記憶が薄くなっているとはいえ、自分でつくった構造がわからなくなることがあるため、今回は指摘された部分だけ手動で直しました。
この作業を60ファイル全て行いました。
断念したこと
テーマファイルの統合は途中で断念
ファイルが60個あるのを見て、「このタイミングで整理統合しよう」と手をつけてみました。
が、思ったより依存関係が複雑で、統合するたびにどこかが動かなくなったりして頭を抱えることに。
余計な労力と時間がかかるだけと判断して、統合は諦めました。
スクリプトのエンキューも断念
CSSやJSファイルの読み込みをテーマファイル側に直書きしており、WordPressの作法に従ってfunctions.phpにスクリプトのエンキューをしようと考えました。
しかしエンキューをすると何故か表示がおかしくなったりして、特定と修正に時間がかかりそうだったので、そのままにしておくことにしました。
最終的に、「動いているコードは極力触らない」 という最初の方針に立ち返って、修正はあくまでPHP8対応に必要な箇所だけに絞って直しました。
リファクタリングしたい気持ちはありますが、今回の目的はそこではないので。
5. 一旦、表示と動作の確認
さて、修正が完了したら、一旦表示と動作チェックです。
各主要なページを表示して、動作を全てチェックします。
テーマに起因するエラーが出ている場合は、ここで修正します。
6. プラグインへの対応
テーマの対応が終わったら、つぎはプラグインの対応です。
エラーで一旦停止したプラグインを見直していきます。
PHP8で動かなくなったプラグインへの対応
今回エラーが出たのが下記プラグインで、それぞれに対応しました。
このプラグインの対応については利用しているものでかなり変わるため、ご参考までに。
Biz-Calendar → 自作プラグインに
イベントカレンダー系のプラグインとして使用していたBiz-Calendarが、PHP8では動作しませんでした。
代替プラグインをいくつか試したものの、既存のデータ構造や表示デザインとの兼ね合いがうまくいかず、結局このサイト専用のカレンダープラグインを自作することにしました。
営業日カレンダープラグイン作ったあとで、Biz-Calendarのコードを修正すれば動くと知ってガックリ。配布してるのでよかったら使ってね。
PTエンジン → 停止・削除。別プラグインの案内
PTエンジンはそもそもサービス自体がすでに終了していたため、停止＆削除。
別プラグインの利用をおすすめしました。
長期運用しているサイトほど、こういった「いつの間にかサポートが終わっていたプラグイン」が混入していることがあります。
PHP移行のタイミングは、こういった古いプラグインを一掃するいい機会でもあります。
サポートが終わってるプラグインは放置するとセキュリティリスクがあがるため、停止・削除、代替も視野にいれてみてください。
カスタム投稿の表示順変更プラグイン → 別プラグインへ移行
カスタム投稿タイプの表示順を変更するプラグインも動作しなくなっていたため、同等の機能を持つ別のプラグインに切り替えました。
こちらは比較的すんなり移行できました。
7. ブロックエディタ対応（リニューアルの場合どこまでやるかを決める）
さて、テーマとプラグインの対応が完了したので、次はエディタの変更を行っていきます。
今回は、クラシックエディタから、ブロックエディタへ移行します。
エディタの移行は、まず「どこまでやるか」をクライアントと相談するところから始めました。
今回のリニューアルは投稿記事が540件近くある状態で、すべてをブロックエディタで整えようとすると表示調整作業が膨大になります。
▼クラシックエディタからブロックエディタに変更したとき、クラシックエディタで投稿された記事はクリニックブロックに変換されます。
▼クラシックブロックはブロックに変換できますが、変換後、まれに表示が崩れることがあるので調整が必要です。
クラシックブロックをブロック化への調整は、確認・調整の工数も含めると費用が3倍近くになる試算だったので、クライアントと話し合った上で下記のように現実的な方針を決めました。
固定ページ（店舗情報部分）だけ表示を調整する
サイトの運営に必要な固定ページについては、ブロック化したあと、修正および表示調整を行いました。
既存の投稿記事はクラシックエディタのまま残す
投稿系とカスタム投稿の540件の記事は、クラシックエディタのままにしています。
表示は問題ないですし、無理に触って崩れるリスクを取る必要もありません。
ただし、既存記事を編集したくなったときのために、「Advanced Editor Tools」プラグインを入れて、クラシックブロックで編集できる状態を確保しています。
新規投稿はブロックエディタのみに設定
今後作成する新規記事はブロックエディタで統一したかったので、「Advanced Editor Tools」の設定を変更し、ブロックエディタのみ使用できるように設定しました。
既存記事との共存がこれで整理されます。
Snow Monkey Editorを導入
文字装飾やマーカーなど、記事編集で使いたい細かい装飾機能のために「Snow Monkey Editor」のプラグインを導入しました。
ブロックエディタの標準機能だけでは少し物足りない部分を補ってくれます。
theme.jsonは導入断念
ブロックエディタ導入と同時に「theme.json」を導入しようとしましたが、記事編集画面の見た目が大きく変わり、これまで使っていた画面と別物になってしまうため、今回は導入しないことにしました。
使いやすさ（クライアントのこれまでの慣れ）を優先した判断です。
8. 本番移行の流れ
ローカルでの動作確認が取れたら、いきなり本番に反映するのではなく、ひとつ段階を踏みました。
① ローカル（LOCAL）で動作と表示の確認
ここまでの作業はすべてLOCALで行っています。本番環境へ移す前に、
- PHP8環境でテーマのエラーが出ないこと
- プラグインが正常に動くこと
- 表示崩れがないこと
を一通り確認します。
② 自分のテストサーバーで再現テスト
LOCALでの確認が取れたあと、自分が管理しているテストサーバーにクライアントのサイトを再現しました。
ここでのポイントは、まずPHP7環境でサイトを再現してから、PHP8に切り替えるという手順を本番と同じ流れで実施したことです。
LOCALとは違い、実際のサーバー環境でPHPバージョンを切り替えることで、ローカルでは気づかなかった挙動の違いが出てくることがあります。
本番サーバーとはサーバー会社が異なるため、完全に同じ環境とは言えません。
それでも「実際のサーバー上でPHP8に切り替えたときの動きを一度見ておく」だけで、本番移行時の事故がかなり減ります。
③ 本番サーバーへ反映
テストサーバーでPHP7からPHP8への移行を行い、問題がなければ、本番サーバーへの反映です。
作業前に本番サイトのバックアップを取ったあと、データをアップロードのうえ、PHPのバージョンアップを行います。
本来PHPバージョンの切り替えはサイトを一時的にメンテナンスモードにしてから行う方が安全ですが、今回は深夜帯（2～3時）の作業だったため、メンテナンスモードは仕様しませんでした。
切り替え後はフロント・管理画面・各種プラグインの動作を再度確認して完了です。
まとめ
今回は9年前のWordPressオリジナルテーマをPHP8対応・ブロックエディタ移行した作業ログをまとめました。
今回の作業で一番意識したのは、「今後もずっと使い続けられる状態にする」ことです。
- エディタをブロックエディタに移行して、記事の更新がしやすい状態にする
- PHPを最新系に上げて、今後のWordPressの更新に耐えられる状態にする
- 動かなくなったプラグインを整理して、壊れにくい構成にする
技術的な負債を一気に解消するのではなく、「あと5年使える状態」を現実的な工数で実現することがゴールでした。
リファクタリングしたい気持ちや、構成を整理したい場面は何度もありましたが、動いているものを無理に触ってトラブルを増やすより、更新しやすく・壊れにくい状態を維持することを優先しました。
PHP移行・エディタ移行を検討している方および、長期運用サイトのリニューアルを検討している方の参考になれば幸いです。