auditar --antes-de-actualizar
Actualizar PrestaShop sin sorpresas, con auditoría del core
Antes de aplicar un parche de seguridad, comparé el core de la tienda archivo a archivo contra el oficial. Presupuesto cerrado y ni una sorpresa.
0
modificaciones al core encontradas en 330 ficheros comparados
Diff contra el zip oficial de PrestaShop 8.2.7
Por qué auditar antes
PrestaShop 8.2.8 era una versión solo de seguridad: corregía una inyección SQL en el back office, una suplantación de IP, un SSRF al importar imágenes, inyección en las exportaciones CSV y un endpoint sin control de permisos. Había que aplicarla.
El riesgo de actualizar a ciegas una tienda con años de historia es que alguien tocó el core «solo un momento» y la actualización lo pisa. Así que antes de dar un presupuesto, miré.
Qué revisé
- 330 ficheros del core (
classes/,src/,controllers/,config/, el admin…) comparados byte a byte contra el zip oficial. Cero modificaciones. - 15 overrides, cada uno con su módulo de origen identificado. Ninguno tocaba un método que cambie en 8.2.8.
- Módulos fantasma y versiones de base de datos distintas a las del disco: ninguno.
- Cómo se hizo la actualización anterior, con su log: quién, cuándo y con qué opciones.
El resultado
Veredicto: se puede actualizar, 10 horas presupuestadas (horquilla honesta de 7 a 13). Las horas se iban a pruebas y a la ventana de producción, no a arreglar sorpresas.
También dejé escrito lo que no entraba: el salto a PrestaShop 9 es un proyecto aparte de semanas, y no se mezcla con un parche de seguridad.
Por qué importa: el cliente sabe lo que paga antes de empezar, y el riesgo se mide en vez de suponerse.