Catégorie « WordPress »

Je viens de mettre en ligne une nouvelle version de mon petit plugin Open search. Cette nouvelle version n'apporte rien fonctionnellement mais inclus le fichier readme.txt nécessaire à l'ajout sur le repository officiel, un fichier de traduction en anglais et une page de documentation en anglais ( enfin, en anglais de développeur qui se débrouille plus ou moins, hein... je suis preneur de toute suggestion de correction qui en ferait du "vrai" anglais ).

Prochaine étape, faire de même avec Post-lister une fois qu'il sera à peu près arrivé à maturité... D'ailleurs la version 0.2 ne devrait pas tarder, maintenant que je suis en vacances, j'ai un peu de temps Au passage s'il y a un volontaire pour la traduction de la doc, il est le bienvenu (pas forcément tout de suite, vu qu'elle va pas mal bouger avec la prochaine version)

J'ai déjà développé quelques plugins WordPress, même si peu sont publiés (pour diverses raisons, la plupart du temps parce qu'ils sont encore trop limités ou pas assez finalisés).

Le dernier en date est Post-lister qui permet d'ajouter des listes d'articles soit dans un message grâce à un shortcode, soit en tant que widget. Au final c'est pas loin de 600 lignes qui mènent à ce résultat (si on vire les nombreux commentaires, on descend pas mal ce chiffre mais bon, les commentaires ça fait partie du code).

Et 600 lignes c'est beaucoup.

Surtout si l'on considère que moins de 200 d'entre elles concernent directement le listage de messages et que le reste serait quasiment identique si au lieu de lister des messages, on affichait une photo de Chuck Norris !

La conclusion est donc évidente : ce code répétitif doit être factorisé d'une manière ou d'une autre, il est exclu de faire des copier/coller à chaque plugin, ce qui serait un cauchemar à maintenir. Pour cela je vois en gros trois possibilités :

1. modifier plein de trucs dans WordPress pour qu'ils facilitent l'intégration de ce genre de plugin : je l'ai déjà fait avec phpBB (pas le choix faut dire vu qu'il ne gère absolument pas de plugins...) mais c'est un cauchemar pour les mises à jour puisqu'on ne peut plus se contenter de remplacer les fichiers... Résultat, je n'utiliserai probablement jamais phpBB3 vu que je devrais tout migrer... et intégralement recommencer pour la version suivante... Donc niet.
2. développer un petit framework annexe à WordPress sous forme d'un plugin à part proposant des classes de base pour pas mal de trucs : ça pourrait être une solution, j'y viendrai probablement à terme d'ailleurs mais c'est pas super pratique parce que ça empêche d'utiliser deux plugins basés sur des versions différentes dudit framework et ça complexifie l'installation (puisqu'il faut installer la dépendance avant).
3. développer un générateur de code : et là où c'est cool c'est qu'à peu de choses près j'avais déjà tout ce qu'il fallait dans ma tentative avortée de développer un script de forum perso : intégration de Smarty, quelques petites classes pour palier au manque flagrant de PHP en matière d'homogénéité des fonctions de traitements de chaines et autres.

C'est donc dans cette troisième voie que je me suis lancé il y a quelque temps et ça commence à prendre forme : en me basant sur un modèle en XML listant les différents paramètres, leur type et quelques autres infos, je génère automatiquement une classe de base contenant le nécessaire pour implémenter un "bloc" affichable sous forme de shortcode et/ou de widget, avec pour ce dernier un formulaire back-office et un fichier .pot pour les chaines localisées associées. Une fois tout ce petit monde généré on peut se concentrer sur la partie intéressante : le fonctionnel réel du plugin, pas son enrobage pour l'intégrer dans WordPress.

Bon, à l'heure actuelle ce n'est pas encore prêt à être publié (c'est chiant à installer et ça ne s'utilise qu'en ligne de commandes) et certains trucs manquent encore à la génération comme la page de configuration des préférences en back-office. Mais ça viendra...

Et du coup la prochaine version de Post-lister ne devrait pas tarder, avec un code refactoré pour être majoritairement généré, quelques options supplémentaires pour la liste des articles et la possibilité d'afficher également des listes de commentaires (c'est à peu près fonctionnel, donc peut-être ce weekend ^^).

À l'origine de ce plugin il y avait Query inside post de k-ny qui permet d'intégrer dans un article une liste d'articles générée automatiquement selon certains critères via une balise ShortCode.

En voulant corriger un bug de ce plugin (si l'on intégrait une liste de messages, les données affichées en bas de l'article, comme le lien vers le flux RSS ou la liste des catégories étaient ceux du dernier article de la liste et non celles de l'article courant) à force de refactoring, j'en suis finalement arrivé à le ré-écrire intégralement ainsi qu'à y ajouter certaines fonctions supplémentaires :

• paramètres d'affichages : afficher pour chaque article de la liste l'auteur et/ou la date et/ou le nombre de commentaires.
• widgetisation : on peut également intégrer une ou plusieurs listes d'articles à sa sidebar sous la forme d'un widget (le fait de définir un widget pouvant être utilisé plusieurs fois en même temps fut d'ailleurs étonnamment laborieux, du fait du caractère passablement brouillon de l'implémentation de la fonctionnalité dans WordPress et du codage du seul widget de base qui l'utilise et peut donc servir d'exemple : le widget d'affichage d'un flux RSS).

Le plugin final étant entièrement recodé, j'ai finalement décidé d'en faire un plugin distinct que voici : Post-lister v0.1

EDIT : Ajout de la page de documentation dédiée.

Vu qu'on m'a posé certaines questions là dessus cette semaine, ça va faire le sujet de l'article d'aujourd'hui.

Ajouter une seconde zone de widgets

Depuis la version 2 (il me semble) de WordPress, si le thème est bien fait, on peut depuis le panneau d'administration ajouter des widgets dans certaines zones bien définies. Dans le thème par défaut, il y a une zone unique pouvant accueillir des widgets, qui se trouve dans la barre latérale. Mais on peut vouloir en ajouter d'autres.

Pour ajouter une nouvelle zone, il faut effectuer deux modifications dans le code du thème :

1. Premièrement, il faut "enregistrer" une nouvelle zone pour que celle-ci soit disponible dans le menu de sélection des zones. Pour cela il faut en général se rendre dans le fichier functions.php du thème et rechercher où est appelée la fonction register_sidebar (dans le thème par défaut, c'est tout en haut du fichier) et l'appeler une fois de plus pour enregistrer une nouvelle zone.

   Cette fonction peut optionnellement prendre en argument un tableau de paramètres permettant de personnaliser le code HTML qui enrobera la liste de widgets. Dans la plupart des cas on n'en a pas besoin mais au cas où c'est bon de savoir que c'est possible, notamment pour éventuellement spécifier une classe particulière à l'une ou l'autre zone en vu d'appliquer des styles différenciés.

   Une fois cela fait, la nouvelle zone est disponible dans le menu de sélection des zones du panneau d'administration (cf la capture d'écran ci-dessus).

2. Dans un deuxième temps, il faut inclure cette zone dans le rendu de la page à un endroit ou un autre (sinon, forcément, ça sert pas à grand chose). Pour cela il suffit d'intégrer le code suivant dans l'un des fichiers de template : <?php dynamic_sidebar(n); ?> en prenant garde de bien remplacer le paramètre "n" par un entier représentant le numéro de la zone que vous voulez afficher.

   Par exemple, si vous venez d'ajouter une zone et qu'il y en avait une seule avant, la nouvelle aura fort logiquement le numéro 2 et le code à insérer sera le suivant : <?php dynamic_sidebar(2); ?>

N'afficher certaines choses que sur la page d'accueil

Afin de ne pas trop surcharger les pages, on peut ne vouloir afficher certaines informations et liens que sur la page d'accueil. Par exemple sur ce site, les encarts "Mes autres sites", "News du serveur" et "Divers" ne s'affichent que sur la page d'accueil (et les pages de contenu fixe).

Pour restreindre l'affichage d'une portion de code d'un fichier de template, c'est très simple :

<?php if ( [CONDITION] ) { ?>
  [CODE HTML À RESTREINDRE]
<?php } ?>

WordPress propose quelques fonctions PHP qui testent dans quel type de page on se trouve et qui peuvent servir à composer la condition (qui remplacera la portion "[CONDITION]" du code ci-dessus). Ces fonctions sont définies dans le fichier wp-includes/query.php et comprennent notamment :

• is_home() disant si l'on se trouve sur la page d'accueil.
• is_page() disant si l'on se trouve sur une page de contenu fixe.
• is_search() disant si l'on est dans la page de recherche.
• is_404() disant si l'on se trouve sur la page d'erreur 404.
• etc.

Pour composer la condition, il suffit d'appeler une ou plusieurs de ces fonctions séparées par une double barre verticale (||) qui représente un "ou" en PHP.

Par exemple pour ajouter une zone de widgets qui ne sera affichée que sur la page d'accueil et les page de contenu fixe, on utilisera le code suivant :

<?php if ( is_home() || is_page() ) { // Home and pages only. ?>
  <?php dynamic_sidebar(2); // Home and pages sidebar. ?>
<?php } ?>

Et ça marche que pour la barre latérale ?

Bien entendu ces deux "astuces" sont valables aussi bien pour la barre latérale que pour n'importe quelle autre partie de votre site. Mais c'est dans la barre latérale que c'est le plus souvent utilisé.

Avec la version 2.5 de WordPress, le plugin Democracy (permettant de gérer des sondages) ajoute un "n" parasite au dessus de chaque sondage à l'enregistrement.

J'ai intégré la correction de ce bug à aux différentes corrections regroupées ici.