Error 500 en PrestaShop 9: qué lo causa y cómo lo solucionamos en reparacionmovil.es

Un error 500 en PrestaShop 9 no es un “mensaje bonito”: es la tienda caída. El cliente ve una página en blanco o un 500 genérico. Tú, como dueño, dejas de vender. Y el reloj corre.

Este artículo cuenta un caso real en reparacionmovil.es — tienda de reparación y accesorios en Madrid — sobre PrestaShop 9: qué lo provocó, cómo lo diagnosticamos y cómo lo dejamos estable. Si tu front o el checkout responden 500, aquí tienes un método claro.

Qué pasó en reparacionmovil.es

La tienda estaba en producción con tráfico real. De golpe:

• El home y varias fichas de producto devolvían HTTP 500.
• El back office a veces cargaba, a veces no (según la ruta).
• No había un mensaje útil en pantalla: solo fallo del servidor.
• Había habido un cambio reciente: actualización de un módulo + limpieza de caché a medias.

Cuando una tienda PrestaShop 9 “se cae” así, lo primero no es reinstalar ni tocar el tema a ciegas. Lo primero es leer el log y aislar la causa.

[CAPTURA: navegador mostrando error 500 / pantalla en blanco en reparacionmovil.es]

[CAPTURA: home de reparacionmovil.es funcionando de nuevo tras el arreglo]

Síntomas: checklist rápido

• HTTP 500 en front (home, categoría, producto o checkout).
• Página en blanco sin texto de error (modo producción).
• El fallo aparece tras actualizar PrestaShop 9, un módulo, el tema o PHP.
• A veces solo falla una URL (checkout, carrito, búsqueda) y el resto parece bien.
• En el servidor hay entradas nuevas en var/logs/ o en el log de PHP/Apache/Nginx.

Qué puede causar un error 500 en PrestaShop 9

En la práctica, casi todos los 500 de PrestaShop 9 caen en uno de estos grupos:

1. Módulo incompatible o mal actualizado

Un módulo llama a una clase, hook o servicio que en PrestaShop 9 cambió o ya no existe. Es la causa más frecuente tras “actualizar desde el back office”.

2. Override o personalización antigua

Overrides en /override hechos para 1.7/8 que rompen en 9. Un solo override de Cart, Order o un controlador puede tumbar el front.

3. Caché / Symfony / contenedor a medias

Caché de producción corrupta, var/cache/prod a medio borrar, o permisos que impiden regenerar el contenedor. Muy típico justo después de un deploy o de pulsar “Limpiar caché”.

4. PHP, memoria o extensiones

Versión de PHP no soportada, memory_limit bajo, o extensión que falta. PrestaShop 9 es más exigente: si el hosting se queda corto, el 500 aparece bajo carga.

5. Base de datos o índices rotos

Tabla dañada, consulta de un módulo, o inconsistencia tras una migración. Menos habitual que los módulos, pero hay que mirarlo si el log apunta a SQL.

6. Permisos de archivos

var/, img/ o config/ sin escritura correcta. A veces el síntoma es 500 intermitente al generar caché o miniaturas.

[CAPTURA: listado de causas frecuentes anotadas junto al log de error]

Cómo lo diagnosticamos (método que usamos)

En reparacionmovil.es seguimos el mismo orden que uso en urgencias:

1. No tocar más la tienda a ciegas. Backup rápido de archivos + BD si no había uno fresco.
2. Activar modo depuración solo el tiempo necesario (o leer logs sin exponer errores al público).
3. Abrir el log de PrestaShop en var/logs/ (y el log PHP del hosting).
4. Identificar el stack trace: módulo, override, clase Symfony, plantilla…
5. Aislar: desactivar el módulo sospechoso por FTP/SSH si el BO no responde.
6. Limpiar caché de verdad y volver a probar home, categoría, producto y checkout.

[CAPTURA: fragmento de log en var/logs con la excepción que apuntaba al módulo]

Qué encontramos en este caso

El log no mentía: tras la actualización, un módulo de terceros ejecutaba código en un hook del front que en PrestaShop 9 lanzaba una excepción fatal (clase/servicio no disponible como esperaba el módulo).

Por eso:

• El 500 era inmediato en páginas que disparaban ese hook.
• No era “todo PrestaShop roto”: era un punto concreto del ciclo de vida de la página.
• Reinstalar el core habría sido una pérdida de tiempo. Había que aislar el módulo y corregir o sustituir esa pieza.

Cómo lo arreglamos

1. Backup completo (archivos + base de datos).
2. Desactivación del módulo conflictivo desde el servidor (renombrando su carpeta en /modules cuando el BO no era fiable).
3. Borrado de caché de producción (var/cache/prod) y regeneración limpia.
4. Comprobación de home, categorías, fichas y flujo de carrito/checkout.
5. Sustitución / actualización del módulo por una versión compatible con PrestaShop 9, o desactivación definitiva si no aportaba valor.
6. Revisión de overrides y de permisos en var/.
7. Monitorización unas horas: sin nuevos fatals en el log.

[CAPTURA: módulo renombrado/desactivado en /modules por SSH o gestor de archivos]

[CAPTURA: checkout de reparacionmovil.es operando tras la recuperación]

# Ejemplo orientativo (SSH): aislar un módulo sospechoso
cd /ruta/a/la/tienda/modules
mv nombremodulo nombremodulo.disabled

# Limpiar caché de producción (con cuidado y backup previo)
rm -rf ../var/cache/prod/*

Nota: las rutas exactas dependen del hosting. No copies comandos a ciegas en producción sin backup.

Guía rápida: qué hacer si te pasa a ti

1. Haz backup.
2. Mira var/logs/ y el log PHP del servidor: busca la primera excepción, no solo la última línea confusa.
3. Si el log nombra un módulo → desactívalo y prueba.
4. Si nombra un override → renómbralo temporalmente.
5. Limpia var/cache/prod y vuelve a cargar.
6. Prueba siempre: home, producto, carrito, pago, back office.
7. Cuando vuelva, decide: actualizar el módulo, reemplazarlo o eliminar la personalización rota.

Cómo prevenir el próximo 500

• Actualiza módulos en staging, no solo en producción.
• No acumules módulos “por si acaso”: cada uno es superficie de fallo en PrestaShop 9.
• Tras cualquier cambio: limpia caché y prueba el checkout de verdad (no solo el home).
• Mantén PHP en una versión soportada por tu PrestaShop 9.
• Ten un plan de urgencia: acceso SSH/SFTP, backups y alguien que sepa leer un stack trace.

Conclusión

En reparacionmovil.es el error 500 de PrestaShop 9 no era un misterio del “servidor mágico”: era un módulo que rompía el front tras un cambio. Con log, aislamiento y caché limpia, la tienda volvió a vender sin rehacerla desde cero.

Si tu PrestaShop 9 está en 500 ahora mismo — o se cae tras actualizar — puedo entrar, leer el log y recuperar la tienda con prioridad en checkout y ventas.

Contactar con PrestaShop Web Design · Soporte urgente y desarrollo PrestaShop en Madrid y remoto en toda España.