✅ Notizie, temi, plugin WEB e WordPress. Qui condividiamo suggerimenti e le migliori soluzioni per siti web.

Crea e recupera endpoint REST personalizzati nei blocchi di Gutenberg

29

In questo post cercherò di creare una panoramica su come creare endpoint API REST personalizzati ed eseguire richieste per essi in un blocco Gutenberg personalizzato. Cioè, fare richieste con fetchmetodi per informazioni non disponibili negli archivi dati registrati di WordPress.

Un promemoria amichevole: la maggior parte delle informazioni di base sono già 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ì come sono senza dover creare i propri endpoint personalizzati. Per accedere a questi negozi, preferisci utilizzare il modulo dati core di WordPress (withSelecte select()). Di seguito è riportato un tutorial che approfondisce come farlo.

API REST di WordPress

Se non lo sapevi già; L’API REST di WordPress è un’interfaccia JSON per inviare e ricevere dati dal tuo sito WordPress. Può essere utilizzato esternamente o internamente. Con l’editor Gutenberg e il passaggio a Javascript, l’utilizzo dell’API REST è 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. 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.

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

Una nota sugli spazi dei nomi è d’obbligo. Un URL API REST inizia con uno spazio dei nomi (‘ wp/v2‘ è lo spazio dei nomi di WordPress’ come mostrato negli URL di esempio sopra). Namespaces è 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 è ‘ awhitepixel‘, quindi se dovessi creare endpoint personalizzati nel mio tema userei lo spazio dei nomi ‘ awhitepixel/v1‘. Con questo spazio dei nomi potrei registrare un endpoint ‘ posts‘ e non causerebbe problemi anche se è identico al nome dell’endpoint di WordPress.

Lavorare con l’API REST in WordPress è un argomento ampio con molte buone informazioni disponibili. In questo post mi concentrerò sull’usabilità nell’editor Gutenberg e su come recuperarli in Javascript.

Cosa faremo e di cosa abbiamo bisogno

L’usabilità per la richiesta di informazioni personalizzate ha un’ampia gamma di casi d’uso, quindi in genere è 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.

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ò che vogliamo con esso all’interno della editfunzione 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ò come farlo.

Presumo che tu abbia già familiarità con come creare blocchi Gutenberg personalizzati, quindi non lo esaminerò in dettaglio qui.

Creazione di un endpoint API REST

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

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(). 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à ‘ callback‘ su una funzione responsabile della restituzione dei dati dell’endpoint. Anche l’impostazione ‘ method‘ è comune, ad esempio l’impostazione dell’endpoint su ‘ GET‘, ‘ POST‘, ‘ PUT‘, ecc.

Iniziamo con la registrazione di un semplice endpoint;

Lo spazio dei nomi del mio tema è " awhitepixel/v1" e sto registrando un endpoint " mydata" all’interno di questo spazio dei nomi. Ciò significa che posso accedere alla mia API REST personalizzata su http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.

Quando registri (o modifichi) i percorsi dell’API REST, dovrai svuotare i tuoi permalink affinché funzionino. Puoi farlo visitando Impostazioni > Permalink e facendo semplicemente clic su Salva.

Il codice sopra non funziona ancora, perché non ho definito la funzione impostata come callback: awhitepixel_rest_route_mydata. 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.

Innanzitutto devi sempre restituire qualcosa dal callback dell’endpoint. Qualsiasi reso verrà automaticamente convertito in JSON da WordPress. Ciò 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/)un’istanza. Puoi anche optare per la restituzione di un [WP_REST_Response](https://developer.wordpress.org/reference/classes/wp_rest_response/)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/)()per garantire che la tua risposta sia una risposta REST valida.

Definiamo la nostra funzione di callback e restituiamo una semplice stringa come inizio;

function awhitepixel_rest_route_mydata($data) { $response = 'Hello there!'; return rest_ensure_response($response); }

Con il codice sopra (e i permalink scaricati), ora posso andare all’URL http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.

Crea e recupera endpoint REST personalizzati nei blocchi di Gutenberg

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/), effettuare query nel database o richiedere dati esterni. Questa parte dipende da te.

