Process de mise à jour — WordPress Bedrock (thème Sage)

Authors

• 

  Rédigé par

  Name

  Gaël GÉRARD

  Website

  gaelgerard.com

  Phone

  02 85 52 38 66

Sommaire

---

1. Prérequis

Avant toute mise à jour :

• [ ] Faire une sauvegarde de la base de données (wp db export ou export via ton hébergeur)
• [ ] Vérifier que le dépôt Git est propre (git status) et créer une branche dédiée (git checkout -b update/YYYY-MM-DD)
• [ ] S’assurer de travailler en local ou sur un environnement de staging, jamais directement en production

Sur un projet en cours de construction je trouve un plugin critique en cours de développement. Celui ci à pour but de nettoyer tous les tests dans une base de données et tous les fichiers associés à ces tests pour économiser de l’espace disque. Le projet n’étant pas finalisé, je ne veux pas que ce plugin soit ajouter sur l’environnement de production avec le risque d’effacer les données réelles.

Pour sécuriser les données avant de mettre à jour le Core WordPress et les plugins, je vais créer une branche dédiée.

# Je créer et bascule sur une nouvelle branche spécifique pour ce développement
git checkout -b feature/plugin-cleanup-database

# J'ajoute uniquement le dossier de mon nouveau plugin
git add web/app/plugins/mon-plugin/

# Commiter ton travail en cours
git commit -m "WIP: dev plugin nettoyage BDD et Supabase"

---

Maintenant que le code est sauvegardé sur sa branche, je peux reprendre le process de mise à jour après être revenu sur la branche principale.

# Revenir sur la branche principale
git checkout main

# Vérifier que le dépôt est propre (ton plugin WIP n'apparaîtra plus ici)
git status

# Créer ta branche de mise à jour (comme indiqué dans ton process)
git checkout -b update/2026-08-25

Une fois les mises à jours Bedrock terminées, validées et fusionnées sur main je pourrais revenir sur le développement du plugin en m’assurant qu’il fonctionne avec les dernières versions.

Il me suffira de retourner sur la branche de mon plugin et d’y rapatrier les nouveautés de main.

# Retourner sur la branche de dev du plugin
git checkout feature/plugin-cleanup-database

# Récupérer les dernières mises à jour (via un rebase pour un historique propre)
git rebase main

Une sécurité supplémentaire : Le pipeline CI/CD

Si, dans le futur, tu décides de fusionner la branche de ton plugin sur main pour centraliser ton code, mais que tu ne veux toujours pas l’activer ou l’envoyer en production, tu peux utiliser ton pipeline de déploiement comme filet de sécurité.

Si tu gères tes déploiements avec des workflows automatisés (comme GitHub Actions), tu peux ajouter une règle d’exclusion explicite lors du transfert des fichiers. Par exemple, si l’étape de déploiement utilise rsync, il suffirait d’ajouter --exclude='web/app/plugins/mon-plugin/' à la commande. Cela garantit que même si le code est sur la branche principale, il ne sera jamais copié sur le serveur de production.

2. Mise à jour du Core WordPress et des plugins

Dans l’architecture Roots, la gestion du cœur WordPress et des extensions se fait à la racine du projet Bedrock.

2.1 Lister les dépendances mettables à jour

Depuis la racine du projet :

composer outdated --direct

La sortie utilise un code couleur :

Couleur	Signification
🔴 Rouge	Nouvelle version disponible, mais bloquée par une contrainte de composer.json (ex. WooCommerce 11.x alors que la contrainte limite à ^10.9)
🟡 Jaune	Peut être mise à jour directement via composer update, sans toucher au composer.json

2.2 Appliquer les mises à jour autorisées

composer update

Note : cette commande régénère composer.lock. C’est ce fichier qui garantit ensuite un déploiement identique en production (voir section 5).

2.3 Mettre à jour la base de données si le Core WP a changé de version majeure

wp core update-db

---

