Comment aborder le développement WordPress moderne (Partie 1)

Publié: 2022-03-11

Ce n'est un secret pour personne que la base de code WordPress est un gâchis. Personnellement, chaque fois que je passe par là, tout ce que je veux, c'est me recroqueviller et pleurer. D'autre part, WordPress est bien en avance sur ses concurrents. Un CMS facile à utiliser et puissant est une entreprise énorme, et WordPress reste populaire parce qu'il offre cela.

Alors pourquoi nous soucierions-nous de la qualité du code dans le noyau de WordPress ? Ça marche, non ?

Oui, cela fonctionne, et il est peu probable que la base de code vieille de 15 ans soit complètement remaniée par ses mainteneurs bénévoles. Malheureusement, cela signifie qu'il fonctionne également comme un exemple de codage "à la manière de WordPress", excusant de nombreux développeurs de ne pas suivre les meilleures pratiques et les techniques de développement modernes. Tant de plugins et de thèmes WordPress ont un code tristement mauvais, et suivre aveuglément les pratiques héritées ne fait que poursuivre la tendance.

Mais qui se soucie du mauvais code qui fait toujours son travail ? Eh bien, rien n'est gratuit et quelqu'un paie pour un travail mal fait. Avec la base de code WordPress elle-même, ses mainteneurs paient de leur temps, heureusement. Mais avec votre propre code, c'est votre client qui paie.

Pour tout système même modérément complexe, le coût du développement initial est insignifiant par rapport au coût de sa maintenance, et la maintenance signifie également l'ajout de nouvelles fonctionnalités. Embaucher un développeur pour réparer un logiciel mal conçu et implémenté coûtera plusieurs fois plus cher que de le développer correctement dès le départ.

Les solutions bon marché sont toujours les plus chères à long terme. Ou ils sont abandonnés après avoir épuisé leur budget. Nous économisons réellement l'argent des clients lorsque nous suivons des principes et des pratiques de conception de logiciels éprouvés. Ces méthodes ne sont pas une mode exagérée, ni un changement pour le changement. La sagesse ici est née de l'expérience collective des développeurs, et le suivre est vraiment payant.

Évidemment, cela ne s'applique pas à des tâches vraiment simples comme l'ajout de quelques lignes de CSS ou quelques publications et réécritures personnalisées. Mais assembler quelques plugins (ou plus communément plusieurs dizaines de plugins) ou créer un site propulsé par Visual Composer n'est pas du génie logiciel, de toute façon.

Ce n'est pas une mauvaise chose en soi - le fait que certaines solutions soient aussi simples explique pourquoi WordPress est si populaire. Mais dans cette série, je parlerai du vrai développement WordPress : écrire du code PHP, HTML, CSS et JavaScript significatif. Je commencerai par le flux de travail général, puis je me concentrerai sur le développement frontal de WordPress dans cet article.

Flux de travail de développement WordPress moderne

En général, le code de qualité est :

  • Lisible. Il est facile de comprendre ce que fait le code et pourquoi.
  • Modulaire. De petits blocs de code avec un objectif clair sont faciles à comprendre, à développer et à tester.
  • Réutilisable. La réutilisation de modules déjà développés pour résoudre des problèmes similaires accélère considérablement le développement.
  • Maintenable. La modification d'anciennes fonctionnalités ou l'introduction de nouvelles fonctionnalités est facile.

Les principaux résultats - un coût de développement et de possession inférieur - ont de nombreux avantages indirects que je n'aborderai pas ici.

Au lieu de cela, je me concentrerai sur les techniques de développement et les meilleures pratiques qui peuvent vous aider à produire un code de qualité. Commençons par le contrôle de version.

Utiliser le contrôle de version

Cela signifie utiliser Git. Malheureusement, le "codage de cow-boy" sur la production via FTP est à peu près toujours une chose. Tout récemment, j'ai travaillé pour une agence basée au Royaume-Uni et ils avaient des fichiers avec des noms comme ceux-ci partout dans leur base de code :

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

La toute première chose à faire lorsque vous prenez un site WordPress est de le mettre sous contrôle de version. Tanking Servers est une rétrospective amusante des erreurs de développement de WordPress. Il aurait été très facile de corriger ces problèmes - et des incidents similaires qui sont probablement arrivés à tout le monde - en utilisant Git.

