La tarjeta de evaluación de riesgo de módulos: 12 comprobaciones antes de instalar

No necesitas saber leer PHP para determinar si un módulo de PrestaShop es seguro para instalarlo en tu tienda en producción. La mayor parte del daño que causa un mal módulo es visible desde un navegador y desde tu back office, si sabes dónde mirar. Esta es la lista de comprobación que usamos nosotros, redactada para que el propietario de una tienda pueda aplicarla sin un desarrollador.

La idea es sencilla. Un módulo es código sin aislamiento (sin sandbox) que se ejecuta con todos los privilegios de tu tienda: puede cargar recursos en cada página, escribir en tu base de datos, modificar el comportamiento del núcleo y hacer llamadas a otros servidores. Así que, en lugar de fiarte de la página de venta, tú observas lo que el módulo realmente hace en una copia segura de tu tienda y lo puntúas. Diez comprobaciones en verde de doce es un módulo que puedes instalar con confianza. Pero la puntuación no lo es todo: algunas filas son motivos de rechazo absoluto. Una señal de alarma en el checkout o en los datos de clientes, en la prueba de reversibilidad, en un nuevo dominio externo o en overrides no declarados significa que el módulo no entra en tu tienda en producción hasta que el proveedor lo explique, digan lo que digan las demás filas.

Ejecuta esto primero en una copia de staging, nunca en producción. Duplica tu tienda (la mayoría de los alojamientos ofrecen un clon de staging con un solo clic) o utiliza una instalación desechable con tu plantilla y tus demás módulos presentes. Conviene que el módulo se enfrente a la misma realidad desordenada que tu tienda real: tu plantilla, tu configuración de idioma y moneda, tus módulos existentes, tus versiones de PrestaShop y de PHP. Un módulo que solo se comporta bien en una instalación en blanco te está diciendo algo.

Las doce comprobaciones

1. Dominios externos y CDN

Cómo ejecutarla: abre la página de inicio de tu tienda, no la página de configuración del módulo, en tu navegador, pulsa F12 para abrir las Herramientas de desarrollo, haz clic en la pestaña Red (Network) y recarga la página. Ordena por Dominio. Anota cada dominio que no sea el tuyo. Ahora instala el módulo y recarga de nuevo. ¿Apareció algún nuevo dominio de terceros?

Aprobado: ningún dominio externo nuevo en páginas que no usan la funcionalidad. Modo de fallo: esta es exactamente la trampa de nuestro ensayo: un módulo que carga una fuente, un script o un rastreador desde el servidor de otra persona en cada página, añadiendo resoluciones DNS, peso, una exposición de privacidad y una dependencia de un servidor que tú no controlas. Si ese servidor está lento o caído algún día, la representación de tu escaparate puede detenerse o degradarse con él.

Si prefieres contarlos con exactitud en lugar de leer la lista a ojo, pega esto en la misma pestaña Consola (Console) de las Herramientas de desarrollo y pulsa Intro: enumera cada dominio que no sea el tuyo y cuántas peticiones hizo cada uno:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Cuenta cada host que no sea tu dominio principal, incluidos los subdominios de CDN que tú mismo gestiones, que puedes ignorar sin problema. Ejecútalo antes de instalar el módulo y de nuevo después: cualquier host genuinamente nuevo es un nuevo tercero del que ahora depende tu escaparate.

Esta es la comprobación de mayor valor de la lista, porque detecta exactamente el fallo de nuestro ensayo: un módulo que añade sigilosamente un dominio de terceros a cada página. Si aquí aparece un host que tú no añadiste a propósito, detente y pregunta al proveedor por qué antes de que llegue nunca a tu tienda en producción.

2. Recursos globales del front office

Cómo ejecutarla: en la misma pestaña Red, filtra por CSS y JS y compara el recuento en tu página de inicio antes y después de instalar. Luego comprueba una página a la que el módulo debería afectar y una a la que no debería.

