Comment éviter les erreurs courantes de développement de thèmes WordPress

WordPress est connu pour être incroyablement flexible, en particulier en ce qui concerne le développement de thèmes et de plugins. Si jamais vous voulez voir une preuve, demandez simplement à un groupe de développeurs comment ils implémenteraient une fonctionnalité spécifique. Il y a de fortes chances que vous receviez plusieurs méthodes différentes pour obtenir le même résultat. Les forums de support sont jonchés de ce genre d'exemples.

Mais avec cette flexibilité s'ajoute la réalité qu'il est facile de faire les choses de la « mauvaise » manière. Maintenant, dans ce cas, "faux" signifie que quelque chose est soit inefficace, soit un peu pénible à maintenir sur la route. Bien que cela puisse fonctionner dans le sens d'être fonctionnel, il existe généralement de meilleures façons de faire avancer les choses.

Examinons cinq des erreurs les plus courantes rencontrées dans le développement de thèmes, ainsi que des alternatives qui vous éviteront de futurs maux de tête.

1. Utilisation d'URL absolues dans les modèles

Si vous avez déjà regardé le code HTML produit par une page ou un article WordPress, vous remarquerez que les images et les liens internes utilisent des URL absolues (complètes). Mais ce n'est pas la meilleure façon de faire avancer les choses lors de l'ajout de code à vos modèles de thème.

Par exemple, supposons que vous développiez un site Web qui utilise une URL temporaire. Une URL absolue codée en dur dans un modèle signifie que vous devrez modifier manuellement le code lorsque vous serez prêt à lancer le site sur son domaine permanent. Bien que cela puisse être fait, il est trop facile d'oublier tous les endroits où ce type de code pourrait se cacher.

WordPress a des moyens intégrés pour déterminer l'URL correcte - extraite directement de la Settings > General du tableau de bord.

Pour un lien, faire écho à esc_url( home_url() ) fournira un chemin complet vers la page d'accueil. Ainsi, au lieu de placer explicitement l'URL dans votre code, vous pouvez ajouter un simple lien vers votre page d'accueil comme ceci :

 <a href="<?php echo esc_url( home_url() ); ?>" />Home</a>

De plus, vous pouvez également l'utiliser pour pointer vers des pages secondaires. Par exemple, si nous voulions créer un lien vers la page À propos de nous de notre site, nous pourrions utiliser le code suivant :

 <a href="<?php echo esc_url( home_url() ); ?>/about-us/" />About Us</a>

Un extrait similaire fonctionne également pour les images. Cet exemple extrait une image du sous-dossier /images/ de notre thème actif :

 <img src="<?php echo esc_url( get_stylesheet_directory_uri() ) ; ?>/images/hello.png" />

2. Ajouter des scripts et des styles directement à un modèle

L'utilisation de scripts et de styles tiers avec WordPress est un monde à part. Lorsque vous commencez à créer des thèmes, vous pouvez être tenté de placer simplement des balises <script> ou <style> , ou même un code d'intégration Google Font directement dans l'en-tête de votre thème. C'est généralement ainsi que les choses se passent avec les sites HTML statiques, il est donc logique de faire la même chose ici.

Mais, comme à peu près tout le reste dans WordPress, il existe une meilleure façon de s'y prendre. Au lieu de cela, profitez de wp_enqueue_script() et wp_enqueue_style() - qui ajoutent des scripts et des feuilles de style aux bons endroits pour vous. Cela facilite également la gestion des actifs, car tout est appelé à partir du fichier functions.php de votre thème.

Plutôt que de réinventer la roue ici, le manuel du thème WordPress contient un guide fantastique sur la façon d'ajouter correctement des scripts et des styles à votre thème.

3. Appel d'instances extérieures de jQuery

Dans une note connexe, l'un des secrets cachés de WordPress est qu'il inclut déjà une copie de jQuery, ainsi que plusieurs fonctionnalités d'interface utilisateur populaires. Ainsi, vous n'avez pas besoin d'installer jQuery ou de l'appeler à distance. Cela permet de tirer facilement parti de la bibliothèque JavaScript populaire et d'implémenter des éléments tels que des onglets, des sélecteurs de date, des boîtes de dialogue et bien plus encore.

Le seul problème est que vous devez activer spécifiquement les éléments que vous souhaitez utiliser via le fichier functions.php de votre thème. Bien que cela crée un peu de courbe d'apprentissage, cela réduit également les ballonnements.

