PrestaShop 9.2: novedades de la versión RC1

PrestaShop 9.2 ofrece a comerciantes y desarrolladores varias novedades que evaluar: un flujo de compra nativo en una sola página, un sistema común de campos adicionales para entidades y un asistente de IA en la interfaz de administración. La pregunta útil es cuáles de estos cambios afectan al trabajo que realmente realiza tu tienda.

Según la comprobación del 26 de septiembre de 2026, el hito disponible es 9.2.0-rc.1, publicado el 21 de septiembre. Sigue siendo una versión preliminar para pruebas aisladas. Una versión candidata no es una recomendación para sustituir una instalación de producción que funciona. Anuncio oficial de RC1.

Este artículo relaciona las novedades de 9.2 con decisiones de negocio. Para los cambios subyacentes de la plataforma, empieza por nuestra visión general de PrestaShop 9. Los ejemplos prácticos siguientes son ejercicios de evaluación propuestos, no resultados obtenidos.

Para examinar con más detalle el flujo de compra, revisa cómo el One Page Checkout nativo cambia la compra antes de elegir los casos de aceptación del checkout.

Interpretar la versión en tres niveles distintos

Un número de versión por sí solo no describe todo lo instalado en una tienda. Distingue la versión del núcleo, los módulos incluidos y las capacidades activadas. Un comerciante que pruebe un paquete de distribución puede encontrar servicios ausentes de una compilación personalizada del núcleo. Otro probador puede tener el mismo núcleo, pero una revisión distinta del módulo de checkout o una selección diferente de opciones experimentales.

Registra esas diferencias antes de comparar capturas o informar de un problema. Una nota de evaluación útil identifica el archivo, la versión del núcleo, la del tema, las de los módulos relevantes y las banderas de funciones activadas. Así se evita que una discusión sobre el «comportamiento de 9.2» mezcle varias instalaciones distintas.

Distingue también la madurez de la versión de la de cada función. Una página puede tener su propia clasificación de madurez mientras el paquete que la contiene sigue siendo una versión candidata. A la inversa, una futura versión estable del núcleo no haría automáticamente que todos los experimentos opcionales estuvieran listos para ser dependencias de producción.

Para una agencia, el resultado debe ser un pequeño mapa del trabajo afectado: checkout de clientes, enriquecimiento del catálogo, asistencia administrativa, extensiones del Back Office e integraciones. Asigna un responsable a cada área. Esto es más útil que pedir a un desarrollador que «pruebe la nueva versión» sin definir qué significa tener éxito.

La incorporación del checkout cambia un punto importante de integración

El nuevo One Page Checkout nativo reúne el proceso de compra en una sola página. Su importancia va más allá del diseño: el proyecto ofrece una implementación común que pueden admitir los desarrolladores de pagos, transportistas y temas. La presentación oficial lo describe como una opción de checkout, no como prueba de que todas las tiendas aumentarán su conversión. Introducción al One Page Checkout.

Como comerciante, evalúa qué ocurre cuando un cliente cambia información después de haber tomado otras decisiones. Un cambio de dirección puede afectar a los métodos de entrega, los impuestos y el importe final. Un cambio de transportista puede afectar al selector de punto de recogida. Una opción de pago puede introducir una redirección o un formulario integrado. Reunir estas interacciones hace especialmente visible su coordinación.

Considera una tienda que vende tanto pequeños accesorios como artículos de gran tamaño. Una demostración convincente no consiste solo en comprar el accesorio con el transportista predeterminado. Añade el artículo voluminoso después de elegir la entrega y comprueba que la elección del transportista y el cargo mostrado se recalculan de forma coherente. El pedido final debe reflejar el carrito más reciente, no un estado anterior de la pantalla.

Una tienda que ya utilice un checkout de terceros debería inventariar sus reglas de negocio adicionales antes de planificar un reemplazo. La selección de fecha de entrega, los campos de empresa y las preferencias de recogida pueden pertenecer al módulo actual o a sus extensiones. La existencia de una alternativa nativa no garantiza una cobertura equivalente.

Convierte estas cuestiones en casos de aceptación antes de comprometerte a reemplazar el checkout. Registra las combinaciones de pago, transportista y tema probadas, incluida cualquier regla aportada por una extensión separada.

Extra Properties crea un lugar común para campos adicionales

El anuncio de congelación de funciones de 9.2 presenta Extra Properties como un sistema nativo de extensión de entidades con soporte para tiendas e idiomas y conexiones a formularios administrativos, tablas y la API. Anuncio de congelación de funciones de 9.2.

La oportunidad arquitectónica es la coherencia. Si un comerciante necesita una nota de manipulación específica de un producto, una agencia puede evaluar un mecanismo de extensión compartido antes de inventar otra convención privada de persistencia. Esto puede aclarar la responsabilidad y la integración, pero solo si el propio campo está bien modelado.

Por ejemplo, distingue una instrucción de manipulación de un historial de eventos de almacén. La primera es un valor vinculado a una entidad. El segundo es una secuencia de eventos con marcas de tiempo, actores y relaciones. Un mecanismo cómodo de campos personalizados no debería convertirse en un contenedor para cualquier registro que mencione un producto.

Hay una distinción similar entre un texto traducido y valores comerciales distintos. Una traducción al francés de una instrucción y una instrucción específica de una tienda son dimensiones separadas. Decide qué dimensión varía realmente antes de registrar un campo; corregir un modelo ambiguo después de introducir datos cuesta más que elegir deliberadamente desde el principio.

Para evaluar la RC, empieza con un campo reversible y un pequeño conjunto de datos de prueba. Sigue su valor a través de la entrada, la recarga y el consumidor previsto. No migres todo el almacenamiento de datos de un módulo de producción solo para explorar la función. Los desarrolladores que implementen el experimento pueden usar nuestra guía de desarrollo de módulos de PrestaShop 9 como base para la estructura del módulo y la preparación para producción.

Ask AI y las integraciones de la distribución necesitan sus propios criterios de aceptación

El anuncio de la beta describe Ask AI en el paquete Classic como una interfaz conversacional del Back Office conectada al servidor MCP de PrestaShop. El mismo anuncio presenta PrestaShop Automation con Klaviyo como una integración de la distribución Classic. Son capacidades de la distribución cuya configuración y dependencias externas merecen una evaluación separada. Anuncio de la beta 9.2.

Para Ask AI, un punto de partida útil es una pregunta cuya respuesta el personal pueda verificar de forma independiente. «Muestra el recuento para esta tienda concreta, este intervalo de fechas y este conjunto de estados de pedido» es una evaluación mejor que una petición abierta para mejorar el negocio. Facilita reconocer un ámbito incorrecto, resultados incompletos o terminología mal interpretada.

Para una acción, define los registros afectados y los valores esperados antes de aprobar nada. Un asistente que interprete correctamente una frase sigue necesitando una vía de ejecución adecuada y permisos suficientes. Su mensaje final debe contrastarse con el estado modificado de la tienda.

Para una integración de marketing, separa la instalación de la preparación de la cuenta. Un conector incluido no establece tus reglas de audiencia, el contenido de las campañas, la gestión de exclusiones ni la configuración de la cuenta. Utiliza una audiencia sintética y un proceso de prueba sin envíos al evaluar una versión candidata. Confirma adónde irían los eventos antes de activar la sincronización sobre una base de datos copiada.

Estas comprobaciones son recomendaciones operativas, no afirmaciones de que un proveedor o módulo concreto implemente todos los controles descritos aquí. Considera la documentación actual de cada integración y su versión instalada como el contrato.

El trabajo del Back Office continúa más allá de las funciones destacadas

La versión también importa a quienes pasan el día configurando y administrando tiendas. Las notas oficiales de cambios para desarrolladores describen otro conjunto de migraciones de páginas a Symfony, disponibles mediante banderas de funciones. También documentan el carácter experimental de las nuevas interfaces de Extra Properties. Cambios de 9.2 para desarrolladores.

Una página migrada puede resultar familiar aunque utilice puntos de extensión distintos por debajo. Esto afecta a las agencias que personalizan formularios, añaden información a tablas o modifican la navegación administrativa. La evaluación adecuada pregunta si una operación de negocio sigue funcionando, no si un botón mantiene el mismo aspecto.

Considera un formulario administrativo personalizado. Un campo podría mostrarse correctamente pero no guardarse, o guardarse bien y mostrar el contexto de tienda equivocado al recargar. Captura el recorrido completo: valor inicial, cambio enviado, valor guardado y formulario reabierto. Incluye una cuenta de empleado con los permisos que utiliza normalmente el personal.

