Deux façons de développer des plugins WordPress Programmation orientée objet

Quand il s'agit d'écrire des plugins WordPress, il y a généralement deux façons de le faire: la programmation orientée objet et la programmation fonctionnelle (les widgets étant l'exception - nous verrons cela plus loin dans l'article).

Bien que les gens se portent généralement pour un style de programmation par rapport à un autre, chacun présente ses propres avantages et inconvénients..

Dans cette série en deux parties, Stephen Harris et moi allons détailler les deux manières d’écrire des plugins WordPress. Plus précisément, je vais parler de la programmation orientée objet, et il couvrira la programmation fonctionnelle.

Comme le niveau d'expérience des lecteurs varie, nous allons parler de programmation de haut niveau. Si vous êtes débutant, vous ne devriez pas avoir de problème à vous suivre. Si, toutefois, vous êtes un développeur plus expérimenté, vous pourrez trouver d'autres informations utiles plus tard dans l'article..

Cela dit, commençons par regarder une approche orientée objet pour développer des plugins WordPress.


Développer des Widgets WordPress

Comme mentionné dans l'introduction, les plugins peuvent être développés pour WordPress de deux manières:

  1. Programmation orientée objet
  2. Programmation fonctionnelle

Le deuxième article de la série couvrira la programmation fonctionnelle, mais fournissons une définition de travail de la programmation orientée objet afin que nous soyons tous au même niveau tout au long de cet article..

Wikipédia déclare:

La programmation orientée objet (POO) est un paradigme de programmation utilisant des "objets" - généralement des instances d'une classe - constitués de champs de données et de méthodes ainsi que de leurs interactions - pour concevoir des applications et des programmes informatiques..

Ceux qui sont plus expérimentés en programmation informatique, notamment ceux qui utilisent des techniques de programmation orientées objet aimeront probablement cette définition.

Mais simplifions le propos de cet article:

La programmation orientée objet est une technique de programmation qui utilise un ensemble de méthodes apparentées pour définir un programme d'ordinateur ou une partie d'un programme d'ordinateur..

Assez simple, non? Dans notre cas, nos plugins sont définitivement partie d'un programme d'ordinateur, car ils sont accrochés à WordPress.

Bien que nous examinions le code dans le reste de cet article, notez que les programmes orientés objet sont identifiés par le regroupement de leurs méthodes associées. cette est fait dans le contexte de ce qu'on appelle une classe - que nous couvrirons momentanément.

Un mot sur les widgets

Bien qu'il soit vrai que les plugins WordPress puissent être développés à l'aide de la programmation orientée objet ou fonctionnelle, il existe une exception en matière de développement de widgets..

Selon l'article du Codex sur le développement de widgets, la structure suivante doit être utilisée pour écrire un widget:

classe My_Widget étend WP_Widget fonction publique __construct () // processus réels du widget formulaire de fonction publique ($ instance) // génère le formulaire d'options sur admin mise à jour de la fonction publique ($ new_instance, $ ancien_instance) // traite les options de widget à enregistrer widget de fonction publique ($ args, $ instance) // affiche le contenu du widget

Cela signifie que tout Les widgets doivent être écrits en utilisant la POO. Si vous n'avez pas vu le code comme ci-dessus, nous le couvrirons dans la section suivante et il devrait fournir tout ce que vous devez savoir pour comprendre ce qui se passe..


Une introduction concise à la POO

Avant de commencer à concevoir des plugins basés sur la POO pour WordPress, examinons de plus près les bases de la POO afin de nous assurer que la terminologie est claire et que le paradigme fonctionne..

Des classes

Comme nous l'avons défini précédemment, la programmation orientée objet utilise "un ensemble de méthodes associées". Mais nous ne pouvons pas nous arrêter là. Après tout, la programmation fonctionnelle fait la même chose.

En POO, ces "méthodes associées" sont toutes liées dans le contexte de ce qu'on appelle une classe. Dans l'exemple de widget ci-dessus, vous verrez le classe mot-clé comme le tout premier mot du code.

Il commence par une ligne qui se termine par un crochet d’ouverture (un peu comme les fonctions), puis encapsule - ou enveloppe - toutes ses fonctions associées avant de se terminer par le crochet de fermeture (pour l’instant, ignorez le s'étend mot-clé dans l'exemple du widget - nous en parlerons dans un instant).

Un regroupement logique de fonctions

Si vous commencez juste à écrire des cours et que vous vous demandez si une fonction appartient à une classe donnée, demandez-vous si la fonction sonne comme quelque chose que cette classe ferait.

Par exemple, dans l'exemple de widget ci-dessus, le mettre à jour méthode est évidemment quelque chose qu'un widget ferait. Mais disons que vous écrivez une classe qui sera responsable de la lecture d'un article de blog dans la base de données WordPress. Il serait logique que cette classe particulière ait une fonction appelée lis ou read_by_id, mais devrait-il avoir une fonction appelée écrire? Qu'en est-il de effacer?

Selon la façon dont vous avez conçu votre classe, éventuellement. Mais si le Unique but de la classe est de lire des données, alors probablement pas.

Et c’est ça la POO: il regroupe logiquement vos fonctions dans une classe, mais ledit groupe logique dépend de la responsabilité que vous assignez à votre classe..

Sujets avancés en POO

La POO est un puissant paradigme qui est utilisé dans toute l'application WordPress. La POO permet des opérations avancées telles que l’héritage (représenté par le s'étend mot-clé dans la classe Widget), des modèles de conception qui sont essentiellement des solutions existantes aux problèmes courants.

Cet article n'essaie pas de plonger profondément dans la programmation orientée objet. Il s'agit simplement d'essayer de fournir une base à partir de laquelle nous pouvons explorer les deux manières d'écrire des plugins WordPress, mais je les mentionne ici si vous êtes intéressé à approfondir davantage la programmation orientée objet..


Développer des plugins de classe

Maintenant que nous avons défini la programmation orientée objet et que nous en avons suffisamment exploré pour jeter les bases, il est temps de commencer à parler des composants du développement basé sur la programmation orientée objet dans le contexte des plugins WordPress..

Dans le reste de cet article, nous allons couvrir les bases de ce qui est nécessaire pour écrire des plugins basés sur la POO, et les avantages que cela apporte..

Définir la classe

Avant de faire n'importe quoi dans le développement orienté objet, vous devez définir votre classe. En supposant que vous ayez déjà une idée de ce que votre classe va faire, il s’agit généralement de trouver le nom de votre classe..

Pour la plupart, je pense que la visualisation d'un exemple de code est toujours un avantage lors de son apprentissage. Nous allons donc jeter un coup d'œil au plugin WordPress Plugin Boilerplate..

Notez que le plugin Boilerplate est un projet que j'ai créé à l'origine pour aider à relancer les plugins basés sur la POO. Il a depuis été contribué par un certain nombre de personnes différentes. Je l'utilise dans cet article parce qu'il montre le sujet à portée de main.

Cela dit, notez que la définition de classe pour le plugin Boilerplate ressemble à ceci:

class PluginName // Plus à venir…

Le plugin Boilerplate étant un point de départ pour le développement, nous voudrions évidemment renommer la classe. Pour cet article, appelons-le DemoPlugin.

class DemoPlugin // D'autres à venir…

À ce stade, nous sommes prêts à commencer à définir des fonctions qui vivent dans la classe..

Le constructeur

Dans OOP, la première fonction que vous êtes susceptible de voir dans une classe est une fonction appelée "le constructeur" et PHP n'est pas différent.

Une définition simple et pratique du constructeur est la suivante:

Le constructeur est l'endroit où vous initialisez les données qui seront utilisées dans la classe.

Comment cela fonctionne varie d'un projet à l'autre, mais nous pouvons faire deux choses principales dans le contexte d'un plugin WordPress:

  1. Configurer le domaine de texte à des fins de localisation
  2. Définir nos actions et filtres (en particulier nos actions et nos filtres).

Dans notre DemoPlugin, c'est ce que nous allons faire. Nous allons définir un textdomain de démo-plugin et nous enregistrerons des actions pour enregistrer et mettre en file d'attente un exemple de feuille de style et un exemple de fichier JavaScript.

Pour être complet dans notre exemple, nous allons également enregistrer un hook pour ajouter du texte à la fin du contenu affiché dans un message..

Commençons par définir le constructeur:

class DemoPlugin fonction publique __construct () 

Notez qu'en PHP, un constructeur est défini par une fonction publique nommée construction qui est précédé de deux traits de soulignement.

Ensuite, définissons notre textdomain:

class DemoPlugin fonction publique __construct () load_plugin_textdomain ('demo-plugin', false, nom de répertoire (plugin_basename (__FILE__)). '/ lang'); 

Dans la ligne de code ci-dessus, notez que nous avons défini la clé de notre domaine textdomain: démo-plugin et la ligne s'attend à trouver les fichiers de localisation dans un sous-répertoire appelé lang dans le répertoire du plugin.

La localisation étant hors de propos pour cet article, je ne vais pas plonger plus loin, mais vous pouvez consulter le code source du Plugin Boilerplate pour voir comment il est configuré..

Ensuite, définissons les actions pour l’enregistrement de nos feuilles de style et de notre code JavaScript, ainsi que le filtre qui ajoutera du texte à la fin de notre contenu:

class DemoPlugin fonction publique __construct () load_plugin_textdomain ('demo-plugin', false, nom de répertoire (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', tableau ($ this, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); 

Si vous n'êtes pas familiarisé avec les actions et les filtres, veillez à lire l'un de mes articles récents ici sur Wptuts +, car il explique la différence..

Maintenant, si vous connaissez le développement de thèmes WordPress ou la programmation fonctionnelle, vous êtes probablement habitué à voir quelque chose comme ce qui suit:

add_action ('wp_enqueue_scripts', 'register_plugin_styles');

Plutôt que:

add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles'));

Notez que la différence entre les deux appels ci-dessus est dans le deuxième paramètre. Plus précisément, dans notre plugin, nous passons un tableau alors que la première ligne de code passe simplement une chaîne.

Parce que nous développons ce plugin en utilisant la POO, WordPress doit savoir où appeler le register_plugin_styles méthode. Comme il habite dans notre classe, nous devons dire à WordPress d'appeler la méthode sur une instance de notre classe.

Avoir du sens?

Pour l’essentiel, nous disons à WordPress: j’ai cette méthode appelée register_plugin_styles, mais vous devez l'appeler sur une instance de cette classe (d'où le ce mot-clé).

Si vous êtes nouveau dans WordPress, mais que vous venez d'un environnement de programmation, vous pouvez imaginer que vous demandez à WordPress de le faire:

$ demo = new DemoPlugin (); $ demo-> register_plugin_styles ();

Quoi qu’il en soit, l’essentiel est que si vous développez vos plugins en utilisant la POO, vous doit enregistrez vos hooks en utilisant un tableau avec deux index: le premier étant $ this et le second étant le nom de la fonction.

Une note sur le passage par référence et passage par valeur

Les développeurs avancés seront familiarisés avec la capacité de PHP à passer par référence et à transmettre par valeur. Dans WordPress Development, il n'est pas rare de voir ce qui suit:

add_action ('wp_enqueue_scripts', tableau (& $ this, 'register_plugin_styles'));

ce est passé par référence; Cependant, depuis PHP 5.4, la possibilité de passer des variables par référence au moment de l'appel a été supprimée. C'est pourquoi ce tutoriel choisit de passer par valeur.

Les fonctions

En programmation, les fonctions sont les unités de code qui sont essentiellement responsables de "faire quelque chose". En programmation orientée objet, il est utile de les penser légèrement différemment.

En POO, les classes sont généralement représentées par des noms. Dans notre cas, nous avons un DemoPlugin. De même, les fonctions sont souvent des verbes. Autrement dit, ce sont des actions que notre nom peut prendre. À ce stade, nous avons déjà choisi de définir les fonctions suivantes:

  • register_plugin_styles
  • register_plugin_scripts
  • append_post_notification

Notez que chaque nom de fonction représente une action pouvant être entreprise. C'est une bonne règle à suivre pour écrire des fonctions.

En programmation fonctionnelle, il n'y a vraiment que l'idée de fonctions; Cependant, dans OOP, il existe plusieurs types de fonctions, dont deux sont des fonctions "publiques" et des fonctions "privées"..

Fonctions publiques

Les fonctions publiques sont des fonctions accessibles en dehors de la classe. Cela signifie que vous pouvez appeler ces méthodes une fois que vous avez instancié la classe..

C'est exactement ce que nous avons fait précédemment dans le code suivant:

$ demo = new DemoPlugin (); $ demo-> register_plugin_styles ();

Fondamentalement, ces fonctions sont accessibles au public (le public pouvant être un programmeur ou un autre objet).

Les fonctions que nous écrivons pour enregistrer nos feuilles de style, notre JavaScript et que nous écrivons pour ajouter du texte à un message avoir être marqué comme public parce qu'il y volonté être un tiers appelant sur eux - WordPress.

Définissons les deux fonctions pour le wp_enqueue_scripts action:

fonction publique register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ('demo-plugin');  fonction publique register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ('demo-plugin'); 

Encore une fois, notez que ces deux fonctions s’attendent à ce que les feuilles de style et JavaScript résident dans css et js sous-répertoires, respectivement. Pour voir cela en action, n'oubliez pas de consulter le Plugin Boilerplate.

Enfin, définissons la fonction pour le contenu filtre:

fonction publique append_post_notification ($ content) $ notification = __ ('Ce message a été ajouté à un plugin de démonstration.', 'demo-plugin-locale'); retourne $ contenu. $ notification; 

Notez que nous utilisons la fonction __ pour nous assurer que notre script est localisé avec le textdomain que nous avons défini dans le constructeur.

Fonctions privées

Si les méthodes publiques sont accessibles à quiconque, cela impliquerait que les fonctions privées ne sont accessibles par personne, non? Pour l’essentiel, c’est exact: la seule personne - ou chose - qui peuvent appeler des méthodes privées sont la classe dans laquelle elles sont définies.

Cela signifie que WordPress, les objets tiers, ni les programmeurs ne peuvent appeler par programme des fonctions privées. Les fonctions privées ne peuvent être appelées qu'à partir de la classe dans laquelle elles sont utilisées.

De manière générale, les fonctions privées sont très utiles lors de l'écriture de méthodes d'assistance - c'est-à-dire qu'elles sont utiles pour manipuler des données en interne afin d'aider une autre fonction à s'acquitter de sa tâche..

Pour donner un exemple de travail, définissons une fonction privée qui retournera une chaîne localisée que notre append_post_notification fonction peut utiliser:

fonction privée get_localized_notification () return __ ('Ce message a été ajouté avec un plugin de démonstration.', 'demo-plugin-locale'); 

Ensuite, refactorisons le append_post_notification fonction pour appeler cette nouvelle aide:

fonction publique append_post_notification ($ content) return $ content. $ this-> get_localized_notification (); 

Notez que nous avons simplifié la première fonction en ajoutant une deuxième fonction. Vous pouvez également dire que nous avons amélioré la lisibilité de la fonction initiale en ajoutant un appel à une fonction avec un nom permettant de clarifier ce qui se passe..

La chose la plus importante à noter est peut-être que pour appeler des fonctions privées, vous devez préfixer l’appel de fonction avec $ this mot clé et le ->. Ceci dit à PHP: "Appelle le get_localized_notification fonction qui vit dans ce classe."

Quoi qu'il en soit, nous avons attribué à chaque méthode une responsabilité unique - une autre bonne pratique en programmation orientée objet - et nous avons démontré l'utilisation de fonctions publiques et privées..

Autres types de fonctions

En programmation orientée objet, il existe également d'autres types de fonctions qui sortent du cadre de cet article..

Pour être complet, je voulais les résumer ici:

  • Les fonctions statiques sont des fonctions qui ne nécessitent pas l'appel d'une instance d'une classe. Au lieu de cela, vous pouvez simplement les appeler directement sur le nom de la classe. Par exemple: DemoPlugin :: use_this_static_method ().
  • Les fonctions protégées ressemblent aux fonctions privées, à l'exception des sous-classes. Autrement dit, les seuls objets pouvant accéder aux fonctions protégées sont les sous-classes de la classe donnée. Ce type particulier de fonction joue dans le concept de succession qui a été mentionné plus haut dans l'article.

Avantages dans WordPress

À ce stade, nous avons atteint toutes les notes optimales en matière de développement WordPress orienté objet. Pour résumer les avantages:

1. Toutes les fonctions sont en contexte

Lorsque vous utilisez une programmation orientée objet, vous n'avez pas besoin de préfixer une fonction avec le nom du thème ou du nom du plug-in sur lequel vous travaillez, ni de vous inquiéter de nommer une fonction avec laquelle vous pourriez interférer. une fonction WordPress, la fonction d'un autre thème ou la fonction d'un autre plugin.

Au lieu de cela, toutes les fonctions vivent dans le contexte d'une autre classe. La seule chose à vérifier est que votre classe n'est pas nommée, ce qui interfère avec une autre classe existante..

2. Les appeler en dehors de l'API

En utilisant la programmation orientée objet, vous pouvez appeler par programmation votre plug-in en dehors de l'API WordPress standard..

Disons que vous développez un thème et que vous souhaitez que quelque chose soit affiché dans la barre latérale fournie par votre plugin. Dans le modèle de la barre latérale, vous pouvez réellement instancier votre plug-in, puis appeler des méthodes dessus pour qu'il écrive des informations dans la barre latérale..

Ceci est particulièrement utile lorsque vous travaillez sur un modèle et que vous souhaitez fournir des données par défaut si l'utilisateur n'entre pas quelque chose manuellement.


Conclusion

Comme nous l’avons dit au début de l’article: c’est un moyen de développer vos plugins WordPress. L'article de Stephen expliquera comment le faire en utilisant une programmation fonctionnelle.

Après avoir lu cet article, vous devriez avoir une meilleure compréhension de la programmation orientée objet, de ses avantages et pouvoir suivre le code documenté dans l'API du widget, dans mon Widget Boilerplate, et même dans certains endroits de la base de code WordPress.


Ressources

  • Stephen Harris
  • Wikipedia sur la POO
  • Ecrire un plugin
  • API de plugin
  • API de widget
  • WordPress Widget Boilerplate
  • WordPress Plugin Boilerplate
  • textdomain
  • Action référence
  • Référence du filtre
  • __