Historia de una odisea

Hace unas semanas tuvimos que exportar e importar algunos cientos de cupones y varias decenas de miles de clientes y pedidos por cada idioma de una tienda online multisitio y multilingüe bajo WooCommerce, concretamente hablamos de Bestway que tras un rediseño integral del sitio web en el que se decidió empezar totalmente desde cero a partir de los trabajos de diseño y programación que APG realizó para otra tienda online de la misma empresa, Gardiun.

Lo que a priori prometía ser un trabajo «sencillo» y rutinario más resultó acabando en una auténtica odisea y en un auténtico quebradero de cabeza que nos ha llevado a emplear muchas de horas de soporte técnico y a tener que realizar un desarrollo personalizado para poder terminar de realizarlo.

La odisea

Comienza por tener que descartar el uso de los plugins que siempre usamos para estos menesteres, los maravillosos plugins para WooCommerce WooCommerce Customer / Order / Coupon Export y Customer/Order/Coupon CSV Import Suite, maravillas que hasta ahora nunca nos habían dado problemas, pero esto no resultaría una odisea si hubiera sido tan «sencillo» como exportar, importar y listo.

Tras resultar absolutamente imposible realizar una exportación e importación completa de pedidos con solvencia utilizando este par de plugins ya que se rompían en ambos sentidos, incluso realizándolas por lotes de años o meses, y nos duplicaban pedidos sin parar al importar, tras realizar varias limpiezas de importaciones, reinstalar copias de seguridad y demás movidas que conlleva el que una exportación e importación de estas características falle, nos decantamos por otra maravilla como el tándem WP All Export y WP All Import con los que nos la prometíamos muy felices, pero de nuevo tuvimos un baño de realidad.

Si bien finalmente ha sido con esta pareja con los que hemos conseguido finalizar el trabajo, es bien cierto que ha sido una auténtica pesadilla conseguirlo ya que los tiempos de exportación e importación han sido de decenas de horas de trabajo. 

¿Y por qué tantos problemas?

El problema ha radicado en un cúmulo de circunstancias:

• Partíamos de una base de datos que se nutría de pedidos importados de forma no muy ortodoxa de una instalación anterior que el cliente tenía sobre Magento.
• Partíamos de una base de datos que no se había actualizado al nuevo HPOS de WooCommerce y tenía que ser exportada a una base de datos en la que los pedidos ya estaban almacenándose sobre HPOS.
• Partíamos de una base de datos que utilizaba un número de pedido personalizado que tenía que ser exportado a una nueva base de datos en la que se tenía que almacenar en un nuevo meta_key ya que se había cambiado de plugin y el metadato que se utilizaba era distinto.
• Partíamos de una base de datos en el que los productos utilizaban el campo SKU estándar y tenía que ser cotejado con miles de productos que utilizaban el campo SKU original en un nuevo metadato personalizado.

Si bien con la exportación e importación de los clientes prácticamente no tuvimos problemas, con los pedidos hemos estado peleando hasta hace bien poco.

¿Desarrollo personalizado para qué?

Sencillo, tras finalizar la odisea nos dimos cuenta de que los totales de los pedidos no se habían calculado bien durante la importación, es decir los precios de los productos eran correctos, los subtotaltes y totales del pedido también, pero no se habían calculado los impuestos, a pesar de tener los impuestos perfectamente configurados en WooCommerce, así que nos tocó desarrollar código personalizado que arreglara el problema sin romper nada.

De nuevo esto parecía una tarea «sencilla» pero de nuevo nos topamos con la odisea que ha rodeado este trabajo.

Tras la imposibilidad de realizar un script que hiciera la actualización de una única vez, debido al gran volumen de datos a procesar que incluso impedía hacer una lectura única del 100% de los pedidos, tras ver cómo las consultas no hacían caso de los metadatos de control que almacenábamos y tras romper algún pedido en el que aparecían decenas de veces los impuestos, finalmente dimos con la tecla y terminamos arreglando definitivamente el problema.

Solución final

En primer lugar desarrollamos un pequeño fichero llamado pedidos.php que subimos a la carpeta raíz de WordPress y que se encargó de leer todos los números de pedido de la tabla wp_wc_orders en el que el tipo fuera shop_order, trocearlos en paquetes de 100 números, y crear una acción programada para cada uno de los paquetes de 100 pedidos. Para ello sólo había que ejecutar fichero en cada uno de los idiomas de la instalación multisite.

Este es el código PHP final de este fichero:

Y en segundo lugar en el fichero functions.php del tema hijo creamos una acción llamada apg_actualiza_pedidos cuya única función era el procesamiento de uno en uno de todos y cada uno de los números de pedido contenidos en los paquetes de 100 números que se habían enviado previamente mediante la acción programada que habíamos creado en el fichero pedidos.php.

Este es el código PHP que gestiona la acción:

Y gracias a esta pequeña función se recorren todos los pedidos de cada uno de los sitios que componen la instalación multisite y se recalculan los totales para corregir todos los errores que surgieron durante la tortuosa importación de los pedidos. Al ejecutarse la función sobre las acciones programadas eliminamos los problemas de errores de time out, de desbordamiento de memoria y demás que nos habíamos encontrado previamente.

Conclusión

Como ves no existe ningún trabajo «sencillo» en WordPress y WooCommerce ya que pueden surgir distintos problemas durante su desarrollo que lo complique hasta convertirlo en una odisea e incluso hacer que sea materialmente imposible terminarlo. Lo importante es tener las herramientas, el conocimiento y la paciencia suficiente para llevar a buen puerto cualquier tipo de problema al que te enfrentes y en eso APG somos especialistas.

Si necesitas cualquier tipo de ayuda en tu sitio web, no dudes en contactarnos para que te ayudemos a resolver tu problema con solvencia y seguridad.