Chociaż większość sklepów zostanie pomyślnie zmigrowana z EDD 2.11 do 3.x, jeśli po migracji danych okaże się, że brakuje niektórych zamówień, istnieją narzędzia, które pomogą w rozwiązywaniu problemów.
Przed uruchomieniem jakiejkolwiek migracji upewnij się, że dane Twojego sklepu są zarchiwizowane. Zdecydowanie zaleca się przetestowanie migracji na lokalnej kopii lub kopii stagingowej Twojej witryny przed wykonaniem jej w środowisku produkcyjnym.
Jeśli stwierdzisz, że brakuje niektórych zamówień w nowych tabelach, pierwszym krokiem jest ustalenie, których. Będziesz musiał mieć możliwość bezpośredniego przeglądania tabel bazy danych za pomocą PHPMyAdmin lub podobnego narzędzia. Mam nadzieję, że masz pojęcie, jakich zamówień może brakować, albo znając konkretny identyfikator, albo znając przybliżony zakres dat.
Pierwszym krokiem jest sprawdzenie tabeli wp_posts pod kątem brakujących płatności (w EDD 2.x używamy terminologii płatności; w EDD 3.x są to teraz zamówienia). post_type będzie miało wartość edd_payment i musisz znaleźć identyfikator(y) płatności, które nie zostały pomyślnie zmigrowane.
Gdy już zanotujesz identyfikator płatności, następnym krokiem jest sprawdzenie tabeli wp_edd_orders pod kątem zamówienia o tym samym identyfikatorze. Jeśli nie istnieje, migracja brakującego zamówienia jest dość prosta; jeśli istnieje, możesz mieć konflikt. Będziesz chciał dokładnie przyjrzeć się zamówieniu i zobaczyć, jaki jest type. Zazwyczaj zdarza się, że rekord zwrotu zostanie utworzony z następnym dostępnym identyfikatorem, co uniemożliwiło migrację oryginalnej płatności. Jeśli type zamówienia to refund, jest to bardzo łatwe do opanowania, ponieważ identyfikator zwrotu tak naprawdę nie ma znaczenia.
Migracja zamówień za pomocą CLI
Gdy znasz identyfikator brakującego zamówienia, będziesz musiał przeprowadzić częściową migrację zamówienia. Pomocne jest upewnienie się, że znasz wszystkie oryginalne dane płatności. Możesz użyć tego polecenia CLI, aby je wyświetlić:
wp edd display_legacy_payment_data 1234
Zastąp 1234 oryginalnym identyfikatorem płatności znalezionym w tabeli posts. Wyświetli to wszystko, co EDD wie o oryginalnej płatności. Może to być pomocne, ponieważ dane są przechowywane inaczej w EDD 3.x.
Domyślne polecenie migracji zamówień to po prostu:
wp edd migrate_payments
Bez żadnych opcji, przejdzie przez każdy obiekt płatności i go zmigruje, kończąc oznaczeniem migracji zamówień jako zakończonej, a następnie przeliczając sprzedaż/zarobki dla wszystkich pobrań w sklepie. Gdy EDD oznaczy migrację zamówień jako zakończoną, musisz dodać kilka flag, aby uruchomić kolejną migrację; w przeciwnym razie EDD tego nie zrobi.
To polecenie akceptuje wiele flag, które zmienią jego zachowanie:
--force: Wymusi ponowne uruchomienie migracji, nawet jeśli została już uruchomiona. Istniejące zamówienia nie zostaną nadpisane. Wymagane jest potwierdzenie.--destroy: To wymusi ponowne uruchomienie migracji, nawet jeśli została już przeprowadzona. Istniejące zamówienia/meta zamówień/pozycje zamówień/itp. pasujące do identyfikatora płatności zostaną usunięte, a płatność zostanie ponownie zmigrowana. Wymagane jest potwierdzenie, ponieważ jest to akcja niszcząca.- Ta opcja jest pomocna, gdy zwroty zamówień zostały wstawione do tabeli zamówień zamiast istniejącego identyfikatora płatności. Zwroty zostaną automatycznie wygenerowane ponownie z następnym dostępnym identyfikatorem w tabeli zamówień.
- Jeśli istniejące zamówienie nie jest zwrotem i wydaje się być zupełnie innym zamówieniem niż to, które próbujesz migrować, wymagane jest dodatkowe potwierdzenie, ponieważ prawdopodobnie niszczy to dane, których nie będzie można odzyskać.
--id: To uruchomi częściową migrację dla konkretnego identyfikatora płatności (identyfikator w tabeli postów WP, który może różnić się od wyświetlanego numeru zamówienia).- Ta flaga nie może być używana z flagami start/end.
- Może być łączona z force/destroy.
- Migracja zamówienia nie zostanie oznaczona jako zakończona.
--start: To uruchomi częściową migrację, zaczynając od (i włączając) konkretnego identyfikatora płatności.- Ta flaga może być używana z flagą end lub bez niej.
- Ta flaga nie może być używana z flagą id.
- Może być łączona z force/destroy.
- Migracja zamówienia nie zostanie oznaczona jako zakończona.
--end: To uruchomi częściową migrację, kończąc na (i włączając) konkretnym identyfikatorze płatności.- Ta flaga może być używana z flagą start lub bez niej.
- Ta flaga nie może być używana z flagą id.
- Może być łączona z force/destroy.
- Migracja zamówienia nie zostanie oznaczona jako zakończona.
Więc jeśli chcesz przetestować ponowną migrację zamówienia, jeśli potwierdziłeś, że (najprawdopodobniej) oryginalna płatność została „zastąpiona” w tabeli zamówień przez zwrot, możesz użyć tego polecenia:
wp edd migrate_payments --force --destroy --id=1234
Uruchomienie tego polecenia spowoduje wymuszone usunięcie zamówienia o identyfikatorze 1234. Następnie zmigruje płatność 1234 na jego miejsce. Jeśli zamówienie 1234 było zwrotem, znajdzie oryginalne zamówienie dla tego (powiedzmy, że było to zamówienie/płatność 123), a następnie usunie zamówienie 123 i ponownie uruchomi migrację dla płatności 123, co odtworzy obiekt zwrotu zamówienia. Rzeczywisty identyfikator dla dowolnego zwrotu nic nie znaczy, więc odtwarzanie zwrotów nie jest problemem. Zwroty są lokalizowane przez kolumnę parent.
Jeśli cofnąłeś się do EDD 2.11 i ponownie uruchamiasz migrację
Ponieważ nie możemy przewidzieć każdego scenariusza z integracjami, EDD pozwala sklepom na cofnięcie się do EDD 2.11, a następnie powrót do wersji 3.x, gdy będą gotowe. W takich przypadkach sugerujemy opróżnienie nowo utworzonych tabel, a następnie uruchomienie migracji, jakby była to pierwsza raz. Prawdopodobnie będziesz musiał użyć polecenia CLI do uruchomienia migracji za pomocą --force, ponieważ EDD mogło już oznaczyć migrację jako zakończoną.
Przed opróżnieniem lub usunięciem jakichkolwiek tabel bazy danych upewnij się, że masz pełną kopię zapasową swojej bazy danych. Przetestuj migrację na stronie staging przed wdrożeniem na produkcji.
Oto lista tabel, które zostały nowo utworzone dla 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
Tabele customers, customermeta i notifications istniały w EDD 2.x. Nie opróżniaj ich. Jeśli używasz rozszerzenia takiego jak Commissions, Recurring Payments lub Software Licensing, te rozszerzenia również rejestrują niestandardowe tabele z edd w nazwie i nie powinny być opróżniane.
Aby przeprowadzić migrację wszystkich danych sklepu, użyj tego polecenia (może być konieczne użycie flagi --force, aby umożliwić ponowne uruchomienie):
wp edd v30_migration
