ThemeForest a récemment mis à jour ses exigences de soumission de thèmes WordPress pour être plus strictes et plus conformes aux meilleures pratiques de développement de thèmes WordPress.
Les directives exigent l'utilisation de plusieurs fonctionnalités de base de WordPress, de hooks de thème standard, et interdisent les fonctions PHP (comme base64 et fopen) qui n'auraient vraiment **jamais dû avoir leur place dans un thème WordPress** pour commencer.
En gros, à 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'un des marchés de thèmes WordPress les plus populaires sur le net. Il n'y a qu'un seul problème...
Shortcodes admissibles
Une chose qui a particulièrement attiré mon attention, cependant, a été la façon dont certaines fonctionnalités de shortcodes « admissibles » étaient autorisées (c'est-à-dire en les incluant directement via le fichier functions.php du thème). Ceux listés comme « admissibles » comprenaient les éléments suivants :
- boutons
- tableaux de prix
- conteneurs d'images
- lettres capitales
- listes
Les shortcodes inadmissibles comprennent : cartes, accordéons et bascules, contenus encadrés, colonnes, formulaires de contact, graphiques.
Le problème des shortcodes dans les thèmes
Je ne peux pas vraiment mieux le dire que Justin Tadlock l'a déjà fait. L'un des problèmes les plus notables est que lorsqu'un utilisateur change de thème, les shortcodes ne seront plus analysés.
Disons que le thème « Super Génial » avait une fonctionnalité de shortcode qui produisait un gros bouton vert avec un lien lorsque vous tapiez quelque chose comme [button url="http://example.com"]Gros Bouton Vert[/button].
Lorsque vous passez à un autre thème (soyons honnêtes, 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 la publication comme s'il s'agissait de n'importe quel autre contenu, comme ceci :
[button url=”http://example.com”]Gros Bouton Vert[/button]
Cela a l'air moche, déroutant et déplacé, et c'est une corvée pour l'utilisateur de revenir en arrière et de les supprimer/remplacer tous.
L'autre problème des shortcodes dans les thèmes
Quelque chose que Tadlock a abordé dans son article « Dealing with shortcode madness » est que de nombreux shortcodes sont si simples et ressemblent à du HTML qu'il pourrait même être préférable d'instruire les utilisateurs à écrire un peu de vrai code HTML (*horreur*).
Le même shortcode [button url="http://example.com"]Texte du bouton[/button] dans mon exemple ci-dessus pourrait être facilement réécrit comme ceci :
<a href="http://example.com" class="button">Texte du bouton ici</a>
Bien qu'il n'y ait peut-être pas de code CSS stylisant le sélecteur .button dans un nouveau thème, au moins un lien normal apparaîtra. Ce qui est une grande amélioration par rapport à un shortcode [button] non interprété apparaissant 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 enseignant, même par petites touches (comme construire un lien), cela aidera. S'ils peuvent comprendre un shortcode, il ne faudra pas beaucoup plus pour qu'ils comprennent le 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 fichent tout simplement. Je veux dire, peut-être qu'ils ne voudront jamais mettre à jour leur thème, auquel cas, ce problème de shortcode serait sans objet.
Le problème, c'est que certains utilisateurs voudront inévitablement changer de thème un jour. Certains utilisateurs voudront installer un plugin qui pourrait entrer en conflit avec d'autres codes mal conçus dans un thème.
Ensuite, ils s'en soucieront 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-le dans un plugin. Un plugin vraiment simple. Il n'a pas besoin d'un panneau d'options séparé. Copiez et collez littéralement tout ce que vous alliez inclure via le fichier functions.php de votre thème, et mettez-le dans un plugin à la place.
Il pourrait même être regroupé avec 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 également. De cette façon, les gros boutons verts que vous avez inclus avec le shortcode [button] seront toujours 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 quelle était exactement la raison de cette décision. Japh Thomson, un évangéliste WordPress chez Envato (la société mère de ThemeForest) a dit ceci à ce sujet dans un commentaire sur WPMU.org :
Les fonctionnalités complexes de shortcodes devraient vraiment résider dans un plugin, pas dans un thème. Cela a également du sens lorsque l'on considère que la plupart de nos auteurs ont plusieurs thèmes.
Clairement, il comprend. C'est donc un mystère pour moi pourquoi il y aurait des shortcodes "admissibles".
Aussi simple qu'un shortcode puisse être, les problèmes que j'ai décrits ci-dessus existeront toujours. ThemeForest s'est montré réactif aux commentaires de la communauté, il est donc possible que cette règle soit modifiée à l'avenir.
Conclusion
Je réalise que ce post 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, simple ou non.
Pouvez-vous imaginer une situation où un thème publié publiquement a absolument besoin d'inclure des fonctionnalités de shortcode via son propre fichier functions.php ?
— Theme Lab (@themelab) 9 juillet 2013
Alerte spoiler : Je n'ai reçu aucune réponse à ce tweet avec un exemple concret de shortcode devant absolument être inclus dans un thème publié publiquement.
C'est parce que ce 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 le même support de shortcode.
Merci beaucoup pour ce post, je viens d'acheter un thème ThemeForest et j'ai le même problème ! Lorsque nous avons téléchargé le thème, les pages indiquent que le shortcode n'est pas compatible... que faire maintenant pour le rendre compatible ? Merci !
Bien que je sois d'accord pour dire que les shortcodes devraient résider dans un plugin plutôt que dans un thème, le code non analysé apparaîtra toujours lorsque le plugin sera désactivé ou remplacé par un autre plugin de shortcodes. Dans un cas comme dans l'autre, cela peut être une corvée pour la personne qui effectue le changement.
Apprendre le HTML de base semble le mieux.
Tout à fait d'accord. Les thèmes devraient gérer la mise en page et les styles. Tout ce qui ajoute des fonctionnalités supplémentaires doit aller dans un plugin.
J'ai la même position sur les shortcodes, mais je comprends le raisonnement de certains thèmes qui les incluent pour que les utilisateurs moins technophiles ajoutent facilement des fonctionnalités, ce qui aide à vendre davantage les thèmes des développeurs.
Bien dit.
Il serait également agréable qu'il y ait une sorte de dégradation élégante pour les shortcodes qui ne sont plus actifs.
Ainsi, les problèmes potentiels peuvent être évités avec des fonctions qui pourraient être ajoutées à l'avenir dans différents thèmes. Les problèmes de maintenance sont des arguments d'achat importants – du moins pour moi !
Je suis entièrement d'accord avec vous. Très peu de gens restent avec un seul thème pour toujours, à moins qu'il ne soit entièrement personnalisé (et alors vous n'avez pas le problème de Themeforest) et les shortcodes sont une plaie à gérer. J'ai récemment découvert ce problème lorsque j'ai commencé à passer d'un thème Theme Junkie à un thème StudioPress/Genesis. Maintenant, j'ai mis le changement en attente, malgré avoir déjà dépensé 80 $ pour cela, car il y a trop à changer, même sur mon nouveau site.
Salut Leland, excellent article, merci pour tes réflexions !
Nous publierons bientôt une mise à jour de ces exigences, basée sur les commentaires de nos auteurs, et j'espère que vous serez satisfait de certains ajustements que nous avons apportés (notamment en ce qui concerne les shortcodes) 🙂
Je pense que ce n'est pas seulement un problème de compatibilité avec d'autres thèmes, mais aussi un problème lié au contenu. Un shortcode devrait simplement être une aide pour traiter le contenu, et les thèmes ne devraient afficher que du contenu pré-traité, sans le traiter eux-mêmes. Lorsque les thèmes traitent les shortcodes par eux-mêmes, ils considèrent ce morceau de texte (ou du moins, il semble que le développeur le fasse) comme un appel à un élément visuel, et non à un élément fonctionnel (ce qu'il est réellement), comme si la portée de ce à quoi sert un thème était manquante. Cette pratique montre un manque de clarté quant à ce que sont le contenu, la fonctionnalité et la visualisation, et comment ces éléments devraient être gérés (c'est-à-dire, le contenu devrait être stocké dans la base de données, la fonctionnalité devrait être gérée via le cœur de WP et les plugins, et la visualisation via les thèmes ; juste comme un exemple très basique). Il n'est pas nécessaire d'être un expert en contenu, un programmeur expérimenté ou un grand designer pour connaître de telles choses, juste un peu d'attention et une réflexion approfondie sur ce que nous offrons à nos utilisateurs, et à quel point il sera facile ou difficile pour eux d'utiliser nos produits. Je pense que c'est acceptable si vous ne connaissez pas les différences mais que vous êtes ouvert à apprendre et à vous améliorer, mais, d'un autre côté, connaître et garder à l'esprit toutes ces choses et proposer quand même des shortcodes (et tout autre élément lié à la fonctionnalité) dans les thèmes, cela me semble une pratique déloyale qui rend vos utilisateurs captifs de votre produit. Je sais que parfois la frontière entre visualisation et fonctionnalité est très mince, mais dans la plupart des cas, la différence est indiscutable.
Désolé pour la longue réponse, c'est un sujet qui m'intéresse vraiment. Excellent article 🙂
Salut Andrés, pas besoin de t'excuser pour la réponse longue, tu soulèves des points très pertinents !
Merci pour cela… J'ai des problèmes récurrents avec les shortcodes dans les thèmes que j'ai achetés. Et quand je change de thème, j'ai du code hérité partout qui doit être remplacé.
Peter, c'est un exemple parfait du problème avec les shortcodes dans les thèmes.
Cela empire lorsque d'autres fonctionnalités non présentées sont également incluses dans un thème, peut-être quelque chose à aborder dans un futur article.