La tienda velasdeolor.es funcionaba con PrestaShop 8.1.1. La madrugada del viernes 16 al sábado 17 de octubre de 2026 la actualizamos a PrestaShop 8.2.8, la última versión de la rama 8. La actualización en sí tardó 72 segundos; prepararla nos llevó una semana. Contamos cómo lo hicimos, porque casi todo lo que evita sustos ocurre antes de pulsar el botón.
Por qué a 8.2.8 y no directamente a PrestaShop 9
PrestaShop 8.2.8 (agosto de 2026) trae correcciones de seguridad y mejoras acumuladas de toda la rama 8. PrestaShop 9 ya está disponible, pero la plantilla de la tienda y varios módulos todavía no están listos para dar el salto. Así que el plan es en dos tiempos: primero dejar la tienda al día dentro de la rama 8 y, después, preparar con calma la migración a la 9 con el mismo método.
1. Un staging de verdad, con datos anonimizados
Todo empieza con una copia de la tienda en un subdominio, protegida con contraseña y fuera de los buscadores. Pero una copia sin más tiene dos peligros: guarda los datos personales de miles de clientes y puede comportarse como la tienda real. Por eso la nuestra:
- Anonimiza los datos de clientes: nombres, direcciones, mensajes y emails se sustituyen por datos ficticios, y las IP se ponen a cero. Solo se conservan las cuentas de la propia tienda.
- No cobra: los módulos de pago quedan en modo de pruebas y sin claves reales.
- No envía emails ni crea envíos: el módulo de la empresa de transporte se apaga, porque con sus credenciales generaría etiquetas reales.
- No mide: sin identificadores de Analytics ni de Google Ads, para no ensuciar las estadísticas.
Además, se refresca con unos scripts en pocos minutos (archivos en menos de medio minuto y base de datos en alrededor de un minuto), así que cada prueba se puede repetir sobre una copia reciente.
2. Sin SSH, pero con scripts
El servidor no tiene acceso SSH y, por seguridad, tiene desactivadas las funciones de PHP que ejecutan comandos del sistema. El asistente de actualización de PrestaShop en línea de comandos usa justo esas funciones para encadenar sus pasos, así que lo lanzamos paso a paso (preparación, archivos, base de datos y módulos) desde un pequeño lanzador que ejecuta trabajos en cola mediante una tarea programada. Cada paso deja su registro, y sabemos exactamente en qué punto está la actualización.
Un aviso importante: en una de las pruebas, el asistente desactivó los 42 módulos que no son nativos, porque en ese modo vuelve a leer su configuración en cada paso y aplica la opción por defecto. Si actualizas por línea de comandos, pasa siempre las opciones de forma explícita: mantener los módulos no nativos activos, no desinstalar los «incompatibles», no regenerar las plantillas de email y no desactivar los overrides.
3. Las personalizaciones del núcleo
En trece años, la tienda había acumulado 20 pequeños cambios en archivos del propio PrestaShop: tamaño de miniaturas en listados y facturas, paginación del panel, longitud de los teléfonos… Una actualización los sobrescribe sin avisar. Para no perderlos, preparamos un script que, para cada cambio, comprueba si ya está aplicado, exige encontrar el código original exacto, guarda una copia y verifica la sintaxis antes de aplicarlo. A medio plazo, la idea es pasarlos a módulos o overrides documentados para no depender de ellos en cada actualización.
4. El ensayo general
El mismo día de la actualización hicimos un ensayo completo sobre una copia de la tienda de esa misma mañana:
- Actualización de 8.1.1 a 8.2.8 en 72 segundos, sin un solo aviso ni error.
- Los mismos módulos activos antes y después, y las 20 personalizaciones reaplicadas.
- Una prueba de humo con 51 direcciones (las páginas clave y una muestra del sitemap) comparadas antes y después: todas iguales, y con un tiempo medio de respuesta algo mejor.
- Pruebas funcionales del buscador, los filtros, el carrito y la caché, y una revisión a mano de la tienda por parte de su responsable.
5. La noche de la actualización
- Hora con poco tráfico: la madrugada del viernes al sábado, que además deja el fin de semana para revisar con calma.
- Copia completa del alojamiento unas horas antes, además de la del propio asistente.
- Modo mantenimiento abierto solo a nuestra IP.
- Un guion con horas y una tabla de 29 situaciones posibles con qué hacer en cada una, incluida una hora límite para decidir si se volvía atrás.
- Al terminar: vaciar la caché de páginas, la del servidor y la de la CDN, repetir la prueba de humo y quitar el mantenimiento.
Al día siguiente, de día, hicimos un pago real pequeño con cada pasarela (y lo devolvimos), revisamos los emails, las tareas programadas y el módulo de seguridad, que tras actualizar avisa de miles de archivos cambiados y necesita tomar una referencia nueva.
utf8mb4: la otra mitad del trabajo
Con los años, la base de datos había acumulado tablas con codificaciones distintas: utf8mb3, utf8mb4 con varios cotejamientos e incluso latin1 en un módulo antiguo. El síntoma son emojis que se pierden en opiniones o mensajes y errores de tipo «Illegal mix of collations» al cruzar tablas.
En staging convertimos 195 tablas a utf8mb4 en menos de tres segundos, columna a columna y conservando tipo, valores por defecto y comentarios (la orden rápida, CONVERT TO, cambia algunos tipos de columna sin pedir permiso). Antes y después se comparan filas, huellas de los datos y resultados de búsquedas con y sin tildes. En producción lo haremos en otra ventana de mantenimiento, por separado: mezclar dos cambios grandes en una misma noche complica saber qué ha fallado si algo falla.
Y después: PHP 8.2
PHP 8.1 dejó de recibir parches de seguridad a finales de 2025. La documentación de PrestaShop recomienda PHP 8.1 para la rama 8 y no incluye 8.2 entre las versiones soportadas, así que este paso lo dimos con cuidado: lo probamos a fondo en staging y, el 21 de octubre, pasamos la tienda a PHP 8.2 como puente hasta PrestaShop 9. Si te planteas lo mismo, haz las pruebas antes y ten en cuenta que estarás fuera de la tabla oficial.
Lo que te recomendamos
- Monta un staging con datos anonimizados y que no pueda cobrar, enviar emails ni crear envíos.
- Haz un ensayo general sobre una copia reciente y compara la tienda antes y después con las mismas páginas.
- Haz inventario de los cambios en el núcleo antes de que la actualización los borre.
- Revisa las opciones del asistente: las de por defecto pueden desactivar tus módulos.
- Ten un guion y un punto de no retorno: a qué hora decides volver atrás y cómo.
- Separa los cambios grandes (versión, codificación, PHP) en ventanas distintas.
Si tu tienda PrestaShop lleva tiempo sin actualizarse y te da miedo tocarla, contacta con nosotros. También te puede interesar lo que nos pasó con un error 500 tras actualizar un módulo y nuestra checklist de seguridad para tiendas PrestaShop.
