El coste real de los módulos gratis: qué obtienes cuando no pagas nada

Las comprobaciones y fuentes de avisos que aparecen abajo están actualizadas para PrestaShop 1.6, 1.7, 8.x y la línea 9.0–9.1. Creamos y vendemos módulos para PrestaShop y gestionamos nuestras propias tiendas, así que tenemos interés en este debate; las comprobaciones de aquí funcionan igual tanto si el módulo es nuestro, de un competidor o gratuito.

Cero es la etiqueta de precio más engañosa en el software de comercio electrónico. Un módulo gratis no cuesta nada al descargarlo, y luego te va pasando la factura poco a poco: en fines de semana de actualización que se tuercen, en un proceso de compra que se rompe un sábado sin nadie a quien llamar, en un back office que se vuelve 300 ms más lento con cada instalación que nadie auditó. Después de más de una década arreglando tiendas PrestaShop, podemos decirte de dónde vienen muchos de esos incendios recurrentes: una gran parte de los errores críticos, incidentes de seguridad y actualizaciones fallidas que terminamos desenredando se remontan a un módulo instalado precisamente porque era gratis. No porque lo gratuito sea malo por naturaleza, algunos módulos gratis son excelentes, y te señalaremos los buenos, sino porque la economía de lo "gratis" produce una serie previsible de problemas en una plataforma que cambia con tanta frecuencia como PrestaShop.

Esta publicación trata de esa factura concreta: lo que pagas realmente cuando no pagas nada, en términos de PrestaShop. Si tu pregunta es más amplia, cómo distinguir un módulo de calidad de un riesgo, independientemente del precio, ese es otro tema, que cubrimos en por qué la calidad de los módulos importa más que la cantidad y la guía para compradores del marketplace PrestaShop Addons. Aquí nos quedamos con la cuestión del precio: gratis, y todo lo que viene pegado a esa palabra.

Por qué existe lo "gratis" y qué te cuesta cada tipo

"Gratis" no significa una sola cosa. Antes de evaluar el riesgo, identifica qué tipo de gratis tienes delante, porque la motivación que hay detrás de un módulo anticipa cómo envejecerá en tu tienda.

¿Y qué implica esto? El "gratis" que quieres es el oficial o el open source mantenido activamente. El "gratis" que acaba costando más en silencio es el antiguo módulo de pago abandonado: es el que más probabilidades tiene de arrastrar tanto una vulnerabilidad conocida como una dependencia rígida de una versión de PrestaShop que estás a punto de dejar atrás.

Los cinco costes ocultos, en términos de PrestaShop

1. Seguridad: PrestaShop publica las pruebas

Este es el coste que puede tumbar una tienda, no solo molestarla. Los desarrolladores de módulos de pago tienen un motivo comercial para parchear rápido: su reputación y las renovaciones dependen de ello. Un módulo gratuito abandonado no tiene a nadie al otro lado. El ecosistema PrestaShop documenta esto públicamente: la base de datos de avisos de seguridad de Friends of Presta (security.friendsofpresta.org) y la propia lista de avisos de seguridad de GitHub de PrestaShop enumeran CVE a nivel de módulo por nombre, y una proporción llamativa de las entradas de inyección SQL son módulos gratuitos o abandonados cuyos front controllers concatenaban $_GET directamente en una consulta en lugar de usar Db::getInstance()->escape() o pSQL().

La exposición práctica en PrestaShop es muy concreta: el front controller de un módulo vulnerable (cualquier cosa bajo modules/<name>/controllers/front/) es accesible por URL uses o no esa función. Un solo parámetro sin sanear ahí puede leer tus tablas ps_customer, ps_address y ps_orders: nombres, correos electrónicos, direcciones e historial de pedidos. Antes de instalar nada, busca el nombre del módulo en esas bases de datos de avisos. Lleva dos minutos y es la comprobación de mayor valor que puedes hacer.

2. Compatibilidad: la actualización es donde mueren los módulos gratis

PrestaShop avanza. Entre 1.6, 1.7, 8 y las actuales 9.0–9.1, la plataforma cambió nombres de hooks, migró partes del back office y de la arquitectura del núcleo a Symfony/Twig, mientras el front office sigue dependiendo de temas y plantillas Smarty, métodos de controlador obsoletos, y también modificó el esquema de base de datos. Todo módulo necesita trabajo continuo para mantenerse al día. Los módulos de pago lo financian; los gratuitos mantenidos por voluntarios a menudo no lo reciben.

El patrón de fallo es tan constante que podemos predecirlo: un módulo gratis instalado en 1.7 lanza errores fatales después de pasar a 8 o 9 porque sigue llamando a un método eliminado, registra o llama a hooks/API cuyo comportamiento o contexto cambió, depende de métodos del núcleo eliminados u obsoletos, o incluye un .tpl para el antiguo front office de Smarty. Lo encuentras en tres sitios: un 500 en el front office, una pantalla blanca en Modules > Module Manager, o una rotura silenciosa en la que el hook simplemente nunca se renderiza. En ese punto tus opciones son: encontrar un reemplazo, pagar a alguien para portar el código, o congelar tu tienda en una versión antigua y cada vez menos segura de PrestaShop. Las tres cuestan más de lo que habría costado un módulo mantenido. (Esta es también la razón por la que estar preparado para actualizar es una cuestión de estrategia de plataforma, no solo de módulos; cubrimos las compensaciones más amplias en por qué elegimos PrestaShop.)

Un hábito defensivo que no cuesta nada: un módulo que quiere sobrevivir a los cambios de versión de PrestaShop protege sus llamadas en lugar de asumir que un método existe. La misma protección, leída desde el otro lado, es cómo puedes hacer una comprobación básica del módulo por tu cuenta: si su código llama a métodos del núcleo sin condiciones, esa es la línea que provocará el fatal en la versión que los eliminó.

// What version-aware module code looks like – and the absence of this
// is what produces the post-upgrade 500. PrestaShop exposes its own
// version, so a careful module checks before it calls:
if (version_compare(_PS_VERSION_, '8.0.0', '>=')) {
    // 8.x / 9.x code path
} else {
    // 1.7.x fallback
}

// Guard a method that may not exist on the running core, rather
// than calling it blindly and fataling on the version that removed it:
if (method_exists('SomeCoreClass', 'someMethod')) {
    SomeCoreClass::someMethod();
}

3. Soporte: tú eres el equipo de soporte

Gratis significa que no hay obligación de soporte, y esa cláusula pesa mucho. Cuando el módulo se comporta mal, tus opciones son un readme.md escueto, un hilo de foro que esperas que alguien responda, o leer tú mismo el código fuente. Para el propietario de una tienda que no es desarrollador, "gratis" se convierte entonces en la factura de un freelance para depurarlo; a menudo, con una tarifa por hora que, en uno o dos incidentes, supera lo que cuesta directamente un módulo de pago con soporte. Lo que compraste por nada te está cobrando por horas, solo que a través de otra persona.

4. Rendimiento: el coste que no ves hasta que perfilas

Los módulos gratis suelen publicarse sin la presión de revisión de código y feedback de clientes que detecta el código lento, así que estadísticamente es más probable que arrastren los pecados clásicos de rendimiento en PrestaShop:

• Consultas dentro de bucles. Un módulo que ejecuta una consulta Db por producto en una página de categoría con 50 productos lanza 50 consultas donde bastaría un JOIN; se ve en el perfilador de depuración de Advanced Parameters > Performance y en SHOW PROCESSLIST bajo carga.
• Hooks registrados de más. Engancharse a displayHeader, displayFooter y actionFrontControllerSetMedia cuando la función solo necesita uno significa que su código se ejecuta en todas las páginas, incluidas aquellas en las que no hace nada.
• Sin caché. Recalcular los mismos datos en cada petición en lugar de usar Cache o una tabla: aceptable en una demo, caro con tráfico real.
• Abuso de overrides. Este es el peor infractor, y es específico de PrestaShop; lo vemos abajo.

[SCREENSHOT: pie del perfilador de depuración de PrestaShop (activa el modo Debug y luego carga una página del front office) mostrando el recuento de consultas y el desglose del tiempo de carga por página. Un módulo que ejecuta consultas dentro de un bucle aparece aquí como un recuento de consultas que aumenta con el número de productos de la página.]

Un solo módulo gratis escrito sin cuidado puede añadir unos cientos de milisegundos al tiempo hasta el primer byte. Matizamos la cifra exacta a propósito, depende por completo del módulo y de tu tráfico, pero la dirección no está en duda, y las páginas más lentas te cuestan tanto en conversión como en las señales de experiencia de página que ponderan los motores de búsqueda. Si la carga de módulos es tu síntoma, lecciones de 10 años de desarrollo con PrestaShop profundiza en lo que realmente mueve la aguja.

5. La trampa de los overrides: el asesino silencioso de los módulos gratis en PrestaShop

Este punto merece su propio apartado porque es donde los módulos gratis para PrestaShop hacen un daño que no notarás hasta que sea demasiado tarde. PrestaShop permite que un módulo deje overrides de clases en /override/classes/ y /override/controllers/, con una caché de mapa de clases generada (cache/class_index.php, o var/cache/<env>/class_index.php en 1.7+) que indica al núcleo qué overrides cargar. Un módulo bien construido usa hooks y toca los overrides con moderación; uno gratuito hecho con prisas sobreescribe clases del núcleo enteras. Las consecuencias son específicas:

• Dos módulos no pueden sobrescribir el mismo método. Instalas un segundo módulo que sobrescribe Product::getPrice() y la segunda instalación falla en silencio o pisa la primera: un conflicto que aparece como "la función simplemente no funciona" sin error.
• Los overrides bloquean la actualización del núcleo. 1-Click Upgrade y la migración a Symfony se atascan con overrides en conflicto; acabas reconciliando archivos manualmente antes de poder cambiar de versión.
• La desinstalación no siempre limpia. El uninstall() de un módulo descuidado deja archivos de override huérfanos, así que el fantasma de un módulo que eliminaste hace meses sigue ejecutándose en cada página.

¿Y qué implica esto? Los conflictos de overrides son la razón más común por la que una tienda PrestaShop se rompe "misteriosamente" después de acumular unos cuantos módulos gratis, y son invisibles hasta que vas a buscarlos en /override/ y /var/cache/. Este es el argumento más fuerte para poseer y entender el código que ejecuta tu tienda, que es el caso más amplio que planteamos en comercio electrónico open source: por qué poseer tu código importa.

Auditar lo que ya hay en tu tienda: solo lectura

Si los módulos gratis ya se han acumulado en una tienda que heredaste o construiste durante años, no tienes que adivinar. Unas cuantas comprobaciones seguras sacan a la luz las tres cosas que muerden: overrides huérfanos, módulos desactivados pero aún presentes, y los archivos fantasma de overrides que sobreviven a una desinstalación. Nada de esto cambia nada: todo es de solo lectura.

Primero, los archivos de override que viven realmente en disco. No hay una tabla de base de datos para esto, así que revisa el sistema de archivos bajo la raíz de tu tienda (por SSH o con el gestor de archivos de tu alojamiento):

# Every core class/controller something has overridden.
# Empty output is the healthy result.
find override/classes override/controllers -name '*.php' -not -name 'index.php' 2>/dev/null

# Cross-check: which overrides the core actually loads (1.7+).
# Files on disk that AREN'T in here are the orphaned ghosts.
grep -o "'[A-Za-z]*' =>" var/cache/prod/class_index.php 2>/dev/null | sort -u

Luego, desde la base de datos (ejecútalo en Advanced Parameters → SQL Manager, solo lectura, sin escrituras), lista todos los módulos instalados y si están realmente activados. Las filas desactivadas que todavía tienen archivos en disco son habituales, y los front controllers de un módulo desactivado pueden seguir siendo accesibles por URL:

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

Un archivo de override en disco que no aparece referenciado en class_index.php, o un módulo desactivado cuya carpeta sigue en modules/, es exactamente el tipo de resto que se ejecuta en cada página o esconde una vulnerabilidad conocida. Una vez que puedes verlo, eliminarlo pasa a ser una decisión en lugar de un misterio.

Cuándo lo gratis es la respuesta correcta

Nada de esto significa "nunca instales un módulo gratis". Significa instalar los adecuados con los ojos abiertos. Lo gratis es realmente la opción correcta cuando:

• Es oficial. Los módulos incluidos con PrestaShop o publicados por el equipo de PrestaShop (los que llevan prefijo ps_: ps_searchbar, ps_emailsubscription, ps_facetedsearch) se mantienen como parte de la plataforma y se prueban con cada versión.
• El proyecto open source está vivo. Abre el repositorio de GitHub y tómale el pulso: commits recientes, más de un colaborador, issues que reciben respuesta, releases etiquetadas para versiones actuales de PrestaShop. Un repositorio sano es una señal fiable.
• Hace una sola cosa pequeña. Un módulo que añade un campo concreto o ajusta una visualización tiene mucha menos superficie para errores que una suite que "lo hace todo". Lo pequeño y enfocado envejece bien.
• Se ha reseñado recientemente. En el marketplace Addons, lee las reseñas más nuevas, no la media histórica: un módulo que ganó cinco estrellas en 2021 puede estar acumulando ahora reseñas de una estrella por "se rompió en 8.x".

La lista de comprobación antes de instalar (gratis o de pago)

Pasa todo módulo, también los de pago, por esta lista antes de que toque tu tienda:

• Fecha de última actualización. Nada que lleve más de un año sin tocarse. Compruébalo antes, no después.
• Compatibilidad de versión explícita. "Funciona con 1.7+" no significa "funciona con 9". Exige que aparezca la versión real y confírmala contra tu instalación en Advanced Parameters > Information.
• Avisos de seguridad. Busca el nombre del módulo en security.friendsofpresta.org y en los avisos de GitHub de PrestaShop.
• Huella de overrides. Descomprímelo y mira en override/. Los overrides sobre Product, Cart, Order o FrontController son una señal amarilla: pregunta si los hooks podrían haber hecho el trabajo.
• Higiene de consultas. Si puedes leer PHP, usa grep en los controladores para buscar $_GET/$_POST sin procesar dentro de cadenas SQL sin pSQL() ni conversiones (int). Ese es el patrón de inyección SQL.
• Copia de seguridad primero, en una copia de staging. Base de datos y archivos. Prueba la instalación en un clon, no en producción. Si se rompe, restauras en lugar de explicar una caída a tus clientes.

La matemática real entre gratis y de pago

Quitando la filosofía, es un problema aritmético. Un módulo gratis se rompe durante una actualización. Tú, o el freelance que contratas, pasáis una tarde diagnosticando un conflicto de overrides, portando un hook obsoleto y volviendo a probar el proceso de compra. Aplica cualquier tarifa local realista por hora a esa tarde y el módulo "gratis" ya ha costado más de lo que habría costado uno de pago mantenido, en un solo incidente; y estos incidentes se repiten cada vez que PrestaShop lanza una versión mayor. Deliberadamente no damos aquí una cifra en dólares porque depende de la tarifa de tu desarrollador y de lo mal que se rompiera el módulo; haz las cuentas con tus propios números. La conclusión se mantiene con independencia de los números que pongas.

Al comparar un módulo de pago con uno gratuito, revisa la licencia, el periodo de actualizaciones y las condiciones de soporte. El precio de compra por sí solo no indica qué ayuda estará disponible después. En mypresta.rocks, los módulos premium incluyen tres meses de soporte y actualizaciones. Hay extensiones de pago y la licencia del módulo continúa después de terminar el soporte. Los módulos gratuitos no incluyen soporte gratuito. Agradecemos los avisos de errores de cualquier usuario porque nos ayudan a mejorar el código.

Preguntas frecuentes

¿Cómo compruebo si un módulo gratis tiene vulnerabilidades de seguridad conocidas?

Busca el nombre técnico del módulo (el nombre de su carpeta, por ejemplo somemodule) en la base de datos de avisos de Friends of Presta en security.friendsofpresta.org y en los avisos de seguridad de GitHub de PrestaShop antes de instalarlo. Los CVE a nivel de módulo aparecen allí por nombre, y una gran parte de las entradas de inyección SQL son módulos gratuitos o abandonados. Es una comprobación de dos minutos y la de mayor valor que puedes hacer, porque un front controller vulnerable bajo modules/<name>/controllers/front/ es accesible por URL uses o no uses nunca esa función.

Un módulo gratis se rompió después de actualizar PrestaShop: ¿cuáles son mis opciones reales?

Tres, y todas cuestan más de lo que habría costado un módulo mantenido: encontrar un reemplazo compatible con tu nueva versión, pagar a un desarrollador para portar el código del módulo roto, o congelar tu tienda en la versión antigua de PrestaShop (lo que te deja en una plataforma cada vez menos segura; no es realmente una opción a largo plazo). El fallo suele ser un método del núcleo eliminado, un hook cambiado o un antiguo .tpl de Smarty, y aparece como un 500 en el front office, un Module Manager en blanco o un hook que silenciosamente nunca se renderiza. La lección está antes: comprueba la compatibilidad de versión explícita antes de actualizar, no después.

¿Cómo puedo saber si un módulo usa overrides y por qué importa?

Descomprime el módulo y mira en su carpeta override/ antes de instalarlo. Los archivos bajo override/classes/ o override/controllers/, especialmente si tocan Product, Cart, Order o FrontController, son una señal amarilla. Importa porque dos módulos no pueden sobrescribir el mismo método (el segundo falla en silencio o pisa el primero), los overrides bloquean 1-Click Upgrade y una desinstalación descuidada deja archivos de override huérfanos ejecutándose en cada página. En una tienda existente, cruza los archivos en disco con var/cache/prod/class_index.php para encontrar los huérfanos.

¿Son seguros los módulos oficiales ps_ para depender de ellos?

Sí: los módulos con prefijo ps_ incluidos con PrestaShop o publicados por el equipo de PrestaShop (ps_searchbar, ps_emailsubscription, ps_facetedsearch y similares) se mantienen como parte de la plataforma y se prueban con cada versión. Son el caso más claro de "lo gratis es la respuesta correcta". Ten en cuenta que esto se refiere específicamente a los módulos oficiales incluidos, no a los módulos gratis en general: que un módulo de la comunidad sea gratuito no dice nada por sí solo sobre su mantenimiento.

¿Pagar por un módulo siempre es mejor que usar uno gratis?

No, y estaríamos intentando venderte algo si dijéramos lo contrario. Lo gratis es realmente correcto para los módulos oficiales ps_, para un proyecto open source sano (commits recientes, varios colaboradores, releases etiquetadas para versiones actuales) y para un módulo pequeño que hace una cosa concreta. La regla honesta no es "de pago gana a gratis", sino "mantenido gana a abandonado". Lo que pagas en un buen módulo de pago son los próximos años de parches de compatibilidad, una respuesta de seguridad cuando aparece un aviso y alguien que contesta cuando se rompe; cuando un módulo gratis ya ofrece un mantenimiento equivalente, el gratuito es la decisión correcta.