|
|
|
@@ -425,10 +425,10 @@ Resultados reales, uno por uno (código de cada prueba en
|
|
|
|
|
un dispositivo real.
|
|
|
|
|
21b. **Accesibilidad del checkout completo** por teclado (no solo el
|
|
|
|
|
buscador) — tab order y foco visible en los 3 pasos.
|
|
|
|
|
22. **Importación manual de imágenes no se reflejaba en el storefront**
|
|
|
|
|
(reportado por el usuario 2026-09-20) — **causa raíz encontrada y
|
|
|
|
|
arreglada en código (2026-09-20), pendiente confirmar con una
|
|
|
|
|
edición real.** `medusaFetch()` en `lib/headless/providers/medusa.ts`
|
|
|
|
|
22. **Importación manual de imágenes no se reflejaba en el storefront —
|
|
|
|
|
RESUELTO 2026-09-20, con un giro real durante la verificación.**
|
|
|
|
|
Reportado por el usuario 2026-09-20. Causa raíz #1 (caché
|
|
|
|
|
multi-pod): `medusaFetch()` en `lib/headless/providers/medusa.ts`
|
|
|
|
|
usaba `next:{revalidate:60,tags:["medusa-products"]}`, caché en
|
|
|
|
|
memoria por-pod que sobrevivía a `force-dynamic`. Con
|
|
|
|
|
`frontend-deploy` en 2 réplicas sin cacheHandler compartido, el POST
|
|
|
|
@@ -437,11 +437,28 @@ Resultados reales, uno por uno (código de cada prueba en
|
|
|
|
|
TTL expirara solo. Una edición puntual + revisar al toque tenía
|
|
|
|
|
~50% de chance de pegarle al pod stale; una importación CSV (mucho
|
|
|
|
|
más lenta) le daba tiempo de sobra al TTL para expirar en ambos.
|
|
|
|
|
**Fix:** se sacó el `next.revalidate`/`tags` del fetch — ya en
|
|
|
|
|
producción. Falta la prueba con una edición manual real (vía
|
|
|
|
|
`temp-admin`/`ari-shopping-tienda` en memoria) para confirmar que
|
|
|
|
|
el síntoma original desapareció, no solo que la causa técnica tiene
|
|
|
|
|
sentido.
|
|
|
|
|
**Fix #1:** se sacó el `next.revalidate`/`tags` del fetch.
|
|
|
|
|
|
|
|
|
|
Verificado en vivo por el usuario con una edición real (agregó
|
|
|
|
|
varias fotos manuales al producto `minnie-y-mickey-mouse`): las
|
|
|
|
|
fotos sí se reflejaron al toque, confirmando el fix #1 — pero
|
|
|
|
|
apareció un segundo síntoma real, no relacionado: "el zoom
|
|
|
|
|
interactivo no se visualiza" en las fotos subidas a mano, aunque sí
|
|
|
|
|
en las de CSV. **Causa raíz #2** (`components/product/product-gallery.tsx`):
|
|
|
|
|
el panel/overlay de zoom arma `backgroundImage: \`url(${selected})\``
|
|
|
|
|
sin comillas — un nombre de archivo con espacio y paréntesis (ej.
|
|
|
|
|
`descarga (4)-xxx.png`, el patrón por defecto de Chrome al descargar
|
|
|
|
|
una imagen sin renombrarla, exactamente como quedan las subidas
|
|
|
|
|
manuales, a diferencia de las de CSV que llegan con nombres
|
|
|
|
|
saneados) rompe la sintaxis de `url()` sin comillas — el navegador
|
|
|
|
|
descarta el valor completo en silencio (`backgroundImage: none`).
|
|
|
|
|
La lupa (recuadro) sí aparecía porque no depende de la URL; solo el
|
|
|
|
|
panel/overlay quedaba en blanco. **Fix #2:** comillas alrededor de
|
|
|
|
|
la URL en las dos ocurrencias del patrón. Verificado en vivo contra
|
|
|
|
|
las 9 fotos reales del producto (2 de CSV + 7 manuales con
|
|
|
|
|
espacio+paréntesis) con Playwright: `computed backgroundImage`
|
|
|
|
|
pasó de `none` a `url("...")` correcto en las 7 que fallaban, sin
|
|
|
|
|
tocar las 2 que ya andaban bien.
|
|
|
|
|
23. **En mobile (viewport real de 320px), la página se cortaba y
|
|
|
|
|
obligaba a scrollear horizontalmente — RESUELTO 2026-09-20.**
|
|
|
|
|
Reportado por el usuario con captura real de `shop.cruzcloud.net`.
|
|
|
|
|
devops