MW WP Form のフックを Form Plant へ移植する — `mwform_` から `fplant_` への書き換えと設計の違い

Posted at 2026-06-13

はじめに

前回の記事では、MW WP Form のフォームを Form Plant へ移行するツールの使い方と、デザインの引き継ぎ方を扱いました。今回はその続きとして、functions.php に書いた mwform_* フックによるカスタマイズを Form Plant の fplant_* フックへ書き換える方法と、その背景にある 2 つのプラグインの設計の違いを、技術者向けに整理します。

先ず、本記事は Form Plant という WordPress フォームプラグインを開発している立場（筆者 = Sofplant）から書いています。MW WP Form は長く使われてきた完成度の高いプラグインで、その柔軟なフック設計を前提に作り込まれたサイトも多いはずです。本記事は、そうしたカスタマイズを Form Plant へ移す時に、どう書き換える必要があるのかを記載しました。移行作業の参考にしてください。

移行ツールは、フォーム定義（入力項目）・メール設定・画面テンプレートを自動変換しますが、functions.php の mwform_* フックは自動変換の対象外で、ここは手作業が必要です。

なお、実装済みフックの全パターン、引数の早見表、サポート外フックの代替策、移行チェックリストは、Form Plant マニュアルの MW WP Form からの移行（フックの移行対応表）にまとめています。本記事は「考え方」と「代表例」に絞り、網羅的な部分はそちらへリンクで送る構成です。

この記事で扱う範囲

移行シリーズの守備範囲を再掲します。本記事は第 2 弾になります。

第 1 弾（前回）: 移行ツールの仕組み / 移行の流れ / フィールド名とラベルの扱い / デザインをそのまま引き継ぐ考え方
第 2 弾（本記事）: mwform_* フックを fplant_* へ書き換える方法 / 2 つのプラグインの設計の違い / フックの観点での「移行できる点・できない点」

本記事のフック名や引数は Form Plant v1.2 以上のものです。MW WP Form 移行ツールと同時に、移行でよく使われるフック群（メール宛先の動的変更、リダイレクト先の変更、選択肢の動的生成、送信スキップなど）を追加しています。

1. 自動変換できない部分 — 2 つのプラグインの設計の違い

1.1 画面遷移モデル（MW WP Form）と AJAX/REST モデル（Form Plant）

MW WP Form は、入力 → 確認 → 完了の各画面をサーバー側でページ遷移しながら処理します。そのため、処理の各段階（処理開始・画面ロードの前後・リダイレクト直前など）に対応するアクションフックを数多く持っています。

一方 Form Plant は、1 ページ内で AJAX / REST により送信し、画面遷移を伴いません。確認画面も完了表示も、JavaScript が同じページ内で要素を差し替えて表現します。結果として、サーバー側に「確認画面に遷移する直前」「リダイレクトする直前」といった地点が存在しません。

両者の送信ライフサイクルを並べると、違いが見えます。図中の点線の矢印は、その段階で発火する代表的なフックです（よく使われるものに絞っています）。まず MW WP Form（画面遷移あり）。

補足: 厳密には、MW WP Form の DB 保存（問い合わせデータ保存）は管理者メール送信の後・自動返信メール送信の前に行われます。mwform_after_send_* は、メール送信・DB 保存・問い合わせ番号の更新がすべて成功した後（完了画面へ移る直前）に発火します。

Form Plant（画面遷移なし・AJAX/REST）は下記です。

なお、確認画面は任意で、使わない設定では入力欄から「送信処理の開始」へ直接進みます。バリデーションは、確認時（上図の最初の「バリデーション」）と送信時のいずれもサーバー側で行われ、この二段でバリデーションする点は MW WP Form も同様です（上の MW 図の「バリデーション（再）」）。Form Plant は送信時にバリデーションとあわせてサニタイズ（型別の値整形）も行うため、図では「バリデーション・サニタイズ」としています。

