Aunque la mayoría de las tiendas migrarán de EDD 2.11 a 3.x sin problemas, si migra sus datos y descubre que faltan algunos pedidos, existen herramientas para ayudar a solucionar problemas.
Antes de ejecutar cualquier migración, asegúrese de que los datos de su tienda estén respaldados. Se recomienda encarecidamente probar la migración en una copia local o de staging de su sitio antes de hacerlo en producción.
Si concluye que faltan algunos pedidos en las nuevas tablas, el primer paso es averiguar cuáles. Necesitará poder ver directamente las tablas de su base de datos usando PHPMyAdmin o una herramienta similar. Esperemos que tenga una idea de qué pedidos podrían faltar, ya sea conociendo el ID específico o un rango de fechas aproximado.
El primer paso es buscar en su 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 necesita encontrar el(los) ID(s) del(los) pago(s) que no se migraron correctamente.
Una vez que haya 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, la migración del pedido faltante es bastante sencilla; si existe, puede tener un conflicto. Querrá observar 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, esto es muy manejable, porque el ID del reembolso en realidad no importa.
Migración de Pedidos con CLI
Una vez que conozca el ID de un pedido faltante, deberá ejecutar una migración de pedido parcial. Es útil comenzar asegurándose de saber cuáles son todos los datos del pago original. Puede usar este comando CLI para verlo:
wp edd display_legacy_payment_data 1234
Reemplace 1234 con el ID de pago original que encontró 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 el marcado de la migración de pedidos como 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, deberá agregar algunas banderas para ejecutar otra migración; de lo contrario, EDD no lo hará.
Este comando acepta varias 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: This will force the migration to run again, even if it’s already been run. Existing orders/order meta/order items/etc which match a payment ID will be deleted and the payment will be migrated again. A confirmation is required, because this is a destructive action.- 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 eso probablemente destruirá datos que no podrán recuperarse.
--id: This will run a partial migration on a specific payment ID (the ID in the WP posts table, which may be different from the displayed order number).- Esta marca no se puede usar con las marcas de inicio/fin.
- Se puede combinar con forzar/destruir.
- La migración del pedido no se marcará como completa.
--start: This will run a partial migration beginning with (and including) a specific payment ID.- Esta marca se puede usar con o sin la marca de fin.
- Esta marca no se puede usar con la marca de id.
- Se puede combinar con forzar/destruir.
- La migración del pedido no se marcará como completa.
--end: This will run a partial migration ending with (and including) a specific payment ID.- Esta marca se puede usar con o sin la marca de inicio.
- Esta marca no se puede usar con la marca de id.
- Se puede combinar con forzar/destruir.
- La migración del pedido no se marcará como completa.
Así que si quieres probar a migrar de nuevo 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 de nuevo, lo que regenerará el objeto de pedido de reembolso. El ID real de cualquier reembolso no significa nada, por lo que regenerar 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
Debido a 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 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 la marca --force para permitir que se ejecute de nuevo):
wp edd v30_migration
