Modulo Auditor de compatibilidad PrestaShop 8.x y 9.x

Descripción

### Actualizar PrestaShop no rompe la tienda. La rompen los módulos.

Pasar de 1.7 a 8.x o a 9.x rara vez falla por el núcleo. Falla por los módulos de terceros, por los overrides que alguien dejó en `/override` y por las plantillas que el tema copió de un módulo hace tres años.

Y el problema es que no se ve venir. Un método que desaparece del núcleo provoca un error fatal en cada petición. Un hook que ya no existe hace que tu módulo **deje de ejecutarse sin ningún error**: esa funcionalidad simplemente se apaga y nadie se entera hasta que un cliente se queja semanas después.

**Ecom Compatible** lo detecta antes de que ocurra.

### Qué revisa

– **El código PHP de cada módulo.** Clases, métodos, constantes y funciones que desaparecen o cambian de firma en la versión destino. Cada hallazgo trae fichero, línea, la orden actual y por cuál sustituirla.
– **Los overrides**, tanto los activos de `/override` como los que trae cada módulo: clase base eliminada, método que ya no existe, firma incompatible con el núcleo destino, dos módulos peleándose por el mismo método, restos de módulos desinstalados, y `namespace` o `declare(strict_types=1)` que impiden que PrestaShop los cargue.
– **Las plantillas `.tpl`** de los módulos y del tema activo: sintaxis de PrestaShop 1.6 que en 1.7+ devuelve vacío, hooks inexistentes y —lo más traicionero— las plantillas que el tema copió de un módulo y que **anulan cualquier corrección futura** de ese módulo.
– **La compatibilidad con PHP 8.x**: funciones eliminadas, sintaxis que dejó de compilar, interpolación obsoleta, propiedades dinámicas, tipos de retorno de interfaces nativas y nullables implícitos, según la versión de PHP a la que vayas.
– **Si existe ya una versión compatible** del módulo, consultando la API de distribución de PrestaShop, el Marketplace de Addons y GitHub.

### Los datos no están escritos a mano

Casi todas las listas de «cambios entre versiones de PrestaShop» que circulan por internet están redactadas a mano y se quedan obsoletas al mes.

Aquí la base de conocimiento se generó **comparando el código fuente real** de PrestaShop 1.7.8.11, 8.1.7, 8.2.7 y 9.1.1: se extrajeron todos los símbolos de `classes/`, `controllers/`, `src/Core/` y `src/Adapter/` de cada versión y se diferenciaron uno a uno.

Hacia PrestaShop 9 eso son **302 clases eliminadas**, **166 clases con métodos eliminados**, **142 métodos con la firma cambiada**, **10 hooks retirados** y **265 constantes y propiedades** que ya no existen. Detectados por comparación, no por suposición.

### Ordenado por quién tiene que arreglarlo

Un listado plano de 200 módulos no sirve para nada. Lo que decide qué haces con un módulo roto es **quién lo mantiene**, así que el informe se agrupa por origen:

| Grupo | Qué significa |
|—|—|
| **PrestaShop (nativos)** | No toques nada: se arreglan solos al actualizar el núcleo |
| **De la plantilla** | Se arreglan actualizando o cambiando el tema; parchearlos a mano es tirar el trabajo |
| **Propios** | Son tuyos: aquí aplican directamente los parches que genera la herramienta |
| **De terceros** | Subdivididos por desarrollador y ordenados por gravedad, para gestionarlo proveedor a proveedor |
| **Instalados pero desactivados** | No rompen nada, pero el actualizador los toca igual |
| **No instalados** | Solo la carpeta: peso muerto que conviene borrar antes de migrar |

Distingue además dos cifras que casi siempre se confunden: cuántos **módulos** están bloqueados y cuántas **órdenes de código** hay que cambiar. Un solo módulo puede tener decenas.

### No solo te dice el problema

– **Ficheros `.diff` aplicables con `git apply`**, con las rutas originales de tu tienda. Solo incluyen reescrituras mecánicas que no cambian la semántica: lo que exige criterio se queda en el informe, nunca en el parche.
– **Propuestas de override** adaptadas a la versión destino, con los métodos eliminados comentados y el código original dentro para que traslades la lógica.
– **Informes en JSON y Markdown**, descargables uno a uno o en un ZIP, guardados en una carpeta protegida con `.htaccess`.
– **Histórico acumulado** que sobrevive a las reinstalaciones: cuándo se detectó cada problema, en qué versión del módulo apareció y en cuál se resolvió. Es el registro de qué arregló cada actualización.
– **Publicación opcional en tu repositorio de GitHub**, para llevar la memoria de todas las tiendas que auditas en un mismo sitio.

### Pensado para catálogos grandes

El análisis va **fichero a fichero** por AJAX y cada lote se corta por tiempo real, sin pasar nunca del 60 % del `max_execution_time` del servidor. Da igual que un módulo tenga 20 ficheros o 5.000: no puede agotar el tiempo de ejecución.

Una **consola en vivo** muestra cada fichero que analiza con marca de tiempo, y si algo falla en el servidor muestra la respuesta literal en lugar de quedarse en blanco.

Para catálogos muy grandes hay una **tarea programada** protegida por token que reanuda el análisis donde lo dejó, de modo que puedes dejarlo trabajando durante días y volver a mirar.

### No toca tu tienda

– **Solo lee.** No modifica ni un fichero de tus módulos: los parches y los overrides se escriben en su propia carpeta y los aplicas tú cuando quieras.
– **Las consultas a internet vienen desactivadas.** Mientras no las actives, todo el análisis es local y no sale un solo byte de tu servidor.
– **La publicación en GitHub es opcional**, va a tu propio repositorio, viene desactivada, tiene vista previa y pide confirmación, con anonimización activada de fábrica.
– **Cero dependencias de Composer.** Nada de Guzzle ni de Symfony propios colisionando con los del núcleo, que es una de las causas más habituales de pantalla en blanco tras actualizar.

### Requisitos

| | |
|—|—|
| PrestaShop | 1.7.0 a 9.x |
| PHP | 7.x y 8.x |
| Versiones destino analizables | 8.0, 8.1, 8.2, 9.0 y 9.1 |
| Extensiones | Ninguna obligatoria (`ZipArchive` solo para la descarga en ZIP) |
| Multitienda | Compatible |
| Documentación | Manual de usuario, documentación técnica y guía de desarrollo |

### Qué no hace

Prefiero decirlo antes de la compra:

– **No garantiza** que la actualización vaya a funcionar. Es análisis estático: detecta lo que se puede detectar leyendo el código, que es la gran mayoría de lo que rompe, pero no las llamadas construidas en tiempo de ejecución ni los fallos que dependan de datos concretos.
– **No arregla los módulos solo.** Genera parches para lo mecánico y te dice exactamente qué cambiar en el resto. Un parche automático sobre lógica de negocio es la forma rápida de romper una tienda.
– **No puede analizar código cifrado** (ionCube y similares).

Haz siempre copia de seguridad y prueba en un entorno de pruebas antes de tocar producción.