PrestaShop 1.7: Guzzle duplicado y tablas de ps_eventbus gigantes

En agosto de 2026 salieron en el grupo dos problemas de tiendas PrestaShop 1.7 con un fondo común: módulos de servicios de PrestaShop instalados «porque venían» y que nadie usaba. Respuesta corta: si sigues en 1.7, haz inventario de esos módulos y desinstala los que no uses; te ahorras errores imposibles de reproducir y tablas gigantes.

Caso 1: errores fatales que salen y no salen

Un compañero de la comunidad, con PrestaShop 1.7.7.8, tenía errores fatales que aparecían en unas páginas sí y en otras no. Contó lo que encontró:

• El núcleo traía su copia de la librería Guzzle (la que hace las peticiones HTTP).
• Nueve módulos traían su propia copia antigua dentro de su carpeta: ps_accounts, productcomments, psaddonsconnect, ps_eventbus, ps_checkout, blockreassurance, ps_mbo, ps_facebook y un conector de terceros.
• Esas copias declaraban las mismas clases (GuzzleHttp\Client, GuzzleHttp\Utils) sin un prefijo propio.

PHP solo admite una clase con ese nombre por petición. La que «gana» depende de qué módulo carga antes su autoloader en esa página concreta. Si ganaba una copia antigua, al núcleo le faltaban métodos nuevos (chooseHandler(), request()); si ganaba la del núcleo, a los módulos les faltaban métodos antiguos (getDefaultUserAgent()). El mismo error, unas veces de un lado y otras del otro.

Para saber cuántas copias tienes:

grep -rl --include=Client.php "namespace GuzzleHttp;" modules/ vendor/

Cómo lo arregló y qué es mejor

Él añadió en las diez copias los métodos que faltaban de la otra versión, como alias que llaman a lo que sí existe en cada fichero. Así da igual cuál gane. Funciona, pero es frágil: en cuanto actualizas uno de esos módulos, su parche desaparece y vuelve el error.

Por orden, lo más sano:

1. Desinstala los módulos de servicios que no usas. Si no usas la cuenta de PrestaShop, el pago de PrestaShop Checkout, la integración con Facebook o el escaparate de módulos, fuera.
2. Actualiza los que sí usas a la última versión que admita tu 1.7 y vuelve a probar.
3. Solo si no queda otra, el parche de alias, documentado para volver a aplicarlo.
4. Y pon fecha a la migración.

Caso 2: ps_eventbus y las tablas de millones de filas

Otro compañero, con PrestaShop 1.7.5.2 y ps_eventbus 1.7.0, sufrió dos caídas de MySQL por falta de memoria en una semana. Rastreándolo encontró:

No se purgaban nunca, y de vez en cuando el módulo lanzaba una consulta sin filtro que en la última ocasión trajo 25 millones de filas de golpe, 1,4 GB. La pregunta que le hicieron en el grupo es la clave: ¿usas algún servicio de marketing de PrestaShop?ps_eventbus sincroniza el catálogo y los pedidos con los servicios en la nube de PrestaShop; si no usas ninguno, no lo necesitas.

• Si no usas esos servicios: copia de seguridad y desinstala los servicios y ps_eventbus.
• Si los usas: actualiza el módulo y consulta con el soporte de PrestaShop antes de vaciar las tablas, para no romper la sincronización.
• En cualquier caso, vigila el tamaño de las tablas de la base de datos de vez en cuando. Una tabla que crece sin parar avisa mucho antes de tumbar el servidor.

Si quieres ayuda para limpiar una 1.7 o planificar su migración, en Rekire lo hacemos con un bono de horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación