Deși majoritatea magazinelor vor migra de la EDD 2.11 la 3.x fără probleme, dacă migrați datele și descoperiți că unele comenzi par să lipsească, există instrumente care vă pot ajuta la depanare.
Înainte de a rula orice migrare, asigurați-vă că datele magazinului dvs. sunt salvate. Este puternic recomandat să testați migrarea pe o copie locală sau de staging a site-ului dvs. înainte de a o face în producție.
Dacă ajungeți la concluzia că lipsesc unele comenzi din noile tabele, primul pas este să aflați care. Va trebui să puteți vizualiza direct tabelele bazei de date folosind PHPMyAdmin sau un instrument similar. Sperăm că aveți o idee despre ce comenzi ar putea lipsi, fie cunoscând ID-ul specific, fie cunoscând un interval de date aproximativ.
Primul pas este să căutați în tabelul dvs. wp_posts pentru plățile lipsă (în EDD 2.x, folosim terminologia plăți; în EDD 3.x, acestea sunt acum comenzi). post_type va fi edd_payment și trebuie să găsiți ID-ul (ID-urile) pentru plata (plățile) care nu au migrat cu succes.
Odată ce ați notat un ID de plată, următorul pas este să căutați în tabelul wp_edd_orders o comandă cu același ID. Dacă nu există, atunci migrarea comenzii lipsă este destul de simplă; dacă există, este posibil să aveți un conflict. Va trebui să examinați cu atenție comanda și să vedeți care este type. De obicei, ceea ce s-a întâmplat este că un record de rambursare a fost creat cu următorul ID disponibil și acest lucru a împiedicat plata originală să poată migra. Dacă type-ul comenzii este refund, atunci acest lucru este foarte gestionabil, deoarece ID-ul rambursării nu contează de fapt.
Migrarea comenzilor cu CLI
Odată ce cunoașteți ID-ul unei comenzi lipsă, va trebui să rulați o migrare parțială a comenzilor. Este util să începeți prin a vă asigura că știți toate datele originale ale plății. Puteți folosi această comandă CLI pentru a le vizualiza:
wp edd display_legacy_payment_data 1234
Înlocuiți 1234 cu ID-ul plății originale pe care l-ați găsit în tabelul posts. Aceasta va afișa tot ceea ce EDD știe despre plata originală. Acest lucru poate fi util, deoarece datele sunt stocate diferit în EDD 3.x.
Comanda implicită de migrare a comenzilor este doar aceasta:
wp edd migrate_payments
Fără opțiuni, va parcurge fiecare obiect plată și îl va migra, terminând prin marcarea migrării comenzilor ca fiind completă și apoi recalcularea vânzărilor/câștigurilor pentru toate descărcările din magazin. Odată ce EDD a marcat migrarea comenzilor ca fiind completă, trebuie să adăugați câteva flag-uri pentru a rula o altă migrare; altfel, EDD nu o va face.
Această comandă acceptă mai multe flag-uri care vor schimba comportamentul:
--force: Aceasta va forța rularea din nou a migrării, chiar dacă a fost deja rulată. Comenzile existente nu vor fi suprascrise. Este necesară o confirmare.--destroy: Aceasta va forța rularea din nou a migrării, chiar dacă a fost deja executată. Comenzile existente/meta comenzilor/articolele comenzilor/etc. care corespund unui ID de plată vor fi șterse, iar plata va fi migrată din nou. Este necesară o confirmare, deoarece aceasta este o acțiune distructivă.- Această opțiune este utilă atunci când comenzile de rambursare au fost inserate în tabelul comenzilor în locul unui ID de plată existent. Rambursările vor fi regenerate automat cu următorul ID disponibil în tabelul comenzilor.
- Dacă comanda existentă nu este o rambursare și pare a fi o comandă complet diferită de cea pe care încercați să o migrați, este necesară o confirmare suplimentară, deoarece este probabil să distrugeți date care nu vor putea fi recuperate.
--id: Aceasta va rula o migrare parțială pe un ID de plată specific (ID-ul din tabelul WP posts, care poate fi diferit de numărul afișat al comenzii).- Acest flag nu poate fi utilizat cu flagurile start/end.
- Poate fi combinat cu force/destroy.
- Migrarea comenzii nu va fi marcată ca finalizată.
--start: Aceasta va rula o migrare parțială începând cu (și incluzând) un ID de plată specific.- Acest flag poate fi utilizat cu sau fără flagul end.
- Acest flag nu poate fi utilizat cu flagul id.
- Poate fi combinat cu force/destroy.
- Migrarea comenzii nu va fi marcată ca finalizată.
--end: Aceasta va rula o migrare parțială terminând cu (și incluzând) un ID de plată specific.- Acest flag poate fi utilizat cu sau fără flagul start.
- Acest flag nu poate fi utilizat cu flagul id.
- Poate fi combinat cu force/destroy.
- Migrarea comenzii nu va fi marcată ca finalizată.
Deci, dacă doriți să testați re-migrarea unei comenzi, dacă ați confirmat că (cel mai probabil) plata originală a fost „înlocuită” în tabelul comenzilor de o rambursare, puteți rula această comandă:
wp edd migrate_payments --force --destroy --id=1234
Rularea acestei comenzi va șterge forțat comanda cu ID-ul 1234. Apoi va migra plata 1234 în locul ei. Dacă comanda 1234 a fost o rambursare, va găsi comanda originală pentru aceasta (să spunem că a fost comanda/plata 123), apoi va șterge comanda 123 și va rula din nou migrarea pentru plata 123, ceea ce va regenera obiectul comenzii de rambursare. ID-ul real pentru orice rambursare nu înseamnă nimic, deci regenerarea rambursărilor nu este o problemă. Rambursările sunt localizate prin coloana parent.
Dacă ați revenit la EDD 2.11 și rulați din nou migrarea
Deoarece nu putem anticipa fiecare scenariu cu integrările, EDD permite magazinelor să revină la EDD 2.11 și apoi să revină la 3.x când sunt pregătite. În aceste cazuri, sugerăm să goliți tabelele nou create și apoi să rulați migrarea ca și cum ar fi prima dată. Probabil va trebui să utilizați comanda CLI pentru a rula migrarea folosind --force, deoarece EDD ar fi putut deja marca migrarea ca finalizată.
Înainte de a goli sau șterge orice tabele de baze de date, asigurați-vă că aveți o copie de rezervă completă a bazei de date. Testați o migrare pe un site de staging înainte de a o aplica în producție.
Iată o listă de tabele nou create pentru 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
Tabelele customers, customermeta și notifications existau în EDD 2.x. Nu goliți acele tabele. Dacă utilizați o extensie precum Commissions, Recurring Payments sau Software Licensing, acele extensii înregistrează, de asemenea, tabele personalizate cu edd în nume și nu ar trebui golite.
Pentru a migra toate datele magazinului, utilizați această comandă (este posibil să fie necesar să utilizați flag-ul --force pentru a permite rularea din nou):
wp edd v30_migration
