Vous avez reçu une maquette pour un site vitrine simple, et vous devez maintenant développer le thème pour le client. La maquette ne contient que quelques pages (4 ou 5) et vous vous dites donc que ça ne va pas être très long ni très compliqué.

Doucement ! Ce n’est pas parce que 5 pages sont maquettées que votre travail s’arrête à ces 5 pages !

Si c’était le cas, vous pourriez livrer 5 pages HTML en dur et ce serait réglé ! Non ?

Dans cette article, on va voir ensemble quelques éléments “pièges” qu’on a tendance à oublier quand on développe un thème, surtout pour un client. Certains points s’appliquent à tout développement d’ailleurs, thème ou extension.

On a tendance à oublier ces petites choses parce que ce ne sont pas le genre d’éléments consignés dans le cahier des charges, car ils ne font pas partie des besoins spécifiques du client. On se concentre tellement sur le particulier, l’unique, qu’on en oublie le générique et certains cas d’utilisation plus courants.

Donc on va voir quelles sont ces petites choses simples qu’il ne faut pas oublier d’implémenter dans vos développements.

Styler les champs de formulaires

Combien de fois j’ai eu besoin d’afficher un formulaire ou un simple champ texte pour un client, et me rendre compte que son thème ne stylait pas les champs de formulaires ! Aucun style ! Ni pour les <input>, ni pour les <button> ! Argh !

J’avais un champ texte par défaut du navigateur, tout moche. Mais sur la page de contact, le formulaire était propre, parce que l’extension de formulaire utilisée chargeait ses propres styles !

Normalement, une extension ne devrait pas vraiment avoir besoin de charger de styles cosmétiques, mais elles y sont obligées pour justement palier à tous ces thèmes qui n’en fournissent pas. Elles prennent donc le relais pour fournir à leurs utilisateurs une bonne expérience. Mais en théorie, c’est le boulot du thème de s’occuper de styler les champs de formulaire.

Donc prenez un peu de temps pour ajouter des styles par défaut pour vos <input>, vos <button>, <select>, et autres. Vous dépendrez moins de vos extensions.

Styler tous les blocs de base de l’éditeur

Dans la même veine, ajoutez des styles pour tous les blocs de base de WordPress. Vous ne pouvez pas savoir si votre client va utiliser un jour le bloc Citation ou non. Ou le bloc Bannière ou le bloc Galerie.

Et je pense que vous n’apprécierez pas trop d’être rappelé 2 mois plus tard pour ça ! Vous allez devoir vous remettre dedans, peut-être ré-installer votre environnement de développement local, etc…

Donc utilisez le contenu de test de WordPress pour créer des articles avec quasiment tous les blocs, et stylez-les uns à uns.

Ajouter les styles de l’éditeur

Optimisez l’expérience d’édition en fournissant des styles pour l’éditeur. Vous pouvez fournir presque exactement la même feuille de styles que celle utilisée sur le devant du site pour l’éditeur. Par contre, pour celle-ci faites attention aux styles pour les champs de formulaires, sinon vos blocs sélectionnés vont avoir une apparence étrange.

Aussi, déclarez les tailles de textes et vos couleurs dans l’éditeur ! C’est très facile, quelques lignes de PHP ou dans le theme.json suffisent et cela simplifie grandement l’expérience utilisateur de vos clients !

Styler les commentaires

Ce n’est pas parce que la maquette de la page article n’affiche pas de commentaires que votre client ne voudra pas bénéficier de cette fonctionnalité.

Donc ajoutez quelques styles pour l’affichage des commentaires. Selon le besoin, vous devrez peut-être fournir un modèle de commentaires personnalisé, mais ajouter un fichier comments.php dans votre thème ainsi que tous les styles qui vont avec est essentiel.

Aussi, cela vous forcera à ajouter des styles de base pour vos formulaires, vu qu’aucune extension ne les prendra en charge.

Utilisez les fonctions de traductions

Ne laissez aucun texte “en dur” dans vos développements. Aucun !

Si votre client vous rappelle dans un mois pour ajouter une langue sur le site, vous serez contraints de repasser sur toutes les chaines de votre thème pour les changer en chaines traduisibles, les mettre de base en anglais, et créer un fichier de traductions avec vos chaines françaises.

Si vous créez un thème pour le répertoire officiel, votre thème ne sera pas accepté, tout simplement !

Mettez donc en place tout le nécessaire pour vos traductions dés maintenant !

Personnellement, même pour les sites clients, je mets toutes mes chaines traduisibles en anglais par défaut, et je crée un fichier de traductions FR, que je charge avec la fonction load_theme_textdomain().

Si vous voulez en apprendre plus sur comment fonctionnent les traductions, j’ai écris un article complet à ce sujet : Internationaliser son thème ou extension WordPress.

Ajouter des hooks

Ah, les hooks ! Sans eux, rien n’est possible ! Pourtant, il arrive parfois d’avoir besoin d’intervenir sur un process ou une donnée, mais de ne pas pouvoir le faire car il manque un hook ! Et c’est frustrant !

Donc, lors de vos développements, ajoutez des hooks pour ne pas infliger ça aux autres développeurs, y compris votre futur vous ! C’est très facile, et c’est gratuit dans le sens où cela n’a aucun impact sur les performances ou la lisibilité de votre code.

Pour voir en détails comment faire, je vous renvoie sur cet article : Ajoutez des hooks dans vos développements WordPress !

Rendre vos fonctions surchargeables

De la même façon, vous pouvez aussi permettre à d’autres développeurs de modifier le comportement ou certaines fonctions de vos développements en rendant vos fonctions surchargeables.

Pour les thèmes, c’est très facile : il suffit d’ajouter un simple if ( ! function_exists( 'ma_fonction' ) ) {...} dans votre thème parent.

Si la fonction en question existe déjà dans le thème enfant, alors c’est celle du thème enfant qui sera prise en compte à la place de celle définie dans le thème parent.

Pour les extensions c’est un peu plus compliqué, car l’utilisateur doit charger sa fonction personnalisée avant la vôtre. Mais le principe reste applicable.

Toutes les fonctions ne sont pas forcément de bonnes candidates pour ce type de traitement, mais si vous pensez qu’un utilisateur pourrait avoir besoin d’avoir la main sur toute la fonction, ajouter un if avant de définir la fonction est vite fait.

Rendre vos modèles surchargeables

Vous savez surement que dans un thème enfant, il est possible de surcharger les modèles du parent en les copiant-collant dans le dossier de votre thème enfant ?

Si ce n’est pas clair pour vous, je vous renvoie à un article que j’ai écris sur les thèmes enfants : Créer un thème enfant. Il explique tout ce qu’il faut savoir sur les thèmes enfants !

Mais vous pouvez aussi surcharger les modèles partiels, à condition qu’ils soient appelés avec get_template_part().

Dans votre thème parent, si vous utilisez des include ou require en spécifiant le chemin en dur pour charger les fichiers, alors il ne sera pas possible de les surcharger dans le thème enfant !

Avec des include ou require, le chemin vers le fichier est en dur. Avec la fonction get_template_part(), WordPress va chercher d’abord dans le thème enfant si le modèle demandé existe, et se rabat sur le thème parent sinon.

Il existe de nombreuses fonctions permettant de chercher des fichiers dans vos thèmes : get_theme_file_uri(), get_theme_file_path(), get_parent_theme_file_uri(), get_parent_theme_file_path(), get_template_directory_uri() ou get_stylesheet_directory_uri(), etc…

Utilisez ces fonctions en priorité !

Ces fonctions permettent de chercher dans les thèmes parents et enfants, mais dans une extension, rien ne vous empêche de créer une petite fonction helper qui va faire la même chose !

Par exemple :

/**
 * Returns the path to a template file.
 * Looks first if the file exists in the `my-folder/` folder in the child theme,
 * then in the parent's theme `my-folder/` folder,
 * finally in the default plugin's template directory
 *
 * @param string $slug The template we're looking for
 * @return string $located The path to the template file if found.
 */
function example_get_template( $slug ) {
    $located = '';
    $template_name = "{$slug}.php";
    if ( file_exists( STYLESHEETPATH . '/my-folder/' . $template_name ) ) {
        $located = STYLESHEETPATH . '/my-folder/' . $template_name;
    } elseif ( file_exists( TEMPLATEPATH . '/my-folder/' . $template_name ) ) {
        $located = TEMPLATEPATH . '/my-folder/' . $template_name;
    } elseif ( file_exists( MY_PLUGIN_PATH . 'templates/' . $template_name ) ) {
        $located = MY_PLUGIN_PATH . 'templates/' . $template_name;
    }
    return str_replace( '..', '', $located ) ;
}