Vous avez fait une erreur dans votre code et tout le site est tombé en panne ? git reset récupère tout comme avant. La nouvelle mise à jour de la version a tout cassé ? git reset fonctionne comme une machine à remonter le temps. Un code malveillant est apparu de nulle part ? git status affiche tous les nouveaux fichiers, les fichiers supprimés ou les modifications apportées à tous les fichiers suivis. Ensuite, vous venez de git checkout , en restaurant les originaux.

Méfiez-vous de l'exposition du dossier .git

OK, il est clairement important d'utiliser Git. Mais lorsque vous le faites, il est tout aussi important d'éviter d'exposer votre référentiel Git au piratage. Le problème survient lorsque vous avez des dossiers .git exposés et que vous y stockez vos informations d'identification.

Une installation WordPress standard vit entièrement dans un dossier Web public, et le dossier .git est très susceptible d'être là aussi. De toute évidence, aucun identifiant de connexion ne doit être stocké dans le référentiel Git, mais il se trouve que la plupart des référentiels contiennent des informations sensibles qui ne doivent pas être divulguées à l'extérieur.

L'accès public au dossier .git doit donc être bloqué. Si vous utilisez Apache, l'ajout de l'extrait ci-dessous en haut du fichier .htaccess bloquera l'accès au dossier .git ainsi qu'aux fichiers journaux. Les fichiers journaux contiennent souvent des informations sensibles, il est donc sage de les rendre également indisponibles. Pour différentes configurations de serveur Web, veuillez demander de l'aide à votre expert DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Utiliser des environnements séparés

Ne faites pas de développement sur des sites en direct - c'est une recette pour les temps d'arrêt et les clients mécontents. OK, mais comment devez-vous le configurer ?

Idéalement, il devrait y avoir trois environnements de développement, le code allant toujours dans un sens : local → staging → production. Il s'agit d'une méthode éprouvée pour éviter les collisions. Toutes les mises à jour du noyau, des plug-ins et des thèmes sont d'abord effectuées localement, puis testées sur la mise en scène et enfin déployées en production.

Par exemple, la configuration spécifique au serveur peut être stockée dans un fichier séparé. Vous pouvez créer un wp-config-local.php pour chaque environnement local et intermédiaire. (N'oubliez pas de l'ajouter à votre fichier .gitignore !) Ajoutez ensuite l'extrait suivant à wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Souvent, la meilleure façon de configurer différents environnements consiste à utiliser des variables d'environnement. Si vous n'êtes pas familier avec ce concept, je vous conseillerais d'utiliser une solution moderne complète comme Roots.

Utiliser WP-CLI

L'interface de ligne de commande WordPress (WP-CLI) est un outil extrêmement utile pour administrer les installations WordPress. Avoir accès à WP-CLI signifie avoir la possibilité d'exécuter pratiquement n'importe quelle fonction de l'API WordPress. Par exemple, vous pouvez ajouter, supprimer et modifier des utilisateurs et leurs mots de passe avec WP-CLI. Utile si vous venez d'hériter d'un site et que le propriétaire s'est lui-même verrouillé.

Un autre exemple est que le déploiement initial est un jeu d'enfant avec WP-CLI. Ceux-ci peuvent être accomplis avec quelques commandes :

  • Téléchargement du noyau, des thèmes et des plugins
  • Recherche et remplacement dans la base de données
  • Ajout d'un utilisateur administrateur

De plus, ces actions peuvent être scriptées et automatisées.

Utiliser les options de déploiement avancées

En parlant d'automatisation, il vaut la peine d'apprendre certaines technologies et processus de déploiement tels que :

  • Intégration continue/déploiement continu/livraison (CI/CD)
  • Docker
  • Tests automatisés (y compris les tests de régression front-end)

Certes, passer de la non-utilisation du contrôle de version à la gestion de Docker est un énorme pas en avant et sera probablement écrasant pour un projet WordPress typique d'une seule personne. Certaines options peuvent même ne pas être possibles selon votre fournisseur d'hébergement. Mais le déploiement avancé est indispensable pour les équipes et pour les grands projets.

Utiliser des peluches

Pour les projets de toute taille, cependant, le peluchage est une aubaine pour la plupart des développeurs. Le peluchage signifie vérifier automatiquement votre code pour les erreurs. Un IDE complet tel que PHPStorm le fait déjà immédiatement ; cependant, des éditeurs plus simples tels que VSCode ou Sublime Text ont besoin d'un programme dédié appelé linter. Une façon de configurer cela consiste à configurer votre éditeur pour qu'il exécute un linter chaque fois que vous enregistrez un fichier.

PHP_CodeSniffer est le linter de facto pour PHP. En plus de vérifier les erreurs de syntaxe, il peut également vérifier si votre code suit les directives de style telles que PSR-2. Cela simplifie grandement les normes de codage suivantes.

Pour JavaScript, ESLint est un linter populaire. Il dispose d'un ensemble de règles étendu et prend en charge les configurations personnalisées pour toutes les versions et tous les frameworks de JavaScript.

Un cas d'utilisation puissant ici consiste à incorporer le linting dans un pipeline de construction CI/CD afin que tout le code soit automatiquement validé avant d'être déployé.

Techniques modernes de développement frontal WordPress

Avec un flux de travail approprié maintenant configuré pour votre projet WordPress global, plongeons-nous dans les meilleures pratiques pour le front-end.

Utilisez des outils modernes : Sass et ES6+

Le monde du développement front-end est en constante évolution et toujours en mouvement. Autrefois, nous pensions que Sass était le meilleur outil pour écrire du CSS - et pour le développement WordPress pré-Gutenberg, il l'est toujours - mais tout le monde a commencé à parler de CSS-in-JS et de composants stylisés.

Même WordPress n'a pas pu résister et a repris quelques-unes de ces nouvelles technologies. Gutenberg, le nouvel éditeur de blocs, est construit sur React et une API REST.

Vous devez absolument vous familiariser avec ces technologies front-end de base :

  • ES6+. La documentation de WordPress l'appelle ESNext et encourage même son utilisation.
  • Toupet. Utilisé par WooCommerce et la meilleure façon d'écrire du CSS si vous n'êtes pas encore dans le truc CSS-in-JS.
  • Pack Web. Même le noyau WordPress utilise Webpack et Babel maintenant.

ES6 et Sass sont respectivement JavaScript et CSS modernes, et Webpack est un outil qui permet d'utiliser toutes ces fonctionnalités modernes sans se soucier de la rétrocompatibilité. Webpack peut être appelé un compilateur d'applications frontales qui génère des fichiers à utiliser dans un navigateur.

Transition de jQuery vers Vue.js ou React

Le noyau WordPress et presque tous les plugins WordPress dépendent de jQuery, vous ne pouvez donc pas simplement arrêter de l'utiliser. En fait, cela n'a aucun sens d'arrêter de l'utiliser pour des tâches simples telles que cacher quelques <div> ou faire une requête AJAX unique lorsque vous avez l'habitude de le faire de cette façon. jQuery va être chargé de toute façon, et c'est simple et facile à utiliser.

Les applications complexes sont là où jQuery a du mal : logique difficile à suivre, rappel infernal, variables globales et pas de modèles HTML. Cela appelle clairement une manière différente d'organiser l'application frontale.

Les bibliothèques frontales modernes telles que React utilisent les principes de la programmation orientée objet (POO) et organisent l'architecture des applications frontales en composants modulaires et réutilisables. Un composant contient tout le code, le balisage et « l'état du composant » (variables) pour un élément particulier. Un élément peut être presque n'importe quoi : un bouton, un champ de saisie, un formulaire utilisateur ou un widget qui affiche les publications récentes du back-end de l'API REST de WordPress. Les composants peuvent contenir d'autres composants, formant une relation hiérarchique.

Avec la complexité des pages Web de nos jours, l'organisation d'une application en composants est un moyen éprouvé de créer des applications Web maintenables et rapides de toute complexité. Les composants sont des « briques » hautement réutilisables, isolées et donc facilement testables. Il est donc vraiment utile d'apprendre ce concept.

Il existe actuellement deux bibliothèques basées sur des composants : Vue.js et React. React serait un choix évident car il est déjà utilisé par Gutenberg. Cependant, pour quelqu'un qui découvre JavaScript moderne, Vue.js pourrait être préférable pour commencer.

React vous plonge dans les profondeurs en utilisant immédiatement les fonctionnalités, les classes, la syntaxe JSX propriétaire et le pipeline de construction Webpack d'ES6. La courbe d'apprentissage est assez raide.

Vue.js, en revanche, est beaucoup plus convivial pour les débutants et peut être utilisé simplement en insérant une <script> . Vue.js utilise du JavaScript simple (ES5), du HTML et du CSS. L'introduction de nouveaux concepts est beaucoup plus progressive.

Après avoir travaillé sur quelques projets Vue.js, vous serez mieux préparé à plonger profondément dans React. Non pas que ce soit toujours nécessaire, mais le développement de Gutenberg, par exemple, l'exige.

