Anche se la maggior parte dei negozi migrerà da EDD 2.11 a 3.x senza problemi, se migri i tuoi dati e scopri che alcuni ordini sembrano mancanti, ci sono strumenti per aiutarti nella risoluzione dei problemi.
Prima di eseguire qualsiasi migrazione, assicurati che i dati del tuo negozio siano sottoposti a backup. È fortemente raccomandato testare la migrazione su una copia locale o di staging del tuo sito prima di eseguirla in produzione.
Se concludi che alcuni ordini mancano dalle nuove tabelle, il primo passo è capire quali. Dovrai essere in grado di guardare direttamente le tabelle del tuo database usando PHPMyAdmin o uno strumento simile. Speriamo che tu abbia un'idea di quali ordini potrebbero mancare, conoscendo l'ID specifico o un intervallo di date approssimativo.
Il primo passo è cercare nella tua tabella wp_posts i pagamenti mancanti (in EDD 2.x, usiamo la terminologia dei pagamenti; in EDD 3.x, ora sono ordini). Il post_type sarà edd_payment e devi trovare l'ID (o gli ID) del/i pagamento/i che non sono stati migrati con successo.
Una volta annotato un ID di pagamento, il passo successivo è cercare nella tabella wp_edd_orders un ordine con lo stesso ID. Se non esiste, la migrazione dell'ordine mancante è abbastanza semplice; se esiste, potresti avere un conflitto. Dovrai esaminare attentamente l'ordine e vedere qual è il type. Di solito, ciò che sarà successo è che un record di rimborso sarà stato creato con il prossimo ID disponibile e ciò ha impedito al pagamento originale di migrare. Se il type dell'ordine è refund, allora questo è molto gestibile, perché l'ID del rimborso non ha importanza.
Migrazione di Ordini con CLI
Una volta che conosci l'ID di un ordine mancante, dovrai eseguire una migrazione parziale dell'ordine. È utile iniziare assicurandosi di conoscere tutti i dati originali del pagamento. Puoi usare questo comando CLI per visualizzarli:
wp edd display_legacy_payment_data 1234
Sostituisci 1234 con l'ID del pagamento originale che hai trovato nella tabella dei post. Questo visualizzerà tutto ciò che EDD conosce del pagamento originale. Questo può essere utile perché i dati sono archiviati in modo diverso in EDD 3.x.
Il comando di migrazione ordini predefinito è semplicemente questo:
wp edd migrate_payments
Senza opzioni, eseguirà ogni oggetto pagamento e lo migrerà, terminando con la marcatura del completamento della migrazione dell'ordine e quindi ricalcolando le vendite/guadagni per tutti i download nello store. Una volta che EDD ha contrassegnato il completamento della migrazione dell'ordine, è necessario aggiungere alcuni flag per eseguire un'altra migrazione; altrimenti, EDD non la eseguirà.
Questo comando accetta più flag che cambieranno il comportamento:
--force: Questo forzerà l'esecuzione della migrazione di nuovo, anche se è già stata eseguita. Gli ordini esistenti non verranno sovrascritti. È richiesta una conferma.--destroy: Questo forzerà l'esecuzione della migrazione di nuovo, anche se è già stata eseguita. Gli ordini esistenti/meta degli ordini/elementi degli ordini/ecc. che corrispondono a un ID di pagamento verranno eliminati e il pagamento verrà migrato di nuovo. È richiesta una conferma, poiché si tratta di un'azione distruttiva.- Questa opzione è utile quando gli ordini di rimborso sono stati inseriti nella tabella degli ordini al posto di un ID di pagamento esistente. I rimborsi verranno rigenerati automaticamente con il prossimo ID disponibile nella tabella degli ordini.
- Se l'ordine esistente non è un rimborso e sembra essere un ordine completamente diverso da quello che stai cercando di migrare, è richiesta una conferma aggiuntiva, poiché ciò comporterebbe la distruzione di dati che non potranno essere recuperati.
--id: Questo eseguirà una migrazione parziale su un ID di pagamento specifico (l'ID nella tabella dei post di WP, che potrebbe essere diverso dal numero d'ordine visualizzato).- Questo flag non può essere utilizzato con i flag start/end.
- Può essere combinato con force/destroy.
- La migrazione dell'ordine non verrà contrassegnata come completata.
--start: Questo eseguirà una migrazione parziale a partire da (e includendo) un ID di pagamento specifico.- Questo flag può essere utilizzato con o senza il flag end.
- Questo flag non può essere utilizzato con il flag id.
- Può essere combinato con force/destroy.
- La migrazione dell'ordine non verrà contrassegnata come completata.
--end: Questo eseguirà una migrazione parziale terminando con (e includendo) un ID di pagamento specifico.- Questo flag può essere utilizzato con o senza il flag start.
- Questo flag non può essere utilizzato con il flag id.
- Può essere combinato con force/destroy.
- La migrazione dell'ordine non verrà contrassegnata come completata.
Quindi, se vuoi testare la rimigrazione di un ordine, se hai confermato che (molto probabilmente) il pagamento originale è stato "sostituito" nella tabella degli ordini da un rimborso, puoi eseguire questo comando:
wp edd migrate_payments --force --destroy --id=1234
L'esecuzione di questo comando eliminerà forzatamente l'ordine con ID 1234. Quindi migrerà il pagamento 1234 al suo posto. Se l'ordine 1234 era un rimborso, troverà l'ordine originale per esso (diciamo che era l'ordine/pagamento 123), quindi eliminerà l'ordine 123 ed eseguirà nuovamente la migrazione per il pagamento 123, che rigenererà l'oggetto ordine di rimborso. L'ID effettivo per qualsiasi rimborso non ha alcun significato, quindi rigenerare i rimborsi non è un grosso problema. I rimborsi sono localizzati tramite la colonna parent.
Se hai eseguito il downgrade a EDD 2.11 e stai eseguendo nuovamente la migrazione
Poiché non possiamo anticipare ogni scenario con le integrazioni, EDD consente ai negozi di eseguire il downgrade a EDD 2.11 e poi tornare alla versione 3.x quando sono pronti. In questi casi, suggeriamo di svuotare le tabelle appena create ed eseguire quindi la migrazione come se fosse la prima volta. Probabilmente dovrai utilizzare il comando CLI per eseguire la migrazione usando --force poiché EDD potrebbe aver già contrassegnato la migrazione come completata.
Prima di svuotare o eliminare qualsiasi tabella del database, assicurati di avere un backup completo del tuo database. Prova una migrazione su un sito di staging prima di eseguirla in produzione.
Ecco un elenco di tabelle create di recente per 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
Le tabelle customers, customermeta e notifications esistevano in EDD 2.x. Non svuotarle. Se utilizzi un'estensione come Commissions, Recurring Payments o Software Licensing, anche tali estensioni registrano tabelle personalizzate con edd nel nome e non dovrebbero essere svuotate.
Per migrare tutti i dati del negozio, usa questo comando (potrebbe essere necessario usare il flag --force per consentirne l'esecuzione di nuovo):
wp edd v30_migration
