Associazione di metadati di WordPress: entità correlate
A questo punto, abbiamo spiegato come creare le entità all’interno del plugin (che, come abbiamo detto, è solo una parola di fantasia per un’altra idea concreta). Vale a dire, abbiamo un utente e un tipo di post personalizzato o un libro. Ed è qui che iniziamo a prendere le due entità separate e a combinare e lavorare con quella che chiameremo associazione di metadati di WordPress.
Ma prima di farlo, è importante capire i due tipi di metadati con cui lavoreremo e i due modi (o tre modi, a seconda di come li guardi) in come possiamo associare i metadati.
Come per il resto dei post della serie, questo non vuole essere un approfondimento nella comprensione di ciascuna delle tabelle o un approfondimento in ciascuna delle funzioni dell’API. Invece, esamineremo ciò che è disponibile, lo metteremo in uso e lasceremo dettagli più fini per post futuri (o forse discussioni nei commenti).
Associazione di metadati di WordPress
I metadati non sono esclusivi di WordPress. Probabilmente lo sai. Ed è spesso definito come :
Informazioni su informazioni o dati su dati.
E questo è un buon modo per dirlo. WordPress offre alcune tabelle di database diverse che possiamo utilizzare per fornire informazioni su determinati altri tipi di entità all’interno di WordPress. Ne useremo un paio più avanti in questo post, ma basti dire che WordPress offre :
- metadati dei commenti,
- postare i metadati,
- metadati a termine,
- e metadati dell’utente
E tutto questo è disponibile out-of-the-box.
Una delle tabelle di metadati di WordPress.
Le API per ciascuno di questi sono coerenti, il che è anche bello. Ma, ancora una volta, ci occuperemo solo di un paio di questi per il resto di questo post.
1 Le tabelle dei metadati
Per il nostro esempio, utilizzeremo una o entrambe delle seguenti due tabelle:
Certo, nella tua installazione potrebbero avere un prefisso diverso, ma il suffisso è lo stesso e ti fai un’idea.
In secondo luogo, utilizzeremo le relative funzioni API per associare i nostri metadati. Li esamineremo nel codice quando associamo i dati tra il nostro utente e il tipo di post personalizzato (o il nostro autore e i nostri libri se desideri utilizzare una terminologia più accurata).
Va bene, allora. L’intera prima parte del post sta solo gettando le basi per quali parti dell’infrastruttura WordPress sottostante utilizzeremo. Detto questo, diamo un’occhiata a come possiamo trasformare programmaticamente questa cosa in qualcosa di un po’ più utile.
2 Associazione dei metadati
L’idea alla base dell’associazione dei metadati di WordPress sembra più complicata di quanto non sia. Pensare in questo modo:
- Date due tabelle, come possiamo condividere informazioni tra due entità che fanno conoscere l’una all’altra?
Ad esempio, dato un utente, come possiamo far conoscere ai metadati dell’utente i metadati dei post. Oppure, ribaltando la situazione, come possiamo far sapere ai metadati dei post qualcosa sui metadati degli utenti correlati?
Ad alto livello, questo è davvero quello che stiamo facendo: stiamo facendo sapere a un’entità che l’altra esiste e la stiamo mettendo in relazione con l’altra. Oppure potrebbe andare dall’altra parte. A seconda dell’implementazione, uno potrebbe essere più vantaggioso dell’altro.
1 unidirezionale
Quando si parla di creare associazioni WordPress unidirezionali, di solito si parla dell’idea che solo un’entità sia a conoscenza dell’altra. Ciò significa che l’utente può essere solo a conoscenza del post.
Quindi potremmo impostare dopo che un post è stato creato come l’utente in questione è a conoscenza del post che è stato appena creato :
<?php
// Using post title as the value, but it's just an example.
add_user_meta( $user_id, $post_id, $post_title );
O forse significa che il post è a conoscenza dell’utente:
<?php
// User user email address a value but just an example.
add_post_meta( $post_id, $user_id, $email_address );
Ma non importa come la guardi, l’associazione va solo in un modo.
E anche se la relazione va in un modo, non deve essere così. Cioè, entrambe le entità possono essere consapevoli l’una dell’altra.
2 Bidirezionale
Poiché le API dei metadati sono così facili e coerenti con cui lavorare, non è difficile lavorarci. Ciascuno di solito richiede almeno due dei seguenti:
- un ID di sorta a cui sono correlati i metadati,
- una meta chiave che può essere utilizzata per cercare le informazioni,
- un valore che memorizza le informazioni associate all’ID e al post.
Per quanto riguarda l’ID e la chiave che scegli spesso dipende dalla tua implementazione, come abbiamo visto.
Fino a questo punto, abbiamo visto come creare un’associazione unidirezionale. Un’associazione a due vie non è niente di diverso. È solo piuttosto che rendere un’entità consapevole dell’altra, rendiamo entrambe le entità consapevoli dell’altra:
<?php
/**
* Using this association will give you the ability to query for information
* both on posts and users and then work with the data accordingly.
*/
add_user_meta( $user_id, $post_id, $post_title );
add_post_meta( $post_id, $user_id, $email_address );
Ma questa non è una decisione che dovrebbe essere presa solo per il gusto di farlo. Invece, vale la pena pensare ad alcuni dei motivi per cui potresti voler scegliere l’uno o l’altro.
Pensare attraverso il problema
Quando si tratta di risolvere problemi come questo, non c’è una soluzione definitiva in termini di "dovresti definirlo [in questo modo]" in qualunque modo possa essere. Invece, devi porsi domande come "cosa rende il modo più semplice per gestire questi dati?"
Ad esempio, se sei principalmente interessato alla gestione degli utenti, forse tutto ciò di cui hai bisogno è che i metadati degli utenti siano a conoscenza di qualsiasi entità a cui sono correlati. In questo modo, quando l’utente viene eliminato, assicurati anche di cercare le entità ad esso correlate tramite la tabella dei metadati dell’utente ed eliminarle anche loro.
Allo stesso modo, forse la stessa funzionalità andrebbe in entrambi i modi. Cioè, proprio come vuoi assicurarti che quando un utente viene eliminato, anche i suoi post vengano eliminati, potresti anche voler eliminare (o modificare) l’utente ogni volta che uno dei suoi post viene rimosso. E se è così, allora l’associazione a due vie lo consente.
Dal momento che hai l’ID di un determinato post e l’ID di un determinato utente, nonché le meta chiavi che hai specificato, è possibile quasi qualsiasi tipo di query che puoi visualizzare tramite l’API dei metadati di WordPress o WP_Query o anche tramite WP_User_Query.
La fine
In definitiva, spero che questa serie abbia fornito alcune informazioni su come creare non solo associazioni di metadati di WordPress, ma anche su come pensare in modo astratto ai concetti all’interno di WordPress in relazione alla creazione di implementazioni di livello superiore nei plug-in e nelle applicazioni Web.
Per coloro che sono interessati, sto pensando di rilasciare questa serie come una piccola risorsa in formato PDF insieme a un plug-in funzionante da studiare. Se questo è qualcosa che ti interessa fare, allora iscriviti alla mailing list qui, e sarò sicuro di farti sapere quando sarà pronta; in caso contrario, usa le informazioni nella serie per andare avanti e creare qualcosa che valga la pena
Voglio di più?
Messaggi di serie
- Associazione di metadati di WordPress: come farlo
- Creazione programmatica di utenti WordPress
- Tipi di post di WordPress: un’astrazione per le entità
- Associazione di metadati di WordPress: entità correlate