Ora, passiamo al lato opposto; come fare le richieste.

Effettuare richieste API REST in Javascript

L’esecuzione della richiesta REST viene comunemente eseguita utilizzando [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)Javascript. WordPress fornisce il proprio wrapper fetchche semplifica le richieste dell’API REST di WordPress; [wp.apiFetch](https://developer.wordpress.org/block-editor/packages/packages-api-fetch/). Questo è ciò che userò nel mio blocco Gutenberg personalizzato. Tieni presente che una fetchrichiesta restituisce una "promessa", quindi è necessario concatenare .then()a per gestire l’effettivo ritorno della richiesta. L’utilizzo di base è qualcosa del genere;

apiFetchci consente di fornire una pathproprietà invece di creare l’URL completo. Tutto ciò che dobbiamo fornire è lo spazio dei nomi e l’endpoint e apiFetchlo aggiungeremo all’URL radice dell’API REST di WordPress. All’interno della .then()funzione abbiamo accesso ai dati che sono già convertiti in JSON. È qui che faresti qualcosa con i dati. Di solito memorizzeresti i dati restituiti, ad esempio, lo stato del componente.

Di seguito è riportato un esempio di componente di un blocco Gutenberg personalizzato edit. È basato sulla classe per essere utilizzato stateper archiviare i dati restituiti dalla richiesta dell’API REST. Questo ci consente anche di eseguire la richiesta componentDidMount()quando viene montata per la prima volta (consultare la documentazione di React sui metodi del ciclo di vita ). Tutto ciò fornisce un semplice esempio per comprendere il concetto di base; non come ricetta per farlo esattamente così. Potresti prendere in considerazione l’utilizzo di ganci React e componenti funzionali o costruire invece un componente di ordine superiore.

L’esempio sopra è un componente basato sulla classe fornito alla editfunzione del blocco in registerBlockType(). 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 è stata restituita la richiesta asincrona. Una volta che il componente è montato (renderizzato per la prima volta) esegue la funzione per eseguire la apiFetchrichiesta. Impostiamo il percorso per l’endpoint che abbiamo registrato in PHP sopra. Il metodo è per impostazione predefinita GET, quindi non è necessario specificarlo in apiFetch. E all’interno .then()della funzione quando la richiesta è pronta aggiorniamo lo stato del componente con i dati restituiti.

Ovviamente la funzione di rendering del tuo blocco farebbe di più 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.

Passaggio di argomenti all’endpoint

In alcuni casi è 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/14restituirebbe l’ID del post 14.

Questo è 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 è 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.

Registriamo una nuova route dell’endpoint. Usiamo lo stesso endpoint di prima (‘ awhitepixel/v1/mydata‘), ma per questo percorso aggiungiamo una corrispondenza regolare per un numero alla fine.

Il modello regex (?P<id>[d]+)sembra criptico, ma sarà abbastanza chiaro con alcune nozioni di base sull’espressione regolare. La [d]+parte corrisponde a qualsiasi numero (0-9) 1 o più volte. Le parti (?P<id>e )servono per la corrispondenza di un gruppo denominato. Il nome del gruppo è in questo caso id, ma puoi nominare i tuoi gruppi come preferisci.

Puoi scegliere di indirizzare questo endpoint a una funzione di callback separata, ma ho scelto di utilizzare la stessa funzione per gestire entrambe /mydatale /mydata/<ID>richieste. Ciò significa che posso nella mia funzione di callback fare:

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); }

Ricorda che il parametro della funzione di callback contiene gli argomenti restituiti. Poiché ho chiamato il mio gruppo corrispondente ‘ id‘, il valore corrispondente sarà accessibile in $data['id']. Infine, poiché utilizzo la stessa funzione per gestire le richieste con e senza ID, posso passare facilmente tra i due diversi resi.

Con questo (e permalink aggiornati), otterrò queste risposte per i miei endpoint personalizzati:

Crea e recupera endpoint REST personalizzati nei blocchi di GutenbergCrea e recupera endpoint REST personalizzati nei blocchi di Gutenberg

Fonte di registrazione: awhitepixel.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More