Penyerahan borang tanpa kepala dengan API REST WordPress

Jika anda membina tapak WordPress, anda memerlukan alasan yang baik untuk tidak memilih plugin Borang WordPress. Mereka mudah dan menawarkan banyak penyesuaian yang akan mengambil satu usaha untuk membina dari awal. Mereka menjadikan HTML, mengesahkan data, menyimpan penyerahan, dan memberikan integrasi dengan perkhidmatan pihak ketiga.

Tetapi katakan kami merancang untuk menggunakan WordPress sebagai CMS tanpa kepala. Dalam kes ini, kami akan berinteraksi dengan API REST (atau GraphQL). Bahagian front-end menjadi tanggungjawab kami sepenuhnya, dan kami tidak boleh bergantung lagi pada plugin borang untuk melakukan pengangkat berat di kawasan itu. Sekarang kita berada di tempat duduk pemandu ketika datang ke hujung depan.

Borang adalah masalah yang diselesaikan, tetapi sekarang kita perlu memutuskan apa yang perlu dilakukan terhadap mereka. Kami mempunyai beberapa pilihan:

• Adakah kita menggunakan API tersuai kita sendiri jika kita mempunyai perkara sedemikian? Jika tidak, dan kami tidak mahu membuatnya, kami boleh pergi dengan perkhidmatan. Terdapat banyak penyedia bentuk statik yang baik, dan yang baru muncul secara berterusan.
• Bolehkah kita terus menggunakan plugin WordPress yang telah kita gunakan dan memanfaatkan pengesahan, penyimpanan, dan integrasi?

Plugin bentuk percuma yang paling popular, Borang Hubungan 7, mempunyai titik akhir API REST penyerahan, dan begitu juga plugin berbayar yang terkenal, Borang Graviti, antara lain.

Dari segi teknikal, tidak ada perbezaan yang nyata antara mengemukakan data borang ke titik akhir yang disediakan oleh perkhidmatan atau plugin WordPress. Oleh itu, kita perlu membuat keputusan berdasarkan kriteria yang berbeza. Harga adalah yang jelas; Selepas itu adalah ketersediaan pemasangan WordPress dan API REST. Mengemukakan kepada titik akhir mengandaikan bahawa ia sentiasa tersedia secara terbuka. Itu sudah jelas ketika datang ke perkhidmatan kerana kami membayar mereka untuk tersedia. Sesetengah persediaan mungkin mengehadkan akses WordPress kepada hanya mengedit dan membina proses. Satu lagi perkara yang perlu dipertimbangkan adalah di mana anda ingin menyimpan data, terutamanya dengan cara yang mematuhi peraturan GPDR.

Ketika datang ke ciri -ciri di luar penyerahan, plugin bentuk WordPress sukar dipadankan. Mereka mempunyai ekosistem mereka, tambahan yang mampu menghasilkan laporan, PDF, integrasi yang sedia ada dengan surat berita, dan perkhidmatan pembayaran. Beberapa perkhidmatan menawarkan banyak ini dalam satu pakej.

Walaupun kita menggunakan WordPress dengan cara "tradisional" dengan hujung depan berdasarkan tema WordPress, menggunakan API REST plugin bentuk mungkin masuk akal dalam banyak kes. Sebagai contoh, jika kita sedang membangunkan tema menggunakan kerangka CSS pertama utiliti, menggayakan borang yang diberikan dengan markup tetap yang berstruktur dengan konvensyen kelas seperti BEM meninggalkan rasa masam di mana-mana mulut pemaju.

Tujuan artikel ini adalah untuk membentangkan dua titik akhir penyerahan Plugin WordPress dan menunjukkan cara untuk mencipta tingkah laku yang berkaitan dengan bentuk biasa yang kami gunakan untuk keluar dari kotak. Apabila menyerahkan borang, secara umum, kita perlu menangani dua masalah utama. Satu adalah penyerahan data itu sendiri, dan yang lain memberikan maklum balas yang bermakna kepada pengguna.

Jadi, mari kita mulakan di sana.

Titik akhir

Mengemukakan data adalah bahagian yang lebih mudah. Kedua -dua titik akhir mengharapkan permintaan pos, dan bahagian dinamik URL adalah ID bentuk.

Hubungi Borang 7 REST API tersedia dengan segera apabila plugin diaktifkan, dan ia kelihatan seperti ini:

 https: //your-site.tld/wp-json/contact-form-7/v1/contact-forms/ <form_id>/maklum balas</form_id>

Jika kita bekerja dengan bentuk graviti, titik akhir mengambil bentuk ini:

 https: //your-site.tld/wp-json/gf/v2/forms/ <form_id>/penyerahan</form_id>