Aprobado: las hojas de estilo y los scripts del módulo se cargan solo en las páginas que los usan. Modo de fallo: un módulo «pequeño» que registra sus recursos en un hook de cabecera global añade peso a cada página de la tienda, incluido el checkout, por una funcionalidad que vive en una sola. Multiplica eso por una docena de módulos descuidados y tendrás una tienda lenta sin un único culpable.

3. Overrides

Cómo ejecutarla: antes de instalar, mira en la carpeta /override de tu tienda por FTP o con el gestor de archivos de tu alojamiento (solo compruebas si aparecen archivos; no necesitas leerlos). Instala el módulo y vuelve a mirar.

Aprobado: no apareció ningún archivo nuevo en /override (una carpeta de serie ya contiene archivos index.php de marcador de posición; tú buscas los nuevos). Modo de fallo: los overrides viven en /override y cambian cómo se comportan las clases y los controladores del núcleo de PrestaShop. Dos módulos que hacen override de la misma clase entran en conflicto y, lo que es crítico, un override que queda tras desinstalar es una de las causas principales de «mi tienda se rompió y desactivar cosas no lo arregló». Los buenos módulos usan hooks y servicios en lugar de hacer override del núcleo.

4. Hooks utilizados

Cómo ejecutarla: en el back office, ve a Diseño › Posiciones (la pantalla de hooks) y observa dónde se registró el módulo. También sueles poder ver los hooks de un módulo en su página de configuración.

Aprobado: los hooks coinciden con la funcionalidad. Un módulo de envíos se engancha en el envío y el checkout; un módulo de pestañas de producto se engancha en la página de producto. Modo de fallo: un módulo enganchado en todas las páginas, displayHeader, displayFooter en todo, «por si acaso», cuando su funcionalidad solo aparece en un lugar. Cada uno de esos hooks es código que se ejecuta en cada carga de página.

5. Cambios en el esquema de la base de datos

Cómo ejecutarla: en la herramienta de base de datos de tu alojamiento (phpMyAdmin o similar), anota el número de tablas antes de instalar. Instala y observa lo que se añadió: compruebas nombres, no contenidos.

Aprobado: las nuevas tablas están claramente asociadas a un espacio de nombres del módulo (un prefijo reconocible) e, idealmente, documentadas. Un puñado de tablas con buenos nombres es completamente normal y correcto. Modo de fallo: un módulo que dispersa tablas sin etiquetar, o escribe en las tablas del núcleo de PrestaShop de formas que no declara, es uno sobre el que no podrás razonar con limpieza más adelante.

Si tienes acceso a la base de datos (phpMyAdmin o la línea de comandos), puedes listar exactamente qué añadió un módulo. Anota la lista antes de instalar, luego ejecútala de nuevo después y compara:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables – list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Una lista corta y con un prefijo claro es saludable. Una dispersión de tablas sin etiquetar, o escrituras no declaradas en tablas del núcleo como ps_orders o ps_customer, es lo que hay que vigilar. (ps_ es el prefijo de tabla por defecto; sustitúyelo por el tuyo si lo cambiaste, y usa el nombre técnico del módulo en lugar de mymodule .)

6. Limpieza al desinstalar

Cómo ejecutarla: tras tu comprobación del esquema, desinstala el módulo y mira de nuevo la base de datos. ¿Qué eliminó y qué dejó?

Aprobado: el módulo elimina lo que creó, o indica claramente en su documentación qué conserva deliberadamente y por qué (conservar tus ajustes para una futura reinstalación es una elección legítima, si se declara). Modo de fallo: restos silenciosos. Tablas huérfanas, filas de configuración y archivos obsoletos que se acumulan cada vez que pruebas un módulo. Esta es la fila en la que «ya lo desinstalaré» falla en silencio.

7. Tareas cron y webhooks

Cómo ejecutarla: revisa la documentación y la página de configuración del módulo en busca de cualquier cosa que se ejecute de forma programada o que llame a un servicio externo en segundo plano: sincronizaciones, feeds, tareas de limpieza, integraciones de «conecta tu cuenta».

