JetFormBuilderをコードスニペットで拡張する実例。送信後の処理を少し賢くする

jetformbuilder-custom-code-thumbnail

この記事には広告を含む場合があります。

記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。

フォーム送信後の処理は、最初からコードで作り込む必要はありません。JetFormBuilderには、メール通知、投稿作成、記録保存、リダイレクト、条件付きの実行など、管理画面から組める送信後アクションがあります。まずは標準設定で作り、あと一歩だけ足りない場面にだけ小さなコードを足すのが安全です。

この記事では、Elementorで作った「相談申し込みページ」にJetFormBuilderの相談フォームを置き、希望メニューによって通知先を変える例で解説します。たとえば「サイト改善相談」は制作担当へ、「広告運用相談」は集客担当へ、「保守相談」はサポート担当へ送る、という実務の分岐です。

この記事の結論

標準の条件付きメール通知で足りるなら、それが一番管理しやすいです。複数の条件が増え、担当者の割り当てや文面の整形をまとめたいときだけ、Call HookとCode Snippetsで送信後の小さな分岐処理を足します。

JetFormBuilderの公式ページでフォーム機能の全体像を確認してから進めると、入力項目、送信後アクション、条件分岐、保存処理の役割がつながりやすくなります。

JetFormBuilder公式ページを見てみる

相談フォームの送信後に通知先を分岐する全体像

この記事で分かること

  • JetFormBuilderの送信後アクションをどこまで標準設定で作るか
  • 相談フォームに用意する入力項目と保存用のデータ項目
  • 希望メニューごとに通知先を切り替える設定例
  • Call HookとCode Snippetsで小さなPHPを足す考え方
  • Elementor側でフォームと完了導線をどう見せるか
  • 個人情報、通知、権限まわりで複雑にしすぎない境界

まず何を作るのか

今回作るのは、制作会社や個人制作者のサイトに置く「相談申し込みフォーム」です。ユーザーは、名前、メールアドレス、希望メニュー、相談内容、希望連絡方法を入力します。送信後は、申込者へ控えメールを送り、管理者用の記録を残し、希望メニューに応じて担当者へ通知します。

静的なElementorページだけで作る場合、ページ上の案内文とフォームは作れます。けれども、送信後の運用はメールボックスに寄りがちです。相談種別が増えると、担当者への転送、対応漏れの確認、過去相談の検索が手作業になります。ここでJetFormBuilderを使うと、フォームの入力画面だけでなく、送信後の処理までWordPress側で組み立てられます。

ただし、最初からCRMのような大きな仕組みにしない方がいいです。この記事では、通知先の切り替えと記録保存に範囲を絞ります。顧客管理、契約管理、請求、会員権限まで一気に作ると、フォームの話ではなく業務システムの設計になります。

どのデータを持たせるのか

フォームに置く入力項目と、WordPress内に保存する記録項目は似ていますが、完全に同じではありません。申込者が入力する項目は少なく、管理者があとから見る項目は少し増やします。JetEngineを併用するなら、相談記録用のデータの箱(CPT)を作り、JetFormBuilderの送信後アクションでそこへ保存できます。

設定項目 値の例 使い道
データの箱 consultation_entry 相談申し込みを1件ずつ保存
Label 相談申し込み 管理画面で見つけやすくする
公開設定 非公開運用 申込内容を一般公開しない
サポート Titleのみ 本文ではなく入力項目で管理する

入力項目は、あとから一覧で確認する単位に分けます。1つの「相談内容」だけに全部入れてしまうと、担当者別やメニュー別の確認ができません。反対に、最初から細かすぎる項目を20個も作ると、ユーザーが入力しにくくなります。最初は次のくらいが現実的です。

画面ラベル フィールド名 サンプル値
お名前 applicant_name Text 山田 太郎
メール applicant_email Text sample@example.com
希望メニュー service_type Select site_renewal
相談内容 message Textarea 既存LPの改善相談
希望連絡方法 contact_method Radio メール
対応状況 entry_status Select 未対応
内部メモ staff_note Textarea 管理者だけが記入
相談フォームの入力項目と保存する記録項目

まず標準の送信後アクションで組む

JetFormBuilderでは、フォーム送信後に実行する処理を「送信後アクション」として並べます。今回の基本形は、次の順番です。

  1. 申込者へ控えメールを送る
  2. 管理用の記録を保存する
  3. 希望メニューに応じて担当者へ通知する
  4. 完了ページへ移動する、または完了メッセージを表示する

