Qu’est-ce qu’un boilerplate ?

Il s’agit, vous l’aurez compris, d’un anglicisme. En français, il faudrait utiliser le mot standard… mais du « code standard » ce n’est pas forcément parlant. Il est également possible de parler de prototype non fonctionnel, c’est peut-être un peu plus parlant mais également un peu plus long et moins souvent utilisé. Je préfère donc utiliser l’anglicisme.

Un boilerplate, appliqué au code, est ainsi une maquette avancée ou un prototype. Il ne s’agit pas seulement de décrire une structure. Le boilerplate peut intégrer une configuration et des fonctionnalités qui restent quasiment les mêmes à chaque utilisation. Dans le cas d’un thème WordPress, il peut ainsi s’agir des différents fichiers à utiliser pour créer le thème (index.php, header.php, footer.php, single.php, etc.) mais également de la configuration d’outils qui seront utilisés pour chaque développement de thème.

Les fonctionnalités de mon WordPress boilerplate

Pour le moment, je ne propose qu’un boilerplate pour les thèmes. Par la suite, j’envisagerai peut-être d’en créer un pour les widgets ou pour les plugins. Ici, je vais donc me contenter de vous décrire mon boilerplate pour développer des thèmes WordPress.

WordPress Logo

Ce que j’utilise à chaque fois

Lorsque je développe un thème WordPress :

  • je m’efforce de respecter les WordPress Coding Standards,
  • j’utilise Gulp pour compiler Sass en CSS, pour minifier les fichiers ou encore pour optimiser les images,
  • je génère un fichier pot pour gérer la traduction du thème,
  • j’utilise normalize.css pour que le rendu dans les navigateurs soit plus uniformisé.

De manière générale, lorsque je crée un projet, j’essaie :

Ce que le boilerplate contient

Pour faciliter le développement de thème, le boilerplate que je propose contient tout ça. Le fichier normalize.css est importé dans Sass après installation avec npm. Il est déjà présent dans le fichier style.scss.

Un automatiseur de tâches

Le boilerplate utilise Gulp pour définir différentes tâches que vont permettre :

  • de générer les fichiers style.css, style-rtl.css, style-editor.css et print.css, d’ajouter les préfixes, de les minifier,
  • de transpiler avec Babel, de générer un fichier unique pour les scripts utilisés et de minifier ce fichier,
  • d’optimiser les images,
  • de générer un fichier pot pour la traduction,
  • de créer une archive du thème en excluant les fichiers dédiés au développement,
  • de surveiller les changements apportés aux fichiers pour exécuter de nouveau les tâches et pour recharger le navigateur avec Browsersync.
Gulp + Babel + Sass + Autoprefixer + Browsersync

Le fichier Gulp contient également des tâches qui vont être utilisées pour la gestion des versions. Grâce à standard-version, il est possible de créer une nouvelle version et de générer un changelog. Cependant, il incrémente le numéro de version uniquement dans package.json. WordPress utilise le numéro de version déclaré dans le fichier style.css et, éventuellement, dans le fichier functions.php. Gulp va permettre de récupérer le nouveau numéro de version et de le copier dans ces fichiers.

Il contient également une tâche qui va permettre d’initialiser votre thème avec la configuration définie dans un fichier dotenv. Il s’agit d’un basique « chercher/remplacer ». En exécutant la tâche, Gulp va, par exemple, remplacer le nom du package, son auteur, l’URL du dépôt ou encore le préfixe à utiliser.

Des scripts npm et Composer

Le boilerplate propose également :

  • la gestion des versions avec standard-version,
  • la génération d’un changelog basé sur Conventional Changelog,
  • un linter et un hook git grâce à Husky pour vérifier que les commits respectent le standard Conventional Commits,
  • des linters pour vérifier que le code respectent les WordPress Coding Standard et des scripts pour essayer de corriger ces erreurs automatiquement.
Composer + npm + Conventional Changelog

Si vous utilisez VS Code, il propose également un fichier de configuration avec des extensions qui peuvent remplacer les scripts définis dans le fichier composer.json.

Comment utiliser ce boilerplate ?

Vous pouvez récupérer les sources sur mon dépôt Github ou Gitlab. Une fois téléchargées, il vous suffit de copier le dossier wordpress-theme dans votre installation WordPress et de le renommer.

Prérequis

Pour que le boilerplate fonctionne, il faut :

  • installer Composer et npm,
  • configurer un hôte virtuel,
  • respecter le format de Conventional Commits pour vos commits.

Premières étapes

Pour commencer, il faut initialiser un nouveau dépôt Git sinon l’une des dépendances ne voudra pas s’installer. Ensuite, vous pouvez exécuter npm install et composer update pour installer toutes les dépendances.

Pour initialiser votre thème, il vous faut un fichier dotenv. Votre répertoire contient un fichier .env.example, il vous suffit de créer une copie et de la nommer .env. Ensuite, il faut remplacer les valeurs dans le fichier.

Browsersync redirige votre hôte virtuel sur localhost. Pour éviter les avertissements liés à l’usage de https en local, il vous faut un certificat valide et renseigner le chemin dans le fichier dotenv. Vous pouvez en générer un avec mkcert et l’enregistrer dans le dossier /certs.

Une fois ces étapes réalisées, vous pouvez exécuter npm run init. Pour mettre à jour le fichier package-lock.json, vous devriez exécuter de nouveau npm install.

Développer votre thème WordPress

Le fichier Composer vous propose deux scripts faisant appel à PHPCode_Sniffer et aux WordPress Coding Standard. Ils vous permettent de détecter et de corriger les erreurs. Il vous suffit d’exécuter composer run lint <fichier(s)> ou composer run lint . (pour l’ensemble du dossier) afin d’afficher les problèmes. Il suffit de remplacer lint par fix pour les corriger.

Le fichier package.json vous propose plusieurs scripts :

  • npm run build vous permet de supprimer les précédents fichiers générés et d’en générer de nouveaux (images, css, js et fichier de traduction),
  • npm run watch vous permet d’exécuter BrowserSync et de surveiller les changements apportés à vos fichiers pour exécuter automatiquement les bonnes tâches,
  • npm run release vous permet de créer une nouvelle version du thème, de créer un commit pour cette version ainsi qu’un tag
  • npm run zip vous permet de créer une archive de votre thème en excluant les fichiers uniquement nécessaires au développement.

Si vous avez besoin d’ajouter des chemins supplémentaires et de modifier la configuration des tâches Gulp (comme l’optimisation des images), il faudra éditer le fichier gulp/config.js.

Si vous souhaitez ajouter des plugins, vous pouvez éditer le fichier gulp/error-handler.js pour gérer les erreurs.

Ce que ce WordPress boilerplate ne fait pas

La création d’une nouvelle version n’est pas automatisée à 100 %. La plupart des thèmes sont traduits dans différentes langues. Pour cela, il est nécessaire de créer les traductions manuellement. Ainsi, il n’est pas possible de combiner les tâches build, release et zip. Toutefois, si vous n’avez pas besoin de traduction, vous pouvez toujours adapter le boilerplate pour automatiser ce processus.

Les fichiers PHP propres à WordPress (functions.php, header.php, etc.) et les fichiers SCSS ne contiennent que très peu de code. Le but n’est pas d’offrir un thème tout fait, mais de proposer une base pour que chacun puisse créer son propre thème avec sa propre structure plus rapidement. D’ailleurs, si vous n’avez pas besoin de tous les fichiers (comme date.php, front-page.php…), vous pouvez les supprimer.

Enfin, si vous estimez qu’il manque des fonctionnalités qui peuvent être utiles pour tout le monde et non pas uniquement pour vos projets, vous êtes libres de les proposer.

Aucun commentaire sur “Un boilerplate pour développer des thèmes WordPress” pour le moment.

S'abonner aux commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *