Imaginez ce scénario : vous trouvez un extrait de code vraiment intéressant sur l'un des nombreux sites de tutoriels WordPress et vous le collez dans le fichier functions.php de votre thème.
L'extrait de code fonctionne comme annoncé, et vous mettez ensuite votre thème en vente sur une place de marché de thèmes bien connue. Prenons-en une au hasard et choisissons... ThemeForest.
Soudain, votre thème devient très populaire, peut-être à cause de la liste massive de « fonctionnalités » apparemment utiles que vous avez listées sur la page de vente de votre thème. Avec le succès de votre thème, viennent également un certain nombre de demandes de support, principalement liées à des plugins qui plantent lors de l'utilisation de votre thème.
Comment est-ce arrivé, vous demandez-vous ? C'est peut-être parce que vous avez aveuglément collé des blocs de code WordPress aléatoires dans votre fichier functions.php sans réellement réfléchir ou anticiper d'éventuels problèmes de compatibilité.
Un exemple réel
Donc, j'essayais de trouver un extrait de code qui extrairait toutes les images jointes d'un article et les afficherait automatiquement sur cet article. J'ai finalement trouvé un morceau de code sur Stack Overflow, je l'ai collé dans mon fichier de fonctions, et cela a semblé résoudre le problème.
La première ligne de code était la suivante :
add_filter('the_content', 'strip_shortcodes');Tant pis, ça a marché, je n'y ai pas réfléchi. Plus tard, j'ai essayé d'intégrer un formulaire de contact avec un shortcode. Surprise, ça n'a pas marché et j'ai passé environ une heure à essayer de comprendre pourquoi. Si j'avais réellement lu le code que je collais, je l'aurais su.
C'était pour le site d'un client, pas un thème publié, donc heureusement je n'ai pas eu à gérer un déluge de demandes de support à cause de ma stupide erreur.
Ce que pensent les développeurs de plugins commerciaux
Voici une citation de Carl Hancock (développeur de Gravity Forms) sur ce sujet précis :
La prise en charge du plugin populaire Gravity Forms signifie que nous rencontrons plus que notre juste part de thèmes mal codés. L'un des principaux problèmes liés au support que nous rencontrons sont les thèmes qui ne sont pas développés selon les meilleures pratiques, ce qui entraîne des problèmes de style pour Gravity Forms et, dans certains cas, des conflits qui empêchent Gravity Forms de fonctionner correctement.
Le plus grand coupable dans ces situations sont les thèmes qui incluent des extraits de code copiés-collés de sites de tutoriels. Les développeurs de thèmes semblent penser que parce que l'extrait de code était sur un site de tutoriel, il doit être bon. Malheureusement, ce n'est pas toujours le cas et ces mauvaises décisions entraînent des maux de tête et des problèmes de support pour les utilisateurs.
Vous voulez limiter le potentiel de rencontrer des problèmes avec des plugins causés par un thème mal développé ? Tenez-vous-en à des développeurs de thèmes réputés tels que Press75, iThemes, Headway Themes, Organic Themes, WooThemes et StudioPress, pour n'en nommer que quelques-uns. Méfiez-vous des places de marché de thèmes où l'expérience et les compétences de l'auteur peuvent faire défaut. Dans la plupart des cas, vous en avez pour votre argent.
Meilleures pratiques de codage
Beaucoup de ces problèmes peuvent probablement être évités en suivant les normes de codage WordPress. Par exemple, vous devriez ajouter un préfixe à vos noms de fonctions pour éviter tout conflit potentiel.
Dans le cas de problèmes de style avec Gravity Forms, vous voudrez peut-être éviter certains styles généraux sur les éléments form et input, et utiliser plutôt les sélecteurs d'ID par défaut de WordPress pour la majeure partie de votre stylisation de formulaire.
Cela inclut #searchform, #s, #searchsubmit dans la boîte de recherche. Également #commentform #author, #url, #email, #comment, #submit pour le formulaire de commentaires.
Conclusion
Si vous êtes un développeur de thèmes, et pas très versé en PHP, faites attention en copiant et collant ces extraits de code dans votre thème. Même si vous n'êtes pas très doué en PHP, vous pouvez au moins lire le code et essayer de le comprendre avant de l'utiliser.
Par exemple, si vous constatez que vos shortcodes ne fonctionnent pas correctement, une ligne de code mentionnant "strip_shortcodes" pourrait y être pour quelque chose.
Parfois, j'ai l'impression que les développeurs de thèmes WordPress collent simplement des extraits aléatoires dans leur fichier functions.php, juste pour pouvoir lister une autre "fonctionnalité" sur les pages de vente de leur thème.
Bien que je ne sois pas un grand fan de ce genre d'idée, cela soulève tout un autre débat sur le rôle des thèmes et des plugins sur les sites WordPress, que je réserverai pour un futur article.
Intéressant... Je suis moi-même développeur de thèmes, merci de porter cela à mon attention...
J'ai même vu des gens copier et coller du code avec des avis de droit d'auteur (demandant que le code ne soit pas partagé !) toujours intacts.
@mkjones – le problème est-il que le filtre a été supprimé, ou que sa suppression n'a pas été annoncée ? Je supprime presque toujours le filtre wpautop car il détruit automatiquement du HTML parfaitement valide (bien sûr, je dis à tout le monde qu'il a disparu).
Ce qui m'irrite le plus, c'est quand ils collent Jquery (et plus de 20 autres scripts/plugins) directement dans l'en-tête de leur thème ou dans un endroit difficile à trouver. Est-ce que wp_enqueue_script est si difficile que ça ?
J'ai en fait posté un exemple rapide d'un fiasco Jquery de Themeforest sur mes forums si quelqu'un veut y jeter un œil.
Je voulais juste ajouter une chose qui pourrait être utile à certains de vos lecteurs.
Plus tôt ce mois-ci, j'aidais un client qui avait acheté une licence de support pour mon plugin. Le thème du client avait environ 20 plugins Jquery différents chargés dans le header.php. Aucun d'entre eux n'utilisait wp_enque_script.
La plupart de ces scripts n'étaient utilisés que pour le slider de la page d'accueil et la galerie (qui n'existaient pas encore). Comme ils étaient chargés sur l'ensemble du site, les scripts provoquaient des erreurs Jquery sur toutes les autres pages du site qui n'avaient pas besoin de ces scripts.
Plutôt que de réécrire entièrement le header.php et parce que je ne savais pas si certains scripts pourraient être nécessaires pour les pages futures. J'ai utilisé quelques tags conditionnels pour résoudre le problème. En utilisant des tags conditionnels, j'ai pu désactiver tous les scripts arbitraires, lorsque le site chargeait le formulaire d'inscription qui était généré par mon plugin.
J'ai en fait posté un exemple rapide d'un fiasco Jquery de Themeforest sur mes forums, si quelqu'un veut y jeter un œil.
Désolé Leland, peux-tu supprimer la première ligne de mon dernier commentaire ? Je pensais l'avoir supprimée avant de poster.
Merci !
Oh MAN, je déteste ça. Ça cause des maux de tête sans fin lors de la personnalisation des thèmes.
Il me semble me souvenir du classique :
remove_filter(‘the_content’, ‘wpautop’);
S'est glissé il y a quelque temps. Sans être correctement annoncé comme une « fonctionnalité » de thème 🙁
Je suis entièrement d'accord avec vous ici ! J'ai déjà parcouru ce chemin et fait cette erreur moi-même, pour me retrouver en difficulté plus tard.
Les choses que vous pouvez faire avec votre functions.php sont géniales, mais vous devez être organisé et prudent avec ce que vous faites si vous ne voulez pas passer des heures à déboguer plus tard.
L'une des recommandations que je donnerais serait d'organiser soigneusement ces extraits de code si vous souhaitez les conserver.
Conservez-les dans des fichiers séparés, bien commentés, doublement testés après leur implémentation. Au final, documenter votre travail est toujours payant, à mon avis.
Je n'aurais pas pu mieux dire moi-même. Ceci ne se limite pas aux extraits de code aléatoires trouvés dans les tutoriels sur le Web. Les développeurs de thèmes insèrent aléatoirement n'importe quel code dans functions.php sans réfléchir — on pourrait penser qu'ils utiliseraient un hook de temps en temps.