公式ドキュメント上でも、送信後アクションにはメール送信、投稿作成・更新、記録保存、Call Hookなどが用意されています。メール通知だけで足りるなら、まずはSend Emailアクションを複数作り、それぞれに条件を付けます。たとえば、希望メニューが site_renewal のときだけ制作担当へ送る、maintenance のときだけ保守担当へ送る、という作り方です。

アクション名 条件 宛先の例 役割
控えメール 常に実行 %applicant_email% 申込者へ内容を返す
制作担当通知 service_type = site_renewal 制作担当 サイト改善相談を受ける
集客担当通知 service_type = ads_support 集客担当 広告相談を受ける
保守担当通知 service_type = maintenance 保守担当 保守相談を受ける
相談記録の保存 常に実行 consultation_entry 後から一覧で確認する

この段階では、コードはまだ不要です。条件が3つ程度で、担当者も固定なら、標準設定の方が画面から確認しやすく、あとで別の制作者が見ても意図が分かります。

送信後アクションを条件つきで並べる流れ

コードを足すべき場面

コードを足すのは、標準設定のアクションが増えすぎるときです。たとえば、希望メニューが8種類あり、地域や予算感でも通知先を変える場合、Send Emailアクションを大量に並べると管理しにくくなります。条件の変更漏れも起きやすくなります。

このとき、JetFormBuilderのCall Hookアクションを使うと、フォーム送信後に任意のWordPressフック名を呼び出せます。記事では、フック名を netchild_jfb_route_notification として、Code Snippetsプラグインに同じ名前の処理を登録する例にします。

最初に確認したいこと

Call Hookは便利ですが、フォームの入力値を扱うコードになります。実運用では、入力値のサニタイズ、メールアドレスの検証、個人情報をログに残さないこと、停止しやすい配置にすることを必ず確認してください。

Code SnippetsにCall Hook用のPHPを置く場所

Call Hookで担当者通知をまとめるPHP例

以下は、希望メニューに応じて通知先を切り替える最小例です。配置場所はCode Snippetsプラグイン、または子テーマの functions.php です。初心者は、エラー時に無効化しやすいCode Snippetsプラグインの方が扱いやすいです。

JetFormBuilder側では、送信後アクションにCall Hookを追加し、Hook Nameに netchild_jfb_route_notification と入力します。フォームのフィールド名は、下のコードと同じ service_typeapplicant_nameapplicant_emailmessage に合わせてください。

add_action( 'netchild_jfb_route_notification', function () {
    $service = isset( $_POST['service_type'] )
        ? sanitize_key( wp_unslash( $_POST['service_type'] ) )
        : '';

    $name = isset( $_POST['applicant_name'] )
        ? sanitize_text_field( wp_unslash( $_POST['applicant_name'] ) )
        : '';

    $email = isset( $_POST['applicant_email'] )
        ? sanitize_email( wp_unslash( $_POST['applicant_email'] ) )
        : '';

    $message = isset( $_POST['message'] )
        ? sanitize_textarea_field( wp_unslash( $_POST['message'] ) )
        : '';

    if ( ! $service || ! $name || ! is_email( $email ) ) {
        return;
    }

    $routes = array(
        'site_renewal' => 'renewal-team@example.com',
        'ads_support'  => 'marketing-team@example.com',
        'maintenance'  => 'support-team@example.com',
    );

    $to = isset( $routes[ $service ] )
        ? $routes[ $service ]
        : 'info@example.com';

    $subject = sprintf( '相談フォーム: %s', $service );
    $body    = sprintf(
        "お名前: %s\nメール: %s\n希望メニュー: %s\n\n相談内容:\n%s",
        $name,
        $email,
        $service,
        $message
    );

    $headers = array(
        sprintf( 'Reply-To: %s <%s>', $name, $email ),
    );

    wp_mail( $to, $subject, $body, $headers );
} );

このコードは、フォームから来た値をそのまま信用せず、sanitize_key()sanitize_text_field()sanitize_email()sanitize_textarea_field() で整えてから使います。送信先も、フォーム入力値から直接受け取るのではなく、サーバー側の配列に固定しています。ここが大事です。ユーザーが見えない入力項目を書き換えても、任意のメールアドレスへ送れない形にしておきます。

