Un article ne se limite pas à son titre et à son contenu : une note de lecture estimée, un identifiant de produit externe, une préférence d’affichage peuvent tous s’y rattacher sans pour autant mériter une colonne dédiée dans la base de données. C’est précisément ce que permet l’API des métadonnées, en associant des paires clé-valeur à un objet WordPress existant.
Fonctions principales et objets concernés
Cette API partage la même logique de fonctions pour plusieurs types d’objets : get_post_meta(), update_post_meta() et delete_post_meta() pour les articles, avec des équivalents directs get_user_meta() pour les utilisateurs et get_term_meta() pour les termes de taxonomie. Toutes ces valeurs sont stockées dans des tables dédiées (wp_postmeta, wp_usermeta, wp_termmeta), chacune structurée en lignes de type clé-valeur liées à un identifiant d’objet.
Exemple d’utilisation
update_post_meta( $post_id, 'temps_lecture_minutes', 6 );
$temps = get_post_meta( $post_id, 'temps_lecture_minutes', true );Pièges fréquents
- Le troisième argument
truedeget_post_meta()retourne une valeur unique ; l’omettre renvoie un tableau, une source fréquente de bugs subtils quand une seule valeur est attendue. - Une métadonnée dont la clé commence par un underscore est considérée comme protégée et n’apparaît pas dans l’éditeur de champs personnalisés natif, sans pour autant être réellement sécurisée contre un accès direct en base.
- Stocker de grandes quantités de données structurées via cette API peut alourdir les requêtes SQL si elles nécessitent des jointures répétées sur
wp_postmeta; une table dédiée devient parfois préférable au-delà d’un certain volume.