Widgets WordPress : refactorisation, partie 8
En ce qui concerne la refactorisation du WordPress Widget Boilerplate, nous avons fait beaucoup de travail pour amener la base de code à une norme plus orientée objet. De plus, nous avons introduit une variété d’autres outils qui nous permettent d’adapter notre code à des normes plus modernes.
Maintenant que nous avons passé du temps à le faire, il est temps de revenir dans le code et de commencer à le refactoriser de manière à permettre l’utilisation de classes abstraites et d’abonnés (qui fonctionnent dans le cadre du modèle de conception piloté par les événements ).
A la fin du message précédent, j’ai écrit :
Dans les prochains articles, nous verrons comment nous pouvons implémenter des abonnés pour le côté public du site (c’est-à-dire là où le contenu du widget est affiché). Et nous ferons de même pour la zone d’administration du site.
Donc, dans cet article, nous allons faire exactement cela. Plus précisément, nous allons commencer par travailler sur un abonné pour le widget, puis faire en sorte que le widget de base s’affiche d’abord du côté administratif du site.
Le passe-partout du widget WordPress : refactorisation, partie 8
La raison pour laquelle je souhaite me concentrer d’abord sur le côté administratif du site est que cela nous permet de :
- comprendre le fonctionnement des abonnés,
- voir comment la base de code devra être organisée,
- coder en dur certaines informations avant de travailler avec la sérialisation.
Une fois que tout cela sera en place, nous serons en bonne position pour porter notre attention sur des choses plus avancées. À savoir, nous pourrons introduire des abonnés pour afficher des informations dans la zone d’administration et des abonnés pour nettoyer, sérialiser, récupérer, valider et afficher des données.
Mais d’abord, faisons le travail nécessaire pour mettre en place une nouvelle classe, configurer le chargeur automatique et afficher le contenu dans la zone administrative du site.
1 L’abonné abstrait
Examinons d’ abord l’abonné abstrait, car c’est ce que tous les abonnés implémenteront.
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* An abstract implementation of a subscriber that requires a hook and the ability to
* start the class.
*/
abstract class AbstractSubscriber
{
/**
* @var string a reference to the hook to which the subscriber should be registered
*/
protected $hook;
/**
* @param string $hook the hook to which the subscriber is registered
*/
public function __construct(string $hook)
{
$this->hook = $hook;
}
/**
* @return string the hook to which the subscriber is registered
*/
public function getHook(): string
{
return $this->hook;
}
/**
* Implements the domain logic for the concrete class implementating this subcriber.
*/
abstract public function load();
}
Notez qu’il a deux fonctions publiques – la construction qui définit le crochet et une fonction pour récupérer le crochet. Il a également une fonction de chargement abstraite qui est l’endroit où toute classe qui étend cette classe implémente sa fonctionnalité spécifique.
Rappelez-vous qu’en raison de la façon dont WordPress gère les actions et les filtres, tout est attaché à un crochet spécifique (soit ceux que WordPress définit, soit des crochets personnalisés).
2 L’espace de noms WordPress
Chaque fois que je travaille sur une fonctionnalité étroitement liée à WordPress, j’essaie de m’assurer de la placer dans un espace de noms WordPress. Cela m’indique, ainsi qu’aux autres développeurs, que tout ce qui réside dans cet espace de noms ne peut pas être séparé de l’application principale.
Donc, dans le répertoire src, créez un répertoire WordPress. C’est là que la classe Widget de base résidera avec toutes les autres classes introduites tout au long de cette série.
Cela signifie que nous n’avons plus besoin de la classe dans le répertoire de l’API. Assurez-vous donc de déplacer la classe, de mettre à jour son espace de noms et de supprimer le répertoire. J’aurai une capture d’écran et du code pour cela un peu plus tard.
De plus, rappelez-vous plus tôt dans la série, nous avons placé le répertoire Views à la racine du répertoire src, mais maintenant nous pouvons le déplacer vers le répertoire WordPress. Alors allez-y et faites-le maintenant.
Le résultat final devrait ressembler à ceci :
Nous pouvons maintenant porter notre attention sur le code.
3 Un regard sur la classe Widget
Nous allons simplifier un peu la classe principale des widgets dans cet article. Cela va annuler une partie du travail que nous avons fait, mais nous avions besoin de ce travail antérieur pour arriver à ce point.
Pour l’instant, nous nous concentrons sur le constructeur et la fonction de récupération du slug de widget. C’est ce qui nous permettra finalement de voir quelque chose dans la zone administrative de WordPress.
Donc, d’abord, assurez-vous que votre classe Widget ressemble à ceci :
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateWordPress;
use WP_Widget;
class Widget extends WP_Widget
{
/**
* @var string unique identifier for your widget
*/
protected $widgetSlug;
/**
* Initializes the plugin by setting its properties and calling the parent class with the description.
*
* @param mixed $widgetSlug
*/
public function __construct($widgetSlug)
{
$this->widgetSlug = $widgetSlug;
parent::__construct(
$this->getWidgetSlug(),
__('Widget Name', $this->getWidgetSlug()),
[
'classname' => $this->getWidgetSlug().'-class',
'description' => __('Short description of the widget goes here.', $this->getWidgetSlug()),
]
);
}
/**
* Return the widget slug.
*
* @return string slug variable
*/
public function getWidgetSlug()
{
return $this->widgetSlug;
}
}Ensuite, puisque nous avons déplacé ce fichier vers l’ espace de noms WordPress, nous devons mettre à jour la section autoload de notre fichier de configuration Composer :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Ensuite, nous devons présenter un abonné.
4 Présentation de l’abonné Widget
Chaque fois que j’ai une classe principale quelconque, j’essaie généralement de créer un abonné simple qui instancie la classe principale et lui permet de faire son travail.
Je le fais parce que WordPress, comme mentionné, utilise le modèle de conception piloté par les événements, ce qui signifie que tout doit être enregistré sur un type de crochet. Et je n’aime pas mélanger la logique de domaine avec la même classe qui s’accroche à WordPress. Alors je les sépare.
Et c’est ce que fait un abonné. Il s’enregistre auprès de WordPress puis invoque la classe responsable de l’exécution du travail.
Cela dit, portez votre attention sur le répertoire des abonnés et ajoutez une classe appelée WidgetSubscriber. Dans cette classe, ajoutez le code suivant :
<?php
<?php
namespace WordPressWidgetBoilerplateSubscriber;
use WordPressWidgetBoilerplateWordPressWidget;
/**
* Initializes the core Widget class that's used by WordPress to instantiate the widget,
* renders the administrative area, provide serialization functionality, and displays the
* public-facing view.
*/
class WidgetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Registers the core Widget class using the WordPress APIs.
*/
public function load()
{
register_widget(new Widget('widget-name'));
}
}
Le constructeur enregistrera la classe avec un hook spécifique que nous verrons dans un instant ; puis il utilisera l’API WordPress pour instancier notre widget (c’est ce qui se passe dans la fonction de chargement ).
5 Le bootstrap
Enfin, nous devons mettre à jour le bootstrap afin qu’il :
- enregistre le WidgetSubscriber avec le crochet approprié,
- ajoute l’abonné au Registre ,
- et démarre le plugin (ce que nous avons fait).
Le bootstrap, après tout cela, devrait ressembler à ceci :
<?php
namespace WordPressWidgetBoilerplate;
use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;
use WordPressWidgetBoilerplateSubscriberWidgetSubscriber;
// Prevent this file from being called directly.
defined('WPINC') || die;
// Include the autoloader.
require_once __DIR__. '/vendor/autoload.php';
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
return $registry;
});
// Add the Widget base class to the Registry.
$registry->add('widgetSubscriber', new WidgetSubscriber('widgets_init'));
// Start the machine.
(new Plugin($registry))->start();Ensuite, vous devriez pouvoir vous connecter à WordPress et activer le plugin.
Un regard sur la zone administrative
À ce stade, il n’y a pas grand-chose à regarder, mais nous y arrivons. Tout d’abord, vous devez remarquer que le widget apparaît maintenant dans la zone qui comprend les widgets disponibles :
Et vous devriez également voir que lorsque vous faites glisser le widget vers une zone widgetisée (ou n’importe quelle barre latérale), aucune option n’est disponible.
Cela dit, nous sommes bien placés pour continuer à bâtir sur ce que nous avons. Vous pouvez toujours continuer à suivre le développement du passe-partout sur GitHub.
Continuer
Ensuite, nous continuerons à développer des fonctionnalités pour la zone administrative du widget. Après cela, nous porterons notre attention sur le côté public du widget ainsi que sur la fonctionnalité de sérialisation.
Vous devriez être en mesure de voir comment les choses commencent à prendre forme alors que nous commençons à séparer la logique en ses diverses composantes. Sinon, ne vous inquiétez pas – il y a beaucoup plus à venir.
Et la version finale du Boilerplate démontrera bien sûr tous les principes sur lesquels nous nous appuyons tout au long de cette série de publications.