Créer des méta-boîtes WordPress maintenables Refactoring

Tout au long de cette série, nous nous sommes concentrés sur la construction de méta-boîtes WordPress maintenables. Je veux dire par là que nous travaillons à créer un plugin WordPress qui soit bien organisé, qui respecte les normes de codage WordPress et qui puisse être facilement adapté et maintenu à mesure que le projet avance dans le temps..

Bien que nous ayons mis en place de bonnes pratiques, il reste encore de la place pour la refactorisation. Pour cette série, cela se fait par conception. Chaque fois que vous travaillez sur un projet pour un client ou pour une grande entreprise, vos chances de maintenir une base de code existante sont plutôt élevées. En tant que tel, je voulais que nous puissions revenir à notre base de code afin d'affiner une partie du code que nous avons écrit.

Notez que cet article ne sera pas écrit dans le format que les autres ont été écrits - c’est-à-dire qu’il n’y aura pas d’approche de développement «Nous allons d’abord faire cela, alors nous le ferons». Au lieu de cela, nous allons mettre en évidence plusieurs domaines nécessitant une refactorisation, puis les gérer indépendamment des autres changements que nous apportons..

Refactoring

Pour être clair, l'acte de refactoring (tel que défini par Wikipedia) est:

Le refactoring améliore les attributs non fonctionnels du logiciel. Les avantages incluent une lisibilité améliorée du code et une complexité réduite pour améliorer la maintenabilité du code source, et créer une architecture interne ou un modèle objet plus expressif pour améliorer l'extensibilité..

En bref, cela rend le code plus lisible, moins complexe, plus facile à suivre et tout cela sans changer le comportement du code du point de vue de l'utilisateur final..

Ceci peut être réalisé de différentes manières, chacune étant unique au projet donné. Dans notre cas, nous allons examiner la refactorisation de nos constructeurs, certaines de nos méthodes de sauvegarde, certaines de nos méthodes d’aide, et plus encore..

En fin de compte, l’objectif est de montrer quelques stratégies qui peuvent être utilisées tout au long de vos futurs projets WordPress. Je vais essayer de couvrir autant que possible dans cet article; cependant, notez qu'il peut y avoir des possibilités de refactorisation supplémentaire qui ne sont pas couvertes.

Si c'est le cas, génial! N'hésitez pas à les créer sur votre propre instance de la base de code. Cela dit, commençons.

Le constructeur

Si vous jetez un oeil à notre constructeur:

nom = $ nom; $ this-> version = $ version; $ this-> meta_box = new Authors_Commentary_Meta_Box (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', tableau ($ this, 'enqueue_admin_scripts'));

Notez que cela fait actuellement deux choses:

Initialiser des propriétés telles que le nom et la version
Enregistrement de points d'ancrage avec WordPress

Il est courant de voir les crochets installés dans le contexte d'un constructeur dans un plugin WordPress, mais ce n'est pas vraiment l'endroit idéal pour le faire..

Un constructeur doit être utilisé pour initialiser toutes les propriétés pertinentes pour la classe donnée, de sorte que lorsqu'un utilisateur instancie une classe, il dispose de tout le matériel nécessaire pour travailler avec cette classe..

Comme ils peuvent ne pas vouloir enregistrer les hooks au moment où ils initialisent la classe, nous devons les résumer en leurs propres initialize_hooks méthode. Notre code devrait maintenant ressembler à ceci:

nom = $ nom; $ this-> version = $ version; $ this-> meta_box = new Authors_Commentary_Meta_Box ();  fonction publique initialize_hooks () add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', tableau ($ this, 'enqueue_admin_scripts'));

Après cela, nous devons nous assurer de mettre à jour le code principal de authors-commentary.php afin qu’il instancie et enregistre correctement les hooks..

initialize_hooks ();  run_author_commentary ();

Ici, la principale différence est que nous avons mis à jour le numéro de version que nous passons à la classe principale et que nous appelons aussi explicitement le initialize_hooks fonctionner dans le cadre de run_author_commentary.

Si vous exécutez votre code maintenant, tout devrait fonctionner exactement comme avant la refactorisation..

J'aimerais également ajouter que vous pouvez plaider en faveur d'une classe distincte chargée de la coordination des points d'ancrage et des rappels, de sorte que la responsabilité incombe à une classe séparée. Bien que je sois fan de cette approche, cela sort du cadre de cet article.

Ensuite, allons de l'avant et faisons la même chose pour auteurs-commentaires-meta-box.php. Plutôt que de créer une nouvelle fonction, nous pouvons simplement renommer le constructeur car celui-ci ne fait rien. Cela signifie que notre code devrait ressembler à ceci:

Pour ça:

Et le dernier changement que nous devons faire est de mettre à jour le constructeur de la classe principale afin qu’il se lit maintenant à l’intérieur du initialize_hooks fonction que nous avons créée dans la classe du plugin principal.

meta_box-> initialize_hooks (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', tableau ($ this, 'enqueue_admin_scripts'));

Encore une fois, actualisez la page et votre plugin devrait toujours fonctionner exactement comme avant la refactorisation..

Méthodes d'assistance

dans le Authors_Commentary_Meta_Box classe, nous avons un certain nombre de conditions dans le save_post fonction qui sont très redondants. Lorsque cela se produit, cela signifie généralement qu'une grande partie de la fonctionnalité peut être résumée dans une fonction d'assistance, puis appelée à partir de la fonction dans laquelle elles ont été initialement placées..

Jetons un coup d'oeil au code tel qu'il est actuellement:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  // Si la zone de texte 'Brouillons' a été renseignée, nous épurons les informations. if (! empty ($ _POST ['authors-commentary-drafts']))) ) Nous allons supprimer tous les espaces blancs, les balises HTML et encoder les informations à enregistrer. $ drafts = trim ($ _POST ['authors- commentaires-projets ']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'auteurs-commentaires-brouillons', $ brouillons);  else if ("! == get_post_meta ($ post_id, 'auteurs-commentary-brouillons', true)) delete_post_meta ($ post_id, 'auteurs-commentary-brouillons'); Si les entrées 'Ressources' existez, parcourez-les et désinfectez-les si (! empty ($ _POST ['authors-commentary-resources']))) $ resources = $ _POST ['authors-commentary-resources']; $ sanitized_resources = array (); foreach ($ resources as $ ressource) $ resource = esc_url (strip_tags ($ ressource));; si (! vide ($ ressource)) $ sanitized_resources [] = $ resource; update_post_meta ($ post_id, 'auteurs-commentary- resources ', $ sanitized_resources); else if ("! == get_post_meta ($ post_id,' auteurs-commentary-resources ', true)) delete_post_meta ($ post_id,' auteurs-commentary-resources ');  // S'il existe des valeurs enregistrées dans l'entrée "Publié", enregistrez-les si (! Empty ($ _POST ["authors-commentary-comments"])) update_post_meta ($ post_id, "authors-commentary-comments" , $ _POST ['authors-commentary-comments']);  else if ("! == get_post_meta ($ post_id, 'auteurs-commentary-comments', true)) delete_post_meta ($ post_id, 'auteurs-commentary-comments');

Mis à part le fait que la méthode est beaucoup trop longue pour commencer, il y a un certain nombre de choses que nous pouvons nettoyer:

La condition initiale qui utilise logique ne pas et logique OU les opérateurs
Les conditionnels qui vérifient la présence d'informations dans le $ _POST tableau
Les fonctions de désinfection, de mise à jour et / ou de suppression des métadonnées associées

Voyons donc chacun de ces éléments individuellement et travaillons à la refactorisation de cette fonction.

1. La condition initiale

Le premier contrôle conditionnel a pour but de s’assurer que l’utilisateur actuel a la possibilité de sauvegarder des données dans la publication donnée. À l'heure actuelle, nous vérifions littéralement si le type de publication actuel est un type de publication valide et si l'utilisateur est autorisé à enregistrer en fonction des valeurs de nonce actuelles transmises par WordPress..

En ce moment, le code se lit comme suit:

S'il ne s'agit pas d'un type de message valide ou si l'utilisateur n'a pas l'autorisation de sauvegarder, quittez cette fonction..

Ce n'est pas terrible, mais pourrait certainement être amélioré. Au lieu d'avoir un OU, consolidons-le en une seule évaluation telle qu'elle se lise:

Si l'utilisateur n'a pas l'autorisation de sauvegarder, quittez cette fonction..

Heureusement, c'est une solution relativement facile. Étant donné que le type de publication en cours de sauvegarde permet de déterminer si l'utilisateur est autorisé ou non à enregistrer la publication, nous pouvons déplacer cette logique dans la liste. user_can_save une fonction.

Alors prenons le is_valid_post_type fonction et déplacez-le dans le user_can_save une fonction:

is_valid_post_type () && $ is_valid_nonce;

Désormais, toute la logique chargée de déterminer si l'utilisateur peut enregistrer les métadonnées post est encapsulée dans une fonction spécialement conçue pour évaluer exactement cela..

Nous avons commencé avec ceci:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;

Et maintenant nous avons ceci:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;

Lit beaucoup plus facilement, n'est-ce pas?

2. Vérification du tableau $ _POST

Ensuite, avant de commencer à nettoyer, valider et sauvegarder (ou supprimer) les métadonnées, nous vérifions la $ _POST collection pour s'assurer que les données existent réellement.

Nous pouvons écrire une petite fonction d'aide qui se chargera de cette évaluation pour nous. Bien que nous écrivions un peu de code qui rend notre évaluation plus verbeuse, les conditionnels se liront un peu plus clairement que si nous les avions laissés tels quels..

Tout d’abord, introduisez la fonction suivante (et notez qu’elle prend un paramètre):

Ensuite, refactoriser tous les appels qui appelaient initialement le ! vide ($ _POST […]) afin qu'ils profitent de cette fonction.

Par exemple, les appels de fonction doivent ressembler à ceci:

if ($ this-> value_exists ('authors-commentary-comments'))) //… sinon //…

2. Suppression des métadonnées

Notez que tout au long des conditions conditionnelles placées dans cette fonction, chaque évaluation de la suppression de métadonnées post si la valeur n'existe pas a exactement la même apparence.

Par exemple, nous voyons quelque chose comme ceci à chaque fois:

C'est une chance évidente de refactoriser le code. En tant que tel, créons une nouvelle fonction appelée delete_post_meta et le faire encapsuler toutes ces informations:

Maintenant, nous pouvons faire en arrière et remplacer toutes les autres évaluations conditionnelles pour faire un appel à cette fonction unique afin qu'elle se présente comme suit:

value_exists ('authirs-commentary-drafts')) // Nous allons supprimer tous les espaces, les balises HTML et coder les informations à enregistrer. $ drafts = trim ($ _POST ['authors-commentary-drafts'])); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'auteurs-commentaires-brouillons', $ brouillons);  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts');