Aprobado: las tareas en segundo plano están declaradas y puedes desactivarlas. Modo de fallo: actividad en segundo plano no declarada: una tarea machacando tu base de datos según un calendario, o un webhook enviando tus datos a algún sitio del que no eras consciente. No puedes gestionar lo que no sabes que se está ejecutando.

8. Puntos de contacto con checkout, pedidos y datos de clientes

Cómo ejecutarla: con el módulo instalado en staging, realiza un pedido de prueba completo de principio a fin. Busca un producto. Abre una página de producto. Abre las pantallas principales del back office. ¿Sigue funcionando todo exactamente como antes?

Aprobado: el checkout, la búsqueda, las páginas de producto y la administración no se ven afectados salvo que ese sea literalmente el cometido del módulo. Modo de fallo: un módulo que toca el flujo de pedidos o los registros de clientes está tocando tus ingresos y tus obligaciones de cumplimiento. Un checkout que se rompe, o que calcula mal en silencio, te cuesta dinero real el día que se publica, no en un laboratorio.

9. Multitienda, idioma y moneda

Cómo ejecutarla: si gestionas más de una tienda, más de un idioma o más de una moneda, prueba el módulo en cada uno. Cambia de tienda, cambia de idioma, cambia de moneda y usa la funcionalidad.

Aprobado: el módulo respeta tu configuración: correcto por tienda, traducido por idioma, importes correctos por moneda. Modo de fallo: un módulo construido y probado contra «tienda 1, inglés, euros» que fija esas suposiciones en el código. Se ve bien en la demo y se desmorona en tu segundo escaparate o en los precios de tus clientes polacos.

10. Compatibilidad con PrestaShop y PHP

Cómo ejecutarla: lee la declaración de compatibilidad en la página del producto y contrástala con tu versión de PrestaShop (1.7, 8.x o 9.x) y tu versión de PHP.

Aprobado: el proveedor nombra las versiones exactas que el módulo admite y las mantiene al día a medida que PrestaShop publica nuevas versiones. Modo de fallo: «compatible con todas las versiones». Ningún módulo serio se prueba contra cada versión de PrestaShop y de PHP jamás publicada; esa afirmación es marketing, y es la fila con más probabilidades de romperse el día que actualices tu tienda.

11. Registro de cambios y rastro de soporte

Cómo ejecutarla: busca un registro de cambios con fechas y un canal de soporte real antes de comprar.

Aprobado: el módulo tiene un historial visible de actualizaciones y una forma de contactar con una persona que lo mantiene. Modo de fallo: sin registro de cambios y sin soporte significa sin dueño. Un módulo sin mantenimiento es un módulo que tarde o temprano dejará de funcionar con una actualización de PrestaShop o de PHP, sin nadie que lo arregle, y te enterarás en el peor momento posible.

12. La prueba de reversibilidad

Cómo ejecutarla: esta es toda la lista de comprobación en un solo movimiento, en staging. Haz una instantánea de tu tienda. Instala el módulo. Desactívalo. Desinstálalo. Compara la tienda con tu instantánea.

Aprobado: instalar → desactivar → desinstalar deja la tienda esencialmente como estaba: sin archivos residuales, sin tablas huérfanas, sin páginas rotas. Modo de fallo: cualquier cosa que no vuelva a su estado. Si un módulo no se puede eliminar con limpieza en una copia de prueba, desde luego no se podrá eliminar con limpieza de tu tienda en producción bajo presión.

Señales de alarma, y lo que realmente significa cada una

No siempre tendrás tiempo para las doce completas. Estos son los atajos: señales que, por sí solas, justifican una mirada mucho más atenta. Cada una se corresponde con una forma concreta en que las cosas salen mal:

Ninguna de estas es prueba de que un módulo sea malo. El código barato y sencillo puede ser perfectamente bueno; un proveedor pequeño puede ser excelente. El problema nunca es el precio ni el autor: es el riesgo no gestionado. Una señal de alarma solo significa que el riesgo no se ha gestionado por ti, así que tienes que gestionarlo tú mismo antes de que llegue a tu tienda en producción.

Dónde encajan los estándares oficiales