図中に点線で示したとおり、Form Plant の各段階にはコールバックを仕込むためのフックが対応します。その中で処理の節目になるのが次の 3 つです。

「送信処理の開始（バリデーション前）」→ fplant_before_submission
「DB 保存」の直後 → fplant_after_submission
「送信・メール完了後の処理」→ fplant_after_submission_complete（外部連携の主フック）

この違いがそのまま、後述する「移行できる / できない」の境界になります。送信処理そのものに紐づくフック（初期値・バリデーション・メール・送信後連携など）は対応するものがありますが、画面遷移に紐づくフック（リダイレクト直前、コンテンツ表示前後など）は、対応する地点がないため移植できません。多くは fplant_before_submission（送信処理の最初）や fplant_after_submission_complete（送信・メール後）で代替します。

1.2 確認画面・完了画面の URL と、コンバージョン計測への影響

画面遷移モデルと AJAX/REST モデルの違いが運用面で表れるのが、画面の URL です。MW WP Form は入力・確認・完了・エラーの各画面をそれぞれ別の固定ページ（別 URL）に割り当てられましたが、Form Plant は設置した 1 ページ内で画面を切り替えます。「コンバージョン計測ができなくなるのでは」と考えるかもしれませんが、完了（サンクス）の計測は従来どおりできます。

まず、移行ツールがこの設定をどう扱うかは次のとおりです。

MW WP Form の設定	Form Plant での扱い
完了画面の URL（`complete_url`）	送信後アクション =「リダイレクト」＋リダイレクト先 URL
完了メッセージ（`complete_message`）	送信後アクション =「カスタムページ」＋完了 HTML
入力 URL / 確認 URL / エラー URL	移行不要（ページ内で遷移するため。移行レポートに通知）

完了（コンバージョン）計測はできる（特別な JS は不要）

送信後アクションで「リダイレクト」を選ぶと、送信完了時に指定したサンクスページ（独自 URL の固定ページ）へ通常のページ遷移で移動します。内部的には window.location による遷移で、SPA 的な擬似遷移ではなくフルページロードです。そのため遷移先のサンクスページは独立したページとして普通に読み込まれ、そこに設置した GA4 などの計測タグも通常どおり発火します。つまり、サンクスページに計測タグを置くか、GA4（や GTM）でサンクスページの URL 到達をキーイベント（旧コンバージョン）に設定する、という通常の方法でコンバージョンを計測できます。フォーム側で特別な JavaScript を書く必要はありません。フォームの内容に応じてサンクスページを出し分けたい場合は fplant_redirect_url（後述 4.8）で動的に変えられます。

なお、送信後アクションでリダイレクトを使わず、完了メッセージや完了 HTML をページ内に表示する方式（=「メッセージ」「カスタムページ」）を選んだ場合に限り、完了表示が同一 URL のまま行われるため「URL 到達」での計測は使えません。この方式で計測したいときは一手間かかり、Form Plant が送信完了時に発火する fplant:success という JavaScript イベントをフックして GA4 のイベントを送る形になります。MW WP Form のように完了 URL での計測を続けたい場合は、ページ内完了ではなくリダイレクト方式を選ぶのが素直です（上記のとおり特別な JS は不要になります）。

MW WP Form と比べて「できなくなること」

純粋にできなくなるのは、確認画面そのものを独自 URL で持つことです。MW WP Form では確認画面を別ページ（別 URL）にできましたが、Form Plant の確認画面はページ内で表示されるため固有 URL を持ちません。確認画面の PV を個別に計測したり、確認画面を直リンクしたりはできません。とはいえ、コンバージョン計測で重要になるのは通常「完了」であり、そちらは上記のとおり計測できます。

得られるメリット

完了でリダイレクトを使わない場合、入力 → 確認 → 完了がページ遷移を伴わないため表示が速く、入力途中の状態が保たれやすい。サーバー側でセッションを持ち回す必要もありません。
確認用・完了用の固定ページを別途作って管理する手間が（リダイレクトを使わなければ）不要で、フォームは 1 ページで完結します。
URL が変わらないので、外部サイトへの埋め込み（iframe / JavaScript）でもフォームが扱いやすくなります。

確認画面の固有 URL は持てませんが、コンバージョン計測（完了の計測）はリダイレクト方式にすればサンクスページへの到達で従来どおり計測でき、そのための特別な作業は不要です。

1.3 メールの渡し方の違い

また、書き換えで特徴的なのがメール処理の違いです。

MW WP Form は、メールを 1 つの $Mail オブジェクト（to / cc / bcc / from / subject / body を保持）としてフィルターに渡します。開発者はこのオブジェクトのプロパティを書き換えて返す設計で、宛先の変更も送信のスキップも、同じオブジェクト操作（$Mail->to = false でスキップ）で行います。

Form Plant は、件名・本文・宛先・ヘッダーをそれぞれ独立したフィルターで渡し、MW WP Formでは1 本にまとめて書いていた処理を、用途ごとに振り分けます。

カスタマイズ内容	MW WP Form	Form Plant
メールの渡され方	1 つの `$Mail` オブジェクト	用途ごとに別のフィルター
宛先を変更	`$Mail->to` を書き換え	`fplant_admin_email_to`（配列を返す）
ヘッダー（CC / BCC 等）を変更	`$Mail->cc` 等を書き換え	`fplant_admin_email_headers`
件名・本文を変更	`$Mail->subject` / `$Mail->body`	`fplant_admin_email_subject` / `_body`
送信をスキップ	`$Mail->to = false`	`fplant_skip_admin_email`（または宛先を空配列）

（自動返信メールは fplant_user_email_* 系を使います。）

これは、宛先・本文・スキップが別々のフックに分かれているぶん、戻り値のサニタイズやエスケープをプラグイン側で一貫して扱える、というメリットがあります（戻り値のエスケープを開発者が気にしなくてよい）。

2. 書き換え前に押さえる 3 つの違い

設計の違いをふまえたうえで、実際にコードを書き換える前に知っておきたい、フックの「呼び出し方」の違いが 3 つあります。

違い 1: フック名の付き方

MW WP Form: フォームごとに フォームキー（例 mw-wp-form-12）がフック名の末尾に付きます。
例: mwform_value_mw-wp-form-12
Form Plant: フックは 2 系統です。
- フィールド名が末尾に付くフック: fplant_field_initial_value_{フィールド名} のように、対象フィールドを名前で狙えます。
- フォーム全体に発火するフック: fplant_redirect_url のようにサフィックスが無く、コールバック内で $form_id を見て対象フォームを判定します。

違い 2: フォームの識別は「フォームキー」ではなく「フォーム ID（数値）」

Form Plant はフォームを 数値の ID で識別します。設置用ショートコードも、MW WP Form の [mwform_formkey key="12"] に対して Form Plant では [fplant id="12"] となります。フォーム ID は次の場所で確認できます。

フォーム編集画面の URL: wp-admin/admin.php?page=fplant-form-new&id=12 の 12
設置用ショートコード: [fplant id="12"] の 12

注意: MW WP Form のフォームキーの番号（mw-wp-form-12 の 12）と Form Plant のフォーム ID は別の体系で、移行ツールで同じ番号になるとは限りません。本記事では対応を分かりやすくするため両方 12 としていますが、実際の値は各編集画面でご確認ください。

サフィックスの無いフックでは、次のように $form_id で対象フォームを絞り込みます。

add_filter( 'fplant_redirect_url', function ( $url, $form_id, $data ) {
    if ( 12 !== $form_id ) {
        return $url; // 対象フォーム以外はそのまま返す
    }
    // フォーム ID 12 だけの処理
    return $url;
}, 10, 3 );

違い 3: name 属性（Form Plant ではフィールド名）が「日本語 → 英数字」に変わる

項目の識別名を、MW WP Form ではフォームタグの name 属性、Form Plant では「フィールド名」と呼びます。移行ツールは、この日本語の name 属性を英数字のフィールド名へ自動変換します（例: お名前 → your_name、メールアドレス → email）。前回記事で触れたとおり、これはメールの差し込みタグにも波及しますが、フックでも同じく、書き換え後は移行後の新しいフィールド名を使う必要があります。

新しいフィールド名は、Form Plant のフォーム編集画面で各フィールドの「名前（name）」として確認できます。

// MW WP Form（name 属性は日本語「お名前」）
add_filter( 'mwform_value_mw-wp-form-12', function ( $value, $name ) {
    if ( 'お名前' === $name ) { /* ... */ }
    return $value;
}, 10, 2 );

// Form Plant（移行後の英数字キー「your_name」をフック名に使う）
add_filter( 'fplant_field_initial_value_your_name', function ( $value, $field, $form_id ) {
    /* ... */
    return $value;
}, 10, 3 );

連番フォールバック（text_1 など）で生成されたフィールド名は何の項目か分かりにくいので、移行後に分かりやすい名前へ変更しておくと、フックの可読性も上がります。その際は、フック名のサフィックスとメール差し込みタグも合わせて更新してください。

3. フック対応早見表

実装済みで「書き換え可能」なフックの対応です。サポート外のフックは「5. フックの観点での移行できる点・できない点」を参照してください。

やりたいこと	MW WP Form	Form Plant
フィールドの初期値を設定	`mwform_value_*`	`fplant_field_initial_value_{name}`
選択肢を動的生成	`mwform_choices_*`	`fplant_field_choices_{name}`
独自バリデーション	`mwform_validation_*`	`fplant_validate_field_{name}`（フィールド値の検証） `fplant_validation_errors`（相関・条件付き必須）
エラーメッセージを変更	`mwform_error_message_*`	`fplant_validation_message_*`
カスタムメールタグ	`mwform_custom_mail_tag(_*)`	`fplant_custom_mail_tag_value_{name}`
メール件名・本文を変更	`mwform_admin_mail_` / `mwform_auto_mail_`	`fplant_admin_email_subject` / `_body`、`fplant_user_email_subject` / `_body`
メール宛先を動的に変更	`mwform_admin_mail_*`（`$Mail->to`）	`fplant_admin_email_to` / `fplant_user_email_to`
メールヘッダー（CC/BCC 等）を変更	`mwform_admin_mail_*`（`$Mail`）	`fplant_admin_email_headers` / `fplant_user_email_headers`
メール送信を条件でスキップ	`mwform_admin_mail_*`（`$Mail->to = false`）	`fplant_skip_admin_email` / `fplant_skip_user_email`
送信完了後に外部連携	`mwform_after_send_*`	`fplant_after_submission_complete`
リダイレクト先を動的に変更	`mwform_redirect_url_*`	`fplant_redirect_url`
完了メッセージを動的に変更	`mwform_complete_content_*`	`fplant_complete_message` / `fplant_success_html`
添付ファイルの保存先・ファイル名	`mwform_upload_dir_` / `mwform_upload_filename_`	`fplant_upload_dir` / `fplant_upload_filename`
設定画面に独自項目を追加	`mwform_settings_extend_fields(_*)`	`fplant_custom_settings_fields`
CSV の文字コード	`mwform_csv_encoding-*`	`fplant_export_encoding`
入力フィールド種別を追加	`mwform_form_fields`	`fplant_field_types`

各フックの引数を含む完全なリファレンスと、ここに載らないフックの扱い（サポート外フックの一覧を含む）は、マニュアルのフックの移行対応表にまとめてあります。

4. 書き換え例（before / after）

代表的なユースケースの書き換えを示します。以降、mw-wp-form-12 はフォームキー、Form Plant 側の 12 はフォーム ID、your_name 等は移行後のフィールド名の例です。ご自身の環境の値に置き換えてください。

