Aunque la mayoría de las tiendas migrarán de EDD 2.11 a 3.x sin problemas, si migras tus datos y descubres que algunos pedidos parecen faltar, existen herramientas para ayudar a solucionar problemas.
Antes de ejecutar cualquier migración, asegúrate de que los datos de tu tienda tengan una copia de seguridad. Se recomienda encarecidamente que pruebes la migración en una copia local o de staging de tu sitio antes de hacerlo en producción.
Si concluyes que faltan algunos pedidos en las nuevas tablas, el primer paso es averiguar cuáles. Necesitarás poder ver directamente las tablas de tu base de datos usando PHPMyAdmin o una herramienta similar. Esperemos que tengas una idea de qué pedidos podrían faltar, ya sea conociendo el ID específico o una fecha aproximada.
El primer paso es buscar en tu tabla wp_posts los pagos faltantes (en EDD 2.x, usamos la terminología de pagos; en EDD 3.x, ahora son pedidos). El post_type será edd_payment y necesitas encontrar el/los ID(s) del/los pago(s) que no migraron exitosamente.
Una vez que hayas anotado un ID de pago, el siguiente paso es buscar en la tabla wp_edd_orders un pedido con ese mismo ID. Si no existe, entonces migrar el pedido faltante es bastante sencillo; si existe, puede que tengas un conflicto. Querrás mirar cuidadosamente el pedido y ver cuál es el type. Por lo general, lo que habrá sucedido es que se habrá creado un registro de reembolso con el siguiente ID disponible y eso impidió que el pago original pudiera migrar. Si el type del pedido es refund, entonces esto es muy manejable, porque el ID del reembolso en realidad no importa.
Migración de Pedidos con CLI
Una vez que conozcas el ID de un pedido faltante, necesitarás ejecutar una migración de pedido parcial. Es útil comenzar asegurándote de conocer todos los datos originales del pago. Puedes usar este comando CLI para verlo:
wp edd display_legacy_payment_data 1234
Reemplaza 1234 con el ID de pago original que encontraste en la tabla de posts. Esto mostrará todo lo que EDD sabe sobre el pago original. Esto puede ser útil porque los datos se almacenan de manera diferente en EDD 3.x.
El comando de migración de pedidos predeterminado es solo este:
wp edd migrate_payments
Sin opciones, recorrerá cada objeto de pago y lo migrará, terminando con la marca de migración de pedidos completa y luego recalculando las ventas/ganancias de todas las descargas en la tienda. Una vez que EDD haya marcado la migración de pedidos como completa, necesitas agregar algunas banderas para ejecutar otra migración; de lo contrario, EDD no lo hará.
Este comando acepta múltiples banderas que cambiarán el comportamiento:
--force: Esto forzará la ejecución de la migración nuevamente, incluso si ya se ha ejecutado. Los pedidos existentes no se sobrescribirán. Se requiere confirmación.--destroy: Esto forzará que la migración se ejecute de nuevo, incluso si ya se ha ejecutado. Los pedidos/metadatos de pedidos/elementos de pedido/etc. existentes que coincidan con un ID de pago se eliminarán y el pago se migrará de nuevo. Se requiere una confirmación, ya que esta es una acción destructiva.- Esta opción es útil cuando los pedidos de reembolso se han insertado en la tabla de pedidos en lugar de un ID de pago existente. Los reembolsos se regenerarán automáticamente con el siguiente ID disponible en la tabla de pedidos.
- Si el pedido existente no es un reembolso y parece ser un pedido completamente diferente al que intentas migrar, se requiere una confirmación adicional, ya que es probable que estés destruyendo datos que no podrán recuperarse.
--id: Esto ejecutará una migración parcial en un ID de pago específico (el ID en la tabla de publicaciones de WP, que puede ser diferente del número de pedido mostrado).- Esta bandera no se puede usar con las banderas de inicio/fin.
- Se puede combinar con force/destroy.
- La migración del pedido no se marcará como completa.
--start: Esto ejecutará una migración parcial comenzando con (e incluyendo) un ID de pago específico.- Esta bandera se puede usar con o sin la bandera de fin.
- Esta bandera no se puede usar con la bandera id.
- Se puede combinar con force/destroy.
- La migración del pedido no se marcará como completa.
--end: Esto ejecutará una migración parcial terminando con (e incluyendo) un ID de pago específico.- Esta bandera se puede usar con o sin la bandera de inicio.
- Esta bandera no se puede usar con la bandera id.
- Se puede combinar con force/destroy.
- La migración del pedido no se marcará como completa.
Así que si quieres probar a volver a migrar un pedido, si has confirmado que (lo más probable es que) el pago original ha sido "reemplazado" en la tabla de pedidos por un reembolso, puedes ejecutar este comando:
wp edd migrate_payments --force --destroy --id=1234
Ejecutar este comando eliminará forzosamente el pedido con un ID de 1234. Luego migrará el pago 1234 en su lugar. Si el pedido 1234 era un reembolso, encontrará el pedido original para ese (digamos que era el pedido/pago 123), y luego eliminará el pedido 123 y ejecutará la migración para el pago 123 nuevamente, lo que regenerará el objeto del pedido de reembolso. El ID real de cualquier reembolso no significa nada, por lo que regenerar los reembolsos no es gran cosa. Los reembolsos se localizan por la columna parent.
Si degradaste a EDD 2.11 y estás ejecutando la migración de nuevo
Dado que no podemos anticipar todos los escenarios con las integraciones, EDD permite a las tiendas degradar a EDD 2.11 y luego volver a 3.x cuando estén listas. En estos casos, sugerimos que vacíes las tablas recién creadas y luego ejecutes la migración como si fuera la primera vez. Probablemente necesitarás usar el comando CLI para ejecutar la migración usando --force ya que EDD puede haber marcado la migración como completa.
Antes de vaciar o eliminar cualquier tabla de base de datos, asegúrate de tener una copia de seguridad completa de tu base de datos. Practica una migración en un sitio de staging antes de comprometerte en producción.
Aquí tienes una lista de tablas que se crean nuevas para EDD 3.x:
wp_customer_addresses wp_customer_email_addresses wp_adjustments wp_adjustmentmeta wp_notes wp_notemeta wp_orders wp_ordermeta wp_order_items wp_order_itemmeta wp_order_adjustments wp_order_adjustmentmeta wp_order_addresses wp_order_transactions wp_logs wp_logmeta wp_logs_api_requests wp_logs_api_requestmeta wp_logs_file_downloads wp_logs_file_downloadmeta
Las tablas customers, customermeta y notifications ya existían en EDD 2.x. No las vacíes. Si usas una extensión como Commissions, Recurring Payments o Software Licensing, esas extensiones también registran tablas personalizadas con edd en el nombre y no deben vaciarse.
Para migrar todos los datos de la tienda, usa este comando (puede que necesites usar el indicador --force para permitir que se ejecute de nuevo):
wp edd v30_migration
