Contact Form 7を更新した後、お問い合わせや予約フォームが送信できなくなることがあります。
フォームはいつもどおり表示され、入力欄もボタンも見えている。それでも、送信すると処理が止まってしまう場合があります。
原因として確認したいのが、以前に追加したカスタマイズコードです。
メールアドレスの再入力チェックや確認画面、独自の入力項目などは、Contact Form 7本体とは別のコードで実装されていることがあります。本体を更新しても、そのコードまで自動的に新しい書き方へ置き換わるわけではありません。
今回は、古いクラスを使ったメールアドレスの一致チェックで予約が送れなくなった事例をもとに、Contact Form 7 6.2への更新で見直したいポイントをまとめます。
実際に起きた、メールアドレス再入力チェックの不具合
今回のケースでは、約5年前に作成した「Contact Form 7 メールアドレスの再入力欄」というスニペットを使用していました。
メールアドレスを2回入力してもらい、一致しなければ「確認用メールアドレスが一致していません」と表示するための処理です。
このコードに、古いクラスである WPCF7_Shortcode が残っていました。
Contact Form 7の更新後、メール欄の入力チェックが実行されると、次のエラーで処理が停止していました。
Class "WPCF7_Shortcode" not found
これは、「呼び出そうとしたクラスが見つからない」という意味のPHPの致命的エラーです。通常の入力エラーとは異なり、処理そのものが途中で止まってしまいます。
今回のサイトでは、そのチェック処理が共通で使われていたため、メール欄のあるフォームすべてに影響し、予約も送れなくなっていました。
今回は、旧クラスを使っていた箇所を修正
該当スニペットの5行目で使用していた WPCF7_Shortcode を、現行のContact Form 7で使われる WPCF7_FormTag に置き換えました。
メールアドレスが一致しているかを確認する機能は残し、古いクラスへの依存を修正した形です。
ただし、「5行目を直せばよい」というのは今回のコードに限った話です。コードの構成や追加した場所によって、修正箇所は異なります。
メールアドレスの再入力機能そのものが廃止されたわけではありません。古い実装が、新しいContact Form 7で動かなくなった事例です。
なぜ、今まで動いていたコードが使えなくなったのか
WPCF7_Shortcode は、以前から非推奨だった
Contact Form 7の公式情報では、WPCF7_Shortcode は2016年12月のバージョン4.6で非推奨になり、WPCF7_FormTag への置き換えが案内されています。
非推奨とは、すぐに使えなくなるとは限らないものの、今後も使い続けることは勧められず、新しい方法への移行が必要な状態です。
互換性のために古い書き方が残されている間は、警告が出ても動作し続けることがあります。そのため、長年問題なく使えているように見える場合があります。
参考：Contact Form 7 4.6・旧クラスの非推奨化
Contact Form 7 6.2で古い互換用ファイルが削除
Contact Form 7 6.2の公式変更内容には、非推奨だった includes/shortcodes.php の削除が含まれています。
古い仕組みへの依存が残っていると、互換用の処理がなくなった段階で、今回のような不具合が表面化します。
「最近書いたコードだから大丈夫」とも限りません。数年前に追加したコードでも、さらに古い解説記事やサンプルを参考にしていれば、非推奨の書き方が含まれる可能性があります。
参考：Contact Form 7 6.2 RC・主な変更点
メールアドレスの一致チェックは、現在も実装できる
Contact Form 7の公式ドキュメントでは、独自の入力チェックの例として、メールアドレスの再入力チェックが紹介されています。
現在の例では、入力チェックに渡される $tag は、すでに WPCF7_FormTag のオブジェクトとして扱われています。
そのため、古いコードで行っていたオブジェクトの作り直し自体が不要な場合もあります。
今回のようにクラス名の置き換えで対応できるケースもありますが、実際のコードを見ずに一律で書き換えるのは避けましょう。対象の入力欄、受け取る値、エラーの返し方まで確認することが大切です。
ほかにも確認したい、古いクラスや関数
メールアドレスの再入力チェック以外でも、古いカスタマイズに次の名前が残っていないか確認する価値があります。
| 古いクラス・関数 | 公式に案内されている移行先 |
|---|---|
WPCF7_Shortcode | WPCF7_FormTag |
WPCF7_ShortcodeManager | WPCF7_FormTagsManager |
wpcf7_add_shortcode() | wpcf7_add_form_tag() |
wpcf7_scan_shortcode() | wpcf7_scan_form_tags() |
これらは、Contact Form 7 4.6の時点で移行が案内されていたものです。
表は古いコードを探すための手がかりです。引数や処理の構成も確認する必要があるため、単純な一括置換で必ず直るという意味ではありません。
参考：Contact Form 7 4.6・非推奨の機能と代替方法
ページに貼ったフォームのショートコードとは別の話
ここでいう旧クラスや旧関数は、PHPのカスタマイズで使われるものです。
固定ページなどに貼る エラー: コンタクトフォームが見つかりません。
名前が似ているため混同しやすいのですが、まず確認するのは、追加したPHPコードや拡張プラグインです。
古いコードは、どこに入っている？
カスタマイズは、Contact Form 7のフォーム編集画面だけにあるとは限りません。
| 確認する場所 | 入っている可能性のある処理 |
|---|---|
使用中のテーマ・子テーマの functions.php | メール一致チェック、送信先変更、独自の入力チェック |
| スニペット管理プラグイン | 過去に追加したContact Form 7用のコード |
| 独自プラグイン | 予約処理、外部サービス連携、独自項目 |
| Contact Form 7の拡張プラグイン | 確認画面、条件分岐、入力補助など |
| MUプラグイン | サイト全体で常時読み込まれる共通処理 |
GRM Base Kitの「ファンクション」でコードを管理している場合は、そこに登録したスニペットも確認対象です。
プラグイン一覧に更新が出ていなくても、自分で登録したコードの互換性が確認されているとは限りません。
Contact Form 7 6.2で、あわせて確認したい変更
WordPressとPHPの動作条件
Contact Form 7 6.2は、WordPress 7.1以上、PHP 8.3以上が必要です。
古いカスタマイズとは別に、動作環境の条件も確認してください。PHPを更新する場合は、Contact Form 7だけでなく、使用中のテーマやほかのプラグインの対応状況も確認します。
詳しくは、Contact Form 7 6.2でPHP 8.3以上が必須になった理由でも紹介しています。
参考：Contact Form 7 6.2・公式リリース情報
独自の入力チェックや内部処理への依存
6.2では、入力チェックの仕組みであるSchema-Woven Validation（SWV）の更新や、オブジェクトのプロパティへの型宣言・読み取り専用指定なども案内されています。
内部の仕組みを直接操作する独自コードや拡張機能は、対応状況を確認する必要があります。
ただし、すべての入力チェックや拡張プラグインが使えなくなるわけではありません。利用している機能と実装によって影響は異なります。
「フォームが表示される」だけでは確認にならない
今回のような入力チェックの不具合は、ページを開くだけでは見つからないことがあります。
フォームの表示までは正常でも、送信時に追加コードが動き、その段階で停止するためです。
また、複数のフォームが同じ処理を使っていれば、お問い合わせフォームだけでなく、予約・資料請求・申し込みフォームにも影響する可能性があります。
更新後は、フォームの見た目だけでなく、実際に送信して受信まで確認することが必要です。
更新後に実施したい送信テスト
次の項目を、利用しているフォームごとに確認しましょう。これらは「今回すべて廃止された機能」ではなく、更新後に動作確認したい項目です。
| 確認項目 | テストする内容 |
|---|---|
| 正常な送信 | 必須項目を入力し、送信を完了できるか |
| メールアドレスの一致 | 同じアドレスを入力した場合に送信できるか |
| メールアドレスの不一致 | 異なるアドレスを入力した場合に、適切なエラーが出るか |
| 必須項目 | 未入力のまま送信した際に、必要な案内が表示されるか |
| 確認画面 | 入力内容を確認し、戻って修正してから送信できるか |
| 条件分岐 | 選択によって表示・非表示になる項目が正しく動くか |
| 添付ファイル | 許可した形式・サイズで送信できるか |
| 迷惑送信対策 | TurnstileやAkismetなどと組み合わせて正常に送信できるか |
| 自動返信 | 送信者に必要な受付メールが届くか |
| 管理者向け通知 | 担当者のメールボックスまで届くか |
| 送信完了後の処理 | 成功時だけサンクスページへ移動するか |
| 外部連携・保存 | 予約管理やデータ保存などに正しく反映されるか |
予約や外部サービスと連動している場合は、テスト用の内容であることが分かるようにし、担当者と調整して実施します。
パソコンとスマートフォンの両方で、入力から完了まで確認しておくと安心です。
「送信処理が止まる」と「メールが届かない」を分けて調べる
フォームの不具合は、すべて同じ原因ではありません。
送信時に処理が止まる場合
送信ボタンを押した後に処理が終わらない、エラーになる、完了画面へ進まない場合は、PHPのエラーログや通信の応答を確認します。
今回のような Class ... not found のほか、廃止された関数、引数の不一致、拡張プラグインとの互換性などが調査対象になります。
送信完了と表示されるのに届かない場合
送信処理が完了していても、受信先のメールボックスに届くとは限りません。
送信元・送信先の設定、メール送信サービス、迷惑メール判定などを確認します。
「メールが届かない」という結果だけで、すぐに古いクラスの問題と決めつけず、どの段階で止まっているかを切り分けましょう。
不具合が起きたときの対応手順
1. 発生条件と更新内容を記録する
いつから送れないのか、どのフォームで起きるのか、直前に何を更新したのかを確認します。
Contact Form 7だけでなく、WordPress、PHP、テーマ、拡張プラグインの変更も記録しておくと調査しやすくなります。
2. エラーログで停止した場所を確認する
今回のような致命的エラーでは、ログに原因のクラス名や、呼び出したファイル・行番号が記録されることがあります。
公開ページに詳細なエラーを表示するのではなく、サーバー側のログを保守担当者が確認する形で調べましょう。
3. 原因のコードを特定して修正する
古いスニペットや拡張機能が原因なら、現行の仕様に合わせて修正します。
Contact Form 7本体のファイルを直接書き換えると、次の更新で修正が失われるため、追加コード側で対応することが基本です。
4. 入力チェックが残っていることも確認する
エラーを止めるためにスニペットを無効化しただけでは、メールアドレスの一致チェックまでなくなる可能性があります。
修正後は「送れた」だけで終わらず、不一致なら送信を止めるなど、もともと必要だった機能も確認します。
更新を止めるのではなく、カスタマイズも保守する
不具合が起きると、Contact Form 7を古いバージョンのまま使いたくなるかもしれません。
しかし、更新を止め続けると、セキュリティ修正や今後の環境変更に対応できなくなります。
復旧のために一時的な切り戻しが必要な場合もありますが、バックアップや影響範囲を確認したうえで判断し、古いコードを修正する計画とセットで進めましょう。
大切なのは、Contact Form 7本体だけでなく、追加したコードや拡張機能も更新・保守の対象にすることです。
複数サイトでは、同じコードが残っていないか確認を
過去に作成したスニペットを、複数のサイトで使い回している場合があります。
ひとつのサイトで WPCF7_Shortcode のような古い記述が見つかったら、同じ時期に制作したサイトや、同じフォーム構成のサイトも確認しましょう。
GRM Fleetのような仕組みで各サイトの更新状況をまとめて把握しつつ、独自コードの点検と送信テストも管理すると、確認漏れを減らしやすくなります。
なお、更新状況の確認やリモート更新だけで、フォームの動作や独自コードの互換性まで保証されるわけではありません。
詳しくは、GRM Fleet Hubの紹介ページをご覧ください。
更新後は、予約やお問い合わせが届くところまで確認しよう
今回の不具合は、メールアドレスの再入力チェックに残っていた古いクラスが原因でした。
長年使っていたコードでも、互換用の仕組みがなくなると動かなくなることがあります。そして、フォームの見た目が正常なまま、送信だけが止まる場合もあります。
Contact Form 7を更新するときは、動作環境、追加したスニペット、拡張プラグインを確認し、入力チェックから送信・受信まで一通りテストしましょう。
「更新後から送れなくなった」「昔追加したコードが残っているか分からない」といった場合は、お問い合わせフォームからご相談ください。