Créer plusieurs sites WordPress localement avec DevKinsta —

À propos de l'auteur

Leonardo Losoviz est un développeur et écrivain indépendant, avec une quête permanente pour intégrer des paradigmes innovants (Serverless PHP, server-side components, GraphQL) …

En savoir plus sur

Léonard
↬

Lors de la création de thèmes et de plugins pour WordPress, nous devons nous assurer qu'ils fonctionnent bien dans tous les différents environnements où ils seront installés. Nous pouvons parfois contrôler cet environnement lors de la création d'un thème pour nos propres sites Web, mais à d'autres moments, nous ne le pouvons pas, comme lors de la distribution de nos plugins via le référentiel WordPress public pour que quiconque puisse le télécharger et l'installer.

Concernant WordPress, le ]les combinaisons possibles d'environnements dont nous devons nous soucier incluent :

• Différentes versions de PHP,
• Différentes versions de WordPress,
• Différentes versions de l'éditeur WordPress (alias l'éditeur de blocs),
• HTTPS activé/désactivé,
• Multisite activé/désactivé.

Voyons comment c'est le cas. PHP 8.0, qui est la dernière version de PHP, a introduit des changements de rupture par rapport aux versions précédentes. Étant donné que WordPress prend toujours officiellement en charge PHP 5.6, notre plugin peut avoir besoin de prendre en charge 7 versions de PHP : PHP 5.6, plus PHP 7.0 à 7.4, plus PHP 8.0. Si le plugin nécessite une fonctionnalité spécifique de PHP, telle que des propriétés typées (introduites dans PHP 7.4), il devra alors prendre en charge cette version de PHP (dans ce cas, PHP 7.4 et PHP 8.0).

Concernant la gestion des versions dans WordPress, ce logiciel lui-même peut parfois introduire des changements de rupture, tels que la mise à jour vers une version plus récente de jQuery dans WordPress 5.6. De plus, chaque version majeure de WordPress introduit de nouvelles fonctionnalités (telles que le nouvel éditeur Gutenberg, introduit dans la version 5.0), qui pourraient être nécessaires pour nos produits.

L'éditeur de blocs ne fait pas exception. Si nos thèmes et plugins contiennent des blocs personnalisés, il est impératif de les tester pour toutes les différentes versions. Au minimum, nous devons nous soucier de deux versions de Gutenberg : celle livrée dans le noyau WordPress et celle disponible en tant que plugin autonome.

Concernant à la fois HTTPS et multisite, nos thèmes et plugins pourraient se comporter différemment en fonction de ceux-ci. être activé ou non. Par exemple, nous pouvons souhaiter désactiver l'accès à un point de terminaison REST lorsque nous n'utilisons pas HTTPS ou fournir des fonctionnalités étendues au super administrateur à partir du multisite.

Cela signifie qu'il existe de nombreux environnements possibles dont nous devons nous inquiéter. Comment le gérons-nous ?

Comprendre les environnements

Tout ce qui peut être automatisé doit l'être. Par exemple, pour tester la logique de nos thèmes et plugins, nous pouvons créer un processus d'intégration continue qui exécute un ensemble de tests sur plusieurs environnements. L'automatisation soulage une grande partie de la douleur.

Cependant, nous ne pouvons pas simplement compter sur le fait que les machines font tout le travail pour nous. Nous devrons également accéder à un site WordPress de test pour visualiser si, après une mise à niveau logicielle, nos thèmes ont toujours l'air comme prévu. Par exemple, si Gutenberg met à jour son système de styles globaux ou le comportement d'un bloc de base, nous voulons vérifier que nos produits n'ont pas été affectés par le changement.

Combien d'environnements différents devons-nous prendre en charge ? Disons que nous ciblons 4 versions de PHP (7.2 à 8.0), 5 versions de WordPress (5.3 à 5.7), 2 versions de Gutenberg (core/plugin), HTTPS activé/désactivé et multisite activé/désactivé. Tout cela représente un total de 160 environnements possibles. C'est beaucoup trop difficile à gérer.

Pour simplifier les choses, au lieu de produire un site pour chaque combinaison possible, nous pouvons le réduire à une poignée d'environnements qui, globalement, comprennent toutes les différentes propriétés.

Par exemple, nous peut produire ces cinq environnements :

1. PHP 7.2 + WP 5.3 + noyau Gutenberg + HTTPS + multisite
2. PHP 7.3 + WP 5.4 + plugin Gutenberg + HTTPS + multisite
3. PHP 7.4 + WP 5.5 + plugin Gutenberg + pas de HTTPS + pas de multisite
4. PHP 8.0 + WP 5.6 + noyau Gutenberg + HTTPS + pas de multisite
5. PHP 8.0 + WP 5.7 + noyau Gutenberg + pas de HTTPS + pas de multisite

