Preparar un módulo comercial para la compatibilidad con PrestaShop 9.2

La afirmación de compatibilidad de un módulo comercial es una promesa al comerciante sobre una combinación de software y comportamiento. «Se instala en PrestaShop 9.2» es una afirmación mucho más limitada que «admite el proceso de compra nativo, las páginas administrativas migradas y el funcionamiento multitienda».

Para la versión 9.2 RC1 disponible el 26 de septiembre de 2026, los proveedores deben describir con precisión las pruebas de la versión candidata. Superar una evaluación RC no justifica declarar compatible una versión estable aún no publicada. Este artículo explica cómo validar un módulo comercial existente, no cómo crear su estructura inicial.

Si el módulo interviene en el pago o la entrega, incluya el plan de QA del One Page Checkout en la matriz de compatibilidad en vez de probar solo la instalación.

Defina la afirmación de compatibilidad antes de diseñar la matriz

Anote las capacidades que el módulo ofrece realmente y las combinaciones que se espera que utilicen los clientes. Un módulo de pago tiene recorridos críticos distintos de los de un módulo de enriquecimiento del catálogo. Una extensión exclusiva del Back Office quizá no necesite una matriz completa de temas de tienda, mientras que una extensión del proceso de compra sí la necesita.

Separe el soporte obligatorio de la compatibilidad opcional. Si el módulo solo admite un recorrido concreto del proceso de compra actualmente, indíquelo expresamente. Si no se admite multitienda, no deje que la instalación en una tienda multitienda sugiera lo contrario.

Enumere las dependencias exactas que respaldan la afirmación: núcleo, entorno de ejecución, módulos nativos, tema cuando corresponda y versión de integración del servicio externo. Mantenga visibles las dependencias experimentales en vez de incluirlas en un amplio intervalo de versiones.

Una afirmación útil para el hito actual es «probado con 9.2.0-rc.1 con estas combinaciones y limitaciones especificadas». Explica a los primeros probadores qué pruebas existen sin implicar que la versión candidata esté lista para producción.

Construya la matriz en torno al riesgo, no a todas las permutaciones posibles

Empiece por los efectos del módulo en el negocio. ¿Qué operación puede modificar dinero, existencias, datos de clientes o el ámbito de tienda? ¿Qué puntos de extensión han cambiado en la versión candidata? ¿Qué dependencias externas pueden producir resultados tardíos o duplicados?

Use una matriz que relacione cada riesgo con pruebas:

Después seleccione combinaciones representativas. Pruebe las versiones mínima y máxima del entorno de ejecución que afirme admitir, con las combinaciones de dependencias más propensas a revelar diferencias. Añada casos específicos donde el código se bifurque según la versión de la plataforma.

No afirme que una matriz por pares demuestra todas las combinaciones. Es una estrategia de cobertura cuyas limitaciones deben permanecer documentadas.

Trate el proceso de compra y las páginas migradas como áreas de integración independientes

Para un módulo del proceso de compra, verifique tanto el flujo de compra admitido como las interacciones dependientes de pago o transportista. Pruebe la actualización de página, el cambio de dirección, el envío fallido y la inicialización repetida. Un módulo que solo reaccione a la carga inicial de la página puede comportarse de forma distinta en el flujo nativo de una sola página.

Para Hummingbird o un tema hijo, registre la revisión del tema y las modificaciones pertinentes. El contrato de plantillas y DOM del proceso de compra es una dependencia concreta de integración, no una simple preferencia de estilo. Contrato oficial del tema para el proceso de compra.

Para extensiones administrativas, identifique las páginas migradas y los indicadores activos. Pruebe el guardado previsto del formulario, el filtro de cuadrícula y el límite de permisos de empleados en cada recorrido admitido. No use una prueba básica realizada solo como SuperAdmin como prueba de los flujos de trabajo del personal habitual.

Verifique que el código de compatibilidad no se ejecute dos veces cuando se registren tanto los hooks antiguos como los nuevos. La ausencia de errores fatales no basta si una acción produce escrituras o notificaciones duplicadas.

Un proveedor debe poder relacionar cada ajuste de compatibilidad con un caso fallido o un cambio documentado del contrato. Evite reescrituras amplias cuyo beneficio no pueda demostrarse.

Revise las suposiciones del entorno de ejecución y los servicios específicos de versión

La compatibilidad del entorno de ejecución incluye código que solo se ejecuta en etapas poco habituales del ciclo de vida: instalación, desinstalación, tareas programadas, gestión de errores y callbacks del proveedor. Ejercite esos recorridos bajo las versiones del entorno incluidas en el intervalo de soporte declarado.

El trabajo de 9.2 añade soporte para definiciones de servicios en PHP y archivos de servicios YAML específicos de versión. Esto ofrece una forma de adaptar la conexión de servicios manteniendo el soporte de versiones anteriores, pero debe verificarse el comportamiento de carga seleccionado en la implementación correspondiente. Cambio de configuración de servicios específica de versión.

Si adopta ese mecanismo, pruebe el contenedor de servicios en cada rama de plataforma que afirme admitir. Confirme qué archivo se selecciona y que ningún servicio exista solo porque la caché local de un desarrollador conservó una definición antigua. No asuma que se fusionarán todos los archivos alternativos de servicios.

Para afirmar compatibilidad con PHP 8.5, compruebe la sintaxis y ejecute las pruebas pertinentes en PHP 8.5. La compatibilidad del núcleo no valida automáticamente las dependencias de un módulo. Las notas de la versión RC enumeran correcciones relacionadas con PHP 8.5, lo que refuerza la necesidad de pruebas específicas de versión en vez de una deducción general. Registro de cambios de la versión candidata.

Inspeccione también las suposiciones sobre conjuntos finitos de valores. El cambio de la condición del producto en 9.2 añade valores que un módulo con una lista de permitidos codificada de forma fija puede rechazar o etiquetar mal. Si su módulo lee las condiciones, compare sus valores admitidos con la enumeración real de la versión candidata y defina el comportamiento ante un valor desconocido. Cambio de la condición del producto.

Pruebe la continuidad de los datos de clientes durante las operaciones del ciclo de vida

Instale la versión publicada del módulo en una base desechable, cree datos representativos y después aplique la actualización candidata del módulo mediante el mecanismo admitido. Verifique que los valores existentes sigan teniendo sentido y que los nuevos valores predeterminados no sobrescriban ajustes deliberados.

Repita el intento de actualización cuando el ciclo de vida lo permita. Una actualización parcialmente completada no debe crear definiciones, índices ni registros de negocio duplicados. Registre cómo detecta y recupera el módulo un paso interrumpido.

Pruebe la desactivación y reactivación por separado de la desinstalación. Los comerciantes suelen desactivar un módulo mientras diagnostican otro problema; esa acción debe seguir la política de conservación documentada. Si la desinstalación puede eliminar datos, explicite la política y verifíquela con registros ficticios.

Para Extra Properties o tablas personalizadas, incluya variaciones de tienda e idioma. Una migración que solo conserve la tienda predeterminada puede parecer correcta en un conjunto de datos sencillo mientras pierde la información importante para un cliente multitienda.

No use una limpieza destructiva solo para que el paquete se reinstale limpiamente durante el desarrollo. El comportamiento del ciclo de vida comercial debe reflejar las expectativas de los clientes y la política publicada del módulo.

Valide el artefacto distribuible

Ejecute la batería de aceptación sobre el archivo que descargarán los clientes. Una copia de desarrollo puede contener recursos generados, dependencias de terceros o archivos de configuración ausentes del módulo empaquetado.

Inspeccione la estructura del archivo y los ficheros necesarios. Confirme que se instala mediante el Back Office admitido o el flujo de despliegue y que sus recursos se cargan sin depender de herramientas de desarrollo. Conserve pruebas y artefactos de compilación solo donde el proceso de distribución los requiera intencionadamente.

Compruebe que no se incluyan credenciales, archivos de entorno local ni extractos de producción. Es una comprobación concreta de empaquetado, no un motivo para añadir material de cumplimiento irrelevante a la interfaz de usuario del producto.

Registre la suma de comprobación del artefacto o el identificador de compilación junto con los resultados de las pruebas. Si se reconstruye un paquete después de validarlo, determine si el contenido cambió y vuelva a ejecutar las comprobaciones afectadas. Una etiqueta de versión por sí sola no distingue dos archivos diferentes con el mismo número.

Dé a cada limitación de soporte un límite verificable mediante una prueba

Una limitación debe identificar el comportamiento excluido, no limitarse a decir que algunas funciones no se admiten. Si una extensión admite el recorrido administrativo antiguo pero no el migrado, registre la página afectada y la prueba que demuestra la carencia. Si una integración de pago excluye una interacción concreta de una sola página, nombre esa interacción y la alternativa admitida.

Evite presentar una solución mediante un indicador como una garantía permanente. Puede ser útil durante la evaluación de la versión candidata, pero una versión futura puede retirar el recorrido antiguo. Asigne un responsable de la adaptación y haga seguimiento de la condición que eliminará la limitación.

Para dependencias externas, conserve la declaración del proveedor específica de versión junto con sus propios resultados. Si más adelante el proveedor retira el soporte o cambia un contrato, el registro de pruebas deja claras las combinaciones de clientes que deben revisarse.

Esto también mejora la clasificación de incidencias de soporte. Un incidente dentro de la matriz declarada es una posible regresión. Uno fuera de ella también merece investigarse, pero no debe confundirse con una combinación ya validada.

Explique la distinción en términos útiles para los comerciantes: operación, versiones y efecto práctico. Los nombres internos de las baterías de pruebas ayudan a los ingenieros, pero no deben ser la única explicación que reciba un cliente.

Publique limitaciones que ayuden a los comerciantes a decidir

Las notas de versión deben indicar qué comportamiento se admite por primera vez, qué combinaciones se probaron y qué sigue excluido. «Diversas mejoras de compatibilidad» dice poco al comerciante sobre si está cubierto su proceso de compra o su flujo multitienda.

Proporcione una plantilla breve de reproducción a los primeros probadores: versiones del núcleo, módulo y tema, indicadores activos, contexto de tienda y secuencia de acciones. Esto reduce los intercambios de soporte dedicados a reconstruir el entorno.

Cuando se publique oficialmente la versión estable 9.2, compare sus cambios finales con la versión candidata validada y vuelva a ejecutar la parte afectada de la matriz antes de ampliar la declaración de soporte. Superar las pruebas de una candidata es una preparación valiosa, pero sigue vinculada al artefacto candidato.

Una afirmación sólida de compatibilidad es, por tanto, un conjunto de pruebas: un contrato de soporte delimitado, casos de regresión específicos, un archivo distribuible verificado y limitaciones honestas. Eso ayuda a los comerciantes a decidir un despliegue y da al proveedor un límite de soporte manejable.

Para conocer el contexto de la plataforma subyacente, consulte nuestra guía de desarrollo de módulos PrestaShop 9 y aplique las comprobaciones específicas de versión anteriores a la instalación que esté evaluando.

Al elegir una extensión, explore los módulos PrestaShop 9 de PrestaSuite y contraste el soporte de versiones y los requisitos de integración documentados con sus propios resultados de pruebas.