# Risoluzione dei problemi di migrazione EDD 3.x Sebbene 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 essere 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 consigliato** 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 conoscendo 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/dei 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 quale sia 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 degli 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 del pagamento originale. Puoi usare questo comando CLI per visualizzarlo: ``` 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 dell'ordine predefinito è semplicemente questo: ``` wp edd migrate_payments ``` Senza opzioni, eseguirà ogni oggetto **payment** e lo migrerà, terminando con la marcatura del completamento della migrazione dell'ordine e quindi ricalcolando le vendite/guadagni per tutti i download nel negozio. Una volta che EDD ha contrassegnato il completamento della migrazione dell'ordine, devi aggiungere alcuni flag per eseguire un'altra migrazione; altrimenti, EDD non lo farà. Questo comando accetta più flag che cambieranno il comportamento: - `--force`: Forza la migrazione a essere eseguita di nuovo, anche se è già stata eseguita. Gli **ordini** esistenti non verranno sovrascritti. È richiesta una conferma. - `--destroy`: Forza la migrazione a essere eseguita di nuovo, anche se è già stata eseguita. Gli **ordini**/metadati dell'ordine/elementi dell'ordine/ecc. esistenti 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é è probabile che si tratti di distruggere dati che non potranno essere recuperati. - `--id`: Esegue 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`: Esegue 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`: Esegue 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 quello (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 di qualsiasi rimborso non ha importanza, quindi rigenerare i rimborsi non è un grosso problema. I rimborsi vengono individuati dalla 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 quindi tornare a 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 usare 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. Esegui 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 ```