Utiliser l'API REST WordPress

L'API REST de WordPress n'est qu'une interface standardisée pour demander et modifier à distance des données de WordPress. C'est plus une question d'architecture logicielle qu'une façon complètement différente de coder. Les mêmes anciens extraits jQuery AJAX pourraient être utilisés avec des paramètres légèrement différents.

L'avantage le plus important ? Étant donné que l'API REST de WordPress normalise la communication entre le back-end et le front-end, c'est une étape majeure vers la modularité, la réutilisabilité et la lisibilité de votre code. Ces terribles modèles avec HTML et PHP mélangés et un peu de SQL jeté dans le mélange doivent disparaître. Une fois que les modèles sont simplement HTML avec des espaces réservés pour les données transmises en tant que paramètres, il n'y a pas de différence majeure entre la transmission de ces données en PHP ou via une API REST à une application frontale.

Vous pouvez également consulter WPGraphQL. Il peut éventuellement remplacer l'API WordPress REST, mais il gagne rapidement du terrain.

Apprenez Gutenberg (les clients en auront bientôt besoin)

Le but ultime de Gutenberg est la personnalisation complète du site, entre autres plans.

Cela jette les bases d'un nouveau modèle pour WordPress Core qui aura finalement un impact sur l'ensemble de l'expérience de publication de la plate-forme.

La page du projet WordPress Gutenberg sur GitHub

Gutenberg a reçu un refus majeur de la part des développeurs WordPress. Certains des arguments contre sa fusion dans le noyau de WordPress étaient :

  • Une part importante des utilisateurs finaux n'en ont pas besoin, il devrait donc s'agir d'un plugin facultatif et non d'une partie du noyau
  • Il a cassé certains sites
  • Ce n'était tout simplement pas prêt et pourrait utiliser plus de polissage et moins de bugs

Cependant, pour les rédacteurs de contenu qui utilisent WordPress comme plateforme de blogs, Gutenberg offre clairement une meilleure expérience que l'ancien éditeur.

La désactivation de Gutenberg sera prise en charge aussi longtemps que nécessaire, oui. Mais y aller maintenant est une bonne idée : lorsqu'un client vous approche et vous demande de faire du développement Gutenberg, vous serez prêt.

Il est temps de se mettre à niveau : même la « méthode WordPress » évolue

L'argument le plus courant contre l'utilisation de tous les outils et techniques décrits ci-dessus dans le développement WordPress est le suivant : la "façon WordPress" de faire les choses fonctionne toujours, et cette manière est censée être meilleure que toutes ces nouvelles choses brillantes.

Mais vous avez maintenant vu que les développeurs principaux de WordPress sont bien au courant de tous les derniers développements. Non seulement cela, ils les utilisent autant que possible dans les nouvelles parties du noyau en raison de leurs avantages évidents. La seule chose qui nous retient est le code hérité que personne ne va refactoriser.

Depuis un certain temps, WordPress et WooCommerce ont suivi la pratique consistant à développer des "plugins de fonctionnalités" qui implémentent et utilisent de nouvelles technologies. Lorsque le moment est venu, ces plugins sont fusionnés dans le noyau, comme l'a fait Gutenberg. WooCommerce a également son propre projet React. L'API WordPress REST a également commencé comme un plugin séparé et fait maintenant partie du noyau WordPress.

La question n'est pas de savoir si nous devons apprendre de nouvelles choses et les utiliser dans mon travail quotidien, mais comment . La réponse est « progressivement », une étape à la fois. Soit vous apprenez quelque chose de nouveau, soit vous faites quelque chose que vous connaissez bien d'une manière nouvelle et différente.

Par exemple, apprenez à utiliser Webpack avec tous vos anciens scripts. Webpack peut transpiler votre nouveau code ES6+ en JavaScript « ordinaire » compatible avec les anciens navigateurs. Il peut également réduire les scripts et les regrouper. C'est une nouveauté. Terminé? Ensuite, réécrivez votre JavaScript en tirant parti des fonctionnalités ES6. C'est une nouvelle façon de faire ce que vous savez bien.

Le résultat : vous apprendrez Webpack et ES6. En tant que professionnels, nous devons intensifier et ne pas reculer. Continuez toujours à apprendre. Et partagez quand vous le faites : Toptal maintient une liste des meilleures pratiques de développement WordPress et accueille les contributions de la communauté.

Dans la partie 2 de notre série, nous plongerons dans la partie PHP du développement back-end WordPress moderne.