実サイトでは、上の example.com の宛先を自社の担当者メールに置き換えます。送信テストは本番公開前にステージングサイトで行い、メールが迷惑メールに入らないか、Reply-Toが意図どおりか、未分類のメニューが info@example.com 相当の共通窓口へ届くかを確認してください。

Elementor側ではどう表示するのか

Elementor側では、相談ページの本文、フォーム、送信後の案内を分けて考えます。ページ上部では「どんな相談を受け付けるのか」を説明し、その下にJetFormBuilderのフォームを配置します。フォームの上には、希望メニューの選び方を短く書く程度で十分です。

完了後の見せ方は2つあります。1つはフォーム下に完了メッセージを表示する方法、もう1つはサンクスページへ移動する方法です。広告流入やアクセス解析を重視するなら、サンクスページに移動させる方が計測しやすいです。通常の問い合わせなら、ページ内の完了メッセージでも問題ありません。

相談記録をJetEngineのデータの箱に保存している場合、管理者向けの一覧ページをElementorで作ることもできます。公開ページではなく、管理者だけが確認する前提のページです。Listing Itemに「お名前」「希望メニュー」「対応状況」「送信日」を置き、Listing Gridで並べると、メールボックスを探すより確認しやすくなります。

運用すると何が楽になるのか

この仕組みで楽になるのは、フォーム送信後の手作業です。メールを見て担当者へ転送する、相談種別をメモする、対応済みかどうかを別のシートに書く、といった作業を減らせます。特に、複数人で問い合わせ対応をするサイトでは、誰に通知されたかをルール化できるのが効きます。

ただし、通知先を自動で切り替えたからといって、対応管理が完全に自動化されるわけではありません。返信の品質、個人情報の扱い、担当者の不在時の代替ルール、対応期限は別途決める必要があります。JetFormBuilderはフォームと送信後処理を作る道具であり、社内ルールそのものを設計してくれるわけではありません。

通知分岐を追加した後の運用改善イメージ

どこから複雑になりすぎるのか

フォームまわりは、便利にしようとするとすぐに複雑になります。希望メニュー、地域、予算、担当者の空き状況、既存顧客かどうか、資料添付の有無、会員権限、決済まで一度に入れようとすると、フォームではなく業務システムの領域です。

最初の実装では、次の範囲に抑えるのがおすすめです。

  • 希望メニューで通知先を分ける
  • 申込者へ控えメールを送る
  • 相談記録をWordPress内に保存する
  • 対応状況だけ管理者が更新できるようにする
  • 個人情報は必要最小限にする

逆に、ログインユーザーの個人情報、決済、予約枠、ファイル添付、外部CRM連携まで扱うなら、権限設計、スパム対策、保存期間、プライバシーポリシー、バックアップ、通知失敗時の再送方法まで見直してください。JetFormBuilderやJetEngineを入れれば、セキュリティ設計や運用設計が不要になるわけではありません。

フォーム拡張で確認したい安全対策

この構成が向いている人・向いていない人

向いているのは、Elementorで相談ページやサービスページを作っていて、問い合わせ後の処理を少し整えたい人です。メール通知を分けたい、相談記録を残したい、担当者への転送を減らしたい、という段階なら、JetFormBuilderと少しのコードで十分に現実的です。

向いていないのは、最初から複雑な顧客管理システムをWordPressだけで作ろうとしているケースです。複数部署の承認、機密情報、決済、契約管理、外部システム連携が絡むなら、専用サービスや開発者による設計も検討した方が安全です。

まとめ

JetFormBuilderのカスタムコード拡張は、標準設定を置き換えるものではありません。まずは送信後アクション、条件付きメール通知、保存処理で作り、管理画面上の設定が増えすぎたときだけ、Call HookとCode Snippetsで小さくまとめます。

今回の相談フォーム例では、希望メニューに応じた通知先切り替えを扱いました。入力項目を分け、保存する記録を決め、Elementor側ではフォームと完了導線を整える。ここまでできると、静的な問い合わせページから一歩進んだ運用が作れます。

JetFormBuilderの送信後アクションを確認しながら、自分のサイトでまず1つだけ自動化するなら、通知先の分岐から始めるのが分かりやすいです。

JetFormBuilder公式ページを見てみる