La propia PrestaShop publica las reglas técnicas que se supone que sigue un módulo bien construido. No necesitas implementarlas, pero son útiles para señalárselas a un proveedor, y coinciden con buena parte de lo anterior. PrestaShop publica los Estándares Técnicos de Desarrollo que se espera que siga un módulo bien construido, disciplina con los overrides, higiene de las tablas del núcleo y del rendimiento de los recursos, seguridad y compatibilidad de versiones, junto con los Estándares de Calidad detrás de la insignia Verified+ en el marketplace de Addons. Ninguno es una garantía por sí solo, muchos buenos módulos viven fuera del marketplace, y una insignia no sustituye las observaciones anteriores, pero forman una parte sensata del cuadro. Si compras a través del marketplace, nuestra guía del comprador de PrestaShop Addons explica cómo leer una ficha.

Un orden de instalación seguro, de principio a fin

En conjunto, todo esto es una única secuencia tranquila:

• Haz una copia de seguridad de tu tienda en producción: archivos y base de datos.
• Instala en una copia de staging que refleje tu plantilla, módulos y ajustes reales.
• Haz una instantánea de la tienda de staging y luego ejecuta las doce comprobaciones anteriores.
• Vigila la pestaña Red en tu página de inicio en busca de dominios nuevos y recursos cargados en todo el sitio.
• Realiza un pedido de prueba y ejercita la búsqueda, las páginas de producto y la administración.
• Desinstala y compara con tu instantánea: confirma que vuelve limpia a su estado.
• Solo entonces instala en producción, en una franja horaria tranquila, y comprueba tus páginas clave una vez más.

Preguntas frecuentes

¿Necesito un desarrollador para evaluar un módulo?

Para la mayoría de estas comprobaciones, no. Contar las peticiones de terceros, probar el checkout y ejecutar la prueba de instalar → desactivar → desinstalar son cosas que puedes hacer desde un navegador y tu back office en una copia de staging. Un par de comprobaciones, mirar en /override, listar las tablas de la base de datos, necesitan acceso a archivos o a la base de datos, que tu alojamiento o desarrollador puede facilitarte, pero nunca tienes que leer código.

Si un módulo está en el marketplace oficial de PrestaShop, ¿es automáticamente seguro?

La validación del marketplace y la insignia Verified+ son una señal real y útil: comprueban muchas de estas cosas por ti. Pero no sustituyen a observar el módulo comportarse en tu propia tienda, con tu plantilla y tus demás módulos. Muchos buenos módulos también viven fuera del marketplace. Ejecuta las comprobaciones en cualquier caso.

El módulo es gratuito. ¿Es eso una señal de alarma por sí sola?

No. Los módulos gratuitos y baratos pueden ser excelentes, y los caros pueden ser descuidados. El precio no te dice nada sobre cómo se comporta el código. La tarjeta de puntuación trata del riesgo gestionado, no del coste: un módulo gratuito que pasa estas comprobaciones es más seguro que uno de pago que las suspende.

Si solo tengo tiempo para una comprobación, ¿cuál es?

Abre la pestaña Red de tu página de inicio y cuenta los nuevos dominios de terceros tras instalar. Lleva un minuto, no necesita código y detecta el tipo más común y más dañino de módulo descuidado: el que grava cada página por una funcionalidad que rara vez verás.

Escrito así parece mucho; en la práctica es una tarde, y sale mucho más barato que la tarde que de otro modo pasarías averiguando por qué se volvió lenta tu tienda, o por qué una página no vuelve a funcionar después de quitar el módulo que la rompió. Para conocer la historia de por qué esto importa, y un relato honesto de un error que cometimos nosotros mismos, lee lo que un módulo de PrestaShop puede hacer que desinstalarlo no deshará. Y sí: ejecuta esta lista de comprobación también contra nuestros módulos. Para eso está. Si quieres que te la ejecutemos nosotros, nuestro análisis de seguridad gratuito y nuestra auditoría de rendimiento se basan exactamente en estas comprobaciones, y si prefieres que tu tienda vigile estas cosas de forma continua en lugar de solo en el momento de la instalación, ese es el cometido de Performance Revolution y Security Revolution.