Extension (plugin) ou fonctions dans le thème : Telle est la question.

Souhaitez des nouvelles fonctions dans WordPress : que choisir ? une extension ou une fonction dans le thème ?
Pour collecter une série d’éléments qui vont concourir à prendre une décision, il est souhaitable de se poser une série de questions :

– Est-ce que les fonctionnalités recherchées ne concernent que le site, l’organisation propre de ses données (data-design) et leur présentation (le thème, le design, l’ergonomie) ?

– Est-ce que les outils seront réutilisables sur d’autres sites et est-ce que leur paramétrage nécessitera l’utilisation de l’interface du tableau de bord par le webmaster ou l’éditeur du site (CMS) ou du blog ?

– Les fonctionnalités souhaitées sont-elles générales au site ou seront-elles affectées à la publication de chaque article ?

– Les fonctionnalités concernent-elles un ou plusieurs des fichiers (générateurs) du thème : index.php, page.php, category.php… ?

– Le niveau d’intervention des outils nécessite-t-il un webmaster ou un éditeur avisé connaissant WordPress ou demande-t-on à ces derniers une bonne connaissance de l’html et du php ?

Les fonctions feront-elles appel à des objets et modules du coeur de WordPress ? De même, ‘hook’, action et filtre ainsi que ‘shortcode’ seront-ils nécessaires ?

De quatre ans d’utilisation de WordPress, de la recherche d’informations – documentations, d’extensions disponibles, de suivi des mises à jour (à visée correctrice ou évolutive), nous avons commencé à définir une première approche.

Quelques objectifs :

– le code php le plus court possible.
– autant que faire se peut : une utilisation exceptionnelle du javascript toutefois pouvant être remis en cause avec des frameworks comme jquery ou mootools.

– maintenir un contact avec le développeur de l’extension (plugin) car rien de pire qu’un outil sans service après-vente notamment après les mises à jour du coeur de WP.

– limiter les insertions dans les headers (script, css) aux seules fichiers, pages concernées afin de limiter les interactions potentielles.

Quelques règles :

Les fonctions qui ne concernent QUE le site (CMS ou Blog) sont installées dans fonctions.php du thème mis au point pour ce site. Exemple : un ‘shortcode’ qui va faire une mise en page spécifique pour les auteurs du site – combinant par exemple retrait et insertion d’une icône –
Autre exemple : une fonction qui définit si un article doit être ou non affiché selon sa catégorie et les droits de la personne connectée ou non. Le site a ainsi des zones publiques et privées.

La mise en extension (plugin) du sélecteur de thèmes (xilitheme-select) s’est imposée car sa principale fonction – sélectionner le thème en fonction du navigateur (sur un ordinateur classique ou un iPod / iPhone) – est indépendante des thèmes qui sont dans la sélection. L’extension donne aussi d’autres informations qui sont exploitables dans les fonctions et élements du thème.

Une approche combinée : xili-language
Cette extension qui modifie le langage du thème en fonction de celui du post ou de la catégorie affichée propose des « hooks » qui permettent au webmaster-concepteur du site d’ajouter des fonctions spécifiques au thème courant (via le fichier functions.php).
Il est ainsi possible de personnaliser dans le thème l’affichage de la liste des langues disponibles ou de définir des règles restrictives au changement de langue du contexte selon le type d’articles (post) en jeu. Cela complète avantageusement l’approche CMS en séparant bien les données de leur présentation.

Le débat est ouvert, utilisez les commentaires ou la page contact.