Si vous regardez attentivement, vous verrez que la fonction est simplement un locate_template() personnalisé. Pensez juste à définir MY_PLUGIN_PATH !

Et voilà ! Les modèles HTML de votre extension peuvent maintenant être surchargés dans un thème !

Inclure un skip link et des labels pour les boutons

Un skip link est un lien caché tout en haut de la page juste après l’ouverture de la balise <body>, qui permet aux utilisateurs de lecteur d’écran de sauter toute la navigation et d’aller directement au contenu principal.

Sans ce skip link, à chaque changement de page, le lecteur d’écran va lire toute votre entête : l’identité de votre site, son slogan, le menu, etc… Quelle perte de temps pour ces utilisateurs !

Ajouter un skip link est tout simple et résout ce problème ! C’est juste un lien vers votre zone de contenu !

Toujours pour aider les utilisateurs de lecteur d’écran, incluez toujours des labels textes clairs pour vos boutons et éléments de formulaire. Ne laissez jamais une icône seule sans texte explicatif, ou un champ de formulaire sans <label>.

Vous pouvez ajouter ce texte explicatif à côté de votre icône en le cachant visuellement avec la classe CSS screen-reader-text, qui est incluse dans les styles par défaut des blocs (sinon, créez la vôtre). Vous pouvez aussi utiliser des attributs aria.

Et pour les formulaires, non, un placeholder n’est pas un label !

Les tweaks spécifiques vont dans le thème enfant

Alors pour ce point, c’est un peu plus nuancé.

Quand je crée un thème parent pour un client, je crée aussi toujours un thème enfant quand j’installe le site, même s’il est vide. La quasi-totalité de mon code est dans le thème parent, et le thème enfant reste souvent presque vide d’ailleurs.

Mais je me pose toujours la question : est-ce que ce que je suis en train de développer est une fonctionnalité “normale” du thème, ou est-ce une exception ? Est-ce que le client aura besoin de modifier certaines choses ?

Si le client a besoin d’un peu d’autonomie et que vous savez qu’il voudra ou aura besoin de “mettre les mains dans le cambouis”, ne le laissez pas toucher au thème parent, mais laissez-lui la possibilité de faire ses modifications dans le thème enfant.

Par exemple, si le client aura besoin de modifier quelques paramètres sur un comportement, il est très facile de définir ces réglages dans le thème enfant, même si la fonctionnalité en question est contenue dans le thème parent.

// in child theme
define( 'MY_THEME_SETTINGS', array( ... ) );

Easy, et ça évite que le client ne farfouille dans le thème parent. Vous pouvez aussi voir comment créer une page de réglages, si besoin.

Aussi, si vous avez fait vos développements en suivant les points précédents, vous pourrez ajouter vos ajustements exceptionnels dans le thème enfant en surchargeant vos fonctions ou hookant des actions et des filtres.

Conclusion

Quand je développe un thème pour WordPress, j’ai tendance à penser d’abord à un usage générique le plus large possible. Je développe comme si j’allais publier le thème sur le répertoire officiel, même si c’est un thème spécifique pour un client.

Le thème sera entièrement fonctionnel et générique : logo, image mise en avant, styles pour tous les blocs, commentaires, etc… Et c’est seulement dans un second temps que j’ajoute les modèles de page et fonctionnalités spécifiques aux besoins du client.

Je construis du général vers le particulier, du générique vers le spécifique. C’est beaucoup plus facile, car les fonctionnalités spécifiques sont construites sur une base stable et solide. C’est donc plus simple et robuste.

Ces quelques bonnes pratiques sont faciles à implémenter, donc pas de raison de ne pas le faire ! J’espère vous avoir aidé !

Enjoy !

PS : Si vous voulez apprendre comment développer un thème WordPress, je vous invite à jeter un œil à ma formation Développer son thème WordPress Classique. Dans cette formation vous pourrez comprendre mon process en entier et vous verrez en détails comment développer un thème de A à Z, en partant d’un dossier vide, en respectant toutes les bonnes pratiques de développement de thèmes. Je suis sûr que ça vous plaira !