Et, à vrai dire, il n'est pas trop difficile d'implémenter un élément d'interface utilisateur jQuery souhaité. Par exemple, pour activer l'utilisation des onglets jQuery UI, ajoutez simplement l'extrait suivant à votre functions.php :

 function my_jquery_elements() { wp_enqueue_script( 'jquery-ui-tabs', array('jquery')); add_action( 'template_redirect', my_jquery_elements ', 10 );

Cela indique à WordPress de charger l'élément à partir de sa bibliothèque déjà existante. À partir de là, concevez vos onglets et définissez-les comme spécifié dans la documentation de l'interface utilisateur jQuery.

4. Aller trop loin dans la personnalisation

La possibilité d'ajouter des champs personnalisés et des types de publication personnalisés peut faciliter la vie des développeurs et des éditeurs de contenu de site. Ils offrent une commodité, une meilleure organisation du contenu et une UX plus intuitive. Mais parfois on va trop loin.

Je suis un grand fan des champs personnalisés, par exemple. Mais même j'admets qu'il y a eu des moments où j'ai personnalisé un thème au point d'en être inflexible. Les champs sont parfaits pour les configurations où nous savons exactement quel contenu devra être saisi, comme les champs d'un profil de membre du personnel.

Cependant, cela peut devenir désordonné lorsqu'il y a des incohérences dans les types de contenu que quelqu'un veut ajouter. Les clients sont connus pour avoir des exceptions "mineures" dans le contenu qui peuvent rendre l'utilisation des personnalisations plus difficile. La logique conditionnelle peut expliquer une partie de cela, mais vous ne pouvez pas aller plus loin avant que l'interface utilisateur ne devienne incontrôlable.

Il n'y a pas de règles strictes pour ce type de personnalisation. La seule chose que nous pouvons vraiment faire est d'utiliser notre meilleur jugement sur ce qui doit être personnalisé et ce qu'il vaut mieux laisser à l'éditeur de contenu WordPress ou même à un plugin de niche. Lorsque nous ajoutons des champs ou des types de publication, sachez simplement que les choses peuvent changer ultérieurement et essayez de construire en gardant cela à l'esprit.

5. Ne pas commenter le code

Je vais faire un autre aveu ici : commenter le code n'est pas un de mes points forts. Ce n'est pas que je n'utilise pas du tout les commentaires, mais c'est plutôt qu'ils ne sont pas très articulés. Habituellement, je soulignerai le début et la fin d'éléments particuliers sans une tonne d'informations entre les deux. Dois-je en faire plus ? Probablement.

Les commentaires sont importants car ils fournissent au moins quelques points de référence dans le code. Lorsque vous fouillez dans des fichiers PHP ou JS qui contiennent plus d'une chose, vous voudrez savoir où trouver un élément particulier.

Même si vous êtes le seul à modifier ce code, les commentaires sont fortement recommandés. Si, par exemple, vous devez changer quelque chose dans six mois, il est peu probable que vous vous souveniez de l'endroit exact où vous avez placé un extrait de code.

Donc, je ne vais pas être un grand hypocrite et vous implorer de tout commenter avec une grande profondeur. Mais je dirai que même un effort minimal ici facilite la maintenance future pour vous ou un autre développeur qui doit passer au peigne fin votre travail.

De meilleures techniques au fil du temps

Construire votre propre thème WordPress peut être une expérience formidable. Mais il faut un peu de pratique pour saisir les détails les plus fins de la création d'un thème bien codé et facile à entretenir. Plus vous gagnerez en expérience, plus vos techniques évolueront.

Je peux honnêtement dire que les premiers thèmes que j'ai mis en place étaient loin d'être aussi efficaces qu'ils le sont maintenant. Et je suis également certain qu'ils ne sont peut-être toujours pas à la hauteur lorsqu'ils sont vus par un développeur vraiment expert. En ce sens, notre évolution est constante.

Enfin, je tiens à souligner que j'ai personnellement commis chacune des erreurs mentionnées ci-dessus. Ce n'est que par essais et erreurs, ainsi que plusieurs visites au Codex, que j'ai découvert comment commencer à faire les choses à la "WordPress Way".

La leçon est que nous allons tous faire des erreurs. Mais chacun nous offre une chance d'apprendre et de nous améliorer.