Obwohl die meisten Shops ohne Probleme von EDD 2.11 auf 3.x migriert werden, gibt es Tools zur Fehlerbehebung, falls nach der Migration Ihrer Daten einige Bestellungen fehlen.
Stellen Sie vor jeder Migration sicher, dass Ihre Shop-Daten gesichert sind. Es wird dringend empfohlen, die Migration auf einer lokalen oder Staging-Kopie Ihrer Website zu testen, bevor Sie sie in der Produktion durchführen.
Wenn Sie feststellen, dass einige Bestellungen in den neuen Tabellen fehlen, müssen Sie zunächst herausfinden, welche. Sie müssen mit PHPMyAdmin oder einem ähnlichen Tool direkt auf Ihre Datenbanktabellen zugreifen können. Hoffentlich haben Sie eine Vorstellung davon, welche Bestellungen fehlen könnten, entweder durch die Kenntnis der spezifischen ID oder durch einen ungefähren Datumsbereich.
Der erste Schritt besteht darin, in Ihrer wp_posts-Tabelle nach den fehlenden Zahlungen zu suchen (in EDD 2.x verwenden wir die Terminologie für Zahlungen; in EDD 3.x sind es jetzt Bestellungen). Der post_type ist edd_payment und Sie müssen die ID(s) für die Zahlung(en) finden, die nicht erfolgreich migriert wurden.
Sobald Sie eine Zahlungs-ID notiert haben, besteht der nächste Schritt darin, in der wp_edd_orders-Tabelle nach einer Bestellung mit derselben ID zu suchen. Wenn sie nicht existiert, ist die Migration der fehlenden Bestellung ziemlich einfach. Wenn sie existiert, haben Sie möglicherweise einen Konflikt. Sie sollten sich die Bestellung genau ansehen und prüfen, welchen type sie hat. Normalerweise ist es passiert, dass ein Rückerstattungsdatensatz mit der nächsten verfügbaren ID erstellt wurde und dies die ursprüngliche Zahlung daran hinderte, migriert zu werden. Wenn der type der Bestellung refund ist, ist dies sehr gut zu handhaben, da die ID der Rückerstattung tatsächlich keine Rolle spielt.
Bestellungen mit CLI migrieren
Sobald Sie die ID für eine fehlende Bestellung kennen, müssen Sie eine teilweise Bestellmigration durchführen. Es ist hilfreich, zunächst sicherzustellen, dass Sie alle ursprünglichen Zahlungsdaten kennen. Sie können diesen CLI-Befehl verwenden, um sie anzuzeigen:
wp edd display_legacy_payment_data 1234
Ersetzen Sie 1234 durch die ursprüngliche Zahlungs-ID, die Sie in der Posts-Tabelle gefunden haben. Dies zeigt alles an, was EDD über die ursprüngliche Zahlung weiß. Dies kann hilfreich sein, da die Daten in EDD 3.x anders gespeichert werden.
Der Standardbefehl zur Bestellmigration lautet einfach:
wp edd migrate_payments
Ohne Optionen durchläuft er jedes Zahlungsobjekt und migriert es, schließt mit der Markierung der Bestellmigration als abgeschlossen ab und berechnet dann die Verkäufe/Einnahmen für alle Downloads im Shop neu. Sobald EDD die Bestellmigration als abgeschlossen markiert hat, müssen Sie einige Flags hinzufügen, um eine weitere Migration durchzuführen. Andernfalls wird EDD dies nicht tun.
Dieser Befehl akzeptiert mehrere Flags, die das Verhalten ändern:
--force: Dies erzwingt die erneute Ausführung der Migration, auch wenn sie bereits ausgeführt wurde. Bestehende Bestellungen werden nicht überschrieben. Eine Bestätigung ist erforderlich.--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.- Diese Option ist hilfreich, wenn Rückerstattungsbestellungen anstelle einer vorhandenen Zahlungs-ID in die Bestellungen-Tabelle eingefügt wurden. Rückerstattungen werden automatisch mit der nächsten verfügbaren ID in der Bestellungen-Tabelle neu generiert.
- Wenn die vorhandene Bestellung keine Rückerstattung ist und vollständig von der zu migrierenden Bestellung abweicht, ist eine zusätzliche Bestätigung erforderlich, da dies wahrscheinlich Daten zerstört, die nicht wiederhergestellt werden können.
--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).- Dieses Flag kann nicht mit den Start/End-Flags verwendet werden.
- Es kann mit force/destroy kombiniert werden.
- Die Bestellungs-Migration wird nicht als abgeschlossen markiert.
--start: This will run a partial migration beginning with (and including) a specific payment ID.- Dieses Flag kann mit oder ohne das End-Flag verwendet werden.
- Dieses Flag kann nicht mit dem id-Flag verwendet werden.
- Es kann mit force/destroy kombiniert werden.
- Die Bestellungs-Migration wird nicht als abgeschlossen markiert.
--end: This will run a partial migration ending with (and including) a specific payment ID.- Dieses Flag kann mit oder ohne das Start-Flag verwendet werden.
- Dieses Flag kann nicht mit dem id-Flag verwendet werden.
- Es kann mit force/destroy kombiniert werden.
- Die Bestellungs-Migration wird nicht als abgeschlossen markiert.
Wenn Sie also testen möchten, ob eine Bestellung neu migriert werden kann, und Sie bestätigt haben, dass die ursprüngliche Zahlung (was höchstwahrscheinlich ist) in der Bestellungen-Tabelle durch eine Rückerstattung „ersetzt“ wurde, können Sie diesen Befehl ausführen:
wp edd migrate_payments --force --destroy --id=1234
Die Ausführung dieses Befehls löscht zwangsweise die Bestellung mit der ID 1234. Dann migriert es die Zahlung 1234 an ihrer Stelle. Wenn die Bestellung 1234 eine Rückerstattung war, findet es die ursprüngliche Bestellung dafür (sagen wir, es war Bestellung/Zahlung 123), löscht dann die Bestellung 123 und führt die Migration für die Zahlung 123 erneut aus, wodurch das Rückerstattungs-Bestellungsobjekt neu generiert wird. Die tatsächliche ID für eine Rückerstattung spielt keine Rolle, daher ist die Neuerstellung von Rückerstattungen kein Problem. Rückerstattungen werden über die Spalte parent gefunden.
Wenn Sie auf EDD 2.11 herabgestuft und die Migration erneut ausführen
Da wir nicht alle Szenarien mit Integrationen vorhersehen können, erlaubt EDD den Shops, auf EDD 2.11 herabzustufen und dann zu 3.x zurückzukehren, wenn sie bereit sind. In diesen Fällen empfehlen wir, die neu erstellten Tabellen zu leeren und dann die Migration so auszuführen, als wäre es das erste Mal. Sie müssen wahrscheinlich den CLI-Befehl verwenden, um die Migration mit --force auszuführen, da EDD die Migration möglicherweise bereits als abgeschlossen markiert hat.
Stellen Sie sicher, dass Sie eine vollständige Sicherung Ihrer Datenbank haben, bevor Sie Datenbanktabellen leeren oder löschen. Üben Sie eine Migration auf einer Staging-Website, bevor Sie sie in der Produktion durchführen.
Hier ist eine Liste der Tabellen, die neu für EDD 3.x erstellt werden:
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
Die Tabellen customers, customermeta und notifications existierten bereits in EDD 2.x. Leeren Sie diese nicht. Wenn Sie eine Erweiterung wie Commissions, Recurring Payments oder Software Licensing verwenden, registrieren diese Erweiterungen auch benutzerdefinierte Tabellen mit edd im Namen und sollten nicht geleert werden.
Um alle Shop-Daten zu migrieren, verwenden Sie diesen Befehl (möglicherweise müssen Sie das Flag --force verwenden, damit er erneut ausgeführt werden kann):
wp edd v30_migration
