Créer des méta-boîtes WordPress maintenables enregistrer et récupérer

À la fin de cette série, nous avons deux autres sujets à couvrir:

  1. Enregistrement d'informations dans la base de données et récupération d'informations à partir de celle-ci
  2. Refactoriser le code pour qu'il soit plus facile à gérer pour nous

Dans l'article précédent, nous avons examiné la validation, la désinfection et l'implémentation de cette fonctionnalité pour les éléments que nous avons affichés sur le front-end. Dans cet article, nous allons poursuivre le processus en enregistrant les informations dans la base de données, en les récupérant et en les affichant au début du processus..

En cours de route, nous examinerons également certaines des fonctions intégrées de l'API WordPress conçues pour nous faciliter la tâche, ainsi que des astuces pour revérifier notre travail dans la base de données afin de nous assurer que nos informations sont en cours de sauvegarde. exactement comme nous l'espérons.

Nous avons juste un peu plus à faire pour donner vie à ce plugin, alors commençons.

La sauvegarde des données

Afin d’afficher des données sur le front-end, nous devons évidemment les avoir d’abord dans la base de données. Puisque nous travaillons avec des méta-boîtes, nous pouvons utiliser les fonctions disponibles via l'API Meta Box afin de sauvegarder ces informations..

Plus précisément, nous allons travailler avec les fonctions suivantes:

  • update_post_meta pour sauvegarder des informations dans la base de données
  • delete_post_meta pour supprimer des informations de la base de données

Il y a une autre fonction, add_post_meta, qui est également disponible pour écrire des informations dans la base de données; toutefois, update_post_meta fait la même chose si les données n'existent pas déjà dans la base de données.

Pourquoi une autre question que j'ai déjà vue à propos de la suppression de métadonnées? Pourquoi supprimer des informations plutôt que de sauvegarder une valeur vide? 

Vous pouvez faire valoir que c'est une préférence personnelle - et c'est le cas - mais si vous travaillez avec un plugin complexe comportant un certain nombre de champs différents et que les champs n'ont aucune valeur, il est alors logique de ne pas conserver une ligne vide..

De plus, à moins que l'absence de valeur ne soit significative pour quelque chose sur l'interface utilisateur, il n'y a aucune raison de conserver une valeur vide car nous permettons à la base de données de refléter plus fidèlement les informations affichées à l'écran.. 

Garder l'interface utilisateur, le code de couche d'application et la base de données aussi cohérents que possible est utile lorsque vous essayez d'écrire du code maintenable.. 

Donc, avec cela dit, examinons le processus de sauvegarde des champs pour chacun de nos champs d'entrée.

1. Ébauche

Rappel du post précédent que le Brouillon onglet contient un seul zone de texte cela est censé être un endroit où les auteurs peuvent collecter diverses notes et URL sur le Web qui sont pertinentes pour le contenu qu'ils se préparent à publier..

Lorsque nous avons quitté ce code pour la dernière fois, nous avions ce qui suit:

Ici, nous cherchons à voir si le contenu de la $ _POST tableau est rempli. Si c'est le cas, nous désinfectons ensuite les informations à l'aide de réduire et esc_textarea.

À ce stade, nous sommes prêts à l'écrire dans la base de données, alors remplaçons la ligne qui lit // Plus à venir… avec le code suivant (notons que nous examinerons plus en profondeur le code après le bloc):

Ici, nous utilisons le update_post_meta pour ajouter ou mettre à jour le contenu de la base de données. Notez que la fonction prend trois paramètres:

  1. L'ID de publication utilisé pour associer ces informations à la publication
  2. Une méta clé utilisée pour identifier de manière unique la valeur
  3. La méta valeur réelle associée à la clé méta

Notez également que si la valeur de la $ _POST tableau est vide alors nous vérifions pour voir s'il y a est une valeur pour le brouillon dans la base de données et, si elle existe, nous la supprimons.

2. ressources

Parce que nous avons déjà tout préparé pour assainir les informations et que nous avons vu comment mettre à jour et supprimer des informations dans la base de données, en procédant de la même manière pour le Ressources onglet est plus du même.

