Dans ce tutoriel, je vais vous expliquer une technique qui vous permet d'utiliser un fichier de modèle pour tous vos besoins en HTML! Vous n'aurez plus besoin de "faire écho" les chaînes depuis vos fonctions, ni de vous soucier de passer ou non de PHP simplement pour afficher des balises.
J'ai passé de nombreuses années à utiliser les frameworks MVC (tels que Zend et Laravel aujourd'hui) où il est recommandé de séparer votre "logique de programmation" (fonctions ou méthodes) de votre "vue" (le balisage HTML résultant). Ce toujours conduit à une base de code plus facile à gérer et il est en fait beaucoup plus facile à écrire. Cette expérience m'a incité à proposer une solution similaire lors du développement de plugins pour WordPress! Ce n'est pas très chic - c'est juste un petit "assistant" qui vous permettra de supprimer tous les fragments HTML et les "échappements" gênants de vos fonctions et de les placer en toute sécurité dans leur propre fichier "modèle".
Donc, j'espère que ce tutoriel vous intéressera et sans plus tarder, commençons!
Commençons ce tutoriel en jetant un coup d'oeil à ce que nous allons améliorer.
Il est très courant de voir quelque chose comme ceci dans un plugin: (cet extrait provient en fait d'un de mes propres tutoriels sur ce site: p)
add_shortcode ('faq', function () $ posts = get_posts (array (// Obtient la FAQ Type de message personnalisé. 'numberposts' => 10, 'orderby' => 'menu_order', 'order' => 'ASC', 'post_type' => 'faq',)); $ faq = ''; // Ouvre le conteneur foreach ($ posts en tant que $ post) // Génère le balisage pour chaque question $ faq. = Sprintf ((''; // Ferme le conteneur return $ faq; // retourne le HTML. );% 1 $ s
% 2 $ s'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
Eh bien rien, vraiment. Mais il pourrait être plus propre, plus facile à redimensionner et à maintenir!
En partant du haut vers le bas, nous pouvons voir que tous dans une seule fonction nous sommes:
Maintenant, vous pouvez très bien regarder cela et penser "C'est un gros problème! Ce n'est que quelques lignes de HTML, quel est le problème?" À certains égards, vous avez bien le droit de penser de la sorte. Mais rappelez-vous, il n’ya que 17 lignes de code pour le moment - que se passe-t-il lorsque vous développez / améliorez le plugin? Que se passe-t-il lorsque votre plugin atteint 50/100/1000 lignes de code (ou plus!). Serez-vous toujours heureux d'avoir des chaînes HTML dispersées autour de votre fonction à différents endroits? Que se passe-t-il lorsque vous voulez générer du code HTML nécessitant une "échappatoire" gênante pour fonctionner correctement dans votre code PHP??
Espérons que vous puissiez constater que cette approche de création et de sortie de balises HTML peut devenir très problématique! Sans compter qu'il devient très difficile de maintenir et d'améliorer le code HTML lorsqu'il est simplement dispersé.
Donc, avec tout cela à l’esprit, j’ai décidé de changer votre façon de penser la sortie HTML dans WordPress. Pour toujours.
Ok, commençons à craquer avec ça.
Notre plugin est simple, il ne comprend que le Vue
classe afin que nous puissions l'utiliser dans l'un de nos autres plugins.
/ * view_renderer.php * / include ('View.php');
Ok, maintenant que nous avons inclus le Vue
classe, il est temps de le construire.
Ici nous avons une classe appelée Vue
avec une seule fonction statique appelée rendre
(cela nous permettra d'utiliser la syntaxe View :: render ($ template)
de n'importe où dans nos plugins) et il faut deux paramètres:
$ filePath
- Le chemin d'accès au fichier de modèle. N'oubliez pas que nous allons conserver nos modèles dans le Vue dossier que nous avons créé plus tôt$ viewData
- Toutes les variables auxquelles nous aimerions avoir accès dans le modèle (beaucoup plus à ce sujet plus tard)Copiez le code ci-dessous dans View.php:
Tout d’abord, nous vérifions si le $ viewData
varible a une valeur (c’est-à-dire avons-nous envoyé quelque chose à utiliser dans le modèle?). Si c'est le cas, nous extrayons le contenu (plus sur cela plus tard)
Ensuite, nous utilisons le tampon de sortie de PHP. Cela nous permet d'analyser un fichier PHP et d'enregistrer le contenu dans une variable
Finalement on retourne la ficelle
Remarque: N'oubliez pas d'activer le plugin maintenant à partir du panneau d'administration
Cela semble assez simple hein? Exactement! Mais bien que cela semble être une simple petite fonction très simple, cela nous offre le luxe de pouvoir écrire nos plugins de manière super organisée, évolutive et maintenable. S'il vous plaît, permettez-moi de démontrer…
Créons un plugin simple appelé Curseur
** Remarque: Ceci est uniquement à des fins de démonstration. N'hésitez pas à utiliser votre propre plugin ici.
OK, nous allons maintenant ajouter un shortcode qui récupérera les 5 derniers articles et les affichera dans une liste avec le titre et le contenu. (Par souci de brièveté, nous ajouterons notre classe de plug-ins et nos crochets d'action dans le même fichier de plug-in, mais veuillez ne pas le faire dans la "vie réelle": p)
/ ** * Ajouter le Shortcode (PHP 5.3 et supérieur) * / add_shortcode ('slider', function () return Slider :: display (););
Cela nous permettra d’utiliser simplement [curseur]
dans n'importe quel post / page et le résultat de Slider :: display ()
afficher()
Méthodeclass Slider public static function display () // Retourne HTML ICI.
/ * * Récupère les 5 derniers posts * / fonction publique statique display () $ posts = get_posts (array ('numberposts' => 5));
Maintenant, nous avons un tableau de poster
objets et nous sommes prêts à construire notre code HTML en les parcourant. Mais nous n'allons pas simplement commencer à insérer des chaînes HTML dans notre fonction ici! Au lieu de cela, nous allons passer le tableau d'objets à un fichier de modèle et obtenir tout le code HTML généré hors du danger.
Ce modèle contiendra l’ensemble de nos balises et nous permettra d’accéder aux données que nous avons. envoyer à plus tard.
Chaque fois que nous voulons utiliser des variables dans nos modèles, nous pouvons simplement envoyer en définissant une valeur dans le $ viewData
tableau. Toute personne familiarisée avec l'utilisation des frameworks MVC se sentira très à l'aise avec cette approche.
$ viewData = array ('posts' => $ posts);
Le tableau clé ici ('des postes
') est important car c'est ainsi que nous nous référerons aux données du modèle. (Vous pouvez appeler cela comme bon vous semble, mais tenez-vous-en à quelque chose de logique.)
Ok, nous avons donc cherché à récupérer les 5 derniers articles et à envoyer ce tableau d'objets au modèle. Il est maintenant temps d'étoffer le fichier modèle..
= $post->post_title?>
= $post->post_content?>
Ah! Est-ce que ça fait du bien d'avoir tout ce balisage dans son propre fichier, loin de notre logique de récupération des données et de programmation? Génial, je sais! La partie la plus importante de cette approche est que nous n’accédons jamais aux données à partir de variables du modèle. Toute la «logique» doit être effectuée dans la méthode qui appelle le modèle. Cela conduit à un très bon flux de travail car vous avez une séparation complète des préoccupations.
Imaginez à quel point ce sera facile lorsque vous serez prêt à utiliser ce plugin. Plus de concaténation de chaînes et de caractères d'échappement dans les fonctions.
Ok, nous avons vu tous les composants, voyons comment tout cela s’allonge pour nous permettre de restituer un modèle et d’obtenir une chaîne (nous pourrons ensuite revenir à notre shortcode):
Vue
la classe existe$ template
Voir :: render ()
méthode et passez les deux paramètres nécessairesDans ce cas, nous revenir le résultat du modèle rendu parce que c'est ainsi codes courts travail. Mais si vous aviez besoin de écho les résultats à la place (par exemple, lorsque vous créez une page Admin, le rappel attend que votre sortie soit imprimée directement), puis remplacez simplement revenir avec écho.
afficher()
Méthode complèteclass Slider static $ template = '/templates/01.template.php'; Fonction statique publique display () if (class_exists ('View')) // Récupère les 5 derniers messages $ posts = get_posts (array ('numberposts' => 5)); // Définir la vue Données $ viewData = array ('posts' => $ posts); // Récupère le chemin complet du fichier de modèle. $ templatePath = dirname (__FILE__). static :: $ template; // Retourne le rendu HTML renvoyé View :: render ($ templatePath, $ viewData); else return "Vous essayez de rendre un modèle, mais nous ne trouvons pas la classe de vue";
J'espère que vous pourrez apprécier le niveau d'organisation que cette approche vous permettra! Maintenant votre afficher La fonction est uniquement responsable de la collecte des données dont elle a besoin et du renvoi du résultat du modèle rendu..
Notre exemple ci-dessus est à peu près aussi basique que possible. Malgré tout, le flux de travail reste considérablement amélioré. Voyons maintenant un autre exemple qui montre à quel point il peut être vraiment utile.
Supposons, par exemple, que votre plugin utilise une méta-boîte personnalisée. Pour ce faire, il faudrait:
Curseur
classeclass Slider static $ metaBox = '/templates/metabox.template.php'; fonction publique __construct () add_action ('add_meta_boxes', array ($ this, 'add_some_meta_box')); / ** * Ajoute le conteneur de méta-boîtes * / fonction publique add_some_meta_box () add_meta_box ('nom_du_champ_méta', 'certains titres de la boîte-méta', tableau ($ this, 'render_meta_box_content'), 'post', 'avancé' ',' haute', ); / ** * Rendre le contenu de la méta-boîte * / fonction publique render_meta_box_content () / ** à partir du Codex ** / echo 'TEST OUTPUT - ceci est rendu dans la boîte méta.
'; // classe // ajouter la fonction de crochet d'action call_Slider () return new Slider (); if (is_admin ()) add_action ('load-post.php', 'call_Slider');
Regardez le render_meta_box_content
méthode là-bas. C'est l'occasion idéale d'utiliser le moteur de rendu de vue! Imaginez un exemple plus réaliste comme celui-ci:
/ ** * Rendu du contenu de la méta-boîte * / fonction publique render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "name"); $ fieldName = static :: $ fieldName; écho 'Votre nom:
'; écho ''; écho ''; écho '';
Urg! Bien sûr, le travail est fait, mais c'est tellement difficile de le faire de cette façon! Et si nous utilisions notre rendu de vue à la place.
/ ** * Rendu du contenu de la méta-boîte * / fonction publique render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'name'), 'field' => static :: $ nom de domaine ); $ templatePath = dirname (__FILE__). static :: $ metabox; echo View :: render ($ templatePath, $ viewData);
Et dans le fichier modèle:
Votre nom:
Cela peut sembler être un très petit avantage dans cet exemple. Mais croyez-moi, si vous gardez vos préoccupations séparées de la sorte, vous deviendrez rapidement un meilleur développeur WordPress.
Je pense que maintenant vous avez probablement une bonne compréhension de ce que nous essayons de réaliser ici et je vous encourage vivement à utiliser cette technique lors de la création de plugins à l'avenir. J'espère que vous constaterez que la «séparation des préoccupations» vous profite.
Notes du tutoriel:
Je serais intéressé de connaître les utilisations que vous avez trouvées pour cette technique, alors partagez-les dans les commentaires :)