À ce stade, nous n’avons vraiment qu’un autre aspect de cette partie du code à refactoriser.

3. Assainissement et épargne

À l’heure actuelle, la manière dont les métadonnées post sont sauvegardées s’effectue grâce à un processus d’évaluation de la présence des données dans le répertoire. $ _POST collecte, en la désinfectant en fonction du type d’information, puis en la sauvegardant dans la métadonnée post.

Idéalement, nous aimerions assainir les données dans sa propre fonction et enregistrer les métadonnées de la post dans sa propre fonction. Ainsi, nous devons introduire de nouvelles fonctions.

D'abord, travaillons sur la désinfection. Parce que nous avons affaire à zones de texte et tableaux, il y a plusieurs façons dont nous devons gérer l'appel de désinfection. Puisque nous travaillons avec un tableau ou non, nous pouvons créer une fonction qui accepte un paramètre facultatif indiquant si nous travaillons avec un tableau ou non..

Si nous ne travaillons pas avec un tableau, nous traiterons les données entrantes sous forme de texte; sinon, nous le traiterons comme un tableau:

Ensuite, nous pouvons mettre à jour les appels de désinfection pour utiliser cette méthode. Mais avant cela, écrivons aussi un petit assistant qui sera chargé de mettre à jour les métadonnées post avec les entrées assainies:

Maintenant, nous pouvons mettre à jour toutes les conditions que nous utilisions précédemment dans la fonction pour lire comme suit:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  if ($ this-> value_exists ('auteurs-commentary-drafts')) $ this-> update_post_meta ($ post_id, 'auteurs-commentary-drafts', $ this-> sanitize_data ('auteurs-commentary-drafts') )  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts');  if ($ this-> value_exists ('authors-commentary-resources')) $ this-> update_post_meta ($ post_id, 'authors-commentary-resources', $ this-> sanitize_data ('authors-commentary-resources', vrai ) );  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-resources');  if ($ this-> value_exists ('authors-commentary-comments')) $ this-> update_post_meta ($ post_id, 'authors-commentary-comments', $ _POST ['authors-commentary-comments']);  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-comments');

Notez que nous pourrions en fait le refactoriser encore plus, de sorte qu’il n’existe pas autant de conditions, mais pour des raisons de longueur, de longueur et d’essai d’introduire d’autres stratégies, cela restera comme suit: un exercice à faire sur votre temps.

Conclusion

Nous avons maintenant terminé notre plugin. Nous avons écrit un plugin qui introduit une boîte à méta pour fournir des options aux auteurs qui écrivent des articles de blog..

De plus, nous avons utilisé les normes de codage WordPress, de solides stratégies d’organisation des fichiers et avons créé un certain nombre de méthodes auxiliaires et d’abstractions qui nous aideront à maintenir ce plugin au cours de son développement futur..

Comme il n'est pas facile de mettre en évidence chaque opportunité de refactorisation, des modifications supplémentaires sont susceptibles d'être apportées. Sur votre temps, n'hésitez pas à essayer de mettre en œuvre certains d'entre eux sur votre propre.

Dans l’ensemble, j’espère que vous avez apprécié la série et qu’elle vous a beaucoup appris, et qu’elle vous aidera à rédiger du code meilleur et plus facile à maintenir dans les futurs projets WordPress..

Code