Si vous utilisez WP Staging CLI v1.10.0 ou v1.11.0, la commande intégrée wpstaging update refusera de vérifier les mises à jour et affichera « Update check skipped for development version ». La CLI ne peut pas se mettre à niveau elle-même sur place sur ces deux versions. Cet article explique ce qui a mal tourné, ce que nous avons corrigé et la commande unique qui vous ramène à une installation saine.
En bref
Versions concernées : v1.10.0 et v1.11.0 uniquement. Pour récupérer, relancez notre installateur officiel. Il détecte votre installation existante, remplace le binaire sur place et laisse vos sites, votre licence et votre configuration intacts.
Linux, macOS, WSL :
curl -fsSL https://wp-staging.com/install.sh | bashWindows PowerShell :
irm https://wp-staging.com/install.ps1 | iexWindows CMD :
curl -fsSL https://wp-staging.com/install.cmd -o install.cmd && install.cmd && del install.cmdAprès cela, vous serez sur v1.11.1 ou une version ultérieure, et wpstaging update fonctionne à nouveau normalement.
Non concerné : Si vous êtes sur la v1.9.0 ou antérieure, ce bug ne vous concerne pas. wpstaging update récupérera la v1.11.1 automatiquement.
Ce qui s’est passé
L’outil de mise à jour traite tout ce qui ne ressemble pas à une chaîne semver propre comme une version de développement et saute silencieusement la vérification des mises à jour. L’intention était raisonnable : lorsque vous compilez la CLI localement avec go run ou make build sans indicateur de version, vous verriez sinon un message déroutant « Update vX.Y.Z available (current: vdev) » à chaque exécution d’une commande.
Le bug : nos étiquettes de version sont poussées comme v1.10.0, v1.11.0, et ainsi de suite, avec un v initial. L’analyseur de version exigeait toutefois un simple 1.10.0. Le v initial était censé être retiré d’abord, mais la vérification de version de développement s’exécutait avant l’étape de retrait. Ainsi, chaque binaire étiqueté comme version se voyait comme une version de développement et sautait silencieusement sa propre vérification de mise à jour.
Les deux chemins de code étaient concernés :
- La commande explicite
wpstaging update, ce qui explique pourquoi son exécution s’interrompait avec le message « skipped » au lieu de mettre à niveau. - La vérification automatique en arrière-plan qui s’exécute une fois par jour sur n’importe quelle commande, ce qui explique pourquoi aucune bannière de mise à niveau n’est jamais apparue non plus.
L’effet net est que les installations de v1.10.0 et v1.11.0 ne peuvent pas se rétablir d’elles-mêmes. Le correctif doit venir de l’extérieur du binaire défectueux, c’est pourquoi l’étape de récupération est l’unique commande de l’installateur ci-dessus et non wpstaging update.
Ce que nous avons fait
- Publié la v1.11.1 avec le correctif. La vérification de version de développement retire désormais d’abord le
vinitial, et ne saute le chemin de mise à jour que pour de véritables étiquettes de développement telles quev0.0.0-devetdev. - Ajouté des tests de régression couvrant les quatre formes qui comptent :
v1.11.1,1.11.1,v0.0.0-devetdev. Les deux premières doivent passer la vérification de développement ; les deux dernières doivent sauter le chemin de mise à jour. Les tests échoueront bruyamment si l’ordre régresse un jour. - Commencé à construire un canal de notification côté serveur dans notre API de licences, afin que, dans le rare cas d’un verrouillage similaire à l’avenir, nous puissions afficher un message dans le produit sans dépendre du chemin de mise à jour lui-même.
Ce que vous devez faire
Exécutez l’unique commande de l’installateur pour votre plateforme depuis la section En bref ci-dessus. Elle va :
- Télécharger la v1.11.1 (ou une version ultérieure) pour votre système d’exploitation.
- Vérifier la somme de contrôle.
- Remplacer le binaire
wpstagingexistant sur place. - Laisser vos sites, votre licence, votre cache et votre configuration intacts.
Une fois terminé, confirmez que la mise à niveau a abouti :
wpstaging --versionVous devriez voir v1.11.1 ou une version supérieure (les binaires publiés affichent le v initial). À partir de ce moment, wpstaging update fonctionne comme prévu, et la vérification quotidienne en arrière-plan récupérera automatiquement les futures versions.
Prévenir cette catégorie de bug
Ce bug était particulièrement pénible parce que le chemin de code défectueux est le même que celui qui vous dirait normalement de mettre à niveau. Une solution de contournement côté utilisateur n’était pas possible ; la récupération devait venir de nous. Pour nous assurer qu’un verrouillage similaire ne puisse pas se reproduire silencieusement, nous mettons en place trois couches :
- Des tests de régression qui éprouvent l’analyseur de version face à de vraies étiquettes de version et à des étiquettes de développement, de sorte que l’ordre entre le retrait et la vérification ne puisse pas être discrètement inversé de nouveau.
- Une vérification de fumée au moment de la publication sur le binaire compilé, qui affirme que le chemin de saut de développement n’est pas pris pour l’étiquette de version réelle. Si une version est un jour livrée avec la vérification de développement activée par erreur, la compilation échouera avant que le binaire n’atteigne les utilisateurs.
- Un canal de notification côté serveur dans l’API de licences. Une fois livré, la CLI pourra afficher de courts messages que nous publions de notre côté, de sorte que tout incident futur puisse être communiqué sans passer par le chemin de mise à jour lui-même.
Merci d’utiliser WP Staging CLI, et désolé pour la gêne occasionnée par ce cas.
Il s’agissait d’une simple erreur humaine d’ingénierie, et non d’un problème de code généré par IA. Nous l’avons manquée, corrigée, et avons ajouté des vérifications de régression et au moment de la publication pour que cette défaillance précise ne puisse pas être livrée silencieusement de nouveau.
Questions ou problèmes
Si l’installateur ne fonctionne pas pour vous, ou si vous voyez quelque chose d’inattendu après la réinstallation, n’hésitez pas à nous contacter :
