「WordPressの更新ボタンを押すのが怖い」
こう思っている方は、実はかなり多いのではないかと思います。
今回ご相談いただいたのは、10年以上前に制作会社で作られた個人サイトでした。一度バージョンを更新したときにエラーが出てログインできなくなった経験があり、それ以来ずっと更新を止めていたという状態です。
結果としてPHPは7.2、WordPressは6.0.14、プラグインは長期間未更新のまま動いていました。
この記事では、本番サイトを一度も壊さずにPHP 7.2から8.3へ上げるまでに何をしたかを、実際の手順どおりに書いていきます。原因だったプラグインの名前も、そのまま出します。
相談の内容：一度壊れて、それ以来10年更新できなかった
いただいたご相談は、要約するとこうでした。
- 10年以上前に制作会社に作ってもらったサイトを、その後は自分で更新している
- 制作会社のサポートが終わったあとも「だましだまし」使ってきた
- 過去にバージョン更新をしたとたんに、サイトがエラーで表示されなくなった
- それ以来、プラグイン・WordPress・PHPのどれも更新していない
- 先日ブログを更新したらSNS連携が効かず、サイト表示エラーも出た
- そろそろ限界だと感じて相談した
一度壊した経験がある方にとって、一番の不安は「また壊れること」です。
なので最初のご返信で、作業方針として先にこうお伝えしています。
いきなり本番環境で更新するのではなく、一度試験環境を作成して最新の状態でも問題なく動作するかを確認したうえで、本番サイトへ反映という形を取らせていただきたいと思っております。
調べてみると、依頼時点でこれだけの状態でした。
- PHP 7.2（サポート終了済み）
- WordPress 6.0.14
- プラグインが長期間未更新。しかも無効化されたままのプラグインが複数ある
- お問い合わせフォーム（Contact Form 7）が表示されない
- SNS連携ボタンが重複している
- コメント欄が表示されない
- SSL未対応（http のまま）
「無効化されたままのプラグインが複数ある」のが重要な手がかりでした。 過去にエラーで復旧作業をしたとき、原因を探すためにプラグインを止めていって、そのまま戻していない状態だと推測できます。
なぜPHPのメジャーアップデートでサイトが壊れるのか
先に仕組みの話をしておきます。ここを理解しておくと、「何が原因か」の見当がつくようになります。
PHP 7系から8系はメジャーアップデートで、言語そのものの仕様が変わっています。代表的なのは次のあたりです。
- 古い関数が削除された（
create_function()やeach()など） - これまで「警告（Warning）」で済んでいた書き方が、致命的なエラー（Error）になった
- 未定義の変数・配列キー・プロパティへのアクセスの扱いが厳しくなった
- 文字列と数値を比較したときの判定ルールが変わった
つまり、PHP 7.2で動いていたコードが、8系では文法として通らなくなることがあるということです。
そしてWordPressの場合、古いコードが残っているのは本体ではなく、ほとんどがプラグインとテーマです。 更新が止まっているサイトほど、ここに古い書き方が溜まっていきます。
さらに厄介なのが、致命的なエラーが出ると画面が真っ白になる点です。WP_DEBUG が無効だとエラー内容が画面に表示されないため、「更新したら真っ白になった、理由は分からない」という状態になります。
これが、過去にこのサイトで起きたことの正体でした。
調査編：本番を触らずに原因を特定する
本番サイトを複製して、ローカル開発環境で検証する
今回の作業で一番大事なのはここです。
本番サイトでPHPを上げて「動くかどうか試す」のは、お客様のサイトを実験台にする行為です。表示されなくなった瞬間に、読者が見られなくなります。
そこで本番サイトを複製し、ローカル開発環境で作業しました。 自分のPCの中なので、何度壊しても本番には一切影響しません。
ちなみに、TEDASKではローカル開発環境にLaravel Herdを使っています。
サーバー上のサブドメインに検証環境を作る方法もありますが、その場合は検索エンジンにインデックスさせない設定（設定 → 表示設定 → 検索エンジンでの表示）を忘れないようにしてください。検証用サイトが検索結果に出ると、本番と重複して表示されることになります。
PHPは一気に上げず、7.4から段階的に上げる
7.2から推奨バージョンの8.3へ一気に上げると、WordPress本体とプラグインのどちらでエラーが出たのか分からなくなります。
そこで、こう進めました。
- まずPHP 7.4に上げる
- エラーが出たら原因を特定して対応する
- 次のバージョンに上げる
- これを繰り返して8.3まで到達する
各段階で、サイトの表示と管理画面の両方を確認します。管理画面だけ、表示側だけ、のどちらかで済ませると片方を見落とします。
このとき、WP_DEBUG を有効にしてエラーログを出す状態で作業します。 真っ白になってから原因を探すのではなく、最初からログを見ながら進めます。
そして、今回7.2からPHP7.4にする際にはエラーは起こりませんでした。
原因だった2つのプラグイン
段階的に上げていった結果、PHPを上げた時点でエラーを起こしていたのは2つのプラグインでした。
- Debug Bar Extender
- My Page Order
どちらもPHP 8以降に対応していないプラグインです。
1. Debug Bar Extender
最後のアップデートが15年前で止まっていました。15年前のコードが、PHP 8の仕様では通りません。
そもそもこのプラグインは、開発者がデバッグ作業をするときに使うものです（併用する Debug Bar も同様）。サイトを運営するうえでは不要なので、必要なときだけ入れる運用をおすすめしています。今回は削除しました。
2. My Page Order
固定ページの表示順を変えるためのプラグインです。こちらもまったくメンテナンスされておらず、開発元の企業も現在は存在しないようでした。
同じことができる現行プラグインとしては Simple Page Ordering があります。今回は、プラグインを停止しても固定ページの表示順に問題が出なかったため、代替を入れずに削除しました。
ここは勝手に決めず、「停止して問題が出たら戻します」とお伝えしてから進めています。 長く運用されているサイトでは、本人も忘れている使い方が残っていることがあるためです。
お問い合わせフォームが表示されなかった原因
これは、過去の復旧作業の影響でした。
以前エラーでログインできなくなったときに、原因を探すためにプラグインを1つずつ停止していった。そのなかに Contact Form 7 が含まれていて、そのまま止まったままになっていたということです。
壊れたときに止めたものを、戻し忘れる。 これは本当によく起きます。復旧を優先するのは正しいのですが、何を止めたかを書き残しておかないと、数年後に「なぜか動いていない機能」として残ります。
今回はプラグインを最新にしたうえで有効化し、送信テストまで行いました。
SNSボタンが重複していた原因
このサイトでは、SNSボタンの表示設定が2系統あって、両方が有効になっていました。
- テーマ本体のオプション設定にあるソーシャルボタン
- テーマ付属の機能拡張プラグイン側にあるソーシャルボタンの自動挿入
どちらも同じ役割なので、ボタンが2つ並ぶ状態になっていました。テーマの更新に追従して新しくなるのは機能拡張プラグイン側だったので、そちらだけを残し、テーマ本体側の表示をオフにしました。
これでボタンの重複が消え、同時にエラーも出なくなりました。
表に出ていないが、セキュリティリスクがあったプラグイン
更新でエラーは起こしていないものの、有効化されたままリスクを抱えていたプラグインが3つありました。いずれも停止して削除しています。
| プラグイン | 状態 | 対応 |
|---|---|---|
| spam-byebye | サポート終了済み。脆弱性による攻撃を受けるリスクあり | 削除し、代替として Throws SPAM Away を導入 |
| Akismet Anti-spam | 商用利用は有料。設定が未完了で機能していなかった | 削除 |
| G Analytics | サポート終了済み。ページを開くとエラーが発生 | 削除。アクセス解析はGA4の公式サイトから見る運用に |
サポートが終わったプラグインが一番危ないのは、脆弱性が見つかっても修正されないことです。 攻撃する側はバージョン情報を見て探してきます。「使っているから残す」ではなく「サポートが続いているか」で判断してください。
Akismetのように「入っているけれど設定が終わっておらず、実は機能していない」プラグインも珍しくありません。入れた記憶があるだけで安心してしまうパターンです。
本番への反映：手順書と切り戻し手順を先に作る
ローカル環境で「この順番なら壊れない」が分かったら、それを手順書にします。
同時に作るのが切り戻し手順です。失敗したときに元に戻す手順のことです。
- バックアップをどこに、いつ取ったか
- 戻すときに何を、どの順番で戻すか
- どこまで戻せば表示が復活するか
この2つを先に作ってから、本番に触ります。
「たぶん大丈夫」で本番を触って、壊れてから慌てて戻し方を考えるのが一番危険です。更新作業の怖さは、作業そのものではなく戻せるかどうかが分からないことにあります。
本番反映の日程は、事前にご相談して決めました。ブログの更新は普段どおり続けていただいて問題ない形で進めています。
フォームのメールが届かない問題（SMTP認証）
PHPの更新とは別に、お問い合わせフォームのメールが迷惑メール扱いされる問題がありました。これは見積の範囲外でしたが、放置すると問い合わせを取りこぼすため、あわせて対応しています。
WordPressは初期状態だと、サーバーのPHPの機能でメールを送ります。この送り方は、送信元が認証されていません。 そして現在、Gmailをはじめとする主要なメールサービスは認証されていない送信者からのメールを拒否または迷惑メール扱いします。
対応は2つです。
1. SMTP認証を設定する
サーバー上にメールアカウントを作り、WordPress側でそのアカウントのパスワード認証を通してメールを送るようにしました。これで「正規の送信者として認証されたメール」になります。
今回は、WP Mail SMTPを利用しました。
2. 問い合わせをWordPress側にも記録する
Flamingo というプラグインを追加しました。Contact Form 7 から送られた問い合わせを、WordPressの管理画面に保存してくれるプラグインです。
メール送信が失敗しても、管理画面を見れば問い合わせ内容が残っています。 これがないと、送信エラーが起きた問い合わせは完全に消えてしまいます。
更新のあとにやったこと
PHPを上げて終わりにはしません。「また10年放置されない状態」にするところまでが作業です。
SSL化（http → https）
このサイトはSSL化が一般的になる前から運営されていたため、httpのままでした。
いまWordPressでサイトを作ればほぼ自動でSSL化されますが、長く運営しているサイトほど未対応のまま残っています。 お問い合わせフォームの送信やログインの通信が暗号化されないため、通信経路でデータが記録されるリスクがあります。
Xserverの場合、SSL証明書そのものは無料です。ただし作業はそれで終わりません。
記事に貼られた画像のURLや、設定に登録されたURLが、データベースの中でhttpのまま残っています。 これを置き換えないと「混在コンテンツ」になり、鍵マークが出なかったり画像が表示されなくなったりします。今回はこのURL置き換え作業を行いました。
この置き換え手順は、別記事にまとめてあります。
👉 WordPressでhttpからhttps（SSL化）に記事がある状態から変更する方法
wwwあり・なしとhttp・httpsの転送設定
www なしのアドレスで運用されていましたが、www ありでもアクセスできる状態でした。同じ内容のサイトが2つのURLで見られる状態は、検索エンジンから見て好ましくありません。
そこで次の2つの転送を設定しました。
www.ありでアクセスされたら、なしへ転送http://でアクセスされたら、https://へ転送
SSL化だけして転送を入れないと、httpのままのURLが生き残ります。 セットで行う作業です。
サーバー側の無料セキュリティ対策（WAF）を有効にする
Xserverには、WordPressへの攻撃を受けにくくする WAF の設定があります。無料で使えるのに有効化されていないことが多いので、オンにしました。
お客様からも「Xサーバーの便利機能も使いこなせずいたようで」という反応をいただきました。契約しているサーバーの機能を見直すだけで効く対策があります。
プラグインの自動更新を有効にする
これまでは更新でエラーが出やすい状態だったため、自動更新が無効にされていました。 今回の対応で更新できる状態になったので、すべて自動更新を有効にしました。
理由は、プラグインの脆弱性が見つかったときの修正が、できるだけ早く適用されるようにするためです。攻撃は公開された脆弱性情報をもとに来るので、更新が遅れるほど危険になります。
もちろん自動更新でエラーが起きる可能性はゼロではありません。 ただ、ハッキングされてサイトが使えなくなるほうが被害が大きいという判断です。
この判断には前提があります。自動更新は「放置の時間を短くする道具」であって、「見なくていい理由」ではありません。 自動更新が走っていたのに別の経路で事故が起きた案件も、以前記事にしています。
👉 【案件事例】「自動更新だから安心」は危険！お問い合わせフォームの不具合から発覚したサーバー全体のセキュリティ事故と解決の全貌
おまけ：謎のエラーメールが毎日届いていた理由
作業後、お客様から「迷惑メールフォルダに、英語のエラーメールが前から大量に届いている」とご連絡がありました。
届いていたのは、こういうメールです。
550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
DKIM = did not pass
SPF = did not pass
原因は BackWPup というバックアップ用プラグインの設定でした。
このプラグインは、バックアップファイルをサーバーに保存するだけでなく、メールに添付して送る設定にすることができます。このサイトでは、その設定が何年も前から有効になっていました。
そして、そのメールがサーバーから認証されない送信者として送られていたため、Gmail側で拒否され、毎回バウンスメールが返ってきていたわけです。
ここが重要なところなのですが、Gmailは現在、認証されていない送信者からのメールを内容に関係なく拒否します。 つまり中身が何であっても通りません。
サイト立ち上げ当初はデータ量も小さく、メールでバックアップを送ることにも無理はありませんでした。ただ現在はバックアップが数百メガバイトになっており、そもそもメールで送るサイズではなくなっています。
対応として、メール添付の設定を削除し、同じスケジュールでサーバー上にのみバックアップを残す形に変えました。
同じ状態の方は、以下を確認してください。
- バックアップ系プラグインの保存先に「メール」が入っていないか
- サイトからGmail宛に出るメールが、SMTP認証を通っているか
「実害がないから放っておいたエラーメール」には、設定の忘れ物が隠れています。
作業後にいただいたご感想
以前バージョン更新したとたんにサイトがエラーで表示されなくなり、以来ずっと更新をしていませんでした。
ずっと放置して見て見ぬふりしていた物置が片付いた感覚です（笑）
丁寧なお仕事痛み入ります。本当にわかりやすくて助かりました。
— 漫画家 Kさま（個人サイト・10年以上運用）
まとめ：WordPress利用者に伝えたいこと
今回の案件から、同じ状況の方にお伝えしたいことは4つです。
1. 一度壊れた経験があるサイトは、自力で再挑戦しないほうがいい
壊れた原因が分からないまま更新を止めている状態は、次に更新しても同じところで壊れます。 原因を特定しないと先に進めません。そして原因の特定は、本番でやるべき作業ではありません。
2. 壊れたときに止めたものは、書き残しておく
今回フォームが表示されなかったのは、過去の復旧作業で止めたプラグインが、そのまま止まっていたためでした。復旧を優先するのは正しい判断です。ただ「何を止めたか」を残しておかないと、数年後に原因不明の不具合として現れます。
3. 検証環境を作るだけで、怖さの大半は消える
「更新が怖い」の正体は、失敗したときに戻せるか分からないことです。本番と同じ環境を1つ作って、そこで壊してから本番に当てれば、本番は一度も壊れません。
4. 止まった時間の長さが、そのまま作業量になる
今回は10年以上分でした。原因だったプラグインの最後の更新は15年前です。更新が1年止まっているサイトと10年止まっているサイトでは、原因の切り分けにかかる時間がまったく違います。早いほうが安く済みます。
PHP 7.2はすでにサポートが終了しています。サーバー会社も順次古いPHPを使えなくしていくので、「動いているから大丈夫」は期限付きです。
更新作業が止まってしまっている方へ
「どこから手を付ければいいか分からない」という状態でも大丈夫です。まず現状を見て、何が起きているかをお伝えするところから承っています。
自分で管理できるようになりたい方へ
すでに自分のサイトを運用している事業者向けに、保守・運用をテーマにした会を開いています。
