Pedido que no abre tras migrar: el error OrderStatusForViewing

Un compañero de la comunidad migró una tienda PrestaShop 1.7 y, al abrir algunos pedidos en el back-office, en lugar de la ficha del pedido le salía un error de tipos. La causa estaba en la tabla ps_order_history: la migración había dejado líneas del historial con un estado de pedido que no existe. Al corregir esas líneas, los pedidos volvieron a abrirse.

El error

Type error: Argument 3 passed to PrestaShop\PrestaShop\Core\Domain\Order\QueryResult\OrderStatusForViewing::__construct() must be of the type string, null given, called in src/Adapter/Order/QueryHandler/GetOrderForViewingHandler.php

Sale al entrar en Pedidos → Pedidos y pinchar en un pedido concreto. El listado carga bien; solo fallan algunos pedidos.

Qué significa

Desde la 1.7.7, la página del pedido en el back-office está hecha con Symfony. Para pintar el historial, PrestaShop lee cada línea de ps_order_history y monta un objeto con el nombre del estado. Ese nombre tiene que ser un texto. Si la línea apunta a un id_order_state que no existe, o a un estado que no tiene nombre en tu idioma, el nombre llega vacío (null) y PHP para la página.

El pedido en sí está bien: sus productos, sus importes y su factura no se han tocado. Lo roto es una línea del historial de estados.

Lo que encontró el compañero

En los pedidos que fallaban había líneas con id_order_state = 0 y id_employee = 0, dejadas por la migración. Un id_employee a 0 es normal por sí solo: es lo que guarda PrestaShop cuando el cambio de estado lo hace el sistema o un módulo de pago, no una persona. El problema era el estado 0, que no existe.

Lo arregló poniendo en cada línea el estado que le tocaba, deduciéndolo por la hora: comparando la fecha de esa línea con las demás del mismo pedido se veía qué estado faltaba en ese punto.

Cómo encontrar las líneas rotas

Antes de tocar nada, haz una copia de la base de datos. Esta consulta solo lee y te da las líneas del historial que apuntan a un estado inexistente:

SELECT oh.id_order_history, oh.id_order, oh.id_order_state, oh.id_employee, oh.date_add
FROM ps_order_history oh
LEFT JOIN ps_order_state os ON os.id_order_state = oh.id_order_state
WHERE os.id_order_state IS NULL
ORDER BY oh.id_order, oh.date_add;

Y esta, los estados que no tienen nombre en alguno de tus idiomas activos:

SELECT os.id_order_state, l.id_lang, l.iso_code
FROM ps_order_state os
CROSS JOIN ps_lang l
LEFT JOIN ps_order_state_lang osl
  ON osl.id_order_state = os.id_order_state AND osl.id_lang = l.id_lang
WHERE l.active = 1 AND osl.id_order_state IS NULL;

Cambia el prefijo ps_ si tu tienda usa otro.

Cómo arreglarlo

• Si la línea tiene un estado inexistente: cámbiale el id_order_state por el que corresponda. Mira las otras líneas del pedido ordenadas por fecha; normalmente se ve qué paso falta (pago aceptado, en preparación, enviado…). Si no hay forma de saberlo, usa el estado que tiene el pedido en ps_orders.current_state.
• Si al estado le falta el nombre: entra en Parámetros de la tienda → Configuración de pedidos → Estados, edita ese estado y rellena el nombre en todos los idiomas. Al guardar desde el back-office se crean las filas que faltan.
• Revisa también ps_orders.current_state: un pedido con un estado actual que no existe fallará igual en otras pantallas.

Corrige un pedido, comprueba que abre y después aplica el mismo arreglo al resto.

Para la próxima migración

Cuando pasas pedidos de una tienda a otra, con un módulo de migración o a mano por SQL, los identificadores de los estados no tienen por qué coincidir: los estados que crean los módulos de pago tienen un número distinto en cada instalación. Antes de dar por buena una migración, abre unos cuantos pedidos de cada estado y lanza la primera consulta. Si devuelve filas, hay que hacer la correspondencia de estados antes de seguir.

Si la migración se te complica, en Rekire la revisamos dentro de nuestros bonos de horas de soporte.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación