{"id":233992,"date":"2023-02-26T18:35:00","date_gmt":"2023-02-26T15:35:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=233992"},"modified":"2022-11-11T13:38:54","modified_gmt":"2022-11-11T10:38:54","slug":"crea-e-recupera-endpoint-rest-personalizzati-nei-blocchi-di-gutenberg","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/crea-e-recupera-endpoint-rest-personalizzati-nei-blocchi-di-gutenberg\/","title":{"rendered":"Crea e recupera endpoint REST personalizzati nei blocchi di Gutenberg"},"content":{"rendered":"\n

In questo post cercher\u00f2 di creare una panoramica su come creare endpoint API REST personalizzati ed eseguire richieste per essi in un blocco Gutenberg personalizzato. Cio\u00e8, fare richieste con fetch<\/code>metodi per informazioni non disponibili negli archivi dati registrati di WordPress.<\/p>\n

Un promemoria amichevole: la maggior parte delle informazioni di base sono gi\u00e0 disponibili nei datastore di WordPress. Ad esempio, le query di base su post, pagine, tipi di post personalizzati, tassonomie, autori, media e altro sono disponibili cos\u00ec come sono senza dover creare i propri endpoint personalizzati. Per accedere a questi negozi, preferisci utilizzare il modulo dati core di WordPress (withSelect<\/code>e select()<\/code>). Di seguito \u00e8 riportato un tutorial che approfondisce come farlo.<\/p>\n

API REST di WordPress<\/h2>\n

Se non lo sapevi gi\u00e0; L’API REST di WordPress \u00e8 un’interfaccia JSON per inviare e ricevere dati dal tuo sito WordPress. Pu\u00f2 essere utilizzato esternamente o internamente. Con l’editor Gutenberg e il passaggio a Javascript, l’utilizzo dell’API REST \u00e8 decisamente aumentato. L’API REST di WordPress ha un sacco di endpoint che possiamo utilizzare. Consulta un riferimento completo su tutti gli endpoint dell’API REST qui<\/a>. Troverai ad esempio gli endpoint per i post e la maggior parte degli altri contenuti interni, sia per la lettura che per l’aggiornamento. Gli sviluppatori di temi o plugin possono registrare i propri endpoint personalizzati.<\/p>\n

Il tuo sito WordPress ha un URL API REST radice, come predefinito situato in <your domain>\/wp-json<\/code>. Ad esempio, un WordPress locale con l’URL http:\/\/localhost\/wordpress\/<\/code>pu\u00f2 accedere all’API REST all’indirizzo http:\/\/localhost\/wordpress\/wp-json<\/code>. Da l\u00ec dobbiamo aggiungere gli endpoint. Facendo riferimento al riferimento sopra degli endpoint, possiamo recuperare un elenco degli ultimi post nell’endpoint \/wp\/v2\/posts<\/code>. Ci\u00f2 significa che se vai http:\/\/localhost\/wordpress\/wp-json\/wp\/v2\/posts<\/code>nel tuo browser otterrai una risposta in formato JSON degli ultimi post nel tuo sito WordPress.<\/p>\n

Una nota sugli spazi dei nomi \u00e8 d’obbligo. Un URL API REST inizia con uno spazio dei nomi (‘ wp\/v2<\/code>‘ \u00e8 lo spazio dei nomi di WordPress’ come mostrato negli URL di esempio sopra). Namespaces \u00e8 un concetto per evitare conflitti nel core di WordPress, temi e plugin aggiungendo endpoint con lo stesso nome. Crea il tuo spazio dei nomi univoco, in genere una forma slug del tuo tema o nome del plug-in. Dopo lo slug una regola generale consiste nell’aggiungere il numero di versione, normalmente a partire dalla v1. Ad esempio, lo slug del mio tema \u00e8 ‘ awhitepixel<\/code>‘, quindi se dovessi creare endpoint personalizzati nel mio tema userei lo spazio dei nomi ‘ awhitepixel\/v1<\/code>‘. Con questo spazio dei nomi potrei registrare un endpoint ‘ posts<\/code>‘ e non causerebbe problemi anche se \u00e8 identico al nome dell’endpoint di WordPress.<\/p>\n

Lavorare con l’API REST in WordPress \u00e8 un argomento ampio con molte buone informazioni disponibili. In questo post mi concentrer\u00f2 sull’usabilit\u00e0 nell’editor Gutenberg e su come recuperarli in Javascript.<\/p>\n

Cosa faremo e di cosa abbiamo bisogno<\/h2>\n

L’usabilit\u00e0 per la richiesta di informazioni personalizzate ha un’ampia gamma di casi d’uso, quindi in genere \u00e8 necessario personalizzare gli esempi di codice seguenti per soddisfare le proprie esigenze. I dati potrebbero essere una query post personalizzata, una query SQL personalizzata o qualcosa di completamente diverso.<\/p>\n

Quando creiamo un endpoint personalizzato, abbiamo il pieno controllo del suo ritorno. Possiamo eseguire qualsiasi tipo di operazione e query in WordPress\/PHP e trasmetterlo come JSON. E nel nostro blocco Gutenberg saremo in grado di recuperare questo ritorno e fare ci\u00f2 che vogliamo con esso all’interno della edit<\/code>funzione del blocco. In genere utilizzeresti i dati per presentare all’utente finale una scelta o informazioni all’interno dell’editor di blocchi, ma puoi anche archiviare le informazioni da essi nel blocco per un ulteriore utilizzo. Puoi anche creare i tuoi archivi personalizzati per questi dati, ma non spiegher\u00f2 come farlo.<\/p>\n

Presumo che tu abbia gi\u00e0 familiarit\u00e0 con come creare blocchi Gutenberg personalizzati, quindi non lo esaminer\u00f2 in dettaglio qui.<\/p>\n

Creazione di un endpoint API REST<\/h2>\n

La registrazione di un endpoint API REST personalizzato viene eseguita in PHP. Aggiungeresti questo codice nel tuo tema functions.php<\/code>o in un codice plug-in attivo. Collega una funzione all’azione rest_api_init<\/code>ed esegui la funzione [register_rest_route](https:\/\/developer.wordpress.org\/reference\/functions\/register_rest_route\/)()<\/code>per ogni endpoint che desideri registrare.<\/p>\n

Fornisci il tuo spazio dei nomi come primo parametro, la route dell’endpoint come secondo e una matrice di impostazioni come terzo parametro per register_rest_route()<\/code>. Il quarto parametro controlla se si desidera o meno sovrascrivere un percorso esistente; non qualcosa che vedremo qui. Nell’array per il terzo parametro dovresti almeno impostare la propriet\u00e0 ‘ callback<\/code>‘ su una funzione responsabile della restituzione dei dati dell’endpoint. Anche l’impostazione ‘ method<\/code>‘ \u00e8 comune, ad esempio l’impostazione dell’endpoint su ‘ GET<\/code>‘, ‘ POST<\/code>‘, ‘ PUT<\/code>‘, ecc.<\/p>\n

Iniziamo con la registrazione di un semplice endpoint;<\/p>\n

add_action('rest_api_init', function() {\n    register_rest_route('awhitepixel\/v1', '\/mydata', [\n        'method' => 'GET',\n        'callback' => 'awhitepixel_rest_route_mydata'\n    ]);\n});<\/code><\/pre>\n
Lo spazio dei nomi del mio tema \u00e8 " awhitepixel\/v1<\/code>" e sto registrando un endpoint " mydata<\/code>" all’interno di questo spazio dei nomi. Ci\u00f2 significa che posso accedere alla mia API REST personalizzata su http:\/\/localhost\/wordpress\/wp-json\/awhitepixel\/v1\/mydata<\/code>.<\/p>\n
Quando registri (o modifichi) i percorsi dell’API REST, dovrai svuotare i tuoi permalink<\/strong> affinch\u00e9 funzionino. Puoi farlo visitando Impostazioni > Permalink e facendo semplicemente clic su Salva.<\/p>\n
Il codice sopra non funziona ancora, perch\u00e9 non ho definito la funzione impostata come callback: awhitepixel_rest_route_mydata<\/code>. La funzione di callback riceve un parametro; una matrice di dati con informazioni e argomenti passati dalla richiesta. Infine devi considerare attentamente il ritorno della tua funzione di callback.<\/p>\n
Innanzitutto devi sempre restituire qualcosa dal callback dell’endpoint. Qualsiasi reso verr\u00e0 automaticamente convertito in JSON da WordPress. Ci\u00f2 significa che puoi restituire praticamente qualsiasi forma di dati nella tua funzione; una stringa, null, una matrice o [WP_Error](https:\/\/developer.wordpress.org\/reference\/classes\/wp_error\/)<\/code>un’istanza. Puoi anche optare per la restituzione di un [WP_REST_Response](https:\/\/developer.wordpress.org\/reference\/classes\/wp_rest_response\/)<\/code>oggetto per un maggiore controllo, ad esempio, sul codice di stato o sulle informazioni di intestazione. Raccomando di racchiudere il ritorno nella funzione [rest_ensure_response](https:\/\/developer.wordpress.org\/reference\/functions\/rest_ensure_response\/)()<\/code>per garantire che la tua risposta sia una risposta REST valida.<\/p>\n
Definiamo la nostra funzione di callback e restituiamo una semplice stringa come inizio;<\/p>\n
function awhitepixel_rest_route_mydata($data) {\n    $response = 'Hello there!';\n    return rest_ensure_response($response);\n}<\/code><\/pre>\n
Con il codice sopra (e i permalink scaricati), ora posso andare all’URL http:\/\/localhost\/wordpress\/wp-json\/awhitepixel\/v1\/mydata<\/code>.<\/p>\n
\"Crea<\/a><\/p>\n
Da qui in poi possiamo aggiungere qualsiasi tipo di codice nella nostra funzione di callback per generare i dati corretti da restituire. Puoi interrogare il contenuto di WordPress con ad es [WP_Query](https:\/\/developer.wordpress.org\/reference\/classes\/wp_query\/)<\/code>, effettuare query nel database o richiedere dati esterni. Questa parte dipende da te.<\/p>\n
Ora, passiamo al lato opposto; come fare le richieste.<\/p>\n
Effettuare richieste API REST in Javascript<\/h2>\n
L’esecuzione della richiesta REST viene comunemente eseguita utilizzando [fetch](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Fetch_API)<\/code>Javascript. WordPress fornisce il proprio wrapper fetch<\/code>che semplifica le richieste dell’API REST di WordPress; [wp.apiFetch](https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-api-fetch\/)<\/code>. Questo \u00e8 ci\u00f2 che user\u00f2 nel mio blocco Gutenberg personalizzato. Tieni presente che una fetch<\/code>richiesta restituisce una "promessa", quindi \u00e8 necessario concatenare .then()<\/code>a per gestire l’effettivo ritorno della richiesta. L’utilizzo di base \u00e8 qualcosa del genere;<\/p>\n
wp.apiFetch({\n    path: '<namespace and endpoint>',\n}).then(data => {\n    console.log('response from apifetch: ', data);\n});<\/code><\/pre>\n
apiFetch<\/code>ci consente di fornire una path<\/code>propriet\u00e0 invece di creare l’URL completo. Tutto ci\u00f2 che dobbiamo fornire \u00e8 lo spazio dei nomi e l’endpoint e apiFetch<\/code>lo aggiungeremo all’URL radice dell’API REST di WordPress. All’interno della .then()<\/code>funzione abbiamo accesso ai dati che sono gi\u00e0 convertiti in JSON. \u00c8 qui che faresti qualcosa con i dati. Di solito memorizzeresti i dati restituiti, ad esempio, lo stato del componente.<\/p>\n
Di seguito \u00e8 riportato un esempio di componente di un blocco Gutenberg personalizzato edit<\/code>. \u00c8 basato sulla classe per essere utilizzato state<\/code>per archiviare i dati restituiti dalla richiesta dell’API REST. Questo ci consente anche di eseguire la richiesta componentDidMount()<\/code>quando viene montata per la prima volta (consultare la documentazione di React sui metodi del ciclo di vita<\/a> ). Tutto ci\u00f2 fornisce un semplice esempio per comprendere il concetto di base; non come ricetta per farlo esattamente cos\u00ec. Potresti prendere in considerazione l’utilizzo di ganci React e componenti funzionali<\/a> o costruire invece un componente di ordine superiore<\/a>.<\/p>\n
const { Component } = wp.element;\nconst { Spinner } = wp.components;\n\u00a0\nclass BlockEdit extends Component {\n    constructor(props) {\n        super(props);\n        this.state = {\n            list: [],\n            loading: true\n        }\n    }\n\u00a0\n    componentDidMount() {\n        this.runApiFetch();\n    }\n\u00a0\n    runApiFetch() {\n        wp.apiFetch({\n            path: 'awhitepixel\/v1\/mydata',\n        }).then(data => {\n            this.setState({\n                list: data,\n                loading: false\n            });\n        });\n    }\n\u00a0\n    render() {\n        return(\n            <div>\n                {this.state.loading? (<Spinner \/>\n                ): (<p>Data is ready!<\/p>\n                )}\n            <\/div>\n        );\n\u00a0\n    }\n}\nexport default BlockEdit;<\/code><\/pre>\n
L’esempio sopra \u00e8 un componente basato sulla classe fornito alla edit<\/code>funzione del blocco in registerBlockType()<\/code>. Imposta un oggetto di stato di un array per contenere i dati (questo dipende dai dati restituiti, ovviamente) e uno stato booleano per sapere quando \u00e8 stata restituita la richiesta asincrona. Una volta che il componente \u00e8 montato (renderizzato per la prima volta) esegue la funzione per eseguire la apiFetch<\/code>richiesta. Impostiamo il percorso per l’endpoint che abbiamo registrato in PHP sopra. Il metodo \u00e8 per impostazione predefinita GET, quindi non \u00e8 necessario specificarlo in apiFetch<\/code>. E all’interno .then()<\/code>della funzione quando la richiesta \u00e8 pronta aggiorniamo lo stato del componente con i dati restituiti.<\/p>\n
Ovviamente la funzione di rendering del tuo blocco farebbe di pi\u00f9 con i dati restituiti stessi. Potresti voler fornire i dati all’utente in qualche modo presentando un elenco da cui forse scegliere. Tutto dipende da che tipo di dati sono e per cosa li vuoi usare.<\/p>\n
Passaggio di argomenti all’endpoint<\/h2>\n
In alcuni casi \u00e8 necessario passare alcuni argomenti all’endpoint. Gli usi comuni stanno passando un ID dopo l’endpoint; ad esempio http:\/\/localhost\/wordpress\/wp-json\/wp\/v2\/posts\/14<\/code>restituirebbe l’ID del post 14.<\/p>\n
Questo \u00e8 piuttosto semplice e viene fatto aggiungendo un modello di ricerca regex all’endpoint durante la registrazione. Richiede una certa conoscenza delle espressioni regolari per costruire modelli complessi, ma di seguito \u00e8 riportato un esempio che corrisponde a un numero e gli assegna il nome ‘id’. Assegnare un nome alle corrispondenze ci consente di accedere alla variabile nella nostra funzione di callback. Lascia che ti mostri cosa intendo.<\/p>\n
Registriamo una nuova route dell’endpoint. Usiamo lo stesso endpoint di prima (‘ awhitepixel\/v1\/mydata<\/code>‘), ma per questo percorso aggiungiamo una corrispondenza regolare per un numero alla fine.<\/p>\n
add_action('rest_api_init', function() {\n    register_rest_route('awhitepixel\/v1', '\/mydata', [\n        'method' => 'GET',\n        'callback' => 'awhitepixel_rest_route_mydata'\n    ]);\n\u00a0\n    register_rest_route('awhitepixel\/v1', '\/mydata\/(?P<id>[d]+)', [\n        'method' => 'GET',\n        'callback' => 'awhitepixel_rest_route_mydata'\n    ]);\n});<\/code><\/pre>\n
Il modello regex (?P<id>[d]+)<\/code>sembra criptico, ma sar\u00e0 abbastanza chiaro con alcune nozioni di base sull’espressione regolare. La [d]+<\/code>parte corrisponde a qualsiasi numero (0-9) 1 o pi\u00f9 volte. Le parti (?P<id><\/code>e )<\/code>servono per la corrispondenza di un gruppo denominato. Il nome del gruppo \u00e8 in questo caso id<\/code>, ma puoi nominare i tuoi gruppi come preferisci.<\/p>\n
Puoi scegliere di indirizzare questo endpoint a una funzione di callback separata, ma ho scelto di utilizzare la stessa funzione per gestire entrambe \/mydata<\/code>le \/mydata\/<ID><\/code>richieste. Ci\u00f2 significa che posso nella mia funzione di callback fare:<\/p>\n
function awhitepixel_rest_route_mydata($data) {\n    if ($data['id']) {\n        $response = 'Create return for ID: '. $data['id'];\n    } else {\n        $response = 'Create general return (no ID provided)';\n    }\n    return rest_ensure_response($response);\n}<\/code><\/pre>\n
Ricorda che il parametro della funzione di callback contiene gli argomenti restituiti. Poich\u00e9 ho chiamato il mio gruppo corrispondente ‘ id<\/code>‘, il valore corrispondente sar\u00e0 accessibile in $data['id']<\/code>. Infine, poich\u00e9 utilizzo la stessa funzione per gestire le richieste con e senza ID, posso passare facilmente tra i due diversi resi.<\/p>\n
Con questo (e permalink aggiornati), otterr\u00f2 queste risposte per i miei endpoint personalizzati:<\/p>\n
\"Crea<\/a>\"Crea<\/a><\/p>\n
Fonte di registrazione:  awhitepixel.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"
Una guida su come creare endpoint API REST di WordPress personalizzati ed eseguire richieste apiFetch per essi in un blocco Gutenberg personalizzato.<\/p>\n","protected":false},"author":1,"featured_media":224922,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[918,896,896,835,939,939,918,1110,814,814,835,844,844,865,865],"tags":[1168],"class_list":["post-233992","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-altro","category-codice","category-guida-per-principianti","category-gutenberg-6","category-n-a","category-plugin-2","category-tutorial","category-wordpress-6","tag-affiai-it"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/233992","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/comments?post=233992"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/233992\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media\/224922"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media?parent=233992"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/categories?post=233992"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/tags?post=233992"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}