Selles postituses püüan luua ülevaate sellest, kuidas luua kohandatud REST API lõpp-punkte ja täita nende jaoks taotlusi kohandatud Gutenbergi plokis. See tähendab, et taotluste fetchesitamine meetoditega teabe saamiseks, mis pole WordPressi registreeritud andmepoodides saadaval.
Sõbralik meeldetuletus: suurem osa põhiteavet on WordPressi andmepoodides juba saadaval. Näiteks postituste, lehtede, kohandatud postitustüüpide, taksonoomiate, autorite, meediumide ja muu kohta põhipäringud on saadaval ilma oma kohandatud lõpp-punktide loomiseta. Nendele poodidele juurdepääsuks kasutaksite pigem WordPressi põhiandmemoodulit (withSelectja select()). Allpool on õpetuse osa, mis annab põhjaliku ülevaate, kuidas seda teha.
WordPress REST API
Kui sa veel ei teadnud; WordPress REST API on JSON-liides teie WordPressi saidi andmete saatmiseks ja vastuvõtmiseks. Seda saab kasutada väliselt või sisemiselt. Gutenbergi redaktori ja Javascriptile üleminekuga on REST API kasutusalad kindlasti suurenenud. WordPress REST API-l on terve hulk lõpp-punkte, mida saame kasutada. Vaadake siit täielikku viidet kõigi REST API lõpp-punktide kohta. Leiad näiteks lõpp-punktid postitustele ja enamikule muule sisesisule – nii lugemiseks kui ka värskendamiseks. Teema või pistikprogrammi arendajad saavad registreerida oma kohandatud lõpp-punktid.
Teie WordPressi saidil on juur REST API URL, mis asub vaikimisi aadressil <your domain>/wp-json. Näiteks URL-iga kohalik WordPress http://localhost/wordpress/pääseb juurde REST API-le aadressil http://localhost/wordpress/wp-json. Sealt peame lisama lõpp-punktid. Viidates ülaltoodud lõpp-punktide viitele, saame hankida lõpp-punkti viimaste postituste loendi /wp/v2/posts. See tähendab, et kui lähete http://localhost/wordpress/wp-json/wp/v2/postsoma brauseris aadressile, saate oma WordPressi saidi viimaste postituste kohta JSON-vormingus vastuse.
Märkus nimeruumide kohta on õige. REST API URL algab nimeruumiga (" wp/v2" on WordPressi nimeruum, nagu on näha ülaltoodud URL-ide näites). Nimeruumid on kontseptsioon, mis aitab vältida kokkupõrkeid WordPressi tuumas, teemades ja pistikprogrammides, mis lisavad sama nimega lõpp-punkte. Looge oma ainulaadne nimeruum, mis on tavaliselt teie teema või pistikprogrammi nime vorm. Pärast nälkja on üldreegel versiooninumbri lisamine, mis algab tavaliselt versioonist 1. Näiteks on minu teema näpunäide " awhitepixel", nii et kui ma peaksin oma teemas kohandatud lõpp-punkte looma, kasutaksin nimeruumi " awhitepixel/v1". Selle nimeruumiga saaksin registreerida lõpp-punkti " posts" ja see ei tekita probleeme, kuigi see on identne WordPressi lõpp-punkti nimega.
REST API-ga töötamine WordPressis on suur teema, mis sisaldab palju head teavet. Selles postituses keskendun Gutenbergi redaktori kasutatavusele ja sellele, kuidas neid Javascriptis alla laadida.
Mida me teeme ja mida vajame
Kohandatud teabe taotlemise kasutatavusel on lai valik kasutusjuhtumeid, nii et tavaliselt peate allolevaid koodinäiteid oma vajadustele vastavaks kohandama. Andmed võivad olla kohandatud postituspäring, kohandatud SQL-päring või midagi muud.
Kui loome kohandatud lõpp-punkti, on meil täielik kontroll selle tagastamise üle. Saame WordPressis/PHP-s teha mis tahes toiminguid ja päringuid ning edastada selle edasi JSON-ina. Ja meie Gutenbergi plokis saame selle tagastuse hankida ja teha sellega ploki editfunktsiooni raames, mida tahame. Tavaliselt kasutate andmeid lõppkasutajale valiku või teabe esitamiseks plokiredaktoris, kuid saate ka selle teabe edasiseks kasutamiseks oma plokki salvestada. Saate nende andmete jaoks luua ka oma kohandatud poed, kuid ma ei hakka seda tegema.
Oletan, et olete juba tuttav kohandatud Gutenbergi plokkide loomisega, nii et ma ei käsitle seda siin üksikasjalikult.
REST API lõpp-punkti loomine
Kohandatud REST API lõpp-punkti registreerimine toimub PHP-s. Lisage see kood oma teemasse functions.phpvõi aktiivsesse pistikprogrammi koodi. Ühendage funktsioon toiminguga rest_api_initja käivitage funktsioon [register_rest_route](https://developer.wordpress.org/reference/functions/register_rest_route/)()iga lõpp-punkti jaoks, mille soovite registreerida.
Esitage oma nimeruum esimese parameetrina, lõpp-punkti marsruut teisena ja seadete massiiv kolmanda parameetrina register_rest_route(). Neljas parameeter määrab, kas soovite olemasoleva marsruudi alistada või mitte; mitte midagi, mida me siin vaatame. Kolmanda parameetri massiivis peaksite atribuudi " callback" määrama vähemalt funktsioonile, mis vastutab lõpp-punkti andmete tagastamise eest. Tavaline on ka ‘ ‘ määramine method, nt lõpp-punkti määramine ‘ GET‘, ‘ POST‘, ‘ PUT‘ jne.
Alustame lihtsa lõpp-punkti registreerimisega;
Minu teema nimeruum on " awhitepixel/v1" ja ma registreerin mydataselles nimeruumis lõpp-punkti " ". See tähendab, et pääsen juurde oma kohandatud REST API-le aadressil http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.
REST API marsruutide registreerimisel (või muutmisel) peate selle toimimiseks loputama oma püsilingid. Seda saate teha, külastades Seaded> Püsilingid ja klõpsake lihtsalt nuppu Salvesta.
Ülaltoodud kood ei tööta veel, kuna ma ei ole määratlenud funktsiooni komplekti tagasihelistamiseks: awhitepixel_rest_route_mydata. Tagasihelistamise funktsioon saab ühe parameetri; päringust edastatud teabe ja argumentidega andmete massiiv. Lõpuks peate hoolikalt kaaluma tagasihelistamisfunktsiooni tagastamist.
Esiteks peate alati midagi oma lõpp-punkti tagasihelistamisest tagastama. WordPress teisendab kõik tagastused automaatselt JSON-iks. See tähendab, et saate oma funktsioonis tagastada praktiliselt igasuguseid andmeid; string, null, massiiv või [WP_Error](https://developer.wordpress.org/reference/classes/wp_error/)eksemplar. Saate valida ka [WP_REST_Response](https://developer.wordpress.org/reference/classes/wp_rest_response/)objekti tagastamise, et saaksite paremini kontrollida nt olekukoodi või päise teavet. Soovitan mähkida tagastamise funktsiooni [rest_ensure_response](https://developer.wordpress.org/reference/functions/rest_ensure_response/)(), et teie vastus oleks kehtiv REST-vastus.
Määratleme tagasihelistamisfunktsiooni ja tagastame alguseks lihtsa stringi;
function awhitepixel_rest_route_mydata($data) {
$response = 'Hello there!';
return rest_ensure_response($response);
}Ülaltoodud koodiga (ja loputatud püsilinkidega) saan nüüd minna URL-ile http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.
Edaspidi saame oma tagasihelistamisfunktsiooni lisada mis tahes koodi, et genereerida tagastamiseks õiged andmed. Saate WordPressi sisu päringuid teha nt [WP_Query](https://developer.wordpress.org/reference/classes/wp_query/), teha päringuid andmebaasis või küsida välisandmeid. See osa on teie otsustada.
Nüüd liigume edasi vastasküljele; kuidas taotlusi esitada.
REST API päringute tegemine Javascriptis
REST-päringu täitmine toimub tavaliselt [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)Javascripti abil. WordPress pakub oma ümbrist fetch, mis lihtsustab WordPress REST API päringuid; [wp.apiFetch](https://developer.wordpress.org/block-editor/packages/packages-api-fetch/). Seda ma kasutan oma kohandatud Gutenbergi plokis. Pidage meeles, et fetchpäringud tagastavad "lubaduse" – seega peame .then()tegeliku päringu tagastamise käsitlemiseks aheldama a. Põhikasutus on umbes selline;
apiFetchvõimaldab meil pakkuda pathatribuuti, selle asemel et koostada täielik URL. Kõik, mida peame esitama, on nimeruum ja lõpp-punkt ning lisame apiFetchselle WordPressi REST API juur-URL-ile. Funktsiooni sees on .then()meil juurdepääs andmetele, mis on juba JSON-iks teisendatud. Siin peaksite andmetega midagi ette võtma. Tavaliselt salvestate tagastatud andmed nt komponendi olekus.
Allpool on näide kohandatud Gutenbergi ploki editkomponendist. See on klassipõhine, et seda saaks kasutada stateREST API päringu tagastatud andmete salvestamiseks. See võimaldab meil ka päringu käivitada componentDidMount()selle esmakordsel ühendamisel (vt Reacti elutsükli meetodite dokumentatsiooni ). Kõik see annab lihtsa näite, et saaksite põhikontseptsioonist aru saada; mitte retseptina, et seda täpselt niimoodi teha. Võite kaaluda Reacti konksude ja funktsionaalsete komponentide kasutamist või ehitada selle asemel kõrgema järgu komponendi.
Ülaltoodud näide on klassipõhine koostis, mis tarnitakse ploki editfunktsioonile registerBlockType(). See seadistab massiivi olekuobjekti andmete hoidmiseks (see oleneb loomulikult tagastatavatest andmetest) ja olekutõbe, et teada saada, millal asünkroonimistaotlus on tagasi tulnud. Kui komponent on paigaldatud (esmakordselt renderdatud), käivitab see apiFetchpäringu täitmise funktsiooni. Määrasime tee lõpp-punktini, mille registreerisime ülalpool PHP-s. Meetod on vaikimisi GET, nii et me ei pea seda määrama apiFetch. Ja .then()funktsiooni sees, kui päring on valmis, värskendame komponendi olekut tagastatud andmetega.
Ilmselt teeks teie ploki renderdusfunktsioon tagastatud andmetega rohkem ära. Võib-olla soovite anda kasutajale andmed, esitades loendi, mille hulgast võib-olla valida. Kõik sõltub sellest, milliste andmetega on tegemist ja milleks soovite neid kasutada.
Argumentide edastamine lõpp-punktile
Mõnel juhul peame lõpp-punktile edastama mõned argumendid. Levinud kasutusalad on ID edastamine pärast lõpp-punkti; http://localhost/wordpress/wp-json/wp/v2/posts/14tagastaks näiteks postituse ID 14.
See on üsna lihtne ja seda tehakse, lisades selle registreerimisel lõpp-punktile regex-otsingu mustri. Keeruliste mustrite loomiseks on vaja mõningaid teadmisi regexide kohta, kuid allpool on näide, mis vastab numbrile ja määrab sellele nime ‘id’. Vastete nimetamine annab meile võimaluse pääseda juurde tagasihelistamisfunktsiooni muutujale. Las ma näitan teile, mida ma mõtlen.
Registreerime uue lõpp-punkti marsruudi. Kasutame sama lõpp-punkti nagu varem (‘ awhitepixel/v1/mydata‘), kuid selle marsruudi jaoks lisame lõppu regexi vaste.
Regulaarne muster (?P<id>[d]+)tundub salapärane, kuid on üsna selge, kui mõistate regexi põhiteadmisi. Osa [d]+vastab suvalisele numbrile (0-9) 1 või enam korda. Osad (?P<id>ja )on mõeldud nimega rühma sobitamiseks. Grupi nimi on antud juhul id, kuid saate oma rühma(de)le nimetada kuidas soovite.
Saate suunata selle lõpp-punkti eraldi tagasihelistamisfunktsiooni, kuid olen otsustanud kasutada sama funktsiooni nii taotluste kui /mydataka /mydata/<ID>taotluste käsitlemiseks. See tähendab, et saan oma tagasihelistamisfunktsioonis teha:
function awhitepixel_rest_route_mydata($data) {
if ($data['id']) {
$response = 'Create return for ID: '. $data['id'];
} else {
$response = 'Create general return (no ID provided)';
}
return rest_ensure_response($response);
}Pidage meeles, et tagasihelistamisfunktsiooni parameeter sisaldab tagastatud argumente. Kuna ma andsin oma sobitatud rühmale nimeks " id", on sobitatud väärtus juurdepääsetav keeles $data['id']. Ja lõpuks, kuna ma kasutan ID-ga ja ilma ID-ta päringute käsitlemiseks sama funktsiooni, saan hõlpsalt kahe erineva tagastamise vahel vahetada.
Selle (ja värskendatud püsilinkide) abil saan oma kohandatud lõpp-punktide jaoks järgmised vastused:
