Utilizzo di WordPress per lo sviluppo di applicazioni Web funzioni disponibili, parte 5 recupero dei dati

Ormai, sai che lo scopo di questa serie è dimostrare come WordPress può essere utilizzato come base per lo sviluppo di applicazioni web.

Abbiamo iniziato con uno sguardo ad alto livello su molti modelli di progettazione di applicazioni web, su come differisce WordPress e perché WordPress dovrebbe essere considerato più come una base piuttosto che come un framework.

Negli ultimi articoli abbiamo esaminato ruoli utente, autorizzazioni, gestione delle sessioni, e-mail e serializzazione dei dati. Ma se hai intenzione di salvare i dati nel database, ha senso solo che lo recupererai, giusto?

Fortunatamente, le API che WordPress ha reso disponibili rendono molto facile il recupero delle informazioni dal database. Inoltre, se hai trovato l'ultimo articolo facile da seguire, non dovresti avere nessun problema a seguire questo articolo, poiché molti dei principi sono gli stessi:

  • Noi recuperiamo le informazioni dal database utilizzando l'ID univoco che abbiamo fornito al momento del salvataggio delle informazioni
  • Escludiamo i dati per assicurarci che sia sicuro eseguire il rendering sul browser
  • Quindi lo restituiamo alla funzione di chiamata

Niente di terribilmente complicato, giusto?

E in realtà non lo è, soprattutto perché si tratta di sfruttare le stesse API (anche se diverse funzioni) che abbiamo usato per salvare le informazioni nella tabella delle opzioni e nelle tabelle dei metadati. In questo articolo, continueremo la nostra discussione su come recuperare le informazioni, nonché su come accertarci che stiamo eseguendo correttamente l'escape delle informazioni per assicurarci che i dati siano sicuri e puliti per il rendering nel browser.


Recupero dei dati

Come ho menzionato negli articoli precedenti, uno dei principali elementi di differenziazione tra un normale sito Web e un'applicazione Web è l'archiviazione dei dati.

E dal momento che WordPress utilizza il proprio database per gestire l'archiviazione dei dati e rende disponibili le API da utilizzare per i propri progetti, è ovviamente un'applicazione Web.

Inoltre, ho appena discusso nell'ultimo articolo, capire come salvare i dati usando le API appropriate è davvero semplice, e una volta che hai imparato a usarne uno, usare il resto è quasi altrettanto semplice. Inoltre, imparare a recuperare i dati è probabilmente ancora più semplice.

Detto questo, ci sono alcune sfumature che dobbiamo considerare quando si procede al recupero dei dati. Ma prima esamineremo il database, daremo un'occhiata a come recuperare le informazioni e poi vedremo come debellare correttamente le informazioni prima di restituirle al browser.

Capire il database

Nell'articolo precedente, abbiamo una panoramica dettagliata delle tabelle a cui è possibile scrivere. Puoi leggere di più su questo in dettaglio nel primo articolo, ma ecco un riassunto delle tabelle che abbiamo discusso:

  • wp_options
  • wp_posts
  • wp_postmeta
  • wp_comments
  • wp_commentmeta

Ricorda, puoi rivedere tutto questo e altro nella pagina di descrizione del database nel codice WordPress.

Lettura dal database

Quindi con questo come nostro ripasso, è il momento di guardare effettivamente come recuperare le informazioni dal database.

Fortunatamente, è semplice come scrivere informazioni nel database. Le due principali differenze sono:

  • Usiamo funzioni leggermente diverse.
  • C'è un po 'di lavoro che dobbiamo fare per assicurarci che i dati che stiamo visualizzando siano formattati in modo pulito per il browser.

Prima di esaminare come gestire i dati, vediamo prima come leggere le opzioni dal database.

La tabella delle opzioni

Ricordiamo dall'ultimo articolo che il modo in cui andiamo a scrivere dati nella tabella delle opzioni è usando il add_option o il get_option funzioni.

