Flux de travail de développement WordPress moderne avec la pile Roots

WordPress existe depuis des lustres, du moins selon les normes Internet, et sa philosophie a toujours été de préserver la rétrocompatibilité. Cet accent mis sur la compatibilité est compréhensible étant donné le nombre considérable de sites Web WordPress en ligne aujourd'hui. Cependant, bien que cela puisse aider ceux qui utilisent encore des environnements hérités avec les anciennes versions de PHP et MySQL (ce qui est un risque de sécurité en soi, mais ce n'est pas le sujet de l'article d'aujourd'hui), cela a également empêché les nouvelles versions de WordPress de tirer pleinement parti de les dernières fonctionnalités PHP.

Cela a également amené de nombreux développeurs WordPress à vivre dans une bulle WordPress, n'étant pas incités à apprendre de nouvelles technologies de développement front-end modernes, et parfois bloqués dans la «bonne vieille façon» de faire les choses.

Pouvez-vous adopter un workflow de développement moderne pour WordPress ?

Vous le pouvez très certainement, et la pile WordPress Roots est là pour vous aider à développer comme en 2019, avec trois outils incroyables :

• Sage comme thème de départ,
• Bedrock en tant que passe-partout WordPress moderne,
• Trellis pour gérer le déploiement et le provisionnement dans différents environnements.

L'équipe Roots a également deux outils supplémentaires en développement : Acorn, un framework de création de plugins, et Clover, un plugin standard. En raison du fait que les deux sont en alpha, ils ne sont pas inclus dans cet article, mais vous devez absolument les surveiller.

Qu'est-ce que la pile de racines exactement

Initialement connu sous le nom de thème Roots, il s'agissait d'un thème de démarrage HTML5 solide comme le roc visant à fournir un point de départ plus propre pour les nouveaux sites Web WordPress. Au fil du temps, il a évolué vers un ensemble complet d'outils, passant par toutes les principales technologies et normes Web modernes (de Grunt à Gulp et Webpack, LESS et SCSS, NPM et Yarn, Bootstrap, les normes de codage PSR-2 et le principe DRY), obligeant ainsi les développeurs WordPress qui l'ont adopté à apprendre en permanence et à se tenir au courant de ce que les technologies de développement front-end modernes ont à offrir.

Aujourd'hui, Roots est devenu un ensemble complet d'outils en expansion continue, visant à vous aider à créer de meilleurs sites WordPress en suivant l'intégralité du cycle, du développement à la mise en scène et à la production, et à faire de vous un meilleur développeur en vous forçant à sortir du confort zone fournie par la soi-disant bulle WordPress.

Mais examinons les trois principaux outils qu'ils proposent, ce qu'ils sont et pourquoi vous devriez envisager de les utiliser.

Racines Sauge 9

Roots Sage 9 est la dernière itération d'un thème de démarrage WordPress entretenu par des professionnels, initialement publié sous le nom de Roots en 2011. Au cours de sa vie, il a subi de nombreux changements, améliorations et reconsidérations des meilleures pratiques, pour finalement devenir ce que aujourd'hui est un excellent point de départ pour introduire un flux de travail de développement frontal moderne pour le développement WordPress.

Ce que Sage essaie de faire est d'adopter un modèle MVC (Modèle-Vue-Contrôleur) où les Vues et le Contrôleur sont complètement séparés ; cela nous permet de réutiliser les vues, qui n'ont pas nécessairement besoin de "savoir" d'où viennent les données, mais elles attendent simplement qu'un contrôleur leur fournisse des données à afficher.

Le contrôleur inclus avec Sage 9 n'est pas le contrôleur réel que vous connaissez peut-être déjà dans d'autres frameworks comme Laravel, la principale différence est que Sage 9 Controller utilise un routage basé sur un modèle au lieu d'un routage basé sur une URL. Fondamentalement, vous laissez WordPress gérer le routage des URL et vous écrivez des contrôleurs pour les fichiers de modèle.

