Le développement moderne de WordPress a évolué au-delà des configurations manuelles et des flux de déploiement incohérents. Radicle combine Roots‘ et d’autres outils de développement WordPress, tels que Bedrock, Sage et Acorn, en une seule pile de départ.
Cette intégration signifie que vous pouvez avoir l’expérience de développement de Laravel directement dans WordPress.
De plus, en installant Radicle sur Kinsta, vous bénéficiez d’un environnement d’hébergement qui prend en charge les exigences techniques de cette pile. Vous bénéficiez d’un accès SSH, de l’intégration WP-CLI et de la possibilité de configurer la racine de votre document.
Ce guide décrit le processus de configuration et les étapes de déploiement nécessaires pour faire fonctionner Radicle sur l’infrastructure de Kinsta.
Radicle et ses composants
Radicle combine trois projets Roots distincts dans un environnement de développement intégré :
- Bedrock fournit la base avec sa structure de dossiers améliorée et sa gestion des dépendances basée sur Composer.
- Sage gère le développement de thèmes avec l’intégration CSS de Tailwind et Vite pour la construction de ressources.
- Acorn fait le lien entre WordPress et Laravel en intégrant les modèles Blade, les migrations, le routage et bien plus encore dans vos projets WordPress.
Ce type d’environnement de développement vous permet de travailler directement à la racine du projet, plutôt que dans les répertoires de thèmes typiques. Vos modèles vivent dans resources/views/ à la racine du projet, tandis que la configuration se fait à travers des fichiers spécifiques à l’environnement dans le répertoire bedrock.
Composer gère le noyau de WordPress, les extensions et les dépendances personnalisées à travers un seul fichier composer.json. La pile nécessite PHP 8.3 ou plus, ainsi que des extensions spécifiques. Vous avez également besoin de Composer pour la gestion des dépendances et de WP-CLI pour les opérations en ligne de commande.
Radicle vs WordPress traditionnel
Les installations classiques de WordPress (c’est-à-dire tout mettre dans le répertoire wp-content) peuvent compliquer le contrôle des versions et rendre difficile le maintien d’installations cohérentes dans différents environnements.
Cependant, Radicle restructure cette installation de manière à ce que vous puissiez contrôler la version du code de votre application sans suivre les fichiers principaux de WordPress ou les médias téléversés :
- Le noyau de WordPress se trouve dans le répertoire
public/wp, séparé de votre code d’application. - Le répertoire
public/contentremplacewp-content, et le code de votre thème personnalisé se trouve à la racine du projet.
La configuration à la Laravel utilise un fichier .env plutôt que d’intégrer les identifiants de la base de données et les clés de sécurité dans les fichiers de configuration. Vous définissez des réglages différents pour les environnements de développement, de staging et de production à l’aide de fichiers de configuration distincts dans bedrock/environments/.
Votre stratégie de contrôle de version en bénéficie car vous ne suivez que le code et la configuration de votre application. Les mises à jour du noyau de WordPress se font via Composer, les extensions servent de dépendances et les changements de thèmes sont stockés dans votre référentiel.
Configurer Radicle pour Kinsta
Lors du déploiement sur Kinsta, vous avez besoin d’une authentification par clé SSH, qui est disponible sur le tableau de bord MyKinsta.
Localisez vos détails d’accès SFTP/SSH dans la section Info du site et ajoutez votre clé SSH publique si vous ne l’avez pas encore fait.
L’infrastructure de Kinsta correspond aux exigences techniques de Radicle. Il utilise PHP 8.3, inclut Composer pour la gestion des dépendances, et a WP-CLI pré-installé, de sorte que vous pouvez gérer WordPress directement à partir de la ligne de commande.
Contrairement à une installation traditionnelle de WordPress, Radicle utilise une structure de répertoire basée sur les versions. Chaque déploiement crée un dossier de version horodaté, et un lien symbolique current pointe vers la version active. La racine web de votre application doit être définie sur public/current/public.
Configurez ensuite vos variables d’environnement. Copiez le fichier .env.example dans la racine de votre projet Radicle et renommez-le en .env. Ensuite, ajoutez les détails de votre base de données et vos réglages d’environnement :
DB_NAME='your_database_name'
DB_USER='your_database_user'
DB_PASSWORD='your_database_password'
DB_HOST='your_database_host'
WP_ENV='staging'
WP_HOME='https://{kinsta-staging-url}'
WP_SITEURL="${WP_HOME}/wp"
Radicle installe le noyau de WordPress dans un sous-répertoire /wp. Cela permet de séparer les fichiers du noyau de votre code d’application personnalisé, ce qui permet d’avoir une structure plus propre et contrôlée par les versions.
Configuration du staging
Votre répertoire de configuration se trouve à la racine de votre projet Radicle, à côté des dossiers public et resources. Ouvrez bedrock/environments/staging.php pour définir les réglages spécifiques à votre environnement de staging. Ce fichier remplace les valeurs de bedrock/application.php chaque fois que le fichier .env définit WP_ENV à staging.
Définissez l’URL de votre site de staging en ajoutant les constantes suivantes au début de staging.php :
<?php
define('WP_HOME', 'https://staging-url');
define('WP_SITEURL', WP_HOME . '/wp');
L’URL du site de staging le modèle de la section Environnements de votre site lors de la sélection de l’environnement de staging.
Votre chemin de déploiement détermine où les fichiers atterrissent sur le serveur Kinsta. Dans MyKinsta, notez le chemin sous les détails de l’environnement. Ce chemin se lit généralement /www/sitename/public et représente votre cible de déploiement. Votre script de déploiement synchronise les fichiers ici, créant une structure telle que /www/sitename/public/releases/timestamp pour chaque déploiement, avec /www/sitename/public/current comme lien symbolique vers la version active.
C’est également une bonne idée d’activer le mode débogage pour votre environnement dev staging dans bedrock/environments/staging.php. En outre, copiez et définissez les informations d’identification de votre base de données pour l’environnement de staging dans votre fichier local .env (qui ne doit pas être soumis au contrôle de version). Vous pouvez également les configurer en tant que variables d’environnement sur votre serveur de déploiement. Kinsta génèrera des identifiants uniques pour chaque environnement.
Configuration de la production
Une fois que vous avez basculé vers votre environnement de production à partir du menu déroulant du tableau de bord MyKinsta, le processus de configuration reflétera l’environnement de production, mais utilisera des valeurs spécifiques à la production et des paramètres de sécurité plus stricts.
Pour ceci, ouvrez bedrock/environments/production.php dans le répertoire bedrock de la racine de votre projet et modifiez l’URL de production :
<?php
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', WP_HOME . '/wp');
La gestion des erreurs en production sera différente de celle de l’environnement de staging. La principale différence consiste à désactiver les affichages de débogage tout en conservant la journalisation des erreurs :
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false); De plus, copiez les identifiants de la base de données de production depuis la section Accès à la base de données de MyKinsta lorsque vous êtes dans votre environnement réel. Ces identifiants sont généralement différents de ceux de l’environnement de production. Cependant, les chemins de déploiement de la production suivent le même modèle que ceux de la phase de staging mais pointent vers le répertoire de votre environnement réel. Le chemin dans les détails de l’environnement de MyKinsta aura probablement une URL différente (mais similaire). Votre script de déploiement ciblera ce chemin pour les versions de production.
Modifier les tâches de déploiement
Le déploiement par défaut de Radicle suppose un contrôle du serveur que Kinsta ne fournit pas par le biais de l’hébergement infogéré. En tant que tel, vous devez supprimer toutes les tâches de déploiement qui tentent de gérer les services du serveur.
Si vous utilisez Trellis (l’outil de déploiement par défaut de Radicle), modifiez trellis/roles/deploy/hooks/finalize-after.yml et supprimez entièrement la tâche Reload php-fpm. Kinsta gère PHP-FPM qui redémarre automatiquement lorsqu’il détecte des modifications de fichiers.
De plus, l’effacement du cache se fait via l’API de Kinsta au lieu des commandes du serveur, vous devrez donc remplacer tout effacement de cache basé sur le serveur par une requête HTTP vers le point de terminaison d’effacement de cache de Kinsta. Vous pouvez ajouter cette tâche à votre crochet de finalisation du déploiement une fois que vous avez configuré une clé API :
- name: Clear Kinsta cache
uri:
url: "{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/"
method: GET
Chaque site a un point de terminaison unique pour la sécurité, que vous pouvez obtenir auprès de l’équipe de support de Kinsta.
La compilation des actifs s’exécute avant le déploiement, et non sur le serveur. Votre machine de développement locale ou votre pipeline CI/CD exécute npm run build pour compiler JavaScript et CSS dans le répertoire public/build. Ces actifs compilés seront déployés avec vos fichiers PHP.
L’installation des dépendances de Composer a lieu après la synchronisation des fichiers en utilisant SSH pour exécuter ce qui suit :
cd /www/sitename/public/current
composer install --no-dev --optimize-autoloader --no-interaction
L’option --no-dev exclut les dépendances de développement tels que les frameworks de test et les outils de débogage. L’indicateur --optimize-autoloader construit des cartes de classes pour un chargement automatique plus rapide, réduisant ainsi la charge de travail liée à la localisation des fichiers de classes lors des requêtes.
Ajouter le plugin Kinsta MU à Radicle
L’extension Kinsta MU permet la mise en cache de la page entière, l’intégration CDN et la gestion du cache pour votre site à travers MyKinsta. En raison de la structure de répertoire non standard de Radicle, vous devrez définir certaines constantes de configuration spécifiques, bien que vous puissiez ajouter l’extension Kinsta MU à Radicle via Composer. Vous pouvez ajouter ces constantes à votre fichier bedrock/application.php après avoir installé l’extension :
/**
* Kinsta CDN fix for Radicle/Bedrock structure
*/
define('KINSTA_CDN_USERDIRS', 'app');
/**
* Fix Kinsta MU Plugins URL path with Radicle/Bedrock
*/
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");
La première constante spécifie votre répertoire d’uploads dans la structure app de Bedrock. La seconde corrige les chemins d’URL des ressources de l’extension afin qu’elle charge correctement les fichiers JavaScript et CSS.
Une fois que vous avez vérifié l’installation de l’extension, vous pouvez tester le nettoyage du cache via le tableau de bord MyKinsta pour confirmer que l’extension communique correctement avec l’infrastructure de Kinsta.
Comment mettre en place des déploiements automatisés
Les actions GitHub sont un moyen simple d’automatiser les déploiements de Radicle vers Kinsta. Par exemple, vous pouvez créer un fichier de flux de travail dans votre dépôt à .github/workflows/deploy.yml. Ce flux de travail se déclenche sur des poussées vers des branches spécifiques, qui construisent des ressources et déploient du code dans l’environnement correspondant.
Les secrets SSH stockés dans votre dépôt GitHub permettront des connexions sécurisées aux serveurs de Kinsta. Pour cela, ajoutez des secrets pour votre clé privée SSH, l’hôte Kinsta, le port SSH et le nom d’utilisateur dans GitHub.
Un script de déploiement orchestre le processus de synchronisation des fichiers. Ce script utilise généralement rsync pour transférer efficacement les fichiers, n’envoie que les fichiers modifiés et conserve les autorisations appropriées. Cependant, vous devriez exclure les fichiers de développement tels que node_modules, .git, et .env du déploiement pour garder votre environnement de production propre.
Une fois la synchronisation des fichiers réussie, les tâches d’effacement du cache et de nettoyage peuvent être exécutées. Le processus implique que le script de déploiement fasse une demande au point de terminaison d’effacement du cache de Kinsta, attende une confirmation, puis exécute toutes les commandes de nettoyage nécessaires.
Configuration des actions GitHub
Vous pouvez définir votre automatisation du déploiement à la racine du dépôt en créant un fichier .github/workflows/deploy.yml. Ce fichier gérera la compilation des actifs, l’installation des dépendances et la synchronisation des fichiers avec Kinsta.
Ici, commencez par des déclencheurs spécifiques aux branches qui déploient la branche staging dans votre environnement staging et la branche main dans la production :
name: Deploy to Kinsta
on:
push:
branches:
- staging
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '22'
- name: Install dependencies and build assets
run: |
npm ci
npm run build
Les stratégies matricielles gèrent plusieurs environnements sans dupliquer le code du flux de travail. Les variables spécifiques à l’environnement que vous ajoutez peuvent changer en fonction de la branche qui a déclenché le flux de travail :
strategy:
matrix:
include:
- branch: staging
ssh_host: ${{ secrets.KINSTA_STAGING_HOST }}
ssh_port: ${{ secrets.KINSTA_STAGING_PORT }}
ssh_user: ${{ secrets.KINSTA_STAGING_USER }}
deploy_path: /www/sitename_1/public
- branch: main
ssh_host: ${{ secrets.KINSTA_PRODUCTION_HOST }}
ssh_port: ${{ secrets.KINSTA_PRODUCTION_PORT }}
ssh_user: ${{ secrets.KINSTA_PRODUCTION_USER }}
deploy_path: /www/sitename_2/public
Les étapes de compilation des ressources créent des fichiers JavaScript et CSS optimisés avant le déploiement. Le flux de travail utilise npm ci au lieu de npm install pour des constructions reproductibles basées sur votre fichier package-lock.json. La commande npm run build exécute votre script de compilation de production défini dans package.json, généralement en exécutant Vite ou un autre bundler pour compiler et minifier les ressources.
À ce stade, vous pouvez ajouter l’installation de Composer après les étapes de Node.js :
- name: Setup PHP
uses: server/setup-php@v2
with:
php-version: '8.3'
- name: Install Composer dependencies
run: composer install --no-dev --optimize-autoloader --no-interaction
Le flux de travail dispose maintenant de ressources compilées et de dépendances installées, prêts à être déployées sur Kinsta.
Détails du script de déploiement
La synchronisation des fichiers via rsync ne transfère que les fichiers modifiés, ce qui réduit le temps de déploiement. Pour résoudre ce problème, ajoutez cette étape à votre flux de travail GitHub Actions après avoir créé vos ressources :
- name: Deploy to Kinsta via rsync
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
run: |
mkdir -p ~/.ssh
echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
rsync -avz --delete
--exclude='.git'
--exclude='node_modules'
--exclude='.env'
--exclude='trellis'
-e "ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no"
./ ${{ matrix.ssh_user }}@${{ matrix.ssh_host }}:${{ matrix.deploy_path }}/releases/$(date +%Y%m%d%H%M%S)/Les drapeaux rsync contrôlent le comportement du transfert :
-aactive le mode archive en préservant les permissions et les horodatages.-vfournit une sortie verbeuse pour le débogage.-zcompresse les données pendant le transfert.
L’option --delete supprime du serveur les fichiers qui n’existent plus dans votre dépôt, ce qui permet de maintenir votre déploiement propre.
Les motifs d’exclusion empêchent le transfert de fichiers inutiles. De plus, les métadonnées Git, les dépendances de développement, les fichiers d’environnement et les outils de déploiement ne sont pas transférés sur le serveur de production. La structure des répertoires de version crée des répertoires horodatés pour chaque déploiement afin de permettre des retours en arrière rapides en modifiant les liens symboliques.
La gestion des liens symboliques permet de connecter vos données persistantes à chaque nouvelle version. Après avoir synchronisé les fichiers, vous pouvez vous connecter au serveur par SSH et créer des liens symboliques :
- name: Create symlinks and update current
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}
# Link shared .env file
ln -nfs ${{ matrix.deploy_path }}/shared/.env
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/.env
# Link uploads directory
ln -nfs ${{ matrix.deploy_path }}/shared/public/content/uploads
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/public/content/uploads
# Update current symlink atomically
ln -nfs ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)
${{ matrix.deploy_path }}/current
EOFLe fichier .env contient une configuration spécifique à l’environnement qui persiste à travers les déploiements. Les téléversements stockés en dehors du répertoire des versions éviteront la perte de fichiers multimédias lorsque les anciennes versions sont supprimées. La mise à jour atomique des liens symboliques (ln -nfs) garantit l’absence de temps d’arrêt, car les requêtes n’atteignent jamais une version à moitié déployée.
Le nettoyage supprime les anciennes versions après un déploiement réussi afin de ne conserver que les cinq versions les plus récentes :
- name: Clean up old releases
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}/releases
ls -t | tail -n +6 | xargs rm -rf
EOFCette stratégie de nettoyage permet de trouver un équilibre entre l’utilisation de l’espace disque et la capacité de retour en arrière. Cinq versions fournissent plusieurs points de retour en arrière tout en évitant une croissance indéfinie de l’espace de stockage.
Résumé
Radicle transforme le développement WordPress en intégrant la structure améliorée de Bedrock, le flux de travail moderne des thèmes de Sage et les fonctionnalités de Laravel d’Acorn en une seule pile.
Le déploiement sur Kinsta nécessite une configuration au-delà de l’hébergement WordPress standard, mais offre des avantages en termes de sécurité, de maintenabilité et d’expérience du développeur qui justifient l’effort de mise en place.
Lorsque vous êtes prêt à déployer des applications WordPress modernes en toute confiance, explorez l’hébergement WordPress infogéré de Kinsta et faites l’expérience d’une infrastructure d’hébergement qui prend en charge le flux de développement personnalisé que vous souhaitez.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
