Creazione di Meta box gestibili Meta Salva e recupera

Mentre arriviamo alla fine di questa serie, abbiamo altri due argomenti da trattare:

  1. Salvataggio delle informazioni e recupero delle informazioni dal database
  2. Refactoring del codice in modo che diventi più gestibile per noi

Nel precedente articolo, abbiamo esaminato la convalida, la disinfezione e l'implementazione di questa funzionalità per gli elementi che abbiamo visualizzato sul front-end. In questo articolo, continueremo il processo salvando le informazioni nel database, recuperando le informazioni e mostrandole sul front-end.

Lungo il percorso, esamineremo anche alcune delle funzioni API di WordPress incorporate progettate per semplificare questo processo e alcuni suggerimenti per ricontrollare il nostro lavoro nel database per verificare che le nostre informazioni vengano salvate esattamente come ci aspettiamo.

Abbiamo ancora un po 'di più per dare vita a questo plug-in, quindi iniziamo.

Salvataggio dei dati

Per poter visualizzare i dati sul front-end, dobbiamo ovviamente prima inserirli nel database. Dato che stiamo lavorando con le meta box, allora possiamo usare le funzioni che sono disponibili tramite l'API di Meta Box per salvare queste informazioni.

In particolare, lavoreremo con le seguenti funzioni:

  • update_post_meta per salvare le informazioni nel database
  • delete_post_meta per rimuovere informazioni dal database

C'è un'altra funzione, add_post_meta, che è anche disponibile per scrivere informazioni nel database; però, update_post_meta fa la stessa cosa se i dati non esistono già nel database.

Un'altra domanda che ho visto emergere quando si tratta di cancellare i metadati dei post è perché? Cioè, perché cancellare le informazioni piuttosto che salvare un valore vuoto? 

Puoi obiettare che questa è una preferenza personale - e lo è - ma se stai lavorando con un plugin elaborato che ha un numero di campi diversi, ed i campi non hanno valore, allora ha senso non mantenere una riga vuota.

Inoltre, a meno che l'assenza di un valore non sia significativa per qualcosa nell'interfaccia utente, non c'è motivo di mantenere un valore vuoto poiché stiamo permettendo al database di rispecchiare più da vicino le informazioni che vengono visualizzate sullo schermo. 

Mantenere l'interfaccia utente, il codice del livello applicazione e il database quanto più coerenti possibile è utile quando si tenta di scrivere codice gestibile. 

Detto questo, esaminiamo il processo di salvataggio dei campi per ciascuno dei nostri campi di input.

1. Bozza

Ricordiamo dal post precedente che il Bozza scheda contiene un singolo textarea è pensato per essere un luogo in cui gli autori raccolgono varie note e URL da tutto il Web pertinenti al contenuto che si stanno preparando a pubblicare.

Quando abbiamo lasciato questo codice, abbiamo avuto il seguente:

Qui, stiamo cercando di vedere se il contenuto del $ _POST l'array è popolato. In tal caso, disinfettiamo le informazioni utilizzando tagliare e esc_textarea.

A questo punto, siamo pronti per scriverlo nel database, quindi sostituiamo la riga che legge // E c'è dell'altro… con il seguente codice (si noti che dopo il blocco daremo un'occhiata più approfondita al codice):

Qui, stiamo usando il update_post_meta funzione per aggiungere o aggiornare il contenuto nel database. Si noti che la funzione accetta tre parametri:

  1. L'ID post utilizzato per associare queste informazioni al post
  2. Una meta chiave che viene utilizzata per identificare in modo univoco il valore
  3. Il valore meta effettivo associato alla meta chiave

Si noti inoltre che se il valore del $ _POST la matrice è vuota, quindi controlliamo se c'è è un valore per la bozza nel database e, se esiste, lo rimuoviamo.

2. Risorse

Perché abbiamo già preparato tutto il lavoro di base per sanificare le informazioni e abbiamo visto come aggiornare e cancellare le informazioni nel database, facendo lo stesso per il risorse la scheda è più o meno la stessa.

