Widgets WordPress : une approche orientée objet
Il y a des années, j’ai créé le WordPress Widget Boilerplate visant à être le suivant :
Un passe-partout organisé et maintenable pour créer des widgets en utilisant les meilleures pratiques de WordPress.
Depuis lors, peu de choses ont changé en ce qui concerne l’ API Widgets (que nous examinerons plus tard dans cet article), mais ce que je considère comme les « meilleures pratiques » a changé. De plus, la mesure dans laquelle je pense que cette API est un solide exemple d’introduction à la programmation orientée objet dans WordPress est élevé.
Ce n’est pas parce qu’il utilise beaucoup de principes orientés objet, ce n’est pas parce qu’il utilise des normes modernes (du moins en ce qui concerne le PHP moderne), mais parce qu’il utilise quelques éléments qui nous aident à en reconnaître quelques-uns, disons, signaux concernant la programmation orientée objet dans WordPress.
Et c’est quelque chose qui ne doit pas être sous-estimé : si vous recherchez des exemples de programmation orientée objet dans WordPress, recherchez des API qui l’utilisent.
De plus, si vous cherchez des moyens d’évaluer votre propre niveau d’évaluation d’un morceau de code (sans parler d’une base de code) pour l’utilisation de classes et de certaines des fonctionnalités les plus avancées de la POO, alors pourquoi ne pas avoir une sorte d’un test décisif pour voir comment vous allez ?
Et l’API Widgets fait exactement cela.
Widgets WordPress: une introduction
Donc, dans une série plus petite que la précédente, je vise à regarder l’API Widgets et à faire quelques choses :
- vous montrer le squelette de base d’un widget et pourquoi il est orienté objet,
- discuter des choses que vous devriez être en mesure de remarquer et pourquoi,
- mettez d’abord à jour le Widget Boilerplate directement sur ce site, puis envoyez-le à GitHub,
- construire un widget en utilisant l’API avec le passe-partout comme base de notre travail.
Et dans cet article, nous allons commencer par le premier point ci-dessus.
Mais d’abord…
Avant d’entrer dans cet article, je vous recommande de lire les articles suivants :
- Deux piliers de la programmation orientée objet: partie 1 sur 2
- Deux piliers de la programmation orientée objet: partie 2 sur 2
- Classes abstraites, partie 1 – Comportement d’abstraction
- Classes abstraites, partie 2 – Classes abstraites et interfaces
Une fois cela fait (ou si vous sentez que vous maîtrisez déjà les sujets), nous sommes prêts à commencer.
[restrict payé="true »]
Les bases de l’API Widgets
Si vous lisez la page du manuel sur les widgets, vous verrez beaucoup de contenu. C’est une bonne chose, mais ce n’est pas toujours la meilleure décision lorsque vous essayez de distiller du contenu à un public tel que vous lorsque vous recherchez des conseils pratiques et orientés objet.
Je vais donc sélectionner les parties pertinentes de la documentation de l’API, puis les appliquer au code qui nous est également fourni.
Qu’est-ce qu’un widget ?
Je pense que la plupart d’entre nous qui travaillons avec WordPress savent ce qu’est un widget, mais il est important de définir le terme afin que nous travaillions tous sur la même idée. Le manuel se lit comme suit :
Un widget est un objet PHP qui génère du HTML. Le même type de widget peut être utilisé plusieurs fois sur la même page (par exemple, le widget de texte). Les widgets peuvent enregistrer des données dans la base de données (dans le tableau des options).
Avec cela en place, regardons le code d’un widget personnalisé, au moins un bout de celui-ci, et voyons ce que nous pouvons glaner en ce qui concerne sa nature orientée objet.
La classe des widgets
Avant même de regarder le code, nous savons qu’il y aura un certain niveau de programmation orientée objet simplement parce que la documentation nous dit de faire trois choses :
- Créez la classe de votre widget en étendant la classe standard WP_Widget et certaines de ses fonctions.
- Enregistrez votre widget afin qu’il soit disponible dans l’ écran Widgets.
- Assurez-vous que votre thème comporte au moins une zone de widgets dans laquelle ajouter les widgets.
Dans cet article, je vais me concentrer sur le premier point (bien que nous verrons éventuellement comment nous introduisons nos widgets dans un thème avant la fin de la série).
Présentons donc le code tel qu’il est présenté dans la documentation et parlons de ce que nous pouvons en apprendre :
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Tout d’abord, nous remarquons que bien que nous ayons défini une classe (que nous pouvons nommer comme nous voulons, ma façon), elle doit étendre WP_Widget. Cela signifie que dans le noyau de WordPress, il existe une classe WP_Widget. Vous pouvez voir une répartition bien organisée du code source sur cette page.
Deuxièmement, le mot clé extend indique que nous utilisons l’ héritage PHP qui est un pilier central de la programmation orientée objet.
Troisièmement, il y a quatre fonctions que nous devons implémenter dont deux nécessitent des arguments. Les fonctions que nous devons implémenter sont les suivantes :
- __construct() qui est le constructeur de classe de base. C’est là que nous devrons nous assurer que le constructeur de la classe parent est appelé, s’il y en a un, puis nous initialisons les propriétés que nous jugeons nécessaires pour notre widget. Nous y reviendrons plus tard dans la série.
- widget() est responsable de la sortie du contenu du widget que l’utilisateur fournit à l’aide de l’interface dans la zone administrative. Il accepte deux paramètres – $args et $instance. Le paramètre $args est l’information à rendre sur la page, et le $instance est une référence à l’instance du widget (puisque plusieurs widgets peuvent être rendus sur une page).
- form() affiche l’interface administrative avec laquelle l’utilisateur interagit pour guider ce qui est affiché sur le front-end du site. Il nécessite également l’ argument $instance afin que les informations fournies concernent le widget réel avec lequel l’utilisateur travaille (par rapport à toutes les instances du widget).
- update() est utilisé pour enregistrer les valeurs dans l’instance actuelle du widget. Il accepte deux arguments. Le premier est la nouvelle instance du widget avec les valeurs de mises à jour que l’utilisateur a fournies (pensez à mettre à jour la valeur d’un widget texte actif) et le deuxième argument est celui de l’ancienne instance du widget ou peut-être de l’instance précédente ou peut-être " l’instance qui contenait les valeurs précédentes.
Ces quatre fonctions doivent être implémentées dans le cadre de l’API Widget, dans le cadre des fonctions héritées de l’interface étendue, et pour produire les fonctionnalités de base d’un widget.
Cela ne signifie pas que plus ne peut pas être ajouté, mais dans le bon sens orienté objet, il serait probablement préférable de reléguer ce comportement dans d’autres classes. Mais nous verrons cela plus tard dans la série lorsque nous créerons notre propre widget.
Quels sont les principaux plats à emporter ?
Pour être sûr que je suis clair sur ce qui serait compris de ce post, c’est le suivant:
- L’API Widgets est orientée objet. Ce n’est pas seulement orienté objet parce qu’il utilise une classe (bien que ce soit certainement un bon point de départ), mais aussi parce qu’il hérite de fonctionnalités intégrées dans une classe de base préexistante.
- Chaque fois que nous héritons du comportement d’une classe de base ou d’une classe parente, nous obtenons gratuitement des fonctionnalités pré-développées. C’est une très bonne chose à propos de la programmation orientée objet car elle nous permet de nous concentrer spécifiquement sur la logique de programmation que nous souhaitons mettre en œuvre.
Imaginez un instant que vous souhaitiez développer un widget, mais à chaque fois que vous le faites, vous devez écrire toutes les fonctionnalités des crochets dans WordPress pour faire toutes les mêmes fonctionnalités passe-partout répétitives.
C’est là que l’héritage et la programmation orientée objet entrent en jeu. Le code répétitif est abstrait dans une classe de base, il n’est donc écrit qu’une seule fois, puis le code sur lequel nous voulons nous concentrer est laissé à notre implémentation.
Tout ce qui précède est ce qu’il faut comprendre lors de la lecture de cette passe initiale au code source pour une API de base orientée objet dans WordPress.
Et après?
Dans le prochain article de cette série, nous allons examiner la nature orientée objet de l’API Widgets et les éléments que vous devriez pouvoir détecter immédiatement en lisant le code.
En effet, il est important de reconnaître certains principes orientés objet dans la pratique et c’est un bon moyen d’évaluer si vous êtes capable de le faire ou non. Si c’est le cas, super ! Ensuite, il continuera à aider à développer ce muscle. Sinon, pas de soucis – cela vous aide toujours à développer ce muscle.
Et cela vous servira bien alors que nous continuons à nous orienter de plus en plus vers le développement WordPress orienté objet par des moyens pratiques.
La théorie nécessaire a été couverte. Commençons donc à le mettre en pratique.