WordPressサイトを構築している場合は、WordPressフォームプラグインを選択しない正当な理由が必要です。それらは便利で、ゼロから構築するために多くの努力が必要なカスタマイズをたくさん提供しています。 HTMLをレンダリングし、データを検証し、提出物を保存し、サードパーティサービスとの統合を提供します。
ただし、WordPressをヘッドレスCMSとして使用する予定だとします。この場合、主にREST API（またはGraphQL）と相互作用します。フロントエンドの部分は完全に私たちの責任になり、その領域で重い持ち上げを行うためにフォームプラグインに頼ることはできません。今、私たちはフロントエンドになると運転席にいます。
フォームは解決された問題でしたが、今ではそれらについて何をすべきかを決める必要があります。いくつかのオプションがあります：
最も人気のあるフリーフォームプラグインであるフォーム7に連絡すると、提出REST APIエンドポイントがあり、特によく知られている有料プラグイン、重力フォームなどもあります。
技術的な観点からは、フォームのデータをサービスまたはWordPressプラグインによって提供されるエンドポイントに送信することに実際の違いはありません。したがって、さまざまな基準に基づいて決定する必要があります。価格は明らかなものです。その後、WordPressのインストールとそのREST APIの可用性があります。エンドポイントに提出すると、常に公開されていることを前提としています。サービスに関しては、それが利用可能になるために支払うため、それはすでに明らかです。一部のセットアップでは、WordPressアクセスが編集および構築プロセスのみに制限される場合があります。考慮すべきもう1つのことは、特にGPDR規制を順守する方法で、データを保存する場所です。
提出を超えた機能に関しては、WordPressフォームプラグインを一致させるのが難しいです。エコシステム、レポートを生成できるアドオン、PDFS、ニュースレターとの容易に利用できる統合、および支払いサービスがあります。これを単一のパッケージで提供するサービスはほとんどありません。
WordPressテーマに基づいてフロントエンドで「従来の」方法でWordPressを使用しても、フォームプラグインのREST APIを使用すると、多くの場合は意味があります。たとえば、ユーティリティファーストCSSフレームワークを使用してテーマを開発している場合、BEMのようなクラスコンベンションで構成された固定マークアップでレンダリングされたフォームをスタイリングすると、開発者の口に酸味が残ります。
この記事の目的は、2つのWordPressフォームプラグインの提出エンドポイントを提示し、箱から出ることに慣れた典型的なフォーム関連の動作を再現する方法を示すことです。一般に、フォームを提出するときは、2つの主な問題に対処する必要があります。 1つはデータ自体の提出であり、もう1つはユーザーに意味のあるフィードバックを提供しています。
それでは、そこから始めましょう。
データの送信はより簡単な部分です。どちらのエンドポイントもPOSTリクエストを期待しており、URLの動的部分はフォームIDです。
フォーム7のREST APIにお問い合わせください。プラグインがアクティブ化されるとすぐに利用できます。これは次のようになります。
https：//your-site.tld/wp-json/contact-form-7/v1/contact-forms/ <form_id>/フィードバック</form_id>
重力型を使用している場合、エンドポイントはこの形状を取得します。
https：//your-site.tld/wp-json/gf/v2/forms/ <form_id>/submissions</form_id>
重力フォームREST APIはデフォルトで無効になります。それを有効にするには、プラグインの設定に移動してから、REST APIページに移動し、「APIへのアクセスを有効にする」オプションを確認する必要があります。フォーム送信エンドポイントではそれを必要としないため、APIキーを作成する必要はありません。
更新（2024年9月10日）： IDは、フォーム7バージョン5.8に接触していますが、フォームの編集ページのURLにあることがあります。
私たちの例フォームには、次のルールを備えた5つのフィールドがあります。
フォーム7のリクエストのボディキーに連絡するには、フォームタグの構文でそれらを定義する必要があります。
{
「誰かの名」：「マリアン・ケニー」、
「Any-Email」：「[電子メール保護]」、
「空間前」：「1922-03-11」、
「オプションメッセージ」： ""
「faketerms」：「1」
}重力フォームは、キーを異なる形式で期待します。 input_プレフィックスを使用して、自動生成されたインクリメンタルフィールドIDを使用する必要があります。 IDは、フィールドを編集するときに表示されます。
{
「入力_1」：「マリアン・ケニー」、
"input_2"： "[電子メール保護]"、
"input_3"： "1922-03-11"、
"input_4"： ""、
"input_5_1"： "1"
}Inputsの名前属性に期待されるキーを使用すると、多くの作業を節約できます。それ以外の場合は、入力名をキーにマッピングする必要があります。
すべてをまとめると、連絡先フォーム7のためにこのようなHTML構造を取得します。
重力形態の場合、アクションと名前の属性を切り替える必要があります。
必要なすべての情報はHTMLで利用可能であるため、リクエストを送信する準備が整いました。これを行う1つの方法は、FormDataをフェッチと組み合わせて使用することです。
const formsubmissionhandler =（event）=> {
event.preventdefault（）;
const formelement = event.target、
{action、method} = formelement、
body = new formdata（formelement）;
fetch（action、{
方法、
体
}）
.then（（respons）=> respons.json（））
.then（（respons）=> {
//送信が無効かどうかを判断します
if（isformsubmisionerror（response））{
//検証エラーがあるときにケースを処理します
}
//幸せな道を処理します
}）
.catch（（error）=> {
//リクエストに問題があるときにケースを処理します
}）;
};
const formelement = document.queryselector（ "form"）;
formelement.addeventlistener（ "submit"、formsubmissionhandler）;控えめに言っても、ユーザーエクスペリエンスは控えめですが、ほとんどの努力で送信を送信できます。フォームを正常に送信するために、ユーザーにできるだけ多くのガイダンスを提供しています。少なくとも、それは私たちがする必要があることを意味します：
組み込みのHTMLフォーム検証を使用することに加えて、JavaScriptを使用して追加のクライアント側の検証を使用したり、サーバー側の検証を活用したりできます。
サーバー側の検証に関しては、連絡先フォーム7と重力フォームの両方が箱から出して、応答の一部として検証エラーメッセージを返します。 WordPress管理者からの検証ルールを制御できるため、これは便利です。
条件付きフィールド検証などのより複雑な検証ルールの場合、プラグインの設定と同期してフロントエンドJavaScriptの検証を維持することはメンテナンスの問題になる可能性があるため、サーバー側にのみ依存することは理にかなっています。
サーバー側の検証のみを使用する場合、タスクは、応答を解析し、関連するデータを抽出し、要素の挿入やクラス名のトグルなどのDOM操作が抽出されます。
連絡先フォーム7の検証エラーがある場合の応答
{
"の中へ"： "＃"、
「ステータス」：「validation_failed」、
「メッセージ」：「1つ以上のフィールドにエラーがあります。チェックしてもう一度やり直してください。」
「posit_data_hash」： ""
「Invalid_fields」：[
{
"into"： "span.wpcf7-form-control-rap.somebodys-name"、
「メッセージ」：「フィールドが必要です。」、
「idref」：null、
「error_id」： "-ve-somebodys-name"
}、
{
"into"： "span.wpcf7-form-control-rap.any-email"、
「メッセージ」：「フィールドが必要です。」、
「idref」：null、
「error_id」： "-ve-Any-Email"
}、
{
"into"： "span.wpcf7-form-control-rap.before-space-age"、
「メッセージ」：「フィールドが必要です。」、
「idref」：null、
「error_id」： "-ve-be-be-bey-age"
}、
{
"into"： "span.wpcf7-form-control-rap.fake-terms"、
「メッセージ」：「メッセージを送信する前に条件を受け入れる必要があります。」
「idref」：null、
「error_id」： "-ve-fake-terms"
}
]
}提出が成功すると、応答は次のようになります。
{
"の中へ"： "＃"、
「ステータス」：「Mail_Sent」、
「メッセージ」：「メッセージありがとうございます。送信されました。」、
"posit_data_hash"： "d52f9f9de995287195409fe6dcde0c50"
}これと比較して、Gravity Formsの検証エラー応答はよりコンパクトになります。
{
「is_valid」：false、
「validation_messages」：{
「1」：「このフィールドが必要です。」、
「2」：「このフィールドが必要です。」、
「3」：「このフィールドが必要です。」、
「5」：「このフィールドが必要です。」
}、
「page_number」：1、
"source_page_number"：1
}しかし、提出の成功に対する応答はより大きくなります。
{
「is_valid」：本当、
"page_number"：0、
"source_page_number"：1、
"cundimation_message"： "<div id="'gform_confirmation_wrapper_1'" class="'gform_confirmation_wrapper'"> <div class="'gform_confirmation_message_1" g form_confirmation>まもなく。</div> </div> "、
「CONDIMATION_TYPE」：「メッセージ」
}どちらも必要な情報が含まれていますが、共通の条約には従わず、どちらも癖があります。たとえば、重力形式の確認メッセージにはHTMLが含まれており、検証メッセージキーにはinput_プレフィックスがありません。これは、リクエストを送信するときに必要なプレフィックスです。一方、連絡先フォーム7の検証エラーには、フロントエンドの実装にのみ関連する情報が含まれています。フィールドキーはすぐに使用できません。それらを抽出する必要があります。
このような状況では、私たちが得る回答を使用する代わりに、望ましい理想的な形式を考え出すことをお勧めします。それができたら、元の応答を適切と思われるものに変える方法を見つけることができます。 2つのシナリオの中で最高のシナリオを組み合わせて、ユースケースの無関係な部分を削除すると、次のようなものになります。
{
「Issuccess」：False、
「メッセージ」：「1つ以上のフィールドにエラーがあります。チェックしてもう一度やり直してください。」
「ValidationError」：{
「moneyss-name」：「このフィールドが必要です。」、
「Any-Email」：「このフィールドが必要です。」、
「入力_3」：「このフィールドが必要です。」、
「入力_5」：「このフィールドが必要です。」
}
}提出が成功すると、IssuccessをTrueに設定し、空の検証エラーオブジェクトを返します。
{
「Issuccess」：本当、
「メッセージ」：「私たちに連絡してくれてありがとう！まもなくあなたと連絡を取ります。」
「ValidationError」：{}
}今、それは私たちが必要とするものに得たものを変えることの問題です。連絡先フォームを正規化するコード7応答は次のとおりです。
const remormizecontactform7response =（response）=> {
//他の可能なステータスは異なる種類のエラーです
const issuccess = response.status === 'mail_sent';
//すべてのステータスに対してメッセージが提供されます
const message = response.message;
const validationError = insuccess
？ {}
：//オブジェクトの配列をオブジェクトに変換します
Object.fromentries（
Response.invalid_fields.map（（error）=> {
//「CF7-FORM-CONTROL-RAP」の後に部品を抽出します
const key = /cf7 [--az ]* .(.*)/.exec(error.into) [1];
return [key、error.message];
}）
）;
戻る {
Issuccess、
メッセージ、
validationError、
};
};重力を正規化するためのコードは応答を形成します。これは次のとおりです。
const remarizegravityformsResponse =（response）=> {
//応答のブール値としてすでに提供されています
const issuccess = response.is_valid;
const message = issuccess
？ // htmlに包まれていますが、おそらくそれは必要ありません
spriphtml（respons.confirmation_message）
：//一般的なエラーメッセージはないので、フォールバックを設定します
「あなたの提出に問題がありました。」;
const validationError = insuccess
？ {}
：//キーをプレフィックスバージョンに置き換えます。
//この方法で、リクエストと応答が一致します
Object.fromentries（
Object.entries（
Response.Validation_Messages
）.map（（[key、value]）=> [`input _ $ {key}`、value]））
）;
戻る {
Issuccess、
メッセージ、
validationError、
};
};検証エラー、成功メッセージ、およびクラスの切り替えを表示する方法はまだありません。ただし、必要なデータにアクセスするためのきちんとした方法があり、軽い抽象化で応答のすべての矛盾を削除しました。まとめると、既存のコードベースにドロップする準備ができているか、その上に構築を続けることができます。
残りの部分に取り組む方法はたくさんあります。理にかなっているものはプロジェクトに依存します。主に状態の変化に反応しなければならない状況では、宣言的でリアクティブなライブラリが大いに役立ちます。 Alpine.JSはCSS-Tricksでここで取り上げられており、デモンストレーションと生産サイトでの使用の両方に最適です。変更がほとんどなく、前の例からコードを再利用できます。適切な指令を追加し、適切な場所に追加する必要があります。
WordPressフォームプラグインが提供するフロントエンドエクスペリエンスを一致させることは、簡単な、不適切なフォームのために、そしてプロジェクトから再利用可能な方法で比較的簡単に行うことができます。フロントエンドに影響を与えずにプラグインを切り替えることができる方法でそれを達成することさえできます。
確かに、マルチページのフォーム、アップロードされた画像のプレビュー、または通常プラグインに焼き付けられる他の高度な機能を作成するには時間と労力がかかりますが、私たちが満たす必要がある要件をより独特であるほど、特定の問題を解決しようとすることはありません。
WordPressをヘッドレスCMSとして使用して、フォームプラグインのREST APIにアクセスして送信エンドポイントを押すと、より広く使用されているプラクティスになります。それは探求し、心に留めておく価値があるものです。将来的には、主にこのような頭のないコンテキストで動作するように設計されたWordPressフォームプラグインを見ても驚かないでしょう。フロントエンドレンダリングがコアの不可欠な部分ではないアドオン機能であるプラグインを想像できます。それがもたらすものであり、それが商業的に成功する可能性がある場合、どのような結果は探求されるべきですが、進化するのに魅力的な空間です。
以上がWordPress REST APIを使用したヘッドレスフォームの提出の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