3. Débloquer une extension retenue par une contrainte de version

Cas typique : une extension n’est pas mise à jour vers sa dernière version car la contrainte définie dans composer.json l’en empêche.

Exemple : WooCommerce est disponible en 11.0.1, mais composer.json contient "wp-plugin/woocommerce": "^10.9.1", ce qui limite les mises à jour à la branche 10.9.x.

Comment vérifier qu’un plugin est bloqué

Relance composer outdated --direct (voir 2.1) : toute ligne en rouge indique une extension dont la version disponible dépasse la contrainte fixée.

Comment corriger

Plutôt que d’éditer composer.json à la main, utilise composer require pour mettre à jour la contrainte et le paquet en une seule commande :

composer require wp-plugin/woocommerce:"^11.0" \
                  wp-plugin/login-armor:"^2.5" \
                  wp-plugin/wordpress-seo:"^28.3"

Cela met à jour composer.json et composer.lock en même temps que le paquet installé.

---

4. Mise à jour des dépendances du thème (Sage)

Sage étant un starter theme, tu ne le mets pas à jour lui-même de manière automatique : tu mets à jour ses dépendances internes (Acorn, packages front, etc.).

4.1 Dépendances PHP du thème

cd web/app/themes/mon-theme-sage

4.2 Dépendances front-end et build

npm update
npm run build

Vérifie que le build se termine sans erreur avant de passer à l’étape suivante.

---

5. Tests et déploiement

1. Navigue sur le site en local pour vérifier que les affichages et optimisations n’ont pas régressé (pages clés, tunnel de commande si WooCommerce, formulaires, etc.).
2. Une fois tout validé, commite les fichiers de lock :
   • composer.lock à la racine
   • composer.lock dans web/app/themes/w3-sage
   • package-lock.json

C’est le point fort de cette architecture : ces fichiers de lock garantissent un déploiement strictement identique entre local, staging et production.

1. Déploie selon ta procédure habituelle (CI/CD, push Git, etc.), puis exécute si besoin composer install --no-dev et wp core update-db côté production.

---

6. Rollback en cas de problème

Si un problème est détecté après déploiement :

git checkout composer.lock web/app/themes/mon-theme-sage/composer.lock package-lock.jsoncomposer install

Puis restaure la base de données depuis la sauvegarde effectuée en étape 1 si nécessaire.

1. Valider tes modifications sur la branche de mise à jour Assure-toi que tout est bien commité sur ta branche actuelle (update/2026-08-25).

git add .
git commit -m "chore: mise à jour WordPress et dépendances"

2. Basculer sur main et la mettre à jour Il est toujours prudent de récupérer les dernières modifications du dépôt distant avant de fusionner, au cas où.

git checkout main
git pull origin main

3. Fusionner la branche de mise à jour dans main

git merge update/2026-08-25

4. Pousser sur le dépôt distant Cette étape va envoyer ton main à jour sur GitHub (et potentiellement déclencher tes pipelines de déploiement GitHub Actions si tu en as configuré pour la production).

git push origin main

5. Nettoyer (Optionnel mais recommandé) Une fois la fusion terminée, tu peux supprimer ta branche de mise à jour en local pour garder un espace de travail propre.

git branch -d update/2026-08-25

Et pour ton développement de plugin…

Comme tu l’as mentionné dans ta sélection, tu vas maintenant vouloir retourner sur la branche de ton plugin et t’assurer qu’il tourne bien avec ce nouveau cœur tout neuf.

Pour récupérer ces mises à jour dans ta branche de développement de plugin :

# Bascule sur la branche de ton plugin
git checkout nom-de-ta-branche-plugin

# Récupère les nouveautés de main (le rebase permet de garder un historique propre, mais un merge fonctionne aussi)
git rebase main 
# OU git merge main

# N'oublie pas de relancer un coup de composer install si nécessaire
composer install

Tu as maintenant un environnement à jour pour continuer sereinement le développement de ton plugin !