L'unica eccezione è che dal momento che abbiamo a che fare con un insieme dinamico di informazioni, dobbiamo associare dinamicamente il post con un ID univoco in base a quante risorse stiamo salvando.

Nel post precedente, il nostro codice assomigliava a questo:

Quando si tratta di elaborare dinamicamente le informazioni, a per ciascuno il ciclo funziona alla grande; tuttavia, quando si salvano le informazioni, è necessario associare una chiave univoca a ciascun valore. 

Un'opzione potrebbe essere quella di impostare un ciclo for per suffix la chiave meta con una chiave univoca (utilizzando l'iteratore per ogni valore nel ciclo), ma ciò può causare problemi quando si tratta di eliminare informazioni. In particolare, se l'utente immette un valore per il primo, il secondo e il terzo input, ma rimuove il secondo input lasciando solo il primo e il terzo durante l'aggiornamento del post, è necessario eliminare correttamente quei valori vuoti e spostare tutti i record di conseguenza.

Questo può essere fatto in diversi modi, ma è in realtà più semplice salvare un singolo array serializzato in un indice univoco piuttosto che cercare di fare qualcosa di elaborato con righe di database, query e così via.

In quanto tale, aggiorniamo il codice sopra per assomigliare a questo:

Se guardi nel database e guardi questa chiave specifica, dovresti vedere qualcosa come questo memorizzato come valore:

un: 3: i: 0; s: 22: "http://tommcfarlin.com"; i: 1; s: 19: "http://tutsplus.com"; i: 2; s: 17:" http://google.com ";

Vedremo come questo si verifica quando recuperiamo le informazioni dal database più avanti in questo articolo. Si noti inoltre che è necessario tenere conto del caso in cui un utente ha rimosso tutte le istanze di risorse.

Proprio come abbiamo fatto nella prima parte dell'articolo, eliminiamo semplicemente i metadati del post se esiste un valore. Questo può essere fatto usando un codice molto simile:

Ora dobbiamo salvare i valori per l'ultima meta-box.

3. Pubblicato

La scheda finale della meta-box, il Pubblicato tab, sarà il più facile da aggiornare per noi in quanto raccoglie tutto ciò che abbiamo visto finora nell'articolo.

In particolare, stiamo iterando attraverso una raccolta di valori, scrivendoli in un array e quindi serializzando l'array nel database. Forse la cosa più importante da notare è che stiamo usando un array associativo e stiamo indicizzando ogni valore con il valore dell'ID commento.

Come vedremo più avanti nell'articolo, questo renderà molto più semplice impostare i valori sull'interfaccia utente.

 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ commento;  update_post_meta ($ post_id, 'autori-commenti-commenti', $ sanitized_comments); 

Proprio come abbiamo fatto nella sezione precedente, se non c'è nulla specificato in $ _POST array, quindi controlliamo l'esistenza dei valori nel database e, se esistono, li cancelliamo:

 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ commento;  update_post_meta ($ post_id, 'autori-commenti-commenti', $ sanitized_comments);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-comments', true)) delete_post_meta ($ post_id, 'autori-commenti-commenti');

Come accennato, questo ultimo esempio tira tutto insieme che abbiamo visto per le ultime due schede, quindi dovrebbe essere un codice relativamente chiaro da seguire a questo punto.

Una parola sul database

Prima di andare oltre, dedichiamo un momento per capire come possiamo finire per interrogare le informazioni dal database. 

Supponiamo che tu abbia un post con l'ID di 9000 (il tuo verrà modificato in base alla configurazione). Puoi prendere quell'ID e guardare nel wp_postmeta tabella per vedere tutte le meta informazioni associate al post.

Inoltre, è possibile specificare la chiave per recuperare solo le informazioni associate all'ID e alla chiave del post.

Se specifichi solo l'ID post, vedrai tutte le meta informazioni associate al post. Se specifichi solo la chiave, vedrai tutti gli ID dei post che contengono contenuti per le loro bozze. Se specifichi sia l'ID del post che la chiave, ti verranno restituite solo le informazioni sulla bozza che hai specificato per un singolo post.