Faire tourner 5 sites WordPress est gérable, mais c'est pas facile car cela implique des défis techniques, notamment l'activation de différentes versions de PHP et la fourniture de certificats HTTPS.

Nous voulons faire tourner facilement des sites WordPress, même si nous avons une connaissance limitée des systèmes. Et nous voulons le faire rapidement puisque nous avons notre travail de développement et de conception à faire. Comment pouvons-nous le faire ?

Gérer les sites WordPress locaux avec DevKinsta

Heureusement, créer des sites WordPress locaux n'est pas difficile de nos jours, car nous pouvons éviter le travail manuel et nous fier à un outil qui automatise le processus pour nous .

DevKinsta est exactement ce genre d'outil. Il permet de lancer un site WordPress local avec un minimum d'effort, pour toute configuration souhaitée. Le site sera créé en moins de temps qu'il faut pour boire une tasse de café. Et cela coûte certainement moins qu'une tasse de café : DevKinsta est 100 % gratuit et disponible pour les utilisateurs de Windows, macOS et Ubuntu .

Comme son nom l'indique, DevKinsta a été créé par Kinstal'un des principaux hébergeurs de l'espace WordPress. Leur objectif est de simplifier le processus de travail avec des projets WordPress, que ce soit pour les concepteurs ou les développeurs, les indépendants ou les agences. Plus nous pourrons configurer notre environnement facilement, plus nous pourrons nous concentrer sur nos propres thèmes et plugins, meilleurs seront nos produits.

La magie qui alimente DevKinsta est Dockerle logiciel qui permet de isoler une application de son environnement via des conteneurs. Cependant, nous ne sommes pas obligés de connaître Docker ou les conteneurs : DevKinsta cache la complexité sous-jacente, nous pouvons donc simplement lancer le site WordPress en appuyant sur un bouton.

Dans cet article, nous allons explorer comment utiliser DevKinsta pour lancer les 5 instances WordPress locales différentes pour tester un plugin, et quelles fonctionnalités intéressantes nous avons à notre disposition.

Lancer un site WordPress avec DevKinsta

Le les images ci-dessus montrent DevKinsta lors de son ouverture pour la première fois. Il présente 3 options pour créer un nouveau site WordPress local :

1. Nouveau site WordPress
   Il utilise la configuration par défaut, y compris la dernière version de WordPress et PHP 8.
2. Importer depuis Kinsta[19659043]Il clone la configuration à partir d'un site existant hébergé sur MyKinsta.
3. Site personnalisé
   Il utilise une configuration personnalisée, fournie par vous.

Appuyer sur l'option #1 produira littéralement un site WordPress local sans même en y pensant. Je pourrais expliquer un peu plus si seulement je pouvais ; il n'y a vraiment pas plus que cela.

Si vous êtes un utilisateur de Kinsta, appuyer sur l'option #2 vous permet d'importer directement un site depuis MyKinsta y compris un dump de sa base de données. (Au fait, cela fonctionne aussi dans le sens inverse : les modifications locales dans DevKinsta peuvent être poussées vers un site de transfert dans MyKinsta .)

Enfin, en appuyant sur l'option #3, nous pouvons spécifier quelle configuration personnalisée à utiliser pour le site WordPress local.

Appuyons sur le bouton pour l'option #3. L'écran de configuration ressemblera à ceci :

Certaines entrées sont en lecture seule. Ce sont des options qui sont actuellement corrigées mais qui seront rendues configurables dans le futur. Par exemple, le serveur Web est actuellement défini sur Nginx, mais le travail pour ajouter Apache est en cours.

Les options que nous pouvons actuellement configurer sont les suivantes :

