Skip to content

Kõik WordPressist, veebiarendusest — ja mitte ainult

📤 Vormide esitamine peata WordPressis: REST API Contact Form 7 ja Gravity Formsi jaoks

📤 Vormide esitamine peata WordPressis: REST API Contact Form 7 ja Gravity Formsi jaoks

Ehitad saiti WordPressi peal ja kontaktivorm on juba lahendatud. Pluginad nagu Contact Form 7 pakuvad valmis HTML-i, valideerimist, salvestamist ja kümneid integratsioone. Vajuta „Paigalda", kleebi lühikood ja kahe minutiga on kõik valmis.

Kuid kõik muutub, kui WordPressist saab peakata CMS. Sina vastutad kogu esikülje eest: React, Vue, tavaline HTML/JS. Ja vormiplugin, mis varem sinu eest märgendi renderdas, ei kontrolli enam kliendipoolt. Selle REST API on aga endiselt olemas. Saada lihtsalt POST päring õigesse lõpp-punkti ja kogu plugina võimekus (väljade valideerimine, salvestamine, integratsioonid) on sinu käsutuses.

Praktikas saad vormipluginade REST API kaudu katta ka puhtalt „traditsioonilisi" juhtumeid. Oletame, et ehitad kohandatud teemat Tailwindiga ja CF7 fikseeritud märgend oma jäiga klassistruktuuriga tundub võõrkehana. API kaudu esitamine võimaldab sul kontrollida vormi iga pikslit, loobumata plugina väljakujunenud ökosüsteemist.

💡 Kiire ülevaade:

  • Milliseid lõpp-punkte Contact Form 7 ja Gravity Forms pakuvad ning kuidas neid peakata keskkonnas aktiveerida.
  • Millist vormingut väljade saatmisel kasutada, et plugin andmed korrektselt vastu võtaks ja tulemuse tagastaks.
  • Kuidas ehitada HTML-vormi, lisada fetch-päring ja kuvada kasutajale eduteadet või valideerimisvigu.
  • Kuidas ühtlustada CF7 ja Gravity Formsi erinevad vastusevormingud üheks mugavaks struktuuriks.

Mida on vaja lõpp-punktide kohta teada

Andmete saatmine REST API kaudu on tehniliselt lihtne osa. Mõlemad pluginad ootavad POST päringut lõpp-punkti, kus dünaamiline URL-i segment on konkreetse vormi identifikaator.

Contact Form 7 pakub REST API-t kohe pärast aktiveerimist. Lõpp-punkt näeb välja selline:

1https://your-site.tld/wp-json/contact-form-7/v1/contact-forms/<FORM_ID>/feedback

Alates versioonist 5.8 (august 2023) läks Contact Form 7 üle SHA-1 räsitud vormiidentifikaatoritele. Vanad numbrilised ID-d töötavad endiselt, kuid uute vormide puhul tuleb identifikaator võtta halduspaneelis vormi redigeerimislehe URL-ilt (viimane segment pärast post=). 2026. aasta aprilli seisuga on pluginil üle 10 miljoni aktiivse installatsiooni ja see on testitud kuni WordPress 7.0-ni.

Gravity Forms kasutab REST API v2 (saadaval alates versioonist 2.4):

1https://your-site.tld/wp-json/gf/v2/forms/<FORM_ID>/submissions

Oluline märkus: Gravity Formsi REST API on vaikimisi keelatud. Selle aktiveerimiseks mine plugina seadetesse → REST API vahekaart → märgi linnuke „Luba juurdepääs API-le". Vormi esitamise lõpp-punkti jaoks ei ole API võtit vaja, see on olemuselt avalik. Gravity Formsi vormiidentifikaator on numbriline ja redigeerimisel halduspaneelis nähtav.

Päringu keha struktuur

Võtame näidisvormi viie väljaga: kohustuslik tekst, e-post ja kuupäev (enne 4. oktoobrit 1957), valikuline tekstiala ning kohustuslik märkeruut.

Näidiskontaktivorm viie sisestusväljaga

Contact Form 7 eeldab võtmeid vormingus, mis on määratud vormisildi süntaksiga. Võti vastab HTML-is vastava välja name atribuudile:

1{
2 "somebodys-name": "Marian Kenney",
3 "any-email": "[email protected]",
4 "before-space-age": "1922-03-11",
5 "optional-message": "",
6 "fake-terms": "1"
7}

Gravity Forms kasutab teistsugust lähenemist: automaatselt genereeritud järjestikuseid identifikaatoreid eesliitega input_. Välja ID on nähtav otse administraatori paneelis konkreetse välja redigeerimisel.

Gravity Formsi välja muutmine nähtava identifikaatoriga input_3

Sama vormi puhul näeb Gravity Formsi päringu keha välja teistsugune:

1{
2 "input_1": "Marian Kenney",
3 "input_2": "[email protected]",
4 "input_3": "1922-03-11",
5 "input_4": "",
6 "input_5_1": "1"
7}

Peamine järeldus: kui annate oma HTML-i sisenditele name atribuudid, mis vastavad pluginapoolsetele oodatud võtmetele, toimub vastendamine automaatselt ja FormData kogub andmed õiges vormingus ilma käsitsi vastendamiseta.

HTML-i ehitamine ja päringu saatmine

Contact Form 7 puhul näeb HTML-i märgistus välja selline (pange tähele, et action on lõpp-punkt ja väljade name atribuudid vastavad ülaltoodud võtmetele):

1<form action="https://your-site.tld/wp-json/contact-form-7/v1/contact-forms/<FORM_ID>/feedback" method="post">
2 <label for="somebodys-name">Your name</label>
3 <input id="somebodys-name" type="text" name="somebodys-name" required>
4
5 <label for="any-email">Email</label>
6 <input id="any-email" type="email" name="any-email" required>
7
8 <label for="before-space-age">Date</label>
9 <input id="before-space-age" type="date" name="before-space-age" max="1957-10-04" required>
10
11 <label for="optional-message">Message</label>
12 <textarea id="optional-message" name="optional-message"></textarea>
13
14 <label>
15 <input type="checkbox" name="fake-terms" value="1" required>
16 I accept the terms
17 </label>
18
19 <button type="submit">Submit</button>
20</form>

Gravity Formsi puhul muutuvad ainult action ja name atribuudid:

1<form action="https://your-site.tld/wp-json/gf/v2/forms/<FORM_ID>/submissions" method="post">
2 <label for="input_1">Your name</label>
3 <input id="input_1" type="text" name="input_1" required>
4 <!-- ... -->
5</form>

Nüüd saatmisest JavaScriptiga: FormData kogub väärtused name alusel automaatselt, seega pole vastendamist vaja:

1const formSubmissionHandler = (event) => {
2 event.preventDefault();
3
4 const formElement = event.target;
5 const { action, method } = formElement;
6 const body = new FormData(formElement);
7
8 fetch(action, { method, body })
9 .then((response) => response.json())
10 .then((response) => {
11 if (isFormSubmissionError(response)) {
12 // Handle validation errors
13 handleValidationErrors(response);
14 return;
15 }
16 // Successful submission
17 handleSuccess(response);
18 })
19 .catch((error) => {
20 // Network error or server unavailable
21 handleNetworkError(error);
22 });
23};
24
25const formElement = document.querySelector("form");
26formElement.addEventListener("submit", formSubmissionHandler);

Andmed on saadetud. Kuid sellest kasutajale ei piisa; nad vajavad tagasisidet: eduteadet, vigadega väljade esiletõstmist, üldist teavitust. Õnneks tagastavad mõlemad pluginad selle teabe vastuses.

Valideerimine: server otsustab, klient kuvab

Lisaks sisseehitatud HTML5 valideerimisele (atribuudid nagu required, type="email" ja max) on mõistlik tugineda serveripoolsele reeglikontrollile, mida pluginad pakuvad. Põhjus: reeglid on konfigureeritud tsentraalselt WordPressi administraatoris ja nende dubleerimine kliendil tähendab topelttööd ning ebakõlade allikat.

Nii Contact Form 7 kui ka Gravity Forms tagastavad valideerimisvead otse vastuse kehas. Keerukate stsenaariumide puhul (tingimuslikud väljad, sõltuv valideerimine) on serveripoolsele valideerimisele tuginemine eriti kasulik: te ei pea loogikat frontendi ja pluginaseadete vahel sünkroniseerima.

Ülesanne taandub kolmele sammule: JSON-vastuse parsimine, veateadete eraldamine ja nende DOM-i sisestamine vastavate väljade kõrvale.