Parlando di recupero dei dati, diamo un'occhiata ai passaggi necessari per visualizzare i metadati dei post nel dashboard del nostro plug-in.

Recupero dati

Ora che tutte le informazioni sono state salvate nel database, possiamo introdurre il codice che lo recupera e visualizzarlo nella scheda corretta di ogni plug-in. La cosa bella di questo è che userà funzioni e costruttori (come get_post_meta e per) che abbiamo già utilizzato.

1. Bozza

Individuare admin / views / parziali / drafts.php. Supponendo che tu abbia seguito tutto fino a questo punto, il codice dovrebbe assomigliare a questo:

Per popolare questo textarea, dobbiamo chiamare get_post_meta utilizzando l'ID del post corrente e la chiave che abbiamo utilizzato per salvare le informazioni in precedenza in questo articolo. Dai un'occhiata al seguente codice:

Tieni presente che stiamo passando tre parametri:

  1. Il primo è il post ID che viene recuperato usando il get_the_ID funzione.
  2. Il secondo è la chiave che abbiamo specificato quando salviamo i dati per identificarli in modo univoco.
  3. Il terzo è un valore booleano vero che dice alla funzione di restituirci il valore come una stringa piuttosto che in un array.

Se il valore non esiste, restituisce semplicemente una stringa vuota in modo che textarea è vuoto.

2. Risorse

Per risorse, facciamo una chiamata simile; tuttavia, questa volta vogliamo eseguire un'iterazione dei risultati in modo da poter creare dinamicamente l'interfaccia utente.

A causa del modo in cui WordPress serializza l'array, vogliamo comunque che le informazioni vengano restituite in un formato stringa (sebbene si tratti di un array de-serializzato) che ci consentirà di utilizzare un per ciascuno loop per scorrere attraverso di esso.

In breve, recuperiamo le informazioni dal database, ciclicandole creando un ingresso elemento per ogni valore e quindi renderlo alla pagina. 

Questo ci consente anche di rimuovere elementi semplicemente cancellando un valore e quindi aggiornando il post. Da lì, il display si riproporrà in modo tale che non ci siano elementi di input vuoti.

3. Pubblicato

Probabilmente questa è la parte più semplice del plugin. Poiché abbiamo già ottenuto così tanto codice nel modello, l'unica cosa che dobbiamo davvero fare è determinare se il valore per la casella di controllo è impostato nella matrice dei meta dati.

Dato che stiamo usando l'ID del commento come indice numerico dell'array, possiamo semplicemente verificare se l'ID del commento è contenuto nell'array di meta chiavi restituito dai metadati.

Ecco come:

load_post_comments (); ?>
  • COMMENT_AUTHOR; ?>: COMMENT_CONTENT; ?>


Si noti che recuperiamo il valore dal database, passando di nuovo vero come il terzo valore. 

Successivamente, prendiamo l'ID del commento corrente e controlliamo se questo valore è contenuto nei tasti dell'array (usando array_key_exists) Dei meta dati post che sono stati restituiti. In tal caso, contrassegniamo la casella come spuntata; altrimenti, non facciamo nulla.

Avanti il ​​prossimo

A questo punto, abbiamo un plugin pienamente funzionante che soddisfa tutti i requisiti che ci siamo prefissati di costruire iniziando dal primo articolo della serie.

Ma lo stesso plugin è mantenibile? Cioè, soddisfa l'obiettivo primario di questa serie?

In qualche modo sì, ma c'è ancora spazio per miglioramenti. Poiché parte dello sviluppo deve lavorare con il codice che ereditiamo, daremo un'occhiata a come refactoring del codice che abbiamo scritto per renderlo più comprensibile e più gestibile.

Inoltre, esamineremo i motivi per cui stiamo eseguendo alcuni dei refactoring che stiamo facendo. Dopotutto, non avrebbe molto senso semplificare il codice o spostarlo senza alcun fondamento logico.

Ma prima di farlo, vai avanti e analizza questo articolo e dai un'occhiata al codice dal repository GitHub associato e lascia commenti, domande o commenti generali sotto.