Ricorda: ognuno prende una chiave univoca che viene utilizzata per identificare il valore nel database e il valore associato a quella chiave. Nel nostro precedente esempio, ho dimostrato quanto segue:

 if (isset ($ _POST ['value']) &&! empty ($ _POST ['value']) $ clean_value = strip_tags (stripslashes ($ _POST ['valore'])); add_option ('mio valore', $ clean_value);

Ciò significa che abbiamo disinfettato e salvato le informazioni nel database utilizzando il il mio valore chiave.

Per recuperare queste informazioni dal database, effettuiamo la seguente chiamata:

 $ my_value = get_option ('my-value');

È quasi troppo semplice.

Ma c'è una cattura per il get_option funzione: possiamo effettivamente specificare un valore predefinito da restituire se non esiste già.

Ad esempio, supponiamo di cercare un valore per la chiave il tuo valore, che non esiste.

 // $ your_value sarà effettivamente uguale a FALSE $ your_value = get_option ('your-value');

In questo caso, la funzione ritornerà FALSE; tuttavia, se specifichiamo un secondo parametro, possiamo restituire un valore predefinito:

 // $ your_value sarà effettivamente uguale a una stringa vuota $ your_value = get_option ('your-value', ");

Ancora niente, niente di terribilmente complicato, giusto?

Che cos'è il tema Mod?

Prima di esaminare come recuperare le informazioni dalle meta tabelle, vale la pena menzionarle, proprio come impostiamo le informazioni set_theme_mod, possiamo anche recuperare le impostazioni del tema usando get_theme_mod.

Direttamente dal codice WordPress:

Recupera un'impostazione di modifica per il tema corrente. Insieme a set_theme_mod () questa funzione a volte può offrire agli sviluppatori di temi un'alternativa più semplice all'API delle impostazioni quando è necessario gestire impostazioni di base specifiche per i temi.

Di nuovo, questo è ovviamente pensato per lavorare con i temi; tuttavia, volevo menzionarlo qui per il gusto di essere completo, e per il bene di arrotondare la discussione iniziata nel precedente articolo.

Oltre a questo, questo è puramente pensato per mostrare come le opzioni possono essere memorizzate in base a come si può lavorare con lo sviluppo del tema; tuttavia, è davvero al di fuori della portata della serie sullo sviluppo di applicazioni.

Le metriche Post Meta e Comment Meta

Ora torniamo a parlare delle tabelle del database più applicabili allo sviluppo di applicazioni e persino alla gestione dei contenuti.

Nell'ultimo articolo, ho dimostrato le funzioni API responsabili della scrittura delle informazioni sulle tabelle dei metadati. Nello specifico, ho delineato le seguenti funzioni:

  • add_post_meta
  • update_post_meta
  • add_comment_meta
  • update_comment_meta

In modo simile con il resto dell'API di opzioni, recuperare informazioni da ciascuna di queste tabelle è davvero semplice, tranne che viene fornito con un singolo "gotcha": per impostazione predefinita, tutte le informazioni restituite da tali funzioni vengono eseguite sotto forma di schieramento.

Questo significa che se devi chiamare:

 $ my_data = get_post_meta (get_the_ID (), 'my-post-information');

Quindi i dati ti verranno restituiti in un array; tuttavia, se vuoi passare VERO alla funzione quando lo si chiama, quindi i dati verranno restituiti in una stringa:

 $ my_data = get_post_meta (get_the_ID (), 'my-post-information', TRUE);

Certo, non c'è destra modo per farlo. Invece, dipende dalle informazioni che vuoi restituite e / o da come vuoi che vengano restituite. Perché non esiste un unico modo per farlo, devi giudicare il tuo utilizzo in base all'implementazione dell'applicazione.

Dati di fuga

Ora, proprio come avevamo bisogno di disinfettare le informazioni prima di scriverle effettivamente nel database, è anche importante che noi eseguiamo correttamente i dati dopo averli recuperati dal database, ma prima di renderli al browser.

La fuga di dati è il processo mediante il quale ci assicuriamo che i dati che stiamo per rendere all'utente siano sicuri. È fondamentalmente la sanitizzazione fatta ai dati; tuttavia, è fatto dopo i dati sono stati recuperati dal database anziché eseguiti prima di scriverli nel database.

Quando si tratta di accettare dati, ci sono quattro funzioni principali di cui dovremmo essere a conoscenza:

  1. esc_html è usato per sfuggire ai blocchi HTML.
  2. esc_url è quando è necessario pulire gli URL che verranno scritti su elementi di testo, attributo nodi o in qualsiasi altro punto del markup.
  3. ESC_JS è usato per sfuggire alle stringhe di testo che vengono utilizzate per echeggiare JavaScript, principalmente JavaScript in linea.
  4. esc_attr codifica diversi caratteri che possono manipolare l'output se non gestiti correttamente.

La cosa bella di questo è che generalmente funzionano allo stesso modo, e il modo per determinare quale si deve usare è relativamente facile:

  • Se stai rendendo inline JavaScript, quindi usa ESC_JS,
  • Se stai rendendo un attributo per un elemento, allora usa esc_attr.

Abbastanza facile, giusto?

Quindi, per esempio, diciamo che volevi scappare da un attributo di un campo di input proveniente dal $ _POST collezione. Per fare questo, devi scrivere il seguente codice:

 '; ?>

Sono piccole cose come questa che possono fare molto per assicurarsi che l'applicazione sia solida sia nella serializzazione dei dati che nel recupero dei dati.


E ora, su Riscrivere l'URL

Abbiamo coperto molto terreno in questa serie, ma c'è ancora molto da fare.

Caso in questione: una delle più belle funzionalità di alcuni dei più popolari framework per applicazioni web è il modo in cui gestiscono gli URL. In breve, forniscono schemi URL chiari che rendono molto semplice comprendere le varie azioni disponibili per i modelli di dati utilizzati in tutta l'applicazione.

WordPress non offre gli URL più puliti o più chiari; tuttavia, questo può essere modificato attraverso l'uso dell'API Rewrite. Nel prossimo articolo, daremo un'occhiata a come possiamo introdurre regole personalizzate per gli URL puliti che assomigliano a qualcosa che si vedrebbe in un'applicazione web piuttosto che in un sistema di gestione dei contenuti o in un blog.