Les shortcodes ne devraient jamais être inclus dans les thèmes. Période.

ThemeForest a récemment mis à jour les conditions de soumission des thèmes WordPress afin de les rendre plus strictes et plus conformes aux meilleures pratiques de développement des thèmes WordPress.

Les directives exigent l’utilisation de plusieurs fonctionnalités de base de WordPress, de crochets de thème standard, et interdisent les fonctions PHP (comme base64 et fopen) qui n’auraient jamais dû avoir leur place dans un thème WordPress pour commencer.

En gros, c’est à peu près la politique de révision des thèmes de WordPress.org, à quelques détails près.

Dans l’ensemble, c’est un pas dans la bonne direction et cela permet de promouvoir les meilleures pratiques sur l’une des places de marché de thèmes WordPress les plus populaires sur le net. Il y a juste un problème…

Shortcodes autorisés

Une chose qui a particulièrement attiré mon attention, cependant, est la façon dont certaines fonctionnalités de shortcodes “admissibles” ont été autorisées (c’est-à-dire en les incluant directement dans le fichier functions.php du thème). Les shortcodes répertoriés comme “admissibles” sont les suivants :

• boutons
• tableaux de prix
• conteneurs d’images
• capsules de chute
• listes

Les shortcodes non autorisés comprennent : les cartes, les accordéons et les toggles, les contenus encadrés, les colonnes, les formulaires de contact, les graphiques.

Le problème des shortcodes dans les thèmes

Je ne peux pas vraiment mieux dire que Justin Tadlock l’a déjà fait. L’un des problèmes les plus visibles est que lorsqu’un utilisateur change de thème, les shortcodes ne sont plus analysés.

Supposons que le thème "Super Awesome" ait un shortcode qui produise un gros bouton vert avec un lien lorsque vous tapez quelque chose comme [button url="http://example.com"]Big Green Button[/button].

Bouton vert

Lorsque vous passez à un autre thème (avouons-le, les gens se lassent facilement des thèmes), il n’y a plus de gros bouton vert. Au lieu de cela, vous voyez le shortcode non analysé dans l’article comme s’il s’agissait de n’importe quel autre élément de contenu, comme ceci :

[button url=”http://example.com”]Gros bouton vert[/button]

C’est moche, confus et déplacé, et c’est pénible pour l’utilisateur de revenir en arrière et de les supprimer/remplacer tous.

L’autre problème des shortcodes dans les thèmes

Dans son article “Dealing with shortcode madness”, Tadlock explique que de nombreux shortcodes sont si simples et si proches du HTML qu’il serait préférable de demander aux utilisateurs d’écrire un peu (*gasp*) de vrai code HTML.

Le même shortcode [button url="http://example.com"]Button Text[/button] dans mon exemple ci-dessus pourrait facilement être réécrit comme quelque chose comme :

<a href="http://example.com" class="button">Texte du bouton ici</a>

Bien qu’il n’y ait pas de code CSS stylisant le sélecteur .button dans un nouveau thème, au moins un lien normal s’affichera. C’est une grande amélioration par rapport à un shortcode [button] non analysé qui apparaît dans le contenu d’un article.

De plus, je pense que chaque utilisateur de WordPress devrait avoir au moins une compréhension de base du code HTML. En leur apprenant, même par petites touches (comme la construction d’un lien), cela les aidera. S’ils peuvent comprendre un shortcode, il n’en faudra pas plus pour qu’ils comprennent le code HTML de base.

Mais les utilisateurs s’en fichent !

Un argument courant que je vois pour défendre toutes sortes de mauvaises pratiques en matière de développement de thèmes est que les utilisateurs s’en moquent. Je veux dire, peut-être qu’ils ne veulent jamais mettre à jour leur thème, dans ce cas, ce problème de shortcode serait un point discutable.

Le problème est que certains utilisateurs voudront inévitablement changer de thème un jour ou l’autre. Certains utilisateurs voudront installer un plugin qui pourrait entrer en conflit avec un autre code mal pensé dans un thème.

Ils s’en soucieront alors probablement, et se demanderont probablement si le thème qu’ils ont acheté avec des centaines de shortcodes intégrés et d’autres fonctionnalités superflues en valait vraiment la peine.

La bonne façon d’inclure des shortcodes

Mettez-les dans un plugin. Un plugin très simple. Il n’a pas besoin d’un panneau d’options séparé. Il suffit de copier et coller ce que vous alliez inclure dans le fichier functions.php de votre thème, et de le mettre dans un plugin à la place.

Il pourrait même être associé à quelque chose comme TGM Plugin Activation pour le rendre obligatoire lors de l’activation du thème. Ou pas. Un thème reste un thème sans shortcodes.

De cette façon, si l’utilisateur change de thème, les shortcodes fonctionneront toujours, car cette fonctionnalité est gérée par le plugin qui est toujours actif.

Peut-être que le plugin pourrait également mettre en file d’attente les styles pour les shortcodes. Ainsi, les gros boutons verts que vous avez inclus avec le shortcode [button] resteront de gros boutons verts, quel que soit le thème utilisé.

Pourquoi ThemeForest a-t-il autorisé les shortcodes “admissibles” ?

Il est difficile de dire exactement quel était le raisonnement derrière cette décision. Japh Thomson, un évangéliste WordPress chez Envato (la société mère de ThemeForest) a eu ce mot à dire dans un commentaire sur WPMU.org:

La fonctionnalité complexe des shortcodes devrait vraiment résider dans un plugin, pas dans un thème. C’est également logique si l’on considère que la plupart de nos auteurs ont plusieurs thèmes.

De toute évidence, il a compris. C’est donc un mystère pour moi de savoir pourquoi il y aurait des shortcodes “admissibles”. Et oui, je réalise qu’il a utilisé le mot “complexe” dans la citation ci-dessus, et que les shortcodes admissibles ont tendance à être assez simples (dropcaps, listes, etc.).

Aussi simple que puisse être un shortcode, les problèmes que j’ai décrits plus haut existeront toujours. ThemeForest a montré qu’il était sensible aux commentaires de la communauté, il est donc possible que cette règle soit modifiée à l’avenir.

Conclusion

Je me rends compte que cet article semble un peu pointilleux, et ces nouvelles directives sont certainement un grand pas dans la bonne direction. Mais il n’y a vraiment aucune raison pour qu’un shortcode soit autorisé dans un thème, qu’il soit simple ou non.

Pouvez-vous penser à une situation dans laquelle un thème publié a absolument besoin d’inclure une fonctionnalité de shortcode via son propre functions.php ?

– Theme Lab (@themelab) 9 juillet 2013

Spoiler alert : Nous n’avons reçu aucune réponse à ce tweet avec un exemple réel d’un shortcode devant absolument être inclus dans un thème diffusé publiquement.

C’est parce qu’il n’est tout simplement pas convivial pour un utilisateur de revenir en arrière et de remplacer des centaines de shortcodes de boutons après avoir changé pour un thème qui n’a pas exactement la même prise en charge des shortcodes.