En ajoutant quelques degrés de complexité à l'ensemble du processus de développement, Sage 9 n'est peut-être pas le meilleur choix pour commencer pour les débutants, car vous aurez pas mal d'apprentissage pour éventuellement le maîtriser et pouvoir l'utiliser en production : la gestion des dépendances et des actifs, la gestion des versions de code, une nouvelle structure de projet, un nouveau moteur de template dérivé de Laravel, le principe DRY (Don't Repeat Yourself), et vous devrez vous en tenir à des normes de codage strictes qui sont un peu différentes de ce que WordPress recommande ; mais si vous êtes un développeur chevronné, cela peut être une bonne longueur d'avance.

Si vous voulez faire tapis avec Sage, gardez à l'esprit ce conseil de Ben Word, l'un des développeurs de l'équipe Roots :

Sage n'est pas un framework de thème, c'est un thème de démarrage. Vous devriez rarement avoir besoin de le mettre à jour, et généralement vous ne devriez pas créer de thèmes enfants à partir de celui-ci. En tant que thème de démarrage, Sage est destiné à être utilisé comme point de départ pour un nouveau projet.

Mais aussi:

Si Underscores est une longueur d'avance de 1 000 heures, Sage est une longueur d'avance de 10 000 heures.

Structure de fichiers et de dossiers avec Sage

La structure de fichiers et de dossiers de Sage est un peu différente de ce que nous avons l'habitude de voir dans d'autres thèmes de démarrage comme Underscores, ou même dans la version majeure précédente de Sage 8.

Voici ce que vous trouverez juste après l'installation de Sage :

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

De plus, certains autres fichiers utilisés par les éditeurs de code et les IDE, tels que .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml, etc.

Voici un bref aperçu des exigences de base de Sage 9 :

• Wordpress >= 4.7
• PHP >= 7.1.3 (avec php-mbstring activé)
• Compositeur
• Node.js >= 8.0.0
• Fil

Substrat rocheux

Bedrock est comme WordPress sous stéroïdes !

Si Sage améliore le développement de votre thème, Bedrock améliore l'ensemble de l'installation de WordPress. Il le fait en fournissant un passe-partout de projet moderne , avec une structure de dossiers et une sécurité améliorées (par exemple en n'ayant pas vos fichiers de configuration à la racine du site Web), des fichiers de configuration et ENV, et une gestion appropriée des dépendances (oui, y compris les plugins et thèmes WordPress) .

Pour le décrire en une seule phrase, nous pourrions dire que Bedrock est un projet WordPress autonome qui automatise l'installation des fichiers principaux et des plugins requis.

Structure des fichiers et des dossiers

Si vous regardez une installation de base de Bedrock, vous pourriez vous sentir perdu au début. Bedrock sépare les fichiers Web, de configuration et de dépendance dans leurs propres dossiers. Voici à quoi ressemble la structure osseuse nue :

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Plus quelques autres fichiers moins importants.

Les exigences du socle rocheux sont :

• PHP >= 7.1
• Compositeur

Treillis

Trellis est une pile LEMP moderne pour gérer vos serveurs de développement, de mise en scène et de production de manière transparente, dans le but de les garder aussi similaires que possible ("parité de développement et de production"). Cela signifie que si votre site WordPress personnalisé fonctionne dans votre environnement de développement, il est prudent de supposer qu'il fonctionnera également en production et que vous pourrez le déployer en toute confiance.

Pour le développement local, Trellis utilise Vagrant, avec un simple vagrant up vous aurez une machine virtuelle exécutant un environnement moderne approprié.

Le provisionnement et le déploiement dans vos environnements de préproduction et de production sont gérés avec des playbooks Ansible, qui sont des fichiers YAML qui indiquent à Ansible ce qu'il faut faire.

Structure de dossier suggérée en treillis

Trellis a une structure de dossiers suggérée composée de seulement deux sous-dossiers :

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Je vous recommande de le laisser tel quel, mais il peut être personnalisé en fonction de vos goûts et de vos besoins.

Exigences relatives au treillis

• Compositeur
• Boîte virtuelle >= 4.3.10
• Vagabond >= 2.1.0

Pourquoi devriez-vous l'utiliser

Si WordPress fonctionne déjà tel quel, pourquoi devriez-vous passer à une pile plus complexe et passer un temps considérable à la maîtriser ? Parce qu'il y a des avantages évidents et d'autres moins évidents. Essayons de voir ce qu'ils sont.

Un thème de démarrage indépendant du framework

Trop de thèmes de démarrage WordPress vous obligent à utiliser un framework CSS spécifique que vous pouvez ou non aimer ou même connaître, mais Sage est complètement indépendant du framework. Lors de l'installation, vous aurez la possibilité d'inclure automatiquement Bootstrap 4, Bulma, Foundation, Tachyons, Tailwind CSS, ou aucun framework du tout si vous voulez repartir de zéro ou utiliser autre chose (CONSEIL : dernièrement, je commence à aimer Tailwind CSS beaucoup).

CONSEIL DE PRO : sur une machine Windows, vous pourriez recevoir le message "Le mode TTY n'est pas pris en charge sur la plate-forme Windows" lors de l'installation et vous ne pourrez pas choisir un framework ou configurer Sage. Vous devrez exécuter ces trois commandes manuellement depuis le dossier du thème si vous souhaitez profiter de la configuration automatique :

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Un processus de construction moderne

Avec Webpack, inclus dans Sage, vous n'aurez plus à vous soucier de compiler des actifs, de concaténer et de minifier du code JavaScript et CSS, d'optimiser des images, de vérifier les erreurs JavaScript et de style et de gérer des bibliothèques externes. Le processus de construction s'occupera de tout cela avec une simple construction de yarn build (ou yarn build:production si vous voulez que vos ressources soient optimisées pour une utilisation en production), produisant tous les fichiers statiques dans votre dossier /dist/ de thème.

PHP moderne et exigences

La version minimale de PHP sur laquelle vous pouvez exécuter WordPress est PHP 5.2.4, cela garantira une rétrocompatibilité pour tous les utilisateurs qui exécutent leurs sites Web dans un environnement hérité, mais les anciennes versions de PHP (<= 7.0) ont officiellement atteint la fin de Life, ils ne sont donc plus pris en charge et peuvent exposer votre site à des failles de sécurité et à des problèmes de performances.

Sage et Bedrock nécessitent tous deux une version saine de PHP 7.1 (bien que si vous avez la possibilité de choisir 7.3, veuillez le faire).

Sage 9 adopte également pleinement les normes de codage PSR-2 (les normes de codage les plus largement utilisées et acceptées

standards utilisés dans la communauté PHP), qui sont un peu différents des standards de codage de WordPress, mais ils vous permettent d'avoir un code plus propre et plus maintenable, surtout si vous travaillez en équipe ou devez partager votre code avec d'autres.

Meilleures dépendances et gestion des packages

La pile Roots utilise largement Composer pour gérer toutes les dépendances et packages, y compris le noyau WordPress, les plugins et les thèmes. Cela peut être un problème si vous utilisez des outils tiers pour gérer les mises à jour de WordPress (comme ManageWP, MainWP ou InfiniteWP), mais quelqu'un pourrait dire que le fait d'avoir tout sous contrôle de version vous donne plus de contrôle et facilite le retour à un travail précédent. version en cas de problème.

De plus, Sage utilise Yarn comme package et gestionnaire de dépendances pour le code d'application et pour lancer le processus de construction.

De meilleurs fichiers de modèles

Il manque à WordPress un véritable moteur de templates, alors pour pallier à cela Sage a adopté Laravel's Blade et il suit le principe DRY : Don't Repeat Yourself.

Voici à quoi ressemble le fichier de modèle par défaut single.blade.php, juste 6 lignes de code :

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

Le moteur de modèle Blade sépare complètement les vues et les contrôleurs et sa syntaxe est plus élégante, concise, lisible et plus facile à écrire que de simples balises PHP. La règle d'or ici est de laisser tout le code PHP en dehors de vos fichiers de modèle (ou du moins d'essayer).

Un autre avantage de l'utilisation de Blade est l'héritage des modèles : un modèle de mise en page de base (la valeur par défaut est /resources/views/layouts/app.blade.php ) définit des blocs contenant les éléments communs du site Web, qui sont ensuite hérités par ses modèles enfants. L'héritage de modèle est idéal pour supprimer le balisage répété des modèles individuels et garder les choses au SEC.

Synchronisation du navigateur

En exécutant yarn start , vous lancerez une session Browsersync. Browsersync est un module de test de navigateur synchronisé pendant le développement. Il surveillera les modifications apportées à vos actifs frontaux et, en collaboration avec Webpack, il injectera automatiquement les modifications dans la session de votre navigateur.

Déploiement rapide, facile et sûr de WordPress

Trellis propose des déploiements WordPress sans temps d'arrêt. Lorsque vous lancez un déploiement, Trellis va cloner votre dépôt, lancer l'installation du compositeur, puis mettre à jour le lien symbolique vers la version actuelle afin qu'il ne modifie jamais directement les fichiers qui sont actuellement servis en production.

Lors de l'utilisation de Bedrock, Trellis nécessite également très peu de configuration.

Désavantages

Le seul inconvénient de l'utilisation de la pile Roots complète (à part l'apprentissage de nouvelles choses, qui ne devrait pas du tout être considérée comme un problème) est que vous devez utiliser un fournisseur d'hébergement compatible Trellis comme Kinsta, une gouttelette DigitalOcean ou tout autre hôte qui prend en charge au moins SSH, Composer et WP-CLI, ainsi que la possibilité de mettre à jour le chemin racine Web.