La seule exception est que, dans la mesure où nous traitons avec un ensemble d'informations dynamique, nous devons associer de manière dynamique la publication à un ID unique, en fonction du nombre de ressources que nous économisons..

Dans le post précédent, notre code ressemblait à ceci:

En ce qui concerne le traitement dynamique des informations, un pour chaque la boucle fonctionne très bien; Cependant, lors de la sauvegarde des informations, nous devons associer une clé unique à chaque valeur.. 

Une option serait de configurer une boucle for afin de suffixer la clé méta avec une clé unique (en utilisant l’itérateur pour chaque valeur de la boucle), mais cela peut poser des problèmes lors de la suppression d’informations. Plus précisément, si l'utilisateur entre une valeur pour les première, deuxième et troisième entrées mais supprime ensuite la deuxième entrée en ne laissant que les première et troisième lors de la mise à jour de la publication, nous devons supprimer correctement ces valeurs vides et décaler tous les enregistrements en conséquence..

Cela peut être fait de différentes manières, mais il est en fait plus facile de sauvegarder un seul tableau sérialisé dans un index unique plutôt que d'essayer de faire n'importe quoi avec les lignes de base de données, les requêtes, etc..

En tant que tel, nous mettons à jour le code ci-dessus pour qu'il ressemble à ceci:

Si vous regardez dans la base de données et regardez cette clé spécifique, vous devriez voir quelque chose comme ceci stocké en tant que valeur:

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

Nous verrons comment cela se passera lorsque nous récupérerons les informations de la base de données plus loin dans cet article. Notez également que nous devons prendre en compte le cas où un utilisateur a supprimé toutes les instances de ressources..

Comme nous l'avons fait dans la première partie de l'article, nous supprimons simplement les métadonnées post si une valeur existe. Cela peut être fait en utilisant un code très similaire:

Maintenant nous devons sauvegarder les valeurs pour la dernière méta-boîte.

3. Publié

Le dernier onglet de la boîte à méta, le Publié onglet, sera la plus facile à mettre à jour, car elle rassemble tout ce que nous avons vu jusqu'à présent dans l'article.

Plus précisément, nous parcourons une collection de valeurs, nous les écrivons dans un tableau, puis nous le sérialisons dans la base de données. La chose la plus importante à noter est peut-être que nous utilisons un tableau associatif et que nous indexons chaque valeur par la valeur de l'ID de commentaire..

Comme nous le verrons plus tard dans l'article, cela facilitera grandement la définition des valeurs sur l'interface utilisateur..

 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ comment;  update_post_meta ($ post_id, 'authors-commentary-comments', $ sanitized_comments); 

Comme nous l'avons fait dans la section précédente, s'il n'y a rien de spécifié dans le $ _POST tableau, nous vérifions l'existence des valeurs dans la base de données et, si elles existent, nous les supprimons:

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

Comme mentionné, ce dernier exemple regroupe tout ce que nous avons vu pour les deux derniers onglets. Le code devrait donc être relativement clair à suivre à ce stade..

Un mot sur la base de données

Avant d'aller plus loin, prenons un moment pour comprendre comment nous pouvons finir par interroger des informations dans la base de données.. 

Supposons que vous avez un message avec l'ID de 9000 (le vôtre varie en fonction de votre configuration). Vous pouvez prendre cet identifiant et regarder dans le wp_postmeta table pour voir toutes les méta-informations qui sont associées à la poste.

En outre, vous pouvez spécifier la clé pour extraire uniquement les informations associées à l’ID de publication et à la clé..

Si vous ne spécifiez que l'ID de la publication, toutes les méta-informations associées à la publication s'affichent. Si vous spécifiez uniquement la clé, tous les ID d'articles contenant le contenu de leurs brouillons s'affichent. Si vous spécifiez à la fois l'ID de publication et la clé, vous récupérerez uniquement les informations de brouillon que vous avez spécifiées pour une publication unique..

En parlant de récupération de données, regardons les étapes nécessaires pour afficher les métadonnées post dans le tableau de bord de notre plugin.

Récupération des données

Maintenant que toutes les informations ont été enregistrées dans la base de données, nous pouvons introduire un code qui va le récupérer et l'afficher dans l'onglet approprié de chaque plugin. La bonne chose à ce sujet est qu’il utilisera des fonctions et des constructeurs (comme get_post_meta et pour) que nous utilisons déjà.

1. Ébauche

Localiser admin / views / partials / drafts.php. En supposant que tout ce que vous avez suivi jusqu'ici, le code devrait ressembler à ceci:

Pour peupler cette zone de texte, nous devons appeler get_post_meta à l'aide de l'ID de publication en cours et de la clé utilisée pour enregistrer les informations plus haut dans cet article. Regardez le code suivant:

Notez que nous passons dans trois paramètres:

  1. Le premier est l’identifiant de la publication qui est récupéré à l’aide du get_the_ID une fonction.
  2. La seconde est la clé que nous avons spécifiée lors de la sauvegarde des données pour l'identifier de manière unique..
  3. La troisième est une valeur booléenne true qui indique à la fonction de nous renvoyer la valeur sous forme de chaîne plutôt que dans un tableau..

Si la valeur n'existe pas, il renvoie simplement une chaîne vide afin que le zone de texte est vide.

2. ressources

Pour Ressources, nous faisons un appel similaire; Cependant, cette fois, nous souhaitons parcourir les résultats afin de créer dynamiquement l'interface utilisateur..

En raison de la façon dont WordPress sérialise le tableau, nous souhaitons toujours que les informations soient renvoyées sous forme de chaîne (bien qu'il s'agisse d'un tableau désérialisé) qui nous permettra d'utiliser un pour chaque boucle pour parcourir à travers elle.

En bref, nous récupérons les informations de la base de données, les parcourons en créant un contribution élément pour chaque valeur et ensuite le rendre à la page. 

Cela nous permet également de supprimer des éléments en supprimant simplement une valeur, puis en mettant à jour le message. A partir de là, l’affichage se re-rendra tel qu’il n’y ait pas d’éléments d’entrée vides..

3. Publié

On peut dire que c'est la partie la plus facile du plugin. Comme nous avons déjà tellement de code dans le modèle, la seule chose à faire est de déterminer si la valeur de la case à cocher est définie dans le tableau de métadonnées..

Puisque nous utilisons l'ID de commentaire comme index numérique du tableau, nous pouvons simplement vérifier si l'ID de commentaire est contenu dans le tableau de clés méta renvoyé par les métadonnées..

Voici comment:

load_post_comments (); ?>
  • comment_author; ?>: comment_content; ?>


Notez que nous récupérons la valeur de la base de données en passant à nouveau vrai comme troisième valeur. 

Ensuite, nous prenons l’ID de commentaire actuel et vérifions si cette valeur est contenue dans les clés du tableau (en utilisant array_key_exists) Des métadonnées de poste qui ont été renvoyées. Si tel est le cas, la case à cocher est cochée. sinon, on ne fait rien.

Suivant

À ce stade, nous avons un plugin pleinement fonctionnel qui répond à toutes les exigences que nous avons voulu créer à partir du premier article de la série..

Mais le plugin lui-même est-il maintenable? C'est-à-dire, remplit-il l'objectif principal de cette série?

D'une certaine manière, oui, mais des améliorations sont possibles. Comme une partie du développement consiste à travailler avec du code dont nous avons hérité, nous allons voir comment remodeler une partie du code que nous avons écrit pour le rendre plus facile à comprendre et à maintenir plus facilement..

De plus, nous examinerons les raisons pour lesquelles nous effectuons une partie de la refactorisation que nous effectuons. Après tout, cela n'aurait pas de sens de simplifier le code ou de le déplacer sans aucune justification..

Mais avant cela, continuez avec cet article, examinez le code du référentiel GitHub associé et laissez des commentaires, des questions ou des commentaires généraux ci-dessous..