• Le nom du site (à partir duquel l'URL locale est calculée),[19659008]Version PHP,
• Nom de la base de données,
• HTTPS activé/désactivé,
• Le titre du site WordPress,
• Version WordPress,
• L'e-mail, le nom d'utilisateur et le mot de passe de l'administrateur,
• Multisite activé/désactivé .

Après avoir complété ces informations pour mon premier site WordPress local, appelé « API GraphQL sur PHP 80 », et cliqué sur « Créer un site », il n'a fallu que 2 minutes à DevKinsta pour créer le site. Ensuite, on me présente l'écran d'informations du site nouvellement créé :

Le nouveau site WordPress est disponible sous son propre domaine local graphql-api-on-php80.local. En cliquant sur le bouton « Ouvrir le site », nous pouvons visualiser notre nouveau site dans le navigateur :

J'ai répété ce processus pour tous les différents environnements requis, et voilà, mes 5 sites WordPress locaux ont été opérationnels en un rien de temps. Maintenant, l'écran initial de DevKinsta répertorie tous mes sites :

Utilisation de WP-CLI

À partir de la configuration requise pour mes environnements, j'ai jusqu'à présent satisfait tous les éléments sauf un : l'installation de Gutenberg en tant que plugin.

Faisons cela ensuite. Nous pouvons installer un plugin comme d'habitude via l'administrateur WP, auquel nous pouvons accéder en cliquant sur le bouton " WP admin " à partir de l'écran d'informations du site, comme le montre l'image ci-dessus.

Mieux encore, DevKinsta est livré avec WP-CLI déjà installé, nous pouvons donc interagir avec le site WordPress via l'interface en ligne de commande.

Dans ce cas, nous devons avoir une connaissance minimale de Docker. L'exécution d'une commande dans un conteneur se fait comme ceci :

docker exec {containerName} /bin/bash -c '{command}'

Les paramètres nécessaires sont :

• Le conteneur de DevKinsta s'appelle devkinsta_fpm.
• La commande WP-CLI pour installer et activer un plugin est wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
• Le chemin vers le site WordPress, dans le conteneur, est /www/kinsta/public/{siteName}.

En résumé, la commande pour installer et activer le plugin Gutenberg sur le site WordPress local est la suivante un :

docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Exploration des fonctionnalités

Il y a quelques fonctionnalités pratiques disponibles pour nos sites WordPress locaux.

La première est l'intégration avec Adminerun outil similaire à phpMyAd min, pour gérer la base de données. Avec cet outil, nous pouvons directement récupérer et modifier les données via une requête SQL personnalisée. Cliquer sur le bouton « Gestionnaire de base de données », sur l'écran d'informations du site, ouvrira Adminer dans un nouvel onglet de navigateur :

La deuxième caractéristique remarquable est l'intégration avec Mailhogle populaire outil de test de messagerie. Grâce à cet outil, tout e-mail envoyé depuis le site WordPress local n'est pas réellement envoyé, mais est capturé et affiché dans la boîte de réception des e-mails :

En cliquant sur un e-mail, nous pouvons voir son contenu :

Accès aux fichiers d'installation locaux

Après avoir installé le site WordPress local, son dossier contenant tous ses fichiers (y compris le noyau WordPress, les thèmes et plugins installés et les éléments multimédias téléchargés) sera accessible au public :

• Mac et Linux : sous /Users/{username}/DevKinsta/public/{siteName}.
• Windows : sous C:Users {username}DevKinstapublic{siteName}.

(En d'autres termes : les fichiers du site WordPress local sont accessibles non seulement via le conteneur Docker, mais également via le système de fichiers de notre système d'exploitation, par exemple en utilisant Mon PC sous Windows, le Finder sous Mac ou n'importe quel terminal.)

C'est très pratique car il offre un raccourci pour installer les thèmes et plugins que nous développons, accélérant ainsi notre travail.

Par exemple, pour tester un changement dans un plugin dans les 5 sites locaux, nous devrions normalement aller à l'administrateur WP sur chaque site et télécharger la nouvelle version de le plugin (ou, alternativement, utilisez WP-CLI).

En ayant accès au dossier du site, cependant, nous pouvons simplement cloner le plugin à partir de son référentiel, directement sous wp-content/plugins :

$ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins
$ git clone git@github.com:leoloso/MyAwesomePlugin.git

De cette façon, nous pouvons simplement git pull pour mettre à jour notre plugin vers sa dernière version, le rendant immédiatement disponible sur le site WordPress local :

$ cd MyAwesomePlugin
$ git pull

Si nous voulons tester le plugin en cours de développement sur une branche différente, nous pouvons de la même manière faire un git checkout:

git checkout some-branch-with-new-feature[19659105]Comme nous pouvons avoir plusieurs sites avec des environnements différents, nous pouvons automatiser cette procédure en exécutant un script bash, qui itère les sites WordPress locaux et, pour chacun, exécute un git pull pour le plugin installé dans :[19659084]#!/bin/bash

iterateSitesAndGitPullPlugin(){
  cd ~/DevKinsta/public/
  pour fichier en *
  fais
    si [ -d "$file" ] ; ensuite
      cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin
      git tirer
    Fi
  Fini
}

iterateSitesAndGitPullPlugin