Vastuse vormingud ja normaliseerimine

Contact Form 7 vastus valideerimisvea korral:

1{
2 "into": "#",
3 "status": "validation_failed",
4 "message": "One or more fields have an error. Please check and try again.",
5 "posted_data_hash": "",
6 "invalid_fields": [
7 {
8 "into": "span.wpcf7-form-control-wrap.somebodys-name",
9 "message": "The field is required.",
10 "idref": null,
11 "error_id": "-ve-somebodys-name"
12 }
13 ]
14}

Edu korral on vastus kompaktsem:

1{
2 "into": "#",
3 "status": "mail_sent",
4 "message": "Thank you for your message. It has been sent.",
5 "posted_data_hash": "d52f9f9de995287195409fe6dcde0c50"
6}

Gravity Formsi vastus valideerimisvea korral on üles ehitatud teisiti:

1{
2 "is_valid": false,
3 "validation_messages": {
4 "1": "This field is required.",
5 "2": "This field is required.",
6 "3": "This field is required.",
7 "5": "This field is required."
8 },
9 "page_number": 1,
10 "source_page_number": 1
11}

Ja edukas vastus sisaldab kinnitust HTML-i sees:

1{
2 "is_valid": true,
3 "page_number": 0,
4 "source_page_number": 1,
5 "confirmation_message": "<div>Thanks for contacting us! We will get in touch with you shortly.</div>",
6 "confirmation_type": "message"
7}

Lähenemiste erinevus on ilmne: CF7 manustab vead CSS-selektoritega objektide massiivi, samas kui Gravity Forms kasutab lamedat objekti numbriliste võtmetega ilma input_ eesliiteta. Gravity Formsi eduteade tuleb HTML-i mähituna. CF7 vastuste väljavõtmed on manustatud selektoritesse (nt span.wpcf7-form-control-wrap.somebodys-name) ja nõuavad regulaaravaldise abil eraldamist.

Iga plugina jaoks eraldi loogika kirjutamise asemel on mugavam normaliseerida mõlemad vastused ühtsele vormingule:

1{
2 "isSuccess": false,
3 "message": "One or more fields have an error. Please check and try again.",
4 "validationError": {
5 "somebodys-name": "The field is required.",
6 "any-email": "The field is required.",
7 "input_3": "The field is required.",
8 "input_5": "This field is required."
9 }
10}

Edu korral seatakse isSuccess väärtuseks true ja validationError on tühi objekt.

Normaliseerimiskood Contact Form 7 jaoks:

1const normalizeContactForm7Response = (response) => {
2 const isSuccess = response.status === 'mail_sent';
3 const message = isSuccess
4 ? response.message
5 : response.message || 'One or more fields have an error.';
6
7 const validationError = isSuccess
8 ? {}
9 : Object.fromEntries(
10 response.invalid_fields.map((error) => {
11 const key = /cf7[-a-z]*.(.*)/.exec(error.into)[1];
12 return [key, error.message];
13 })
14 );
15
16 return { isSuccess, message, validationError };
17};

Normaliseerimiskood Gravity Formsi jaoks (pane tähele: veavõtmetele lisatakse input_ eesliide, et need ühtiksid päringu võtmetega):

1const normalizeGravityFormsResponse = (response) => {
2 const isSuccess = response.is_valid;
3 const message = isSuccess
4 ? stripHtml(response.confirmation_message)
5 : 'There was a problem with your submission.';
6
7 const validationError = isSuccess
8 ? {}
9 : Object.fromEntries(
10 Object.entries(response.validation_messages).map(([key, value]) => [
11 `input_${key}`,
12 value,
13 ])
14 );
15
16 return { isSuccess, message, validationError };
17};

Nüüd on sul ühtne vastuseobjekt olenemata pluginast. Jääb üle vaid kirjutada veateadete kuvamine ja klasside ümberlülitamine DOM-elementidel ning vorm ongi kasutamiseks valmis.

Normaliseerimisest elava liideseni

Kui vastus on teisendatud ühtsele struktuurile, taandub tagasiside kuvamine DOM-i manipuleerimisele. Veateate lisamine välja kõrvale, klassi ümberlülitamine ümbrisel ja üldise teavituse näitamine: neist kolmest toimingust piisab valdavale enamusele stsenaariumitest.

