Si estás ejecutando WP Staging CLI v1.10.0 o v1.11.0, el comando integrado wpstaging update se negará a buscar actualizaciones e imprimirá «Update check skipped for development version». La CLI no puede actualizarse a sí misma en el sitio en estas dos versiones. Esta publicación explica qué salió mal, qué hemos corregido y el comando de una sola vez que te devuelve a una instalación sana.
En resumen
Versiones afectadas: solo v1.10.0 y v1.11.0. Para recuperarte, vuelve a ejecutar nuestro instalador oficial. Detecta tu instalación existente, reemplaza el binario en el sitio y deja tus sitios, licencia y configuración intactos.
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.cmdDespués de eso, estarás en v1.11.1 o posterior, y wpstaging update vuelve a funcionar con normalidad.
No afectado: Si estás en la v1.9.0 o anterior, este bug no te afecta. wpstaging update obtendrá la v1.11.1 automáticamente.
Qué pasó
El actualizador trata cualquier cosa que no parezca una cadena semver limpia como una compilación de desarrollo y omite silenciosamente la comprobación de actualizaciones. La intención era razonable: cuando compilas la CLI localmente con go run o make build sin una marca de versión, de lo contrario verías un confuso mensaje «Update vX.Y.Z available (current: vdev)» cada vez que ejecutaras un comando.
El error: nuestras etiquetas de lanzamiento se publican como v1.10.0, v1.11.0, etc., con una v inicial. El analizador de versiones, sin embargo, requería un 1.10.0 simple. Se suponía que la v inicial debía eliminarse primero, pero la comprobación de compilación de desarrollo se ejecutaba antes del paso de eliminación. Así, cada binario etiquetado como lanzamiento se veía a sí mismo como una compilación de desarrollo y omitía silenciosamente su propia comprobación de actualizaciones.
Ambas rutas de código se vieron afectadas:
- El comando explícito
wpstaging update, por lo que ejecutarlo se interrumpía con el mensaje «skipped» en lugar de actualizar. - La comprobación automática en segundo plano que se ejecuta una vez al día en cualquier comando, por lo que tampoco apareció nunca un banner de actualización.
El efecto neto es que las instalaciones de v1.10.0 y v1.11.0 no pueden recuperarse por sí solas. La solución tiene que venir de fuera del binario roto, por lo que el paso de recuperación es el comando del instalador de arriba y no wpstaging update.
Qué hicimos
- Lanzamos la v1.11.1 con la corrección. La comprobación de compilación de desarrollo ahora elimina primero la
vinicial, y solo omite la ruta de actualización en etiquetas de desarrollo genuinas comov0.0.0-devydev. - Añadimos pruebas de regresión que cubren las cuatro formas que importan:
v1.11.1,1.11.1,v0.0.0-devydev. Las dos primeras deben pasar la comprobación de desarrollo; las dos últimas deben omitir la ruta de actualización. Las pruebas fallarán ruidosamente si el orden vuelve a regresar. - Empezamos a construir un canal de notificación del lado del servidor en nuestra API de licencias, para que, en el raro caso de un bloqueo similar en el futuro, podamos mostrar un mensaje dentro del producto sin depender de la propia ruta de actualización.
Qué necesitas hacer
Ejecuta el comando del instalador para tu plataforma desde la sección En resumen de arriba. Hará lo siguiente:
- Descargar la v1.11.1 (o posterior) para tu sistema operativo.
- Verificar la suma de comprobación.
- Reemplazar el binario
wpstagingexistente en el sitio. - Dejar tus sitios, licencia, caché y configuración intactos.
Una vez que termine, confirma que la actualización aterrizó:
wpstaging --versionDeberías ver v1.11.1 o superior (los binarios lanzados imprimen la v inicial). A partir de este punto, wpstaging update funciona como se espera, y la comprobación diaria en segundo plano recogerá automáticamente los futuros lanzamientos.
Prevenir esta clase de error
Este error fue especialmente doloroso porque la ruta de código rota es la misma que normalmente te diría que actualizaras. No era posible una solución del lado del usuario; la recuperación tenía que venir de nosotros. Para asegurarnos de que un bloqueo similar no pueda repetirse en silencio, estamos implementando tres capas:
- Pruebas de regresión que ejercitan el analizador de versiones contra etiquetas de lanzamiento reales y etiquetas de desarrollo, de modo que el orden entre eliminar y comprobar no pueda volver a invertirse silenciosamente.
- Una comprobación de humo en el momento del lanzamiento sobre el binario compilado que afirma que la ruta de omisión de desarrollo no se toma para la etiqueta de lanzamiento real. Si un lanzamiento se envía alguna vez con la comprobación de desarrollo activa por error, la compilación fallará antes de que el binario llegue a los usuarios.
- Un canal de notificación del lado del servidor en la API de licencias. Una vez entregado, la CLI podrá mostrar mensajes cortos que publiquemos desde nuestro lado, de modo que cualquier incidente futuro pueda comunicarse sin pasar por la propia ruta de actualización.
Gracias por usar WP Staging CLI, y disculpa la fricción que causó este caso.
Esto fue un simple error humano de ingeniería, no un problema de código generado por IA. Lo pasamos por alto, lo corregimos y añadimos comprobaciones de regresión y del momento del lanzamiento para que este fallo concreto no pueda volver a enviarse en silencio.
Preguntas o problemas
Si el instalador no te funciona, o ves algo inesperado tras reinstalar, ponte en contacto:
