ほとんどのストアはEDD 2.11から3.xへ問題なく移行できますが、データを移行した後に一部の注文が見当たらない場合は、トラブルシューティングのためのツールがあります。
移行を実行する前に、必ずストアのデータをバックアップしてください。本番環境で移行を実行する前に、ローカルまたはステージング環境のサイトコピーで移行をテストすることを強く推奨します。
新しいテーブルから一部の注文が欠落していると判断した場合、最初のステップはどの注文が欠落しているかを特定することです。PHPMyAdminなどのツールを使用してデータベーステーブルを直接確認できる必要があります。特定のIDを知っているか、おおよその日付範囲を知っているかによって、どの注文が欠落している可能性があるかについてのアイデアがあることを願っています。
最初のステップは、欠落している支払い（EDD 2.xでは支払いという用語を使用しますが、EDD 3.xでは注文と呼ばれます）をwp_postsテーブルで確認することです。post_typeはedd_paymentであり、正常に移行できなかった支払いのIDを見つける必要があります。
支払いIDを記録したら、次のステップはwp_edd_ordersテーブルで同じIDを持つ注文を確認することです。存在しない場合は、欠落している注文の移行は非常に簡単です。存在する場合は、競合が発生している可能性があります。注文を注意深く確認し、typeが何であるかを確認してください。通常、発生しているのは、次の利用可能なIDで返金レコードが作成され、元の支払いが移行できなかったという状況です。注文typeがrefundの場合、返金のIDは実際には重要ではないため、これは非常に管理しやすいです。
CLIを使用した注文の移行
欠落している注文のIDがわかったら、部分的な注文移行を実行する必要があります。元の支払いデータのすべてを把握していることを確認することから始めるのが役立ちます。このCLIコマンドを使用して表示できます：
wp edd display_legacy_payment_data 1234
1234を、postsテーブルで見つけた元の支払いIDに置き換えてください。これにより、EDDが元の支払いについて知っているすべてが表示されます。EDD 3.xではデータが異なる方法で保存されているため、これは役立ちます。
デフォルトの注文移行コマンドは次のとおりです：
wp edd migrate_payments
オプションなしで実行すると、すべての支払いオブジェクトを処理して移行し、注文移行完了のマークを付け、ストア内のすべてのダウンロードの売上/収益を再計算します。EDDが注文移行完了のマークを付けたら、別の移行を実行するためにフラグを追加する必要があります。そうしないと、EDDは実行しません。
このコマンドは、動作を変更する複数のフラグを受け入れます：
--force: 既に実行されている場合でも、移行を強制的に再度実行します。既存の注文は上書きされません。確認が必要です。--destroy: これにより、すでに実行されている場合でも、移行が再度実行されます。既存の注文/注文メタ/注文アイテムなど、支払いIDと一致するものは削除され、支払いは再度移行されます。これは破壊的なアクションであるため、確認が必要です。- このオプションは、返金注文が既存の支払いIDの代わりに注文テーブルに挿入された場合に役立ちます。返金は、注文テーブル内の次の利用可能なIDで自動的に再生成されます。
- 既存の注文が返金でなく、移行しようとしている注文と完全に異なると思われる場合、追加の確認が必要です。これは、回復不能なデータを破壊する可能性が高いからです。
--id: 特定の支払いID（表示されている注文番号とは異なる場合がある、WP投稿テーブルのID）で部分的な移行を実行します。- このフラグは、開始/終了フラグと一緒に使用することはできません。
- force/destroyフラグと組み合わせることができます。
- 注文移行は完了としてマークされません。
--start: 特定の支払いIDから（それを含めて）始まる部分的な移行を実行します。- このフラグは、終了フラグと組み合わせて使用することも、単独で使用することもできます。
- このフラグは、idフラグと一緒に使用することはできません。
- force/destroyフラグと組み合わせることができます。
- 注文移行は完了としてマークされません。
--end: 特定の支払いIDで（それを含めて）終わる部分的な移行を実行します。- このフラグは、開始フラグと組み合わせて使用することも、単独で使用することもできます。
- このフラグは、idフラグと一緒に使用することはできません。
- force/destroyフラグと組み合わせることができます。
- 注文移行は完了としてマークされません。
したがって、注文の再移行をテストしたい場合、元の支払いが返金によって注文テーブルで「置き換え」られたことを確認した場合（これが最も可能性が高い）、次のコマンドを実行できます。
wp edd migrate_payments --force --destroy --id=1234
このコマンドを実行すると、IDが1234の注文が強制的に削除されます。次に、その代わりに支払い1234が移行されます。注文1234が返金だった場合、その元の注文（たとえば、注文/支払い123）が見つかり、次に注文123が削除され、支払い123の移行が再度実行され、返金注文オブジェクトが再生成されます。返金の実際のIDは意味を持たないため、返金の再生成は問題ありません。返金はparent列によって検索されます。
EDD 2.11にダウングレードして移行を再度実行する場合
統合のすべてのシナリオを予測することはできないため、EDDではストアがEDD 2.11にダウングレードしてから準備ができたときに3.xに戻すことができます。これらの場合、新しく作成されたテーブルを空にしてから、初めて移行を実行するように移行を実行することをお勧めします。EDDがすでに移行を完了としてマークしている可能性があるため、移行を実行するために--forceを使用したCLIコマンドを使用する必要があるでしょう。
データベーステーブルを空にする、または削除する前に、データベースの完全なバックアップがあることを確認してください。本番環境にコミットする前に、ステージングサイトで移行をテストしてください。
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
customers、customermeta、notifications テーブルは EDD 2.x に存在していました。それらを空にしないでください。Commissions、Recurring Payments、Software Licensing などの拡張機能を使用している場合、それらの拡張機能は edd という名前のカスタムテーブルも登録しており、空にしないでください。
ストアデータをすべて移行するには、このコマンドを使用します（再度実行するには --force フラグを使用する必要がある場合があります）。
wp edd v30_migration