4.1 フィールドの初期値を設定する

// before: MW WP Form（ログインユーザーのメールアドレスを初期値に。引数は $value, $name）
add_filter( 'mwform_value_mw-wp-form-12', function ( $value, $name ) {
    if ( 'email' === $name && is_user_logged_in() ) {
        $value = wp_get_current_user()->user_email;
    }
    return $value;
}, 10, 2 );

// after: Form Plant（フック名の末尾にフィールド名を付ける）
add_filter( 'fplant_field_initial_value_email', function ( $value, $field, $form_id ) {
    if ( is_user_logged_in() ) {
        $value = wp_get_current_user()->user_email;
    }
    return $value;
}, 10, 3 );

4.2 選択肢を動的に生成する（投稿・タームから）

MW では選択肢を「ラベル => 値」の連想配列で扱いましたが、Form Plant は array( 'label' => ..., 'value' => ... ) の配列で扱います。

// before: MW WP Form（引数は $children, $atts）
add_filter( 'mwform_choices_mw-wp-form-12', function ( $children, $atts ) {
    if ( 'product' === ( $atts['name'] ?? '' ) ) {
        foreach ( get_posts( array( 'post_type' => 'product' ) ) as $p ) {
            $children[ $p->ID ] = $p->post_title;
        }
    }
    return $children;
}, 10, 2 );

// after: Form Plant
add_filter( 'fplant_field_choices_product', function ( $options, $field, $form_id ) {
    foreach ( get_posts( array( 'post_type' => 'product' ) ) as $p ) {
        $options[] = array( 'label' => $p->post_title, 'value' => (string) $p->ID );
    }
    return $options;
}, 10, 3 );

対応フィールド種別: セレクト / ラジオ / チェックボックス。動的に追加した選択肢は、描画・確認画面・バリデーション（許可値チェック）で同じソースが参照されます。

4.3 独自バリデーション

MW は Validation オブジェクトにエラールールをセットする方式でした。Form Plant のバリデーションフックは用途で 2 つに分かれます。

フィールド単位 fplant_validate_field_{name}: そのフィールド自身の値を検証し、問題があればエラー文字列を返します（$error をそのまま返せば問題なし）。ただし 値が空のフィールドでは発火しません（空欄の判定は標準の必須設定に任せる設計のため）。
フォーム全体 fplant_validation_errors: 全フィールドの送信データとエラー配列を受け取り、$errors['フィールド名'] にメッセージを積みます。空欄でも発火するので、複数フィールドにまたがる条件や条件付き必須はこちらを使います。

例として、お問い合わせ種別（inquiry_type）で「その他」が選ばれたときだけ詳細テキスト（other_text）を必須にする、という条件付き必須を書いてみます。other_text が空のときに判定する必要があるため、フォーム全体の fplant_validation_errors を使います。

// before: MW WP Form（「その他」選択時のみ other_text を必須に）
add_filter( 'mwform_validation_mw-wp-form-12', function ( $Validation, $data ) {
    if ( 'その他' === ( $data['inquiry_type'] ?? '' ) && '' === trim( $data['other_text'] ?? '' ) ) {
        $Validation->set_rule( 'other_text', 'noEmpty', array(
            'message' => '「その他」を選択された方は、具体的な内容をご入力ください。',
        ) );
    }
    return $Validation;
}, 10, 2 );

// after: Form Plant（フォーム全体のフックで判定し、$errors にフィールド名キーで積む）
add_filter( 'fplant_validation_errors', function ( $errors, $fields, $data ) {
    if ( 'その他' === ( $data['inquiry_type'] ?? '' ) && '' === trim( (string) ( $data['other_text'] ?? '' ) ) ) {
        $errors['other_text'] = '「その他」を選択された方は、具体的な内容をご入力ください。';
    }
    return $errors; // 追加しなければそのまま返す
}, 10, 3 );

MW は $Validation にルールをセットして返し、Form Plant は $errors にフィールド名（other_text）をキーにしてメッセージを積みます。どちらも送信データ全体（$data）から他フィールドの値（inquiry_type）を参照できるため、このような相関・条件付き必須が書けます。一方、フィールド自身の値の形式チェック（入力があるときだけ検証する用途）には fplant_validate_field_{name} が向きます。

4.4 カスタムメールタグ

移行ツールは MW の [mwform_custom_mail_tag] を Form Plant の custom_mail_tag フィールドへ変換します。タグの値を供給するフックは手動で書き換えます。

// before: MW WP Form（{member_rank} タグ。引数 $value, $name, $insert_id）
add_filter( 'mwform_custom_mail_tag_mw-wp-form-12', function ( $value, $name, $insert_id ) {
    if ( 'member_rank' === $name ) {
        $value = get_user_meta( get_current_user_id(), 'rank', true );
    }
    return $value;
}, 10, 3 );

// after: Form Plant（custom_mail_tag フィールド "member_rank" の値を供給）
add_filter( 'fplant_custom_mail_tag_value_member_rank', function ( $value, $field, $form_id ) {
    return get_user_meta( get_current_user_id(), 'rank', true );
}, 10, 3 );

移行ツールが custom_mail_tag フィールドへ自動変換したケースでは、対応するこのフィルターの登録が事実上セットで必要になります（値を供給するコードが無いと、タグが空になります）。移行後に忘れずに対応付けてください。

4.5 メール宛先を動的に振り分ける（`$Mail->to` の置き換え）

MW で $Mail->to を書き換えていた処理は、宛先を配列で返すフィルターになります。CC / BCC / Reply-To はヘッダー用フィルターで扱います。

// before: MW WP Form（問い合わせ種別で宛先を振り分け。$Mail オブジェクトを改変）
add_filter( 'mwform_admin_mail_mw-wp-form-12', function ( $Mail, $values ) {
    if ( '営業' === ( $values['category'] ?? '' ) ) {
        $Mail->to = 'sales@example.com';
    }
    return $Mail;
}, 10, 2 );

// after: Form Plant（宛先は配列で返す）
add_filter( 'fplant_admin_email_to', function ( $to, $form_id, $data ) {
    if ( 12 === $form_id && '営業' === ( $data['category'] ?? '' ) ) {
        $to = array( 'sales@example.com' );
    }
    return $to;
}, 10, 3 );

// ヘッダー（CC / BCC / Reply-To）は別フィルターで
add_filter( 'fplant_admin_email_headers', function ( $headers, $form_id, $data ) {
    if ( 12 === $form_id ) {
        $headers[] = 'Bcc: archive@example.com';
    }
    return $headers;
}, 10, 3 );

自動返信メール側は fplant_user_email_to / fplant_user_email_headers を使います。

4.6 メール送信を条件でスキップする（`$Mail->to` を空にする処理の置き換え）

MW で「宛先を空にして送信を抑止する」手法は、専用フィルターで明示的に行います。

// before: MW WP Form（条件によって管理者メールを送らない。$Mail->to を空にする）
add_filter( 'mwform_admin_mail_mw-wp-form-12', function ( $Mail, $values ) {
    if ( empty( $values['needs_notify'] ) ) {
        $Mail->to = ''; // 宛先を空にすると送信されない
    }
    return $Mail;
}, 10, 2 );

// after: Form Plant（専用フィルターで送信を中止）
add_filter( 'fplant_skip_admin_email', function ( $skip, $form, $data, $submission_id ) {
    if ( (int) $form['id'] === 12 && empty( $data['needs_notify'] ) ) {
        return true; // true を返すと送信中止
    }
    return $skip;
}, 10, 4 );

自動返信メールは fplant_skip_user_email を使います。なお、4.5 の fplant_admin_email_to が空配列を返した場合も送信されないため、「宛先を空にしてスキップ」という MW 的な書き方に近い挙動も選べます。

4.7 送信完了後に外部サービスへ連携する

Slack 通知・CRM 連携・Google スプレッドシートへの記録など、送信後処理の主役となるフックです。

// before: MW WP Form（送信完了後に Slack 通知。引数は $Data）
add_action( 'mwform_after_send_mw-wp-form-12', function ( $Data ) {
    notify_slack( $Data->get( 'email' ) );
} );

// after: Form Plant（引数は $data, $form_id, $form, $submission_id）
add_action( 'fplant_after_submission_complete', function ( $data, $form_id, $form, $submission_id ) {
    if ( 12 === $form_id ) {
        notify_slack( $data['email'] ?? '' );
    }
}, 10, 4 );

MW の $Data->get( 'キー' ) は、Form Plant では送信データ配列 $data['キー'] で取り出します。

4.8 リダイレクト先を動的に変更する

// before: MW WP Form（引数は $url, $Data）
add_filter( 'mwform_redirect_url_mw-wp-form-12', function ( $url, $Data ) {
    return ( 'premium' === $Data->get( 'plan' ) ) ? home_url( '/thanks-premium/' ) : $url;
}, 10, 2 );

// after: Form Plant（戻り値は esc_url_raw 済みとして扱われます）
add_filter( 'fplant_redirect_url', function ( $url, $form_id, $data ) {
    if ( 12 === $form_id && 'premium' === ( $data['plan'] ?? '' ) ) {
        $url = home_url( '/thanks-premium/' );
    }
    return $url;
}, 10, 3 );

リダイレクトは、フォームの「送信後のアクション」設定で「リダイレクト」を選んでいる場合に有効です。1.2 で触れた完了計測（サンクスページの PV 計測）も、この設定が起点になります。

ここに挙げた以外（完了メッセージの変更、添付ファイルの保存先・ファイル名、設定画面への独自項目追加、CSV の文字コードなど）の書き換え例は、マニュアルの書き換え例（before / after）集にまとめています。

5. フックの観点での移行できる点・できない点

ここまでの設計の違いをふまえると、フックは大きく 3 つに分かれます。手元のフックがどれに当たるかは、次の流れで判断できます。

5.1 そのまま移行できる（同等フックがある）

送信処理の本体に紐づくフックは、おおむね対応があります。初期値・フィールド種別・バリデーション・エラーメッセージ・カスタムメールタグ・メール件名/本文・送信前後のアクション・送信完了後の外部連携などです。加えて v1.2 では、移行需要の高いメール宛先/ヘッダーの動的変更・リダイレクト先の変更・選択肢の動的生成・送信スキップ・完了表示の変更・設定画面への独自項目追加・CSV の文字コード・添付ファイルの保存先/ファイル名を実装しました。MW でよく使われるフックの多くは、この層で書き換えられます。

5.2 設計差を埋めて代替する

完全な 1 対 1 対応ではないものの、別フックや標準機能で目的を達成できるかと思います。

フォーム HTML をコードで加工（mwform_post_content）: フォーム設定の HTML テンプレート機能で直接編集し、動的な値差し込みは fplant_template_values、テーマ側でのテンプレート差し替え（オーバーライド）は fplant_locate_template で対応します。
DB に保存しない項目の指定（mwform_no_save_keys）: フォーム設定の「送信データの保存」（保存しない / メタデータのみ / すべて保存）で制御でき、項目単位で除外したい場合は fplant_before_save_submission_data フィルターで該当キーを unset します。
メール送信結果の参照: fplant_after_admin_email_send / fplant_after_user_email_send が $result を受け取ります（結果の参照は可能で、結果自体を上書きする用途には対応しません）。

5.3 設計上、移行できない（対応する概念がない）

次の系統は、Form Plant のアーキテクチャ上、対応する地点や概念がありません。実装するなら独自設計が必要になるため、現状はサポート外としています。

画面遷移に紐づくフック: リダイレクト直前（mwform_before_redirect）、コンテンツ表示前後（mwform_before_load_content / mwform_after_load_content）など。Form Plant は AJAX/REST で画面遷移を伴わないため、これらに相当するサーバー側の地点がありません（確認画面そのものを URL で持てない点は 1.2 のとおり）。送信前後の処理は fplant_before_submission / fplant_after_submission_complete で代替します。
管理画面の問い合わせデータ・CSV カラム系: 一覧カラム定義（mwform_inquiry_data_columns）、CSV カラム定義（mwform_csv_columns）、対応ステータス（mwform_response_statuses）など。MW は問い合わせを WordPress 投稿として管理しますが、Form Plant は独自テーブル（wp_fplant_submissions）と独自の一覧・エクスポートを使うため、前提が根本的に異なります（CSV の文字コードだけは需要が高いため fplant_export_encoding として実装済みです）。
フォームエディタ拡張・タグ生成ツール系: タグジェネレータ（mwform_tag_generator_*）など。Form Plant はフィールド追加をモーダル UI で行い、タグ生成ツールという仕組みを持ちません。フィールド種別の追加自体は fplant_field_types で可能ですが、その編集 UI を差し込む API は現状ありません。
インフラ・エラー画面・スパム系: Akismet 判定（mwform_akismet_responce）、セッション Cookie 制御（mwform_secure_cookie）、メールログの保存先（mwform_log_directory）など。日付フィールド・CSS・セッション・スパム対策・ログの仕組みが異なるためです。なお、スパム対策については、Form Plant が honeypot・reCAPTCHA・Cloudflare Turnstile・使い捨てメール判定・レート制限などを標準で内蔵しているため、Akismet 連携フックに相当する代替は標準機能側にあります（移行ツールでは Akismet 設定は引き継がれないため、reCAPTCHA / Turnstile を別途設定します）。

つまり「移行できない」と言っても、その多くは Form Plant の標準機能が役割を引き継いでいるものです。フックが無いこと自体が機能の欠落を意味するわけではありません。サポート外フックの一覧と、それぞれの代替策はマニュアルのサポート外のフックと代替策にまとめています。

まとめ

MW WP Form から Form Plant へのフック移行は、フォーム定義の移行とは別に、functions.php のカスタマイズを手作業で書き換える工程になります。

機械的な置換では済まず、**画面遷移モデル（MW）と AJAX/REST モデル（Form Plant）**という設計の違いから、移行できないフックもある。
できない例は確認画面の URLですが、送信後アクションをリダイレクトにすればサンクスページ（独自 URL）へ通常遷移するため、その PV でコンバージョン計測は従来どおりでき、ページ内完了でも送信完了の JavaScript イベントで計測できる。
書き換え前に、フック名の付き方・フォームの数値 ID 識別・フィールド名の英数字化の 3 点を押さえる。
メール周りは、MW の 1 つの $Mail オブジェクト操作が、Form Plant では宛先・ヘッダー・件名/本文・スキップの別フィルターに分かれる。
送信処理本体のフックはおおむね移行でき、画面遷移・管理画面・エディタ・インフラ系は設計上の対応がない（ただしその多くは Form Plant の標準機能が役割を引き継いでいる）。

実装済みフックの全パターン、引数の早見表、サポート外フックの代替策、移行チェックリストは、Form Plant マニュアルの MW WP Form からの移行にまとめています。フックでカスタマイズしている方は、移行前にそちらで対応関係を確認していただければと思います。

移行シリーズはこれで一区切りです。比較・移行ツールとデザイン・フックと設計差の 3 本を通して、MW WP Form のサイトを Form Plant へ移すときの全体像をお伝えできていれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

MW WP Form のフックを Form Plant へ移植する — `mwform_*` から `fplant_*` への書き換えと設計の違い