Hoewel de meeste winkels zonder problemen van EDD 2.11 naar 3.x zullen migreren, zijn er, als u uw gegevens migreert en ontdekt dat sommige bestellingen ontbreken, tools om u te helpen bij het oplossen van problemen.
Zorg ervoor dat uw winkelgegevens zijn geback-upt voordat u een migratie uitvoert. Het is sterk aanbevolen om de migratie te testen op een lokale of staging-kopie van uw site voordat u deze in productie uitvoert.
Als u concludeert dat er bestellingen ontbreken in de nieuwe tabellen, is de eerste stap om erachter te komen welke. U moet rechtstreeks toegang hebben tot uw databasetabellen met PHPMyAdmin of een vergelijkbare tool. Hopelijk heeft u een idee van welke bestellingen mogelijk ontbreken, hetzij door de specifieke ID te kennen, hetzij door een geschatte datumbereik te kennen.
De eerste stap is om in uw wp_posts-tabel te kijken naar de ontbrekende betalingen (in EDD 2.x gebruiken we de terminologie van betalingen; in EDD 3.x zijn het nu bestellingen). Het post_type zal edd_payment zijn en u moet de ID('s) vinden voor de betaling(en) die niet succesvol zijn gemigreerd.
Nadat u een betalings-ID hebt genoteerd, is de volgende stap om in de wp_edd_orders-tabel te kijken naar een bestelling met diezelfde ID. Als deze niet bestaat, is het migreren van de ontbrekende bestelling vrij eenvoudig; als deze wel bestaat, heeft u mogelijk een conflict. U wilt zorgvuldig naar de bestelling kijken en zien wat het type is. Meestal is er een terugbetalingsrecord aangemaakt met de volgende beschikbare ID en dat heeft voorkomen dat de oorspronkelijke betaling kon worden gemigreerd. Als het bestellingstype refund is, is dit zeer beheersbaar, omdat de ID van de terugbetaling er niet echt toe doet.
Bestellingen migreren met CLI
Zodra u de ID voor een ontbrekende bestelling kent, moet u een gedeeltelijke bestellingsmigratie uitvoeren. Het is nuttig om te beginnen met ervoor te zorgen dat u alle oorspronkelijke betalingsgegevens kent. U kunt dit CLI-commando gebruiken om deze weer te geven:
wp edd display_legacy_payment_data 1234
Vervang 1234 door de oorspronkelijke betalings-ID die u in de posts-tabel hebt gevonden. Dit toont alles wat EDD weet over de oorspronkelijke betaling. Dit kan nuttig zijn omdat de gegevens anders worden opgeslagen in EDD 3.x.
Het standaard commando voor bestellingsmigratie is gewoon dit:
wp edd migrate_payments
Zonder opties wordt elk betalingsobject doorlopen en gemigreerd, eindigend met het markeren van de bestellingsmigratie als voltooid en vervolgens het herberekenen van de verkopen/inkomsten voor alle downloads in de winkel. Zodra EDD de bestellingsmigratie als voltooid heeft gemarkeerd, moet u enkele vlaggen toevoegen om een andere migratie uit te voeren; anders zal EDD dit niet doen.
Dit commando accepteert meerdere vlaggen die het gedrag zullen veranderen:
--force: Dit dwingt de migratie om opnieuw te worden uitgevoerd, zelfs als deze al is uitgevoerd. Bestaande bestellingen worden niet overschreven. Een bevestiging is vereist.--destroy: Dit dwingt de migratie om opnieuw te worden uitgevoerd, zelfs als deze al is uitgevoerd. Bestaande bestellingen/bestelgegevens/bestelitems/etc. die overeenkomen met een betalings-ID, worden verwijderd en de betaling wordt opnieuw gemigreerd. Een bevestiging is vereist, omdat dit een destructieve actie is.- Deze optie is handig wanneer terugbetalingsbestellingen zijn ingevoegd in de bestellingentabel op de plaats van een bestaand betalings-ID. Terugbetalingen worden automatisch opnieuw gegenereerd met het eerstvolgende beschikbare ID in de bestellingentabel.
- Als de bestaande bestelling geen terugbetaling is en een volledig andere bestelling lijkt te zijn dan degene die u probeert te migreren, is een extra bevestiging vereist, omdat dit waarschijnlijk gegevens vernietigt die niet kunnen worden hersteld.
--id: Dit voert een gedeeltelijke migratie uit op een specifiek betalings-ID (het ID in de WP posts-tabel, dat kan verschillen van het weergegeven bestelnummer).- Dit vlag kan niet worden gebruikt met de start/eind vlaggen.
- Het kan worden gecombineerd met force/destroy.
- De bestellingsmigratie wordt niet als voltooid gemarkeerd.
--start: Dit voert een gedeeltelijke migratie uit beginnend met (en inclusief) een specifiek betalings-ID.- Dit vlag kan worden gebruikt met of zonder de eind vlag.
- Dit vlag kan niet worden gebruikt met de id vlag.
- Het kan worden gecombineerd met force/destroy.
- De bestellingsmigratie wordt niet als voltooid gemarkeerd.
--end: Dit voert een gedeeltelijke migratie uit eindigend met (en inclusief) een specifiek betalings-ID.- Dit vlag kan worden gebruikt met of zonder de start vlag.
- Dit vlag kan niet worden gebruikt met de id vlag.
- Het kan worden gecombineerd met force/destroy.
- De bestellingsmigratie wordt niet als voltooid gemarkeerd.
Dus als u wilt testen om een bestelling opnieuw te migreren, als u hebt bevestigd dat (dit is hoogstwaarschijnlijk) de oorspronkelijke betaling is "vervangen" in de bestellingentabel door een terugbetaling, kunt u dit commando uitvoeren:
wp edd migrate_payments --force --destroy --id=1234
Het uitvoeren van dit commando zal de bestelling met ID 1234 geforceerd verwijderen. Vervolgens zal het betaling 1234 migreren in plaats daarvan. Als de bestelling 1234 een terugbetaling was, zal het de oorspronkelijke bestelling daarvan vinden (laten we zeggen dat het bestelling/betaling 123 was), en dan bestelling 123 verwijderen en de migratie voor betaling 123 opnieuw uitvoeren, wat het terugbetalingsbestellingsobject opnieuw zal genereren. Het daadwerkelijke ID voor een terugbetaling doet er niet toe, dus het opnieuw genereren van terugbetalingen is geen probleem. Terugbetalingen worden gevonden via de parent kolom.
Als u downgradet naar EDD 2.11 en de migratie opnieuw uitvoert
Omdat we niet elke scenario met integraties kunnen anticiperen, staat EDD winkels toe om te downgraden naar EDD 2.11 en dan terug te keren naar 3.x wanneer ze er klaar voor zijn. In deze gevallen raden we aan om de nieuw aangemaakte tabellen te legen en dan de migratie uit te voeren alsof het de eerste keer was. U zult waarschijnlijk de CLI-opdracht moeten gebruiken om de migratie uit te voeren met --force, aangezien EDD de migratie mogelijk al als voltooid heeft gemarkeerd.
Voordat u database tabellen leegt of verwijdert, zorg ervoor dat u een volledige back-up van uw database heeft. Oefen een migratie op een staging site voordat u deze in productie uitvoert.
Hier is een lijst met tabellen die nieuw zijn aangemaakt voor 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
De tabellen customers, customermeta en notifications bestonden al in EDD 2.x. Leeg deze niet. Als u een extensie gebruikt zoals Commissions, Recurring Payments of Software Licensing, registreren die extensies ook aangepaste tabellen met edd in de naam en mogen deze niet worden geleegd.
Om alle winkelgegevens te migreren, gebruikt u dit commando (mogelijk moet u de vlag --force gebruiken om het opnieuw te laten uitvoeren):
wp edd v30_migration