Reaktiivsete liideseuuenduste jaoks on mugavad kerged deklaratiivsed teegid nagu Alpine.js. Minimaalne süntaks, ehitussammuta ja loomulik integreeritus serverivastustega teevad sellest praktilise valiku vormide jaoks peakeskkonnas. Alpine.js-i lähenemist käsitleti põhjalikult CSS-Tricksis; selle materjali kood töötab peaaegu muutmata kujul koos ülal saadud normaliseeritud vastusega.

Kokkuvõte

Kliendipoolse funktsionaalsuse taasesitamine, mida vormipluginad pakuvad „karbist välja", on lihtsate vormide puhul paar tundi tööd. Üks meeldiv boonus: kui abstraheerida vastus normaliseerimisfunktsiooni kaudu, saad vahetatava taustasüsteemi. Contact Form 7-lt Gravity Formsile (või vastupidi) üleminek on võimalik ilma esikülje muudatusteta; asenda lihtsalt lõpp-punkt ja normaliseerimisfunktsioon.

Mitmeleheküljelised vormid, üleslaaditud piltide eelvaated, hinnakalkulaatorid: jah, see on tõsine arendustöö. Kuid mida unikaalsemad on projekti nõuded, seda tugevam on argument kohandatud esikülje kasuks REST API baasil: sa ei võitle kellegi teise märgendi vastu ega tee mööndusi valmis renderduse piirangute tõttu.

Vormide „headless" lähenemine ei ole hüpoteetiline tulevik. Täna pakuvad pluginad nagu Contact Form 7 ja Gravity Forms täisfunktsionaalseid REST API-sid ning esikülje raamistikud võimaldavad vormi ehitada tundide, mitte päevadega. Proovi seda oma järgmises projektis, kus vormi välimus on kriitiline: kasuta CF7 või GF-i taustasüsteemina ja ehita liides nullist. Tõenäoliselt üllatad, kui lihtne see on.

⁉️🤔 Korduma kippuvad küsimused

Kas Contact Form 7 REST API töötab tasuta versiooniga?

Jah, REST API on saadaval kohe pärast tasuta pluginat aktiveerimist; lisakonfiguratsiooni pole vaja. 2026. aasta aprilli seisuga on Contact Form 7-l üle 10 miljoni aktiivse installatsiooni ja REST API on olnud pluginatuuma stabiilne osa alates versioonist 4.8.

Mis on teisiti räsitud vormi-ID-dega Contact Form 7 uuemates versioonides?

Alates versioonist 5.8 (august 2023) genereerib CF7 vormi identifikaatorina numbrilise ID asemel SHA-1 räsi. Vanad numbrilised ID-d töötavad endiselt. Räsi leiad halduspaneelil vormi redigeerimise lehe URL-ilt: /wp-admin/admin.php?page=wpcf7&post=<HASH>&action=edit. See asendatakse lõpp-punktis samamoodi nagu numbriline ID.

Kas Gravity Forms REST API kaudu vormide saatmiseks on vaja API võtit?

Ei, /gf/v2/forms/<ID>/submissions lõpp-punkt ei nõua saatmiseks autentimist. Küll aga on Gravity Forms REST API ise vaikimisi keelatud; selle peab pluginaseadetes lubama (Forms → Settings → REST API → Enable access to the API).

Kas sama JavaScripti koodi saab kasutada nii Contact Form 7 kui ka Gravity Forms puhul?

Jah, just selleks ongi vastuse normaliseerimine. Mõlemad normaliseerimisfunktsioonid (CF7 ja GF jaoks) tagastavad sama struktuuriga objekti: isSuccess, message ja validationError väljad. Ühenda õige funktsioon sõltuvalt pluginast ja kogu ülejäänud kood (veateated, väljade esiletõstmine, üldine teavitus) töötab muudatusteta.

Mida teha, kui vorm ei saada ja server tagastab 404 vea?

Kontrolli kolme asja: kas plugin REST API on lubatud (eriti oluline Gravity Forms puhul), kas vormi identifikaator lõpp-punkti URL-is on õige ja kas REST API-d ei blokeerita serveri tasemel või mõne turvaplugina poolt. Contact Form 7 puhul veendu ka, et WordPress REST API on globaalselt aktiivne; ilma selleta ei saa CF7 AJAX-saatmisi töödelda.