Migración de páginas a Symfony en PrestaShop 9.2: qué revisar de nuevo

Una extensión del Back Office puede sobrevivir visualmente a una migración de página y aun así fallar funcionalmente. Su campo puede aparecer pero no guardarse nunca. Su columna de cuadrícula puede mostrar valores mientras los filtros usan la consulta equivocada. Su enlace de navegación puede funcionar para un administrador y fallar para el personal habitual.

PrestaShop 9.2 continúa la migración de páginas administrativas. El trabajo concreto del proyecto incluye Acceso rápido, la lista de Países y las traducciones del cuerpo de los correos. Son cambios de páginas específicos, no una nueva arquitectura general de módulos. Migración de Acceso rápido, Trabajo en la lista de Países, Migración de la traducción del cuerpo de los correos.

Para las pruebas de RC1 a fecha de 26 de septiembre de 2026, identifique la ruta de página activa y la compilación exacta de la extensión. La revisión siguiente se centra en cómo una personalización existente cruza los límites de la página migrada.

Registre la implementación activa mediante el flujo de pruebas de indicadores de funcionalidades; una personalización puede comportarse de forma distinta en las rutas antigua y migrada.

Relacionar cada personalización con el contrato del que depende

Empiece por el comportamiento de negocio: un campo personalizado en un formulario de país, un enlace en Acceso rápido, un filtro adicional de cuadrícula o un flujo de traducción. Después identifique cómo lo implementa el módulo.

Las posibles dependencias incluyen un hook del constructor de formularios, un hook del gestor de formularios, una definición de cuadrícula, una consulta de cuadrícula, un nombre de ruta, un bloque de plantilla o un selector JavaScript. Estas dependencias tienen modos de fallo diferentes. Tratarlas todas como «un problema de hook» ralentiza el diagnóstico.

Lea el código fuente del módulo y registre dónde se declara cada dependencia. Busque los identificadores, nombres de plantillas y selectores de la página afectada. Use el código fuente de la candidata instalada para verificar los puntos de extensión correspondientes; no deduzca un nombre de hook simplemente poniendo en mayúsculas la etiqueta de la página.

Un inventario útil tiene este aspecto:

Este inventario debe ser lo bastante pequeño para revisarlo. Si una personalización ya no responde a una necesidad del negocio, elimínela mediante un cambio de mantenimiento deliberado en vez de conservarla automáticamente.

Seguir un valor del formulario durante todo el ciclo

Una integración de formulario tiene varias etapas: datos iniciales, construcción del formulario, validación, gestión del comando o la persistencia y siguiente lectura. Una extensión que solo interviene en una etapa puede parecer funcional hasta que un usuario recarga.

Para una personalización relacionada con países, elija un valor de prueba válido y anote su almacenamiento y alcance previstos. Cargue el formulario, cambie el valor, envíelo y vuelva a abrir la misma entidad. Repita después con un valor no válido y confirme que el valor válido anterior permanece intacto.

Compruebe si el módulo lee parámetros brutos de solicitud que pertenecían a la página antigua. Un formulario migrado puede usar una estructura de datos distinta. Evite resolver ese desajuste aceptando entradas arbitrarias sin pasar por la validación del formulario.

Si el módulo modifica un constructor de formularios, verifique que también se integra con la etapa de persistencia correcta. Un campo renderizado por un hook genérico no pasa automáticamente a formar parte de la operación de dominio de la página. Del mismo modo, un gestor no debe escribir un campo que no se haya enviado realmente en la acción actual.

Inspeccione las ediciones parciales y los campos deshabilitados. Un valor ausente puede significar «no forma parte de este envío», no «borra el valor guardado». Documente la distinción antes de cambiar el gestor.

Probar las cuadrículas como consultas, no solo como tablas

Una columna personalizada de cuadrícula suele tener una modificación de consulta asociada. Verifique conjuntamente la consulta de datos y cualquier consulta de recuento. Una unión que multiplica filas puede volver incoherente la paginación aunque la primera página visible parezca plausible.

Use datos de prueba que revelen duplicaciones: más de una fila relacionada, distintas asociaciones de tienda y un registro sin valor relacionado. Pruebe el filtro y el orden usados por el personal. Compare los identificadores de registro esperados con el resultado renderizado.

No añada una unión sin límites solo para que aparezca una columna. Comprenda los alias y la estructura de consulta de la cuadrícula migrada en el código fuente de la candidata. Un alias copiado de una implementación antigua puede referirse a otra tabla o a ninguna.

Inspeccione también las acciones de fila después de aplicar un filtro. La acción debe dirigirse a la entidad prevista y conservar un contexto de retorno razonable. Una acción sin filtrar correcta no demuestra que la navegación filtrada funcione bien.

Para la migración de Países, un caso de aceptación útil combina filtrado de listas, una operación de estado permitida y un resultado actualizado. El objetivo es verificar la integración del módulo con la lista migrada, no reproducir toda la batería de tests del núcleo de la página.

Las rutas, accesos directos y derechos de empleados forman un único límite

Acceso rápido es un ejemplo especialmente claro de una pequeña función de interfaz con varias dependencias. Un acceso directo tiene destino, texto visible y un empleado que lo sigue. Un cambio de ruta puede afectar al destino; un cambio de permisos puede afectar a si la operación se permite.

Genere los enlaces administrativos mediante el mecanismo de enrutamiento adecuado y compatible de la versión instalada. Evite conservar una URL antigua codificada de forma rígida solo porque sigue funcionando en la sesión de un administrador.

Pruebe un acceso directo con un empleado que tenga los permisos usados en el trabajo habitual. Una cuenta SuperAdmin puede ocultar asignaciones de permisos ausentes. Pruebe también una operación denegada y confirme que un enlace personalizado no crea una omisión de autorización.

Si el módulo guarda un destino, decida si representa una ruta de negocio estable o una URL transitoria con información de sesión. Esta última no debe convertirse en un acceso directo permanente por una copia accidental.

Cuando un enlace antiguo deje de ser válido, documente el contrato de sustitución en las notas de actualización del módulo. No obligue al personal a descubrir el cambio mediante fallos de navegación sin explicación.

Las páginas de traducción necesitan pruebas específicas por idioma

Para una extensión que intervenga en las traducciones del cuerpo de los correos, distinga el idioma de la interfaz del empleado, el idioma editado y el idioma del mensaje generado para el cliente. Pueden ser diferentes.

Use dos traducciones de prueba visiblemente distintas. Guarde una, cambie a la otra y verifique que la primera permanece igual. Después renderice el mensaje de prueba pertinente en un receptor de correo mediante el flujo compatible. La recarga del formulario demuestra persistencia; el mensaje renderizado demuestra que el consumidor previsto la usó.

Compruebe la selección de plantillas específica del módulo y las suposiciones de respaldo frente a la página migrada. Una personalización que busca un elemento DOM antiguo concreto puede dejar de activarse aunque los datos de traducción sigan siendo correctos.

Prefiera los puntos de extensión compatibles de formularios y plantillas a sustituciones frágiles de scripts de toda la página. Si JavaScript es necesario, vincúlelo a un elemento o ciclo de vida documentado y asegúrese de que navegar repetidamente no registra dos veces el mismo comportamiento.

No trate las etiquetas traducidas como prueba de que el contenido traducido se guarda correctamente. Son rutas distintas y requieren comprobaciones separadas.

Comparar el comportamiento de la extensión en las rutas pertinentes

Cuando la candidata exponga rutas antigua y migrada, ejecute el mismo caso de negocio en cada una y registre la ruta activa. El artículo de indicadores explica cómo gestionar esa comparación; este artículo se centra en el contrato de extensión que cambia.

Un adaptador de compatibilidad debe elegir la integración adecuada sin ejecutar ambas escrituras. Si un módulo se suscribe a eventos antiguos y nuevos para un soporte transitorio, verifique que una acción del usuario provoca una sola operación de persistencia prevista.

Mantenga acotados los fallos. «El módulo es incompatible con Symfony» no es un diagnóstico útil. «El campo personalizado se renderiza mediante el nuevo hook del constructor pero el gestor sigue leyendo la clave de solicitud antigua» identifica un límite que puede corregirse.

Conserve la revisión exacta de la candidata al comunicar incidencias al proyecto. La documentación de la rama puede cambiar mientras el archivo de la versión permanece igual. Una referencia de código fuente de una rama posterior no demuestra cómo se comporta un paquete anterior.

Revisar un fallo silencioso antes de añadir código de respaldo

Considere un campo personalizado que aparece en la página migrada pero vuelve a su valor antiguo después de guardar. Capture primero los datos enviados del formulario y después siga la ruta compatible del gestor en un entorno privado de pruebas. Determine si el valor fue rechazado, ignorado, transformado o guardado con otro alcance.

No añada inmediatamente una segunda escritura directa en la base de datos después de enviar el formulario. Eso puede ocultar la integración ausente mientras evita la validación, los eventos o el comportamiento transaccional. Corrija el límite responsable de la pérdida del valor y añada un test de ciclo completo que falle si vuelve a ocurrir.

Del mismo modo, si una columna de cuadrícula está vacía, distinga un valor ausente en la consulta de un desajuste de renderizado. Un respaldo de plantilla que muestre un valor predeterminado puede hacer parecer reparada la página mientras oculta datos ausentes. Use datos de prueba cuyo valor correcto difiera visiblemente del respaldo.

Estas investigaciones mantienen pequeñas las adaptaciones de compatibilidad. Sustituyen una suposición concreta rota en vez de superponer otra ruta de persistencia o renderizado.

Entregar una adaptación respaldada por pruebas

Antes de publicar la extensión adaptada, pruebe su paquete distribuible real en una instalación candidata limpia. Los archivos de desarrollo pueden ocultar recursos ausentes, definiciones de servicios obsoletas o exclusiones del empaquetado.

El registro de aceptación debe nombrar las páginas afectadas, los indicadores pertinentes, los roles de empleados y las operaciones que pasaron. Indique explícitamente cualquier ruta no compatible. Si una solución temporal requiere una página antigua, asígnele un responsable y una condición de retirada.

Las migraciones de páginas de PrestaShop 9.2 favorecen límites de extensión precisos. Siga los datos a través de los formularios, verifique las cuadrículas como consultas y trate conjuntamente las rutas y los permisos. Esto produce una adaptación más pequeña y fiable que reescribir un módulo según suposiciones sobre la interfaz nueva.

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 la compatibilidad de versiones y los requisitos de integración documentados con sus propios resultados de pruebas.