> El coste de un módulo no está en instalarlo, está en cada actualización de tu tienda. Qué te ata a una versión y cómo se conecta hoy sin instalar nada. [Inicio](https://www.sendingbay.com/) · [Blog](https://www.sendingbay.com/blog) · Módulos de envíos # Lo que de verdad cuesta un módulo de envíos en tu tienda Instalar un módulo en tu tienda parece gratis: descargas un fichero, lo subes y ya tienes los envíos conectados. El coste no está en instalarlo. Está en los tres años siguientes, cada vez que actualizas la tienda y tienes que comprobar si el módulo sigue vivo. Lo que vas a encontrar ## El día que actualizas y algo deja de funcionar Casi todas las tiendas online en España corren sobre un gestor de contenidos: WooCommerce sobre WordPress, PrestaShop, y unas cuantas más. Y casi todos los servicios que conectas (pasarela de pago, facturación, envíos) llegan en forma de módulo: un paquete de código que se instala dentro de tu tienda y pasa a formar parte de ella. Funciona. Hasta que actualizas. Porque un módulo no es una pieza suelta que convive con tu tienda: es tu tienda. Corre con su mismo PHP, en su misma versión, con sus mismas dependencias. Cuando algo de eso se mueve, el módulo tiene que moverse con ello. Y si no se mueve, se rompe algo: a veces el propio módulo, a veces la pantalla en la que estaba. ## El coste que nadie te cuenta al instalarlo: la versión Este es el caro, y se ve mejor con un ejemplo real y público. PrestaShop 1.7 entró en mantenimiento de solo seguridad en cuanto salió PrestaShop 8. El [anuncio del propio proyecto](https://build.prestashop-project.org/news/2023/178-in-extended-support-phase/), en enero de 2023, no deja lugar a interpretación: a partir de ahí, los parches de 1.7.8 solo se publicarían si se reportaban fallos críticos o si hacían falta correcciones de seguridad. Y añadía cuándo terminaba eso: Ese día llegó. PrestaShop va hoy por la 9.1 estable, con la 9.2 en beta. Así que 1.7 ya no se mantiene, y quien siga ahí lo hace sin red. Ahora crúzalo con tus módulos. Cada uno se publicó para una versión concreta. Si tu tienda va por 1.7 y tu proveedor de envíos solo publica módulo para 8, no puedes actualizar sin quedarte sin envíos. Si actualizas primero y el módulo no está listo, tampoco. Te has quedado atrapada entre dos calendarios que no controlas: el de tu gestor de contenidos y el de cada proveedor que tengas instalado. Y multiplícalo. No tienes un módulo: tienes el de envíos, el de la pasarela, el de facturación, el del chat. Para actualizar la tienda los necesitas alineados a todos a la vez. ### Y la ventana no deja de estrecharse Lo de PrestaShop no es un caso raro. En el mundo de WordPress pasa lo mismo, y encima el margen se ha reducido a propósito. WooCommerce seguía una política llamada L-2: daba soporte a la última versión de WordPress y a las dos anteriores. En junio de 2023, con WooCommerce 7.8, [la cambió a L-1](https://developer.woocommerce.com/2023/02/23/revisiting-wordpress-core-support-policy-for-woocommerce/): la última y una anterior, con el objetivo declarado de reducir el riesgo de fallos y empujar a las tiendas a mantenerse al día. Es una decisión razonable desde el lado del software. Desde el lado de la tienda significa otra cosa: la ventana en la que tu montaje es oficialmente compatible se acortó a la mitad. Y WordPress publica varias versiones mayores al año, así que esa ventana se mide en meses, no en años. Súmalo a lo anterior y tienes el cuadro completo: tu gestor de contenidos avanza en su calendario, tu proveedor de envíos publica módulo en el suyo, y tú estás en medio con la obligación de que ambos coincidan. Nadie te avisa el día que dejan de hacerlo. ## Los otros tres costes - El de la actualización que no haces. El efecto práctico de lo anterior es que dejas de actualizar. Y una tienda sin actualizar acumula fallos de seguridad conocidos, que es un problema bastante mayor que el que estabas evitando. - El del rendimiento. Cada módulo añade código que se ejecuta en tu tienda, y algunos se cargan en todas las páginas aunque solo hagan falta en una. En una tienda con doce módulos instalados, el tiempo de carga ya no depende solo de tu servidor. - El del sitio donde falla. Un módulo de envíos suele tocar el carrito y el checkout, que es exactamente donde no te puedes permitir un error. Un fallo en la ficha de producto es molesto; en el paso de pago, es una venta perdida y un cliente que no vuelve. ## Por qué existía el módulo, en su defensa Conviene decir que el módulo no fue una mala idea. Fue la única idea durante años. Cuando tu tienda vive en tu propio servidor y no expone una forma estándar de que otros sistemas hablen con ella, la manera de conectar algo es meterlo dentro. El módulo era eso: la única puerta que había. Y a cambio daba algo real (control total, funcionamiento sin depender de que un tercero esté disponible) que sigue teniendo valor en algunos casos. Lo que ha cambiado no es que el módulo fuera malo. Es que ha dejado de ser la única puerta. ## Qué ha cambiado: conectar sin instalar Las plataformas de tienda llevan años abriendo formas de conectarse desde fuera, sin que haya que instalar nada dentro. La conexión se autoriza una vez, los pedidos salen hacia el servicio y los estados vuelven, y el código vive en el servicio, no en tu tienda. La diferencia práctica, para quien lleva una tienda: | | Módulo instalado | Conexión desde fuera | |---|---|---| | Dónde vive el código | Dentro de tu tienda | En el servicio | | Al actualizar la tienda | Hay que comprobar compatibilidad | No te afecta | | Si el proveedor mejora algo | Descargas y actualizas tú | Lo tienes sin hacer nada | | Si falla | Puede tumbar una página tuya | Se cae la conexión, no tu tienda | | Versiones | Necesitas la de tu versión exacta | No aplica | No es magia ni es gratis: a cambio dependes de que el servicio esté disponible, y de lo que la plataforma de tu tienda permita hacer desde fuera. Pero el reparto de riesgos cambia por completo, y sobre todo desaparece el problema de las versiones, que es el que te dejaba atrapada. ## Cinco preguntas antes de conectar cualquier cosa a tu tienda Sirven para envíos y para todo lo demás. Se hacen antes de contratar, no después: - ¿Esto se instala dentro de mi tienda o se conecta desde fuera? Es la pregunta madre. Todo lo demás depende de la respuesta. - Si se instala: ¿hay versión para la mía, y qué pasa cuando actualice? Que te digan quién publica la versión nueva y en cuánto tiempo suele estar. - ¿Toca el checkout? Si la respuesta es sí, súbele la exigencia a todo lo demás. - ¿Qué pasa el día que lo quite? Un módulo mal desinstalado deja tablas, tareas programadas y restos. Preguntarlo antes es incómodo; descubrirlo después, más. - ¿Dónde miro si algo falla? Si el problema puede estar en tu tienda o en el servicio, conviene saber de antemano quién lo mira y cómo se avisa. ## Cómo encaja esto con SendingBay [eComm](https://www.sendingbay.com/ecomm) funciona desde el navegador, sin instalar nada en tu tienda. Es la respuesta a la primera pregunta de la lista de arriba, y es también la razón por la que las tres de en medio dejan de aplicar: no hay versión que casar, no hay código nuestro en tu checkout y no hay nada que desinstalar. Lo que sí tienes que valorar es lo otro: que la conexión dependa de un servicio externo, y que lo que se pueda automatizar sea lo que tu plataforma permita hacer desde fuera. Eso es un intercambio, no una ventaja gratuita, y conviene entenderlo antes de decidir. Si quieres ver cómo queda esto dentro de una operación con varias redes, está en la guía de [trabajar con varios transportistas](https://www.sendingbay.com/blog-varios-transportistas). ## Preguntas frecuentes ### ¿Qué es un módulo de envíos? Es un paquete de código que se instala dentro de tu tienda online para conectarla con un servicio de envíos. Corre con el mismo PHP y las mismas dependencias que tu tienda, así que pasa a formar parte de ella: cuando actualizas la tienda, hay que comprobar que el módulo sigue siendo compatible. ### ¿Es mejor un módulo o una conexión desde fuera? Depende de qué riesgo prefieras. El módulo te da control y funciona sin depender de un tercero, pero te ata a versiones y vive dentro de tu checkout. La conexión externa quita el problema de versiones y no toca tu tienda, a cambio de depender de que el servicio esté disponible. ### ¿Qué pasa si actualizo mi tienda y el módulo no es compatible? Que te quedas entre dos opciones malas: no actualizar, y acumular fallos de seguridad conocidos, o actualizar y perder la función que daba ese módulo hasta que su proveedor publique la versión nueva. Por eso conviene preguntar antes quién publica esa versión y en cuánto tiempo. ### ¿PrestaShop 1.7 sigue teniendo soporte? No. El propio proyecto anunció que 1.7.8 pasaba a recibir solo parches críticos y de seguridad tras el lanzamiento de PrestaShop 8, y que ese mantenimiento terminaría al publicarse PrestaShop 9. PrestaShop va hoy por la versión 9.1 estable, así que 1.7 ya no se mantiene. ### ¿Qué versiones de WordPress soporta WooCommerce? Desde WooCommerce 7.8, en junio de 2023, sigue una política L-1: da soporte a la última versión de WordPress y a la anterior. Antes era L-2, que incluía dos anteriores. En la práctica, la ventana en la que tu tienda está oficialmente soportada se mide en meses, porque WordPress publica varias versiones mayores al año. ### ¿Cuántos módulos son demasiados en una tienda? No hay un número bueno. La señal de alarma no es la cantidad, es la dependencia cruzada: si para actualizar tu tienda necesitas que cuatro proveedores distintos publiquen versión compatible a la vez, ya tienes demasiados, sean cuatro o veinte. La pregunta útil es cuántos te impiden actualizar hoy. ### ¿Necesito instalar algo para usar SendingBay eComm? No. eComm funciona desde el navegador, sin instalar nada en tu tienda ni en tu ordenador. Eso significa que no hay módulo que casar con tu versión de PrestaShop o de WooCommerce, ni código nuestro corriendo dentro de tu checkout, ni nada que desinstalar el día que decidas dejarlo. ## Fuentes Lo de PrestaShop sale del [anuncio oficial del proyecto](https://build.prestashop-project.org/news/2023/178-in-extended-support-phase/) (5 de enero de 2023) y de su [página de versiones](https://prestashop.es/versions/), consultada el 3 de septiembre de 2026. El cambio de política de WooCommerce, del [blog de desarrollo de WooCommerce](https://developer.woocommerce.com/2023/02/23/revisiting-wordpress-core-support-policy-for-woocommerce/). Los costes de rendimiento, checkout y desinstalación son elaboración propia a partir del funcionamiento conocido de los módulos en un gestor de contenidos: no son datos de mercado y por eso no llevan cifras. ## Sin módulos que casar con tu versión eComm conecta tu tienda con las redes de transporte desde el navegador, sin instalar nada en ella. 15 días de prueba con acceso completo, sin tarjeta. [Ver qué hace eComm](https://www.sendingbay.com/ecomm)