WordPress 사이트를 구축하는 경우 WordPress 양식 플러그인을 선택 하지 않아야 할만한 이유가 필요합니다. 그들은 편리하고 처음부터 구축하기 위해 많은 노력을 기울일 수있는 많은 사용자 정의를 제공합니다. 그들은 HTML을 렌더링하고, 데이터를 검증하고, 제출물을 저장하며, 타사 서비스와 통합을 제공합니다.
그러나 우리가 WordPress를 헤드리스 CMS로 사용할 계획이라고 가정합니다. 이 경우 주로 REST API (또는 GraphQL)와 상호 작용할 것입니다. 프론트 엔드 부분은 전적으로 우리의 책임이되며, 더 이상 양식 플러그인에 의존하여 해당 영역에서 무거운 리프팅을 할 수는 없습니다. 이제 우리는 프론트 엔드와 관련하여 운전석에 있습니다.
형태는 해결 된 문제 였지만 이제는 그들에 대해 무엇을 해야할지 결정해야합니다. 몇 가지 옵션이 있습니다.
가장 인기있는 무료 양식 플러그인 인 Contact Form 7에는 제출 REST API 엔드 포인트가 있으며 잘 알려진 유료 플러그인, 중력 양식도 있습니다.
기술적 인 관점에서 볼 때 양식의 데이터를 서비스 또는 WordPress 플러그인이 제공 한 엔드 포인트에 제출하는 것 사이에는 실질적인 차이가 없습니다. 따라서 우리는 다른 기준에 따라 결정해야합니다. 가격은 분명한 가격입니다. 그 후 WordPress 설치 및 REST API의 가용성이 있습니다. 엔드 포인트에 제출하면 항상 공개적으로 사용할 수 있다고 전제로 제공됩니다. 서비스에 관해서는 이미 분명합니다. 일부 설정은 WordPress 액세스를 편집 및 빌드 프로세스 만 제한 할 수 있습니다. 고려해야 할 또 다른 사항은 데이터를 저장하려는 곳, 특히 GPDR 규정을 준수하는 방식으로 데이터를 저장하는 것입니다.
제출물 이외의 기능과 관련하여 WordPress Form 플러그인은 일치하기 어렵습니다. 그들은 생태계, 보고서를 생성 할 수있는 애드온, PDF, 뉴스 레터와 쉽게 이용 가능한 통합 및 결제 서비스를 보유하고 있습니다. 단일 패키지로 제공하는 서비스는 거의 없습니다.
WordPress 테마를 기반으로 프론트 엔드와 함께 "전통적인"방식으로 WordPress를 사용하더라도 Form Plugin의 REST API를 사용하면 많은 경우에 적합 할 수 있습니다. 예를 들어, 유틸리티 우선 CSS 프레임 워크를 사용하여 테마를 개발하는 경우 BEM과 같은 클래스 컨벤션으로 구성된 고정 마크 업으로 렌더링 된 형태를 스타일링하면 개발자의 입에 신맛이납니다.
이 기사의 목적은 두 개의 WordPress 양식 플러그인 제출 엔드 포인트를 제시하고 상자에서 벗어나는 데 사용했던 일반적인 양식 관련 동작을 재현하는 방법을 보여주는 것입니다. 양식을 제출할 때 일반적으로 두 가지 주요 문제를 처리해야합니다. 하나는 데이터 자체의 제출이고 다른 하나는 사용자에게 의미있는 피드백을 제공하는 것입니다.
그래서, 거기서 시작합시다.
데이터 제출이 더 간단한 부분입니다. 두 엔드 포인트는 게시물 요청을 기대하고 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는 기본적으로 비활성화됩니다. 이를 가능하게하려면 플러그인 설정을 한 다음 나머지 API 페이지로 이동하여 "API에 대한 액세스 활성화"옵션을 확인해야합니다. 양식 제출 엔드 포인트에 필요하지 않으므로 API 키를 만들 필요가 없습니다.
업데이트 (2024 년 9 월 10 일) : ID는 연락처 양식 7 버전 5.8에서 해시되지만 양식 편집 페이지의 URL에서 찾을 수 있습니다.
이 예제 양식에는 다음 규칙이있는 5 개의 필드가 있습니다.
Contact Form 7의 요청의 차체 키의 경우 양식 태그 구문으로 정의해야합니다.
{
"Somebodys-Name": "Marian Kenney",
"모든-메일": "[이메일 보호]",
"공간 전": "1922-03-11",
"선택적 메시지": "",
"가짜 테르스": "1"
}중력 형태는 키를 다른 형식으로 기대합니다. 입력 _ 접두사와 함께 자동 생성 된 증분 필드 ID를 사용해야합니다. 필드를 편집 할 때 ID가 표시됩니다.
{
"Input_1": "Marian Kenney",
"input_2": "[이메일 보호]",
"입력 _3": "1922-03-11",
"input_4": "",
"input_5_1": "1"
}입력 이름 속성에 예상 키를 사용하면 많은 작업을 저장할 수 있습니다. 그렇지 않으면 입력 이름을 키에 매핑해야합니다.
모든 것을 정리하면 연락처 양식 7을 위해 이와 같은 HTML 구조를 얻습니다.
중력 형태의 경우 동작과 이름 속성 만 전환하면됩니다.
필요한 모든 정보는 HTML에서 사용할 수 있으므로 요청을 보낼 준비가되었습니다. 이를 수행하는 한 가지 방법은 FormData를 Fetch와 함께 사용하는 것입니다.
const formsubmissionHandler = (이벤트) => {
event.preventDefault ();
const formelement = event.target,
{action, method} = Formelement,
Body = New FormData (Formelement);
페치 (액션, {
방법,
몸
})
. then ((응답) => response.json ())
. ((응답) => {
// 제출이 유효하지 않은지 결정합니다
if (isformSubmissionError (응답)) {
// 유효성 검사 오류가있을 때 케이스를 처리합니다
}
// 행복한 길을 처리합니다
})
.catch ((오류) => {
// 요청에 문제가있을 때 케이스를 처리합니다.
});
};
const formelement = document.querySelector ( "form");
formelement.addeventListener ( "제출", formsubmissionHandler);우리는 적은 노력으로 제출물을 보낼 수 있지만 사용자 경험은 가장 적게 말합니다. 우리는 가능한 한 많은 지침을 통해 양식을 성공적으로 제출하기 위해 많은 지침을 빚지고 있습니다. 최소한, 그것은 우리가 필요하다는 것을 의미합니다.
내장 HTML 양식 유효성 검증을 사용하는 것 외에도 추가 클라이언트 측 유효성 검사에 JavaScript를 사용하거나 서버 측 유효성 검사를 활용할 수 있습니다.
서버 측 유효성 검사와 관련하여 Contact Form 7 및 Gravity Forms는 상자 밖으로이를 제공하고 응답의 일부로 유효성 검사 오류 메시지를 반환합니다. WordPress 관리자의 검증 규칙을 제어 할 수 있으므로 편리합니다.
조건부 필드 유효성 검증과 같은보다 복잡한 유효성 검사 규칙의 경우 플러그인 설정과 동기화하여 프론트 엔드 JavaScript 검증을 유지하는 것이 유지 보수 문제가 될 수 있기 때문에 서버 측에만 의존하는 것이 합리적 일 수 있습니다.
서버 측 유효성 검사 만 사용하면 작업은 응답을 구문 분석하고 관련 데이터를 추출하고 요소 삽입 및 클래스 이름을 전환하는 것과 같은 DOM 조작에 관한 작업이됩니다.
연락처 양식 7에 대한 유효성 검사 오류가있는 경우 응답은 다음과 같습니다.
{
"안으로": "#",
"상태": "validation_failed",
"메시지": "하나 이상의 필드는 오류가 있습니다. 다시 확인하고 다시 시도하십시오."
"게시 된 _data_hash": "",
"invalid_fields": [
{
"in in": "span.wpcf7-form-control-wrap.somebodys-name",
"메시지": "필드가 필요합니다.",
"Idref": Null,
"ERRER_ID": "-VE-SOMEBODYS-NAME"
},
{
"into": "span.wpcf7-form-control-wrap.any-email",
"메시지": "필드가 필요합니다.",
"Idref": Null,
"error_id": "-Ve-any-Email"
},
{
"in in": "span.wpcf7-form-control-wrap.be ofer-space-age",
"메시지": "필드가 필요합니다.",
"Idref": Null,
"ERRER_ID": "-Ve-be-space-Age"
},
{
"into": "span.wpcf7- 형식-통계-랩 .fake-terms",
"메시지": "메시지를 보내기 전에 이용 약관을 수락해야합니다.",
"Idref": Null,
"error_id": "-Ve-fake-terms"
}
]]
}성공적인 제출시 응답은 다음과 같습니다.
{
"안으로": "#",
"상태": "mail_sent",
"메시지": "메시지 주셔서 감사합니다. 전송되었습니다.",
"게시 된 _data_hash": "D52F9F9DE995287195409FE6DCDE0C50"
}이와 비교하여 중력 형태의 검증 오류 응답이 더 작습니다.
{
"is_valid": 거짓,
"validation_messages": {
"1": "이 필드가 필요합니다.",
"2": "이 필드가 필요합니다.",
"3": "이 필드가 필요합니다.",
"5": "이 필드가 필요합니다."
},
"page_number": 1,
"source_page_number": 1
}그러나 성공적인 제출에 대한 응답은 더 큽니다.
{
"is_valid": true,
"page_number": 0,
"source_page_number": 1,
"volictation_message": "<div id="'gform_confirmation_wrapper_1'class"> <div id="'gform_confirmation_message_1'class" gform_confirmation_message> 우리와 접촉 할 것입니다!
"확인 _type": "메시지"
}<p> 둘 다 우리에게 필요한 정보가 포함되어 있지만 공통 협약을 따르지 않으며 둘 다 단점이 있습니다. 예를 들어, 중력 형식의 확인 메시지에는 HTML이 포함되어 있으며 유효성 검사 메시지 키에는 입력 _ 접두사가 없습니다. 요청을 보낼 때 필요한 접두사입니다. 다른 한편으로, 접촉 양식 7의 유효성 검사 오류에는 프론트 엔드 구현과 관련된 정보가 포함되어 있습니다. 필드 키는 즉시 사용할 수 없습니다. 그들은 추출되어야합니다.</p>
<p> 이와 같은 상황에서, 우리가 얻는 응답으로 작업하는 대신 원하는 이상적인 형식을 생각해내는 것이 좋습니다. 일단 우리가 그것을 갖게되면, 우리는 원래의 응답을 우리가 보는 것에 대한 원래의 응답을 변환 할 수있는 방법을 찾을 수 있습니다. 두 시나리오의 최선을 결합하고 유스 케이스의 관련없는 부품을 제거하면 다음과 같은 것으로 끝납니다.</p>
<pre rel="JSON" data-line=""> {
"issuccess": 거짓,
"메시지": "하나 이상의 필드는 오류가 있습니다. 다시 확인하고 다시 시도하십시오."
"ValidationError": {
"somebodys-name": "이 필드가 필요합니다.",
"모든 에메일": "이 필드가 필요합니다.",
"입력 _3": "이 필드가 필요합니다.",
"입력 _5": "이 필드가 필요합니다."
}
}그리고 성공적인 제출시, 우리는 issuccess를 true로 설정하고 빈 유효성 검사 오류 개체를 반환합니다.
{
"issuccess": 사실,
"메시지": "연락 해주셔서 감사합니다! 곧 연락 드리겠습니다.",
"ValidationError": {}
}이제 그것은 우리가 필요한 것을 우리가 필요로하는 것을 변화시키는 문제입니다. 연락처 양식 7 응답을 정상화하는 코드는 다음과 같습니다.
const normalizeContActForm7Response = (응답) => {
// 다른 가능한 상태는 다른 종류의 오류입니다.
const issuccess = response.status === 'mail_sent';
// 모든 상태에 대한 메시지가 제공됩니다
const 메시지 = response.message;
const validationError = issuccess
? {}
: // 객체 배열을 개체로 변환합니다.
물체.
response.invalid_fields.map ((error) => {
// "CF7- 형식 제어-랩"이후 부품을 추출합니다.
const key = /cf7;-az ]* (.
return [key, error.message];
})
);
반품 {
issuccess,
메시지,
ValidationError,
};
};중력을 정상화하기위한 코드는 반응이 다음과 같습니다.
const normalizegravityformsResponse = (응답) => {
// 이미 응답에서 부울로 제공됩니다
const issuccess = response.is_valid;
const 메시지 = issuccess
? // html로 싸여서 우리는 그것을 필요로하지 않을 것입니다.
striphtml (response.confirmation_message)
: // 일반적인 오류 메시지가 없으므로 폴백을 설정했습니다.
'제출에 문제가있었습니다.';
const validationError = issuccess
? {}
: // 키를 접두사 버전으로 바꿉니다.
// 이렇게하면 요청 및 응답이 일치합니다
물체.
객체.
response.validation_messages
.
);
반품 {
issuccess,
메시지,
ValidationError,
};
};여전히 유효성 검사 오류, 성공 메시지 및 토글 클래스를 표시하는 방법이 여전히 누락되었습니다. 그러나 우리는 필요한 데이터에 액세스 할 수있는 깔끔한 방법을 가지고 있으며 가벼운 추상화로 응답의 모든 불일치를 제거했습니다. 합쳐지면 기존 코드베이스로 떨어질 준비가되었거나 그 위에 계속 구축 할 수 있습니다.
나머지 부분을 다루는 방법에는 여러 가지가 있습니다. 의미가있는 것은 프로젝트에 달려 있습니다. 우리가 주로 상태 변화에 반응 해야하는 상황에서는 선언적이고 반응적인 라이브러리가 많은 도움이 될 수 있습니다. Alpine.js는 CSS- 트릭에서 여기에서 다루었으며 시연과 생산 현장에서 사용하기에 완벽하게 적합합니다. 거의 수정 없이는 이전 예제에서 코드를 재사용 할 수 있습니다. 적절한 지침과 올바른 장소에만 추가하면됩니다.
WordPress Form 플러그인이 제공하는 프론트 엔드 경험과 일치하는 것은 직접적으로 간단하지 않은 형태와 프로젝트에서 프로젝트까지 재사용 할 수있는 방식으로 쉽게 수행 할 수 있습니다. 우리는 프론트 엔드에 영향을 미치지 않고 플러그인을 전환 할 수있는 방식으로이를 달성 할 수도 있습니다.
물론, 다중 페이지 양식, 업로드 된 이미지의 미리보기 또는 플러그인에 일반적으로 구워지는 다른 고급 기능을 만드는 데 시간과 노력이 필요하지만, 우리가 충족해야 할 요구 사항이 고유할수록 제출 엔드 포인트를 사용하는 것이 더 많이 사용되는 것이 더 의미가 있지만, 많은 문제를 해결하려고하지 않지만, 우리가 원하는 것은 아닙니다.
WordPress를 헤드리스 CMS로 사용하여 양식 플러그인의 나머지 API에 액세스하여 제출 엔드 포인트에 도달하는 것이 더 널리 사용되는 연습이됩니다. 탐험하고 명심해야 할 가치가 있습니다. 앞으로 나는 주로 이와 같은 헤드리스 맥락에서 작동하도록 설계된 WordPress 양식 플러그인을보고 놀라지 않을 것입니다. 프론트 엔드 렌더링이 코어의 필수 부분이 아닌 애드온 기능인 플러그인을 상상할 수 있습니다. 어떤 결과와 상업적 성공을 가질 수 있다면, 여전히 탐구해야하지만 진화를 볼 수있는 매혹적인 공간입니다.
위 내용은 WordPress REST API를 사용한 헤드리스 양식 제출의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
