Caso real: colchoneriasgonzalez.com — Colchonerías González, colchonería online en España.
El encargo no era “subir un zip y cruzar los dedos”. Había que actualizar PrestaShop 9 con un rebuild controlado: PrestaShop 9.1.4 en Plesk, PHP 8.3, tema Hummingbird con CSS/JS a medida, front y back office en vivo. Base de datos nueva para PS9; la BD antigua se dejó intacta para poder volver atrás.
Si estás planificando una migración PrestaShop 9, este artículo cuenta lo que falló de verdad —y cómo se dejó estable— sin inventar drama ni “trucos mágicos”.
Qué se veía (síntomas)
En una migración de este tipo los síntomas no siempre llegan juntos. Aquí se acumulaban capas distintas:
- El dump de MySQL 8 no importaba limpio en MariaDB del Plesk (collation).
- Tras mover el entorno, sesiones / cifrado del back office se rompían si se regeneraban mal las cookie keys.
- En el BO, al guardar módulos o entrar en Performance, 403 por query strings largas (nginx).
- Tras renombrar la carpeta admin, el panel “no cargaba” o petaba por rutas Twig/Symfony antiguas.
- Había que cortar a producción con FO + BO operativos, no solo “la home abre”.
Eso es lo que la gente busca cuando escribe errores al actualizar PrestaShop o panel administración PrestaShop 403: no un tutorial genérico, sino dónde se rompe el stack.
Diagnóstico: tres capas, un mismo go-live
El diagnóstico no fue “un módulo malo”. Fue multi-capa:
- Base de datos: MySQL 8 → MariaDB 10.6 (collation
utf8mb4_0900_ai_ci). - Aplicación PrestaShop 9:
parameters.php/ keys Defuse, caché Symfony/Twig, carpeta admin renombrada. - Servidor Plesk (nginx): regla de hardening que bloquea argumentos de URL demasiado largos.
Si solo miras el BO o solo miras el dump, te quedas a medias. Actualizar PrestaShop en Plesk es también un trabajo de compatibilidad de servidor.
Qué encontramos (causa real)
1) Collation MySQL 8 → MariaDB en Plesk
El dump venía de MySQL 8 con collation utf8mb4_0900_ai_ci. En el Plesk de destino, MariaDB 10.6 no la traga igual: el import falla o deja la BD a medias.
Fix: normalizar el dump a utf8mb4_general_ci antes de importar (reemplazo controlado de collations en el SQL, no “a ojo” en producción).
Lección: actualizar PrestaShop sin perder datos empieza por que el dump sea importable. No es solo copiar archivos del núcleo.
2) Cookie / crypto keys tras el traslado
En PrestaShop (Symfony + Defuse) las claves de cookie y cifrado no son decorativas. Si regeneras _COOKIE_KEY_ / claves relacionadas “porque es un servidor nuevo”, puedes romper sesiones y el descifrado de datos sensibles del entorno.
Fix: restaurar las keys correctas desde el app/config/parameters.php (o equivalente) del entorno que ya funcionaba. No inventar valores nuevos a ciegas.
Lección: en una migración PrestaShop 9, las keys viajan con el proyecto. Regenerarlas solo cuando sabes el impacto (y con plan de re-login / datos cifrados).
3) BO 403 al guardar: tokens largos vs nginx en Plesk
En nginx (Plesk) había hardening del estilo:
if ($args ~ ".{250,}") { return 403; }En PrestaShop 9 el back office lleva token / _token largos en la query (configuración de módulos, Performance, etc.). Esa regla devolvía 403 al guardar.
Primer intento de excepción: solo la carpeta antigua /admin750. En producción el BO ya era /admin500 (rename). Además, rutas como /modules/ps_accounts/.../notifications.js?ctx=... también superaban el umbral.
Fix (idea): no aplicar el 403 de “args muy largos” a /admin[0-9]+ y /modules/; mantener la protección en el front office frente a scrapers con query basura.
Lección: muchos “errores al actualizar PrestaShop” en BO son reglas WAF/nginx, no bugs del core.
4) Admin que no carga tras renombrar la carpeta
Se renombró la carpeta admin (de admin750 a admin500 — buena práctica de seguridad). La caché Symfony/Twig seguía apuntando a rutas tipo:
admin750/themes/new-theme/...Resultado: Twig LoaderError → BO en blanco o roto.
Fix:
- Vaciar/regenerar caché del admin (
var/cache/...). - Symlink temporal
admin750→admin500mientras el container se reconstruye (solo puente). - Rebuild del container/caché hasta que las rutas usen
admin500. - Quitar el symlink cuando el BO carga limpio.
Lección: renombrar carpeta admin PrestaShop en 8/9 sin limpiar caché Symfony es una forma clásica de “actualizar y que el panel muera”.
Cómo lo solucionamos (paso a paso)
- Montar el entorno PS 9.1.4 en Plesk con PHP 8.3 FPM.
- Crear BD nueva para PS9; no tocar la BD antigua (cutover seguro).
- Normalizar el dump:
utf8mb4_0900_ai_ci→utf8mb4_general_cie importar. - Desplegar archivos + tema Hummingbird + CSS/JS custom.
- Restaurar keys correctas en parámetros (sin inventar cookie keys).
- Ajustar nginx: excepción de args largos para
/admin[0-9]+y/modules/. - Renombrar admin; limpiar caché Twig/Symfony; symlink temporal si hace falta; rebuild.
- Smoke-test: home, ficha, carrito/checkout básico, login BO, guardar en un módulo, Performance, módulos críticos.
- Apuntar DNS/document root al nuevo stack cuando FO + BO estaban estables.
Sin contraseñas. Sin tokens. Solo el proceso.
Resultado
- Tienda en PrestaShop 9.1.4 en Plesk (PHP 8.3).
- Front office en vivo (Hummingbird + custom).
- Back office estable: guardar módulos / Performance sin 403.
- Admin renombrado sin LoaderError de Twig.
- BD nueva en marcha; BD antigua intacta como red de seguridad.
- Cutover con checklist FO + BO + módulos clave.
No es “PrestaShop 9 instalado”. Es actualizar PrestaShop 9 y dejarlo operable en un hosting real.
| Área | Problema | Estado final |
|---|---|---|
| MariaDB / dump | utf8mb4_0900_ai_ci | Import con utf8mb4_general_ci |
| Keys | Regeneración ciega | Keys del entorno válido |
| nginx Plesk | 403 por args largos | Excepción admin + modules |
| Carpeta admin | Twig → admin750 | Caché + rutas en admin500 |
Checklist si vas a actualizar PrestaShop 9
- Staging o BD/archivos nuevos aparte del live.
- Comprobar motor BD destino (MariaDB vs MySQL 8) y collation del dump.
- PHP 8.1+ (aquí 8.3) según requisitos de tu 9.1.x.
- Inventario de módulos compatibles con PS9; tema soportado (Hummingbird u otro).
- No regenerar cookie/crypto keys a ciegas al copiar el proyecto.
- Revisar reglas nginx/WAF de Plesk (403 por query larga en admin).
- Tras renombrar carpeta admin: borrar caché Symfony/Twig y probar login + guardar.
- Smoke-test FO + BO antes de dar el go-live por cerrado.
- Search Console: sitemap, propiedad correcta, revisar 404 tras el cambio de URLs.
SEO tras la migración (nota corta)
Después del cutover conviene mirar lo básico en Search Console: sitemap enviado, redirecciones si cambió www/apex o rutas, y que las URLs importantes respondan 200. No es el núcleo de este caso —el BO y la BD lo fueron—, pero una migración PrestaShop 9 mal cerrada en SEO se nota en semanas, no en minutos.
Conclusión
En Colchonerías González, actualizar PrestaShop 9 no se rompió por “un clic del instalador”. Se cruzaron collation MySQL→MariaDB, keys de cifrado, un 403 de nginx por tokens largos del admin y una caché Twig anclada a la carpeta admin antigua. Cada pieza sola es molesta; juntas tumban el back office el día del go-live.
La forma correcta: diagnosticar por capas → corregir dump y servidor → estabilizar BO → smoke-test → cortar con la BD vieja a salvo.
¿Quieres migrar o actualizar PrestaShop (1.7/8 → 9) en Plesk u otro hosting sin improvisar el viernes por la tarde? Puedo ayudarte con el plan, la migración y las pruebas. Madrid y remoto en toda España.
Migración PrestaShop · Soporte técnico PrestaShop · Mantenimiento PrestaShop · Acelerar PrestaShop · Errores al actualizar PrestaShop · Contactar
actualizar PrestaShop 9, migración PrestaShop 9, PrestaShop 9 Plesk, actualizar PrestaShop sin perder datos, errores al actualizar PrestaShop, panel administración PrestaShop 403, MariaDB utf8mb4, renombrar carpeta admin PrestaShop, Colchonerías González, caso de éxito