API REST Forms Gravity dilumpuhkan secara lalai. Untuk membolehkannya, kita perlu pergi ke tetapan plugin, kemudian ke halaman API REST, dan periksa pilihan "Dayakan Akses ke API". Tidak perlu membuat kunci API, kerana titik akhir penyerahan bentuk tidak memerlukannya.

UPDATE (Sep. 10, 2024): IDS adalah hashed dalam Borang Kenalan 7 versi 5.8, tetapi masih boleh didapati di URL halaman penyuntingan borang.

Badan permintaan

Borang contoh kami mempunyai lima bidang dengan peraturan berikut:

• medan teks yang diperlukan
• medan e -mel yang diperlukan
• medan tarikh yang diperlukan yang menerima tarikh sebelum 4 Oktober 1957
• Textarea pilihan
• kotak semak yang diperlukan

Untuk kekunci badan Permintaan Borang 7, kita perlu menentukannya dengan sintaks bentuk-tag:

 {
  "Nama Seseorang": "Marian Kenney",
  "Mana-mana-Email": "[E-mel dilindungi]",
  "Sebelum-Ruang-usia": "1922-03-11",
  "Mesin pilihan": "",
  "Jangka Palsu": "1"
}

Borang graviti menjangkakan kunci dalam format yang berbeza. Kami perlu menggunakan ID medan tambahan yang dijana, dengan prefix input_. ID dapat dilihat apabila anda menyunting medan.

 {
  "input_1": "Marian Kenney",
  "input_2": "[dilindungi e -mel]",
  "input_3": "1922-03-11",
  "input_4": "",
  "input_5_1": "1"
}

Mengemukakan data

Kita boleh menyelamatkan diri kita banyak kerja jika kita menggunakan kekunci yang diharapkan untuk atribut nama input. Jika tidak, kita perlu memetakan nama input ke kunci.

Meletakkan semuanya bersama -sama, kami mendapat struktur HTML seperti ini untuk Borang Kenalan 7:

nama seseorang Hantar

Dalam kes borang graviti, kita hanya perlu menukar tindakan dan atribut nama:

Nama seseorang Hantar

Oleh kerana semua maklumat yang diperlukan tersedia di HTML, kami bersedia menghantar permintaan tersebut. Salah satu cara untuk melakukan ini ialah menggunakan Formdata dalam kombinasi dengan pengambilan:

 const formSubmissionHandler = (event) => {
  event.PreventDefault ();

  const formElement = event.target,
    {tindakan, kaedah} = formElement,
    badan = formData baru (formElement);

  ambil (tindakan, {
    kaedah,
    badan
  })
    .the (response) => response.json ())
    .THEN ((respons) => {
      // Tentukan sama ada penyerahan tidak sah
      jika (isformSubmissionError (respons)) {
        // Mengendalikan kes apabila terdapat ralat pengesahan
      }
      // Mengendalikan jalan gembira
    })
    .catch ((error) => {
      // mengendalikan kes apabila ada masalah dengan permintaan
    });
};

const formElement = document.QuerySelector ("Form");

formElement.AddeventListener ("submit", formSubmissionHandler);

Kami boleh menghantar penyerahan dengan sedikit usaha, tetapi pengalaman pengguna adalah subpar, untuk mengatakan paling sedikit. Kami berhutang kepada pengguna sebanyak mungkin untuk menyerahkan borang dengan jayanya. Sekurang -kurangnya, ini bermakna kita perlu:

• Tunjukkan ralat global atau mesej kejayaan,
• Tambahkan mesej ralat pengesahan medan dalam talian dan arah yang mungkin, dan
• menarik perhatian kepada bahagian -bahagian yang memerlukan perhatian dengan kelas khas.

Pengesahan medan

Di samping menggunakan pengesahan borang HTML terbina dalam, kami boleh menggunakan JavaScript untuk pengesahan sampingan pelanggan tambahan dan/atau mengambil kesempatan daripada pengesahan sisi pelayan.

Apabila ia datang kepada pengesahan sisi pelayan, kedua-dua borang hubungan 7 dan borang graviti menawarkan keluar dari kotak dan mengembalikan mesej ralat pengesahan sebagai sebahagian daripada respons. Ini mudah kerana kita dapat mengawal peraturan pengesahan dari admin WordPress.

Untuk peraturan pengesahan yang lebih kompleks, seperti pengesahan medan bersyarat, mungkin masuk akal untuk bergantung hanya pada sisi pelayan kerana mengekalkan pengesahan JavaScript depan selaras dengan tetapan plugin boleh menjadi isu penyelenggaraan.

Jika kita hanya pergi dengan pengesahan sisi pelayan, tugas menjadi mengenai menghuraikan respons, mengekstrak data yang berkaitan, dan manipulasi DOM seperti memasukkan unsur-unsur dan togol-nama kelas.

Mesej respons

Tanggapan apabila terdapat ralat pengesahan untuk Borang Kenalan 7 kelihatan seperti ini:

 {
  "ke": "#",
  "Status": "validation_failed",
  "Mesej": "Satu atau lebih bidang mempunyai ralat. Sila periksa dan cuba lagi.",
  "Posted_data_hash": "",
  "Invalid_fields": [
    {
      "ke dalam": "span.wpcf7-form-control-wrap.somebodys-name",
      "Mesej": "Bidang diperlukan.",
      "Idref": null,
      "error_id": "-ve-somebodys-name"
    },
    {
      "ke dalam": "span.wpcf7-form-control-wrap.any-email",
      "Mesej": "Bidang diperlukan.",
      "Idref": null,
      "error_id": "-ve-any-email"
    },
    {
      "ke dalam": "span.wpcf7-form-control-wrap.before-space-age",
      "Mesej": "Bidang diperlukan.",
      "Idref": null,
      "error_id": "-ve-sebelum-ruang-usia"
    },
    {
      "ke dalam": "span.wpcf7-form-control-wrap.fake-term",
      "Mesej": "Anda mesti menerima terma dan syarat sebelum menghantar mesej anda.",
      "Idref": null,
      "error_id": "-ve-fake-term"
    }
  ]
}

Pada penyerahan yang berjaya, respons kelihatan seperti ini:

 {
  "ke": "#",
  "Status": "mail_sent",
  "Mesej": "Terima kasih atas mesej anda. Ia telah dihantar.",
  "Posted_data_hash": "D52F9F9DE995287195409FE6DCDE0C50"
}

Berbanding dengan ini, tindak balas ralat pengesahan bentuk graviti lebih padat:

 {
  "is_valid": palsu,
  "validation_messages": {
    "1": "bidang ini diperlukan.",
    "2": "Bidang ini diperlukan.",
    "3": "Bidang ini diperlukan.",
    "5": "Bidang ini diperlukan."
  },
  "Page_Number": 1,
  "source_page_number": 1
}

Tetapi respons mengenai penyerahan yang berjaya lebih besar:

 {
  "is_valid": Benar,
  "Page_Number": 0,
  "source_page_number": 1,
  "pengesahan_message": "<div id="'gform_confirmation_wrapper_1'" class="'gform_confirmation_wrapper'"> <div id="'gform_confirmation_message_1'" class="'gform_confirmation_message_1" gorm_confirmation_message tidak lama lagi.> </div> ",
  "Pengesahan_type": "Mesej"
}<p> Walaupun kedua -duanya mengandungi maklumat yang kami perlukan, mereka tidak mengikuti konvensyen yang sama, dan kedua -duanya mempunyai kebiasaan mereka. Sebagai contoh, mesej pengesahan dalam bentuk graviti mengandungi HTML, dan kunci mesej pengesahan tidak mempunyai awalan input_ - awalan yang diperlukan apabila kami menghantar permintaan. Di sisi lain, kesilapan pengesahan dalam Borang Kenalan 7 mengandungi maklumat yang hanya berkaitan dengan pelaksanaan front-end mereka. Kekunci medan tidak dapat digunakan dengan segera; Mereka perlu diekstrak.</p>
<p> Dalam keadaan seperti ini, bukannya bekerja dengan respons yang kami dapat, lebih baik untuk menghasilkan format yang diinginkan dan ideal. Sebaik sahaja kita mempunyai itu, kita dapat mencari cara untuk mengubah respons asal terhadap apa yang kita lihat patut. Jika kita menggabungkan yang terbaik dari dua senario dan mengeluarkan bahagian yang tidak relevan untuk kes penggunaan kita, maka kita berakhir dengan sesuatu seperti ini:</p>
<pre rel="JSON" data-line=""> {
  "Issuccess": palsu,
  "Mesej": "Satu atau lebih bidang mempunyai ralat. Sila periksa dan cuba lagi.",
  "ValidationError": {
    "Seseorang-nama": "Bidang ini diperlukan.",
    "Mana-mana-Email": "Bidang ini diperlukan.",
    "Input_3": "Bidang ini diperlukan.",
    "Input_5": "Bidang ini diperlukan."
  }
}

Dan pada penyerahan yang berjaya, kami akan menetapkan issuccess kepada benar dan mengembalikan objek ralat pengesahan kosong:

 {
  "Issuccess": Benar,
  "Mesej": "Terima kasih kerana menghubungi kami! Kami akan menghubungi anda tidak lama lagi.",
  "ValidationError": {}
}

