Imaginez le scénario suivant : vous trouvez un bout de code vraiment sympa 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 prévu et vous mettez votre thème en vente sur une place de marché bien connue. Tirons-en un au hasard et choisissons… ThemeForest.
Soudain, votre thème devient très populaire, peut-être en raison de la liste massive de “fonctionnalités” apparemment utiles que vous avez énumérées sur la page de vente de votre thème. Le succès de votre thème s’accompagne également d’un certain nombre de demandes d’assistance, principalement liées à des plugins qui se cassent lors de l’utilisation de votre thème.
Comment cela est-il arrivé, vous demandez-vous ? Peut-être parce que vous avez collé à l’aveuglette des morceaux de code WordPress dans votre fichier functions.php sans vraiment réfléchir ou anticiper les éventuels problèmes de compatibilité.
Un exemple concret
J’essayais de trouver un bout de code qui permettrait d’extraire toutes les images attachées à un article et de les afficher automatiquement sur cet article. J’ai fini par trouver un bout de code sur Stack Overflow, je l’ai collé dans mon fichier de fonctions, et il a semblé résoudre le problème.
La première ligne de code était la suivante :
add_filter('the_content', 'strip_shortcodes') ;Oh, bien sûr, cela a fonctionné, je n’en ai pas tenu compte. Plus tard, j’ai essayé d’intégrer un formulaire de contact avec un shortcode. Surprise, cela n’a pas fonctionné et j’ai passé une heure à essayer de comprendre pourquoi. Si j’avais vraiment lu le code que je collais, je l’aurais su.
C’était pour le site d’un client, pas pour un thème publié, donc heureusement je n’ai pas eu à faire face à un déluge de demandes d’assistance à 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 même sujet :
Soutenir le populaire plugin Gravity Forms signifie que nous voyons plus que notre part de thèmes mal codés. L’un des principaux problèmes liés au soutien que nous rencontrons sont les thèmes qui n’ont pas été développés en utilisant les meilleures pratiques, ce qui entraîne des problèmes de style de Gravity Forms et, dans certains cas, des conflits qui font que Gravity Forms ne fonctionne pas correctement.
Le plus grand coupable dans ces situations sont les thèmes qui incluent des extraits de code copiés-collés à partir de sites tutoriels. Les développeurs de thèmes semblent penser que parce que l’extrait de code se trouve 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 d’assistance pour les utilisateurs.
Vous voulez limiter les risques de problèmes avec les 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 citer que quelques-uns. Méfiez-vous des marchés de thèmes où l’expérience et les compétences de l’auteur peuvent être insuffisantes. Dans la plupart des cas, vous en aurez pour votre argent.
Meilleures pratiques de codage
Beaucoup de ces problèmes peuvent être évités en respectant les normes de codage de WordPress. Par exemple, vous devriez préfixer les noms de vos fonctions pour éviter tout conflit potentiel.
Dans le cas de problèmes de style avec Gravity Forms, vous pouvez éviter certains styles généraux sur les éléments de formulaire et de saisie, et utiliser à la place les sélecteurs d’ID par défaut de WordPress pour l’essentiel de vos styles de formulaire.
Ceux-ci incluent #searchform, #s, #searchsubmit dans la boîte de recherche. Egalement #commentform #author, #url, #email, #comment, #submit pour le formulaire de commentaire.
Conclusion
Si vous êtes un développeur de thème et que vous n’avez pas de grandes connaissances en PHP, soyez prudent lorsque vous copiez et collez 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” peut y être pour quelque chose.
Parfois, j’ai l’impression que les développeurs de thèmes WordPress se contentent de coller des extraits de code au hasard dans leur fichier functions.php, juste pour pouvoir présenter une nouvelle “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, il s’agit d’un tout autre débat sur le rôle des thèmes et des plugins sur les sites WordPress, que je garderai pour un prochain article.
Interesting..I’m a theme developer myself thank you from bringing this to my attention…
I’ve even seen people copy and paste code with copyright notices (asking that the code not be shared!) still intact.
@mkjones – is the problem that the filter was removed, or that its removal wasn’t advertised? I almost always remove the wpautop filter because it automatically destroys perfectly good HTML (of course I tell everyone that it’s gone).
What really irritates me the most is when they paste Jquery (and 20+ other scripts/plugins) directly in the header of their theme or in some hard to find. IS wp_enqueue_script that difficult?
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums if anyone wants to check it out.
Just wanted to add one more thing that may be helpful to some of your readers.
Earlier this month I was helping out a client that purchased a support license for my plugin. The clients theme had around 20 different Jquery plugins loaded into the header.php. Not one of them were using wp_enque_script.
Most of these scripts were only being used for the home page slider and gallery page (that didn’t yet exist.) Since they were getting loaded across the entire site, the scripts were throwing Jquery errors on all of the rest of the pages in the site that had no need for these scripts.
Rather than rewriting the entire header.php and because I didin’t know if any of the scripts may be needed for future pages. I used a few conditional tags to solve the problem. By using conditional tags, I was able to turn off all of the arbitrary scripts, when the site loaded the registration form that was being generated by my plugin.
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums, if anyone wants to check it out.
Sorry Leland, can you remove that first line in my last comment? I thought I removed it before posting.
Thanks!
Oh MAN I hate this. It causes NO end of headaches when customising themes.
I seem to recall the classic:
remove_filter(‘the_content’, ‘wpautop’);
Creeping into one a while ago. Without being properly advertised as a theme ‘feature’ 🙁
I completely agree with you here! I have been down this road and done this mistake myself, only to find myself in trouble later on.
The things you can do with your functions.php are great, but you need to be organized and careful with what you do if you don’t want to spend hours debugging later.
One of the recommandations I would give would be to carefully organize these snippets of code if you want to keep them.
Keep them in separated files, well commented, double test after implementing. In the end, documenting your work always pays off imo.
Couldn’t have said it any better myself. This isn’t just limited to random code snippets found in tutorials around the Web. Theme developers just randomly drop any and all code into functions.php without thinking about — you’d think they’d use a hook once in a while.