Cela laisse la plupart des hébergements partagés bon marché (plutôt) hors du jeu et c'est quelque chose que vous et/ou votre client devez prendre en compte avant de commencer un nouveau projet.

Comment commencer

Cela peut être considéré comme une nouvelle version de la célèbre «installation de WordPress en 5 minutes», mais pour les développeurs front-end modernes. Cela ajoute quelques degrés de complexité pour un développement ultérieur, mais en fin de compte, les avantages que vous pouvez obtenir en valent vraiment la peine.

Nous nous concentrerons sur l'adoption de la pile complète (Sage, Bedrock et Trellis), mais vous pouvez n'en utiliser qu'une seule ou une combinaison d'entre elles. Sage peut être utilisé comme point de départ pour un thème autonome sur n'importe quelle installation WordPress ; Bedrock peut être utilisé avec n'importe quel thème WordPress que vous souhaitez ; et les déploiements Trellis sont configurés pour les sites basés sur Bedrock et prennent en charge tout le nécessaire, mais avec un peu de bricolage, ils peuvent être personnalisés pour presque tous les besoins.

Comment créer un nouveau projet

La configuration d'un nouveau projet WordPress avec Trellis, Bedrock et Sage est assez simple, à quelques lignes de commande.

Installez Trellis dans le dossier de votre choix (par exemple example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Installez Bedrock dans le sous-dossier /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Installez et compilez Sage :

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Déploiement

Le déploiement en staging ou en production est encore plus facile si vous avez tout configuré correctement selon la documentation officielle. C'est juste une ligne de commande (à partir du dossier example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

Vous pouvez également facilement annuler votre déploiement, exécutez simplement :

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Conseils sur la configuration de votre environnement de développement sous Windows

Si vous recherchez sur Google comment installer et utiliser la pile Roots, en particulier Trellis, vous trouverez de nombreux didacticiels axés sur Linux ou MacOS, mais très peu d'informations sont disponibles pour Windows où vous trouverez deux problèmes principaux : Ansible n'est pas disponible pour Windows, et Vagrant est généralement extrêmement lent sur les machines Windows.

Lorsque j'ai initialement pensé à cet article, la documentation officielle de Trellis pour Windows suggérait d'exécuter Ansible à l'intérieur de la machine virtuelle Vagrant, mais c'était en quelque sorte une façon hacky de faire les choses et ce n'était pas très fiable.

Depuis lors, ils ont mis à jour la documentation avec des instructions appropriées sur la configuration de tout avec WSL (sous-système Windows pour Linux), il n'est donc pas nécessaire de réinventer la roue et d'écrire un didacticiel à ce sujet. Il est bon de savoir qu'il existe trois pages d'instructions détaillées étape par étape que vous pouvez suivre avant d'installer Trellis : Configuration de Windows, Configuration de Windows : Sage et Configuration de Windows : Trellis.

Bon codage !