No actives todos los experimentos a la vez y después intentes diagnosticar las diferencias resultantes. Parte de una referencia explícita, cambia una opción relevante y conserva pruebas suficientes para identificar la ruta activa. Registra el estado de la opción junto a cada resultado para que otro desarrollador pueda reproducir la misma ruta administrativa.

Una primera reunión de revisión práctica

Da a cada responsable de flujo una pregunta que responder antes de la siguiente reunión. El responsable del checkout identifica la dependencia de pago o entrega menos segura. El del catálogo selecciona un campo que merezca modelarse. El administrador indica una pregunta repetitiva con una respuesta verificable manualmente. El desarrollador enumera las páginas personalizadas afectadas por la versión candidata.

Revisa esas respuestas antes de programar un proyecto amplio de pruebas. Si nadie puede identificar una necesidad actual de una capacidad, déjala fuera del experimento inicial. Así la revisión de la versión sigue vinculada al trabajo que el negocio reconoce y ofrece una razón clara para cada investigación más profunda.

Elegir un recorrido breve de evaluación para tu tienda

El mejor primer experimento depende de las limitaciones de la tienda. Un checkout muy personalizado hace prioritario el comportamiento de pagos y entregas. Un módulo de catálogo con muchos campos auxiliares hace interesante Extra Properties. Una agencia que mantiene extensiones administrativas debería priorizar los contratos de las páginas migradas. Un comerciante que considere Ask AI debería empezar con un pequeño conjunto de preguntas verificables y una acción claramente delimitada.

Utiliza un registro sencillo de decisiones:

Un experimento fallido sigue siendo útil si produce una incompatibilidad reproducible y una siguiente acción clara. Una demostración exitosa solo es útil para las combinaciones realmente probadas. Evita convertir cualquiera de los resultados en una afirmación universal sobre todas las tiendas PrestaShop.

Por tanto, merece la pena evaluar PrestaShop 9.2 como un conjunto de cambios concretos en los flujos de trabajo. Mantén visible el estado actual de RC, selecciona las capacidades que resuelvan un problema real y documenta las pruebas que justificarían el siguiente paso. Nuestra guía de actualización segura de PrestaShop ofrece información sobre cómo planificar una actualización controlada; mantén cualquier experimento con la RC de 9.2 separado de una migración de producción.

Preguntas frecuentes

¿Debo instalar PrestaShop 9.2 RC1 en mi tienda en producción?

Utiliza la versión candidata en un entorno de pruebas aislado. Su propósito es validar la próxima versión e identificar regresiones pendientes. Mantén separada tu instalación de producción operativa y desactiva la captura real de pagos, los mensajes a clientes y la sincronización externa en una copia de prueba de la tienda antes de ejecutar escenarios de evaluación.

¿El One Page Checkout nativo sustituye automáticamente mi checkout actual?

No consideres la disponibilidad de un checkout nativo como un plan de reemplazo. Primero identifica las funciones aportadas por tu checkout actual, módulos de pago, integraciones de entrega y tema. Prueba explícitamente la configuración prevista, incluidos los cambios de dirección, el recálculo de entrega y las rutas de retorno del pago. La disponibilidad de una función por sí sola no garantiza un comportamiento equivalente.

¿Qué función nueva debería evaluar primero una agencia?

Empieza por la función que se cruce con la personalización más importante de la tienda. Puede ser el comportamiento del checkout, campos adicionales de entidades o una página administrativa migrada. Elige una operación de negocio, registra su resultado esperado y reprodúcela con los permisos de empleado, el contexto de tienda y los ajustes de idioma pertinentes.

Conclusión: hacer que la revisión de la versión lleve a acciones

Elige un flujo, asigna su responsable y define un resultado que pueda comprobarse de forma independiente. Conserva el archivo y las versiones de los módulos junto con las pruebas, registra las dependencias sin resolver y decide si los hallazgos justifican una prueba más amplia. Así el interés por PrestaShop 9.2 se convierte en una evaluación práctica sin confundir una demostración alentadora con estar listo para producción.

¿Planeas tu próxima extensión? Explora los módulos de PrestaShop 9 de PrestaSuite y revisa la compatibilidad declarada de cada módulo antes de incluirlo en una prueba de la versión candidata de 9.2.