Sekarang ini adalah masalah mengubah apa yang kita perlukan. Kod untuk menormalkan Borang Kenalan 7 Respons adalah ini:

 const normalIzeContactForm7Response = (response) => {
  // status lain yang mungkin adalah jenis kesilapan yang berbeza
  const issuccess = response.status === 'mail_sent';
  // Mesej disediakan untuk semua status
  const message = response.message;
  const validationError = issuccess
    ? {}
    : // kami mengubah pelbagai objek ke dalam objek
    Objek.Fromentries (
      response.invalid_fields.map ((error) => {
        // Ekstrak bahagian selepas "CF7-Form-Control-Wrap"
        const key = /cf7:- AZ 8 .(.*)/.exec(Error.into);

        kembali [kunci, error.message];
      })
    );

  kembali {
    issuccess,
    mesej,
    ValidationError,
  };
};

Kod untuk menormalkan bentuk graviti tindak balas angin menjadi ini:

 const normalizeGravityFormsResponse = (response) => {
  // disediakan sebagai boolean dalam respons
  const issuccess = response.is_valid;
  mesej const = issuccess
    ? // datang dibalut dengan html dan kami mungkin tidak memerlukannya
      striphtml (response.confirmation_message)
    : // tiada mesej ralat umum, jadi kami menetapkan sandaran balik
      'Ada masalah dengan penyerahan anda.';
  const validationError = issuccess
    ? {}
    : // Kami menggantikan kunci dengan versi prefixed;
      // dengan cara ini permintaan dan tindak balas perlawanan
      Objek.Fromentries (
        Objek.entries (
            response.validation_messages
        ) .map (([kunci, nilai]) => [`input _ $ {key}`, nilai])
      );

  kembali {
    issuccess,
    mesej,
    ValidationError,
  };
};

Kami masih kehilangan cara untuk memaparkan kesilapan pengesahan, mesej kejayaan, dan kelas togol. Walau bagaimanapun, kami mempunyai cara yang kemas untuk mengakses data yang kami perlukan, dan kami mengeluarkan semua ketidakkonsistenan dalam respons dengan abstraksi cahaya. Apabila disatukan, ia sudah siap untuk dijatuhkan ke dalam pangkalan kod sedia ada, atau kami boleh terus membina di atasnya.

Terdapat banyak cara untuk menangani bahagian yang tinggal. Apa yang masuk akal bergantung kepada projek. Untuk situasi di mana kita perlu bertindak balas terhadap perubahan negara, perpustakaan deklaratif dan reaktif dapat membantu banyak. Alpine.js diliputi di sini pada trik CSS, dan ia sesuai untuk kedua-dua demonstrasi dan menggunakannya di tapak pengeluaran. Hampir tanpa sebarang pengubahsuaian, kita boleh menggunakan semula kod dari contoh sebelumnya. Kami hanya perlu menambah arahan yang betul dan di tempat yang betul.

Membungkus

Memadankan pengalaman front-end yang disediakan oleh plugin borang WordPress boleh dilakukan dengan mudah untuk bentuk yang mudah, tidak membingungkan-dan dengan cara yang boleh diguna semula dari projek ke projek. Kita juga boleh mencapainya dengan cara yang membolehkan kita menukar plugin tanpa menjejaskan bahagian depan.

Pasti, ia memerlukan masa dan usaha untuk membuat bentuk multi-halaman, pratonton imej yang dimuat naik, atau ciri-ciri canggih lain yang biasanya kami bakar terus ke dalam plugin, tetapi semakin unik keperluan yang perlu kita temui, lebih masuk akal untuk menggunakan titik akhir penyerahan kerana kita tidak perlu bekerja melawan pelaksanaan depan yang diberikan untuk menyelesaikan banyak masalah, tetapi tidak pernah kita dapat menyelesaikan banyak masalah, tetapi tidak pernah kita dapat menyelesaikan banyak masalah, tetapi tidak pernah kita dapat menyelesaikan banyak masalah, tetapi tidak pernah kita dapat menyelesaikan banyak masalah, tetapi tidak pernah kita dapat menyelesaikan masalah,

Menggunakan WordPress sebagai CMS tanpa kepala untuk mengakses API REST plugin borang untuk memukul titik akhir penyerahan pasti akan menjadi amalan yang lebih banyak digunakan. Ini sesuatu yang patut diterokai dan diingat. Pada masa akan datang, saya tidak akan terkejut melihat plugin bentuk WordPress yang direka terutamanya untuk bekerja dalam konteks tanpa kepala seperti ini. Saya boleh bayangkan plugin di mana rendering front-end adalah ciri tambahan yang bukan sebahagian daripada terasnya. Apa akibat yang akan ada, dan jika ia dapat mencapai kejayaan komersial, masih akan diterokai tetapi merupakan ruang yang menarik untuk menonton berevolusi.

Atas ialah kandungan terperinci Penyerahan borang tanpa kepala dengan API REST WordPress. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!