Widgets WordPress : refactorisation, partie 12

En ce qui concerne la refactorisation du WordPress Widget Boilerplate – surtout compte tenu du chemin parcouru depuis le début du projet il y a huit ans – nous avons fait beaucoup de travail.

Nous l’avons amené à une norme beaucoup plus moderne et nous facilitons beaucoup son utilisation, de sorte que la création de futurs widgets devrait être plus facile. Et cela ne vient pas seulement du standard du passe-partout mais d’un standard orienté objet afin que la maintenance et la qualité du code soient supérieures.

Dans le dernier message, nous avons terminé une grande partie du travail pour la zone d’administration et sommes prêts à commencer notre travail sur le code pour le front-end.

Nous l’avons dit:

Ensuite, nous allons examiner le rendu du contenu sur le front-end. Nous approchons de la fin de la refactorisation du Boilerplate mais il reste juste un peu plus à faire avant que nous soyons prêts à le fusionner dans la branche master de la base de code.

Donc dans ce post, on va reprendre là. Maintenant, si vous avez suivi jusqu’à ce point, vous devriez avoir tout ce dont vous avez besoin de la branche de développement.

Sinon, assurez-vous de le tirer car c’est là que nous allons reprendre dans le reste du message.

Le passe-partout du widget WordPress : refactorisation de la partie 12

Maintenant, en ce qui concerne le front-end, il est facile de considérer le front-end comme tout ce que l’utilisateur voit devant lui, que ce soit dans la zone administrative ou non.

Cependant, cette série a clairement indiqué que nous divisons ce que l’utilisateur voit entre la zone administrative et la zone publique du site.

Donc, ce que nous allons faire, c’est travailler sur la zone du code qui affiche des informations pour l’utilisateur sur la zone publique du site. Nous allons commencer par simplement lire les informations et les afficher.

Ensuite, dans le prochain article, nous verrons comment travailler avec la logique conditionnelle concernant certaines des options pour voir s’il y a quelque chose que nous devons faire.

Cela dit, passons au code.

Sur les données que nous afficherons

N’oubliez pas que le widget, à ce stade, a trois choses qui influencent son affichage :

1. le titre du widget,
2. le contenu du widget,
3. une bascule pour savoir si nous devons ou non afficher le titre

La troisième option consiste principalement à montrer comment utiliser un type d’élément différent. Parce que, techniquement, si nous ne voulions pas afficher le titre du widget, nous ne mettrions rien dans le widget.

Mais je pense que cela aide à montrer comment utiliser différents types d’éléments et leurs valeurs de manière pratique (ou semi-pratique).

Quoi qu’il en soit, cela dit, nous savons que pour chaque instance donnée du widget, les données sont stockées avec le titre ,  le contenu et  le nom et les identifiants du titre d’affichage fournis par WordPress.

Ainsi, nous utiliserons ceux de notre code frontal pour afficher les valeurs.

Préparation des fonctions d’affichage

En règle générale, la  fonction widget est responsable de l’affichage de la sortie du widget. Mais l’une des choses que nous avons essayé de faire est de séparer les préoccupations de notre widget en un ensemble plus ciblé de classes et de fonctions.

La première chose que nous voulons faire est d’écrire une  classe WidgetDisplay qui sera chargée, comme cela est sûrement évident, d’afficher le contenu du widget.

Pour l’instant, cela inclura inconditionnellement le titre, le contenu et la valeur d’inclure ou non le titre. WordPress met également à disposition certains contenus comme le balisage qui doit apparaître avant le widget et après le widget, nous nous assurerons donc de l’inclure également.

Mais d’abord, effaçons la classe :

<?php

namespace WordPressWidgetBoilerplateWordPress;

class WidgetDisplay
{
  private $widgetSlug;

  public function __construct(string $widgetSlug)
  {
      $this->widgetSlug = $widgetSlug;
  }

  public function show($args, $instance)
  {
    // More to come
  }
}

Après cela, nous devons nous assurer que nous l’écrivons également aux autres classes. Tout d’abord, nous nous assurerons de l’inclure dans notre classe Widget :

<?php
public function widget($args, $instance)
{
    return $this->widgetDisplay->show($args, $instance);
}

Et puis nous l’ajouterons à la classe WidgetAdmin (puisque c’est là que résident les principales fonctions de l’API Widget – cela délègue simplement la responsabilité à la classe appropriée):

<?php

public function __construct($widgetSlug)
{
    parent::__construct($widgetSlug);
    $this->widgetSerializer = new WidgetSerializer($this->getWidgetSlug());
    $this->widgetDisplay = new WidgetDisplay($this->getWidgetSlug());
}

À ce stade, nous n’affichons encore rien. Nous sommes proches et nous nous concentrerons là-dessus bientôt.

Affichage des données

En supposant que vous puissiez ajouter le code ci-dessus sans erreur, il est temps d’afficher le contenu du widget.

Nous pouvons le faire de plusieurs façons, d’un simple var_dump à un travail réel pour afficher le contenu d’une manière plus conviviale. Et je suis beaucoup plus fan de ce dernier.

Alors faisons ça.

Dans la  fonction show de votre  classe WidgetDisplay, ajoutez le code suivant :

<?php
public function show($args, $instance)
{
    include_once 'Views/Widget.php';
}

Et puis la vue pour le modèle peut être aussi simple que ceci :

<div id="<?php echo $args['id']; ?>">
    <h3 class="widget-title"><?php echo $instance['title']; ?></h3>
    <p><?php echo $instance['content']; ?></p>
    <pre><?php echo $instance['display-title']; ?></pre>
</div><!-- #<?php echo $args['id']; ?>-->

Cela garantira que le balisage approprié pour tout le contenu avant le widget, le contenu du widget et le contenu est correctement rendu.

Encore une fois, rappelez-vous que nous affichons du contenu qui ne sera pas dans la version finale de ceci, mais nous nous rapprochons et nous en parlerons dans le prochain article.

Je vous recommande de jouer avec l’  option Afficher le titre pour voir comment il s’affiche sur le front-end compte tenu du balisage que nous avons fourni.

Pour l’instant, la sortie du widget devrait ressembler à ceci :

Mais c’est tout ce qu’il y a à couvrir dans ce post.

Dans le refactor final

La dernière chose que nous allons examiner après cela est de resserrer une partie de la logique conditionnelle avec un mot sur la mise en cache des données (puisque nous en faisons déjà un peu dans les articles précédents).

Pour l’instant, cependant, n’hésitez pas à jouer avec ce que nous avons ici avec le code que nous n’avons pas inclus (comme ce qui peut être affiché avant ou après le widget.

Ils ont été délibérément exclus de cet exemple, mais ils ne le seront peut-être pas toujours en fonction du travail que vous effectuez.