Wie ein kleiner Versionsparser-Bug die WP-Staging-CLI-Selbstupdates brach

Wenn du WP Staging CLI v1.10.0 oder v1.11.0 nutzt, weigert sich der eingebaute Befehl wpstaging update, nach Updates zu suchen, und gibt „Update check skipped for development version" aus. Die CLI kann sich auf diesen beiden Versionen nicht selbst an Ort und Stelle aktualisieren. Dieser Beitrag erklärt, was schiefgelaufen ist, was wir behoben haben und welcher einmalige Befehl dich zu einer gesunden Installation zurückbringt.

Kurzfassung

Betroffene Versionen: nur v1.10.0 und v1.11.0. Zur Wiederherstellung führe unseren offiziellen Installer erneut aus. Er erkennt deine bestehende Installation, ersetzt die Binärdatei an Ort und Stelle und lässt deine Seiten, Lizenz und Konfiguration unangetastet.

Linux, macOS, WSL:

curl -fsSL https://wp-staging.com/install.sh | bash

Windows PowerShell:

irm https://wp-staging.com/install.ps1 | iex

Windows CMD:

curl -fsSL https://wp-staging.com/install.cmd -o install.cmd && install.cmd && del install.cmd

Danach bist du auf v1.11.1 oder neuer, und wpstaging update funktioniert wieder normal.

Was passiert ist

Der Updater behandelt alles, was nicht wie ein sauberer Semver-String aussieht, als Development-Build und überspringt die Update-Prüfung stillschweigend. Die Absicht war vernünftig: Wenn du die CLI lokal mit go run oder make build ohne Versionsflag baust, würdest du sonst bei jedem Befehlsaufruf eine verwirrende Meldung „Update vX.Y.Z available (current: vdev)" sehen.

Der Bug: Unsere Release-Tags werden als v1.10.0, v1.11.0 und so weiter mit einem führenden v gepusht. Der Versionsparser erwartete jedoch ein bloßes 1.10.0. Das führende v sollte zuerst entfernt werden, aber die Development-Build-Prüfung lief vor dem Entfernungsschritt. So sah sich jede release-getaggte Binärdatei als Development-Build und übersprang stillschweigend ihre eigene Update-Prüfung.

Beide Code-Pfade waren betroffen:

• Der explizite Befehl wpstaging update, weshalb dessen Ausführung mit der „skipped"-Meldung abbrach, statt zu aktualisieren.
• Die automatische Hintergrundprüfung, die einmal täglich bei jedem Befehl läuft, weshalb auch nie ein Upgrade-Banner erschien.

Der Nettoeffekt ist, dass sich Installationen von v1.10.0 und v1.11.0 nicht selbst erholen können. Die Lösung muss von außerhalb der defekten Binärdatei kommen, weshalb der Wiederherstellungsschritt der Installer-Einzeiler oben ist und nicht wpstaging update.

Was wir getan haben

1. v1.11.1 mit dem Fix veröffentlicht. Die Development-Build-Prüfung entfernt nun zuerst das führende v und überspringt den Update-Pfad nur noch bei echten Development-Tags wie v0.0.0-dev und dev.
2. Regressionstests hinzugefügt, die die vier relevanten Formen abdecken: v1.11.1, 1.11.1, v0.0.0-dev und dev. Die ersten beiden müssen die Dev-Prüfung bestehen; die letzten beiden müssen den Update-Pfad überspringen. Die Tests schlagen laut fehl, falls die Reihenfolge jemals wieder regrediert.
3. Begonnen, einen serverseitigen Benachrichtigungskanal in unserer Lizenz-API aufzubauen, damit wir im seltenen Fall einer ähnlichen Aussperrung in Zukunft eine In-Produkt-Nachricht anzeigen können, ohne vom Update-Pfad selbst abhängig zu sein.

Was du tun musst

Führe den Installer-Einzeiler für deine Plattform aus dem Abschnitt Kurzfassung oben aus. Er wird:

• v1.11.1 (oder neuer) für dein Betriebssystem herunterladen.
• Die Prüfsumme verifizieren.
• Die vorhandene wpstaging-Binärdatei an Ort und Stelle ersetzen.
• Deine Seiten, Lizenz, Cache und Konfiguration unangetastet lassen.

Sobald er fertig ist, bestätige, dass das Upgrade gelandet ist:

wpstaging --version

Du solltest v1.11.1 oder höher sehen (veröffentlichte Binärdateien geben das führende v aus). Ab diesem Punkt funktioniert wpstaging update wie erwartet, und die tägliche Hintergrundprüfung erfasst künftige Releases automatisch.

Diese Art von Bug verhindern

Dieser Bug war besonders schmerzhaft, weil der defekte Code-Pfad derselbe ist, der dir normalerweise das Upgrade ankündigen würde. Eine nutzerseitige Umgehung war nicht möglich; die Wiederherstellung musste von uns kommen. Um sicherzustellen, dass eine ähnliche Aussperrung nicht erneut still auftreten kann, setzen wir drei Schichten ein:

• Regressionstests, die den Versionsparser gegen sowohl echte Release-Tags als auch Development-Tags ausführen, sodass die Reihenfolge zwischen Entfernen und Prüfen nicht erneut still umgekehrt werden kann.
• Eine Release-Zeit-Smoke-Prüfung an der gebauten Binärdatei, die sicherstellt, dass der Development-Skip-Pfad für das tatsächliche Release-Tag nicht genommen wird. Sollte ein Release jemals mit fälschlicherweise aktiver Dev-Prüfung ausgeliefert werden, schlägt der Build fehl, bevor die Binärdatei die Nutzer erreicht.
• Ein serverseitiger Benachrichtigungskanal in der Lizenz-API. Einmal ausgeliefert, kann die CLI kurze Nachrichten anzeigen, die wir von unserer Seite veröffentlichen, sodass jeder künftige Vorfall kommuniziert werden kann, ohne über den Update-Pfad selbst zu gehen.

Danke, dass du WP Staging CLI nutzt, und Entschuldigung für die Reibung, die dieser eine Fall verursacht hat.

Das war ein ganz gewöhnlicher menschlicher Entwicklungsfehler, kein Problem mit KI-generiertem Code. Wir haben ihn übersehen, behoben und Regressions- sowie Release-Zeit-Prüfungen hinzugefügt, damit genau dieser Fehler nicht erneut still ausgeliefert werden kann.

Fragen oder Probleme

Wenn der Installer bei dir nicht funktioniert oder du nach der Neuinstallation etwas Unerwartetes siehst, melde dich bitte:

• Kontaktformular
• GitHub: eröffne ein Issue im WP-Staging-CLI-Release-Repository