Embora a maioria das lojas migrará do EDD 2.11 para o 3.x sem problemas, se você migrar seus dados e descobrir que alguns pedidos parecem estar faltando, existem ferramentas para ajudar na solução de problemas.
Antes de executar qualquer migração, certifique-se de que os dados da sua loja estejam em backup. É fortemente recomendado que você teste a migração em uma cópia local ou de homologação do seu site antes de fazê-la em produção.
Se você concluir que alguns pedidos estão faltando nas novas tabelas, o primeiro passo é descobrir quais. Você precisará ser capaz de olhar diretamente para as tabelas do seu banco de dados usando o PHPMyAdmin ou uma ferramenta semelhante. Esperançosamente, você tem uma ideia de quais pedidos podem estar faltando, seja sabendo o ID específico ou sabendo um intervalo de datas aproximado.
O primeiro passo é procurar na sua tabela wp_posts pelos pagamentos ausentes (no EDD 2.x, usamos a terminologia de pagamentos; no EDD 3.x, agora são pedidos). O post_type será edd_payment e você precisa encontrar o(s) ID(s) do(s) pagamento(s) que não migraram com sucesso.
Depois de anotar um ID de pagamento, o próximo passo é procurar na tabela wp_edd_orders por um pedido com o mesmo ID. Se ele não existir, a migração do pedido ausente é bastante simples; se ele existir, você pode ter um conflito. Você vai querer olhar cuidadosamente para o pedido e ver qual é o type. Geralmente, o que terá acontecido é que um registro de reembolso terá sido criado com o próximo ID disponível e isso impediu que o pagamento original pudesse migrar. Se o type do pedido for refund, isso é muito gerenciável, porque o ID do reembolso na verdade não importa.
Migrando Pedidos com CLI
Depois de saber o ID de um pedido ausente, você precisará executar uma migração parcial de pedidos. É útil começar garantindo que você saiba todos os dados originais do pagamento. Você pode usar este comando CLI para visualizá-lo:
wp edd display_legacy_payment_data 1234
Substitua 1234 pelo ID do pagamento original que você encontrou na tabela de posts. Isso exibirá tudo o que o EDD sabe sobre o pagamento original. Isso pode ser útil porque os dados são armazenados de forma diferente no EDD 3.x.
O comando de migração de pedidos padrão é apenas este:
wp edd migrate_payments
Sem opções, ele percorrerá todos os objetos de pagamento e os migrará, finalizando com a marcação da migração de pedidos como completa e, em seguida, recalculando as vendas/ganhos de todos os downloads na loja. Uma vez que o EDD tenha marcado a migração de pedidos como completa, você precisa adicionar algumas flags para executar outra migração; caso contrário, o EDD não o fará.
Este comando aceita várias flags que mudarão o comportamento:
--force: Isso forçará a migração a ser executada novamente, mesmo que já tenha sido executada. Pedidos existentes não serão sobrescritos. É necessária confirmação.--destroy: Isso forçará a migração a ser executada novamente, mesmo que já tenha sido executada. Pedidos/metadados de pedidos/itens de pedidos/etc. existentes que correspondem a um ID de pagamento serão excluídos e o pagamento será migrado novamente. Uma confirmação é necessária, pois esta é uma ação destrutiva.- Esta opção é útil quando pedidos de reembolso foram inseridos na tabela de pedidos no lugar de um ID de pagamento existente. Os reembolsos serão regenerados automaticamente com o próximo ID disponível na tabela de pedidos.
- Se o pedido existente não for um reembolso e parecer ser um pedido completamente diferente do que você está tentando migrar, uma confirmação adicional é necessária, pois isso provavelmente destruirá dados que não poderão ser recuperados.
--id: Isso executará uma migração parcial em um ID de pagamento específico (o ID na tabela de posts do WP, que pode ser diferente do número do pedido exibido).- Esta flag não pode ser usada com as flags de início/fim.
- Pode ser combinada com force/destroy.
- A migração do pedido não será marcada como concluída.
--start: Isso executará uma migração parcial começando com (e incluindo) um ID de pagamento específico.- Esta flag pode ser usada com ou sem a flag de fim.
- Esta flag não pode ser usada com a flag id.
- Pode ser combinada com force/destroy.
- A migração do pedido não será marcada como concluída.
--end: Isso executará uma migração parcial terminando com (e incluindo) um ID de pagamento específico.- Esta flag pode ser usada com ou sem a flag de início.
- Esta flag não pode ser usada com a flag id.
- Pode ser combinada com force/destroy.
- A migração do pedido não será marcada como concluída.
Portanto, se você quiser testar a remigração de um pedido, se você confirmou que (isso é o mais provável) o pagamento original foi "substituído" na tabela de pedidos por um reembolso, você pode executar este comando:
wp edd migrate_payments --force --destroy --id=1234
Executar este comando excluirá forçadamente o pedido com o ID 1234. Em seguida, ele migrará o pagamento 1234 em seu lugar. Se o pedido 1234 era um reembolso, ele encontrará o pedido original para isso (digamos que era o pedido/pagamento 123), e então excluirá o pedido 123 e executará a migração para o pagamento 123 novamente, o que regenerará o objeto do pedido de reembolso. O ID real para qualquer reembolso não significa nada, então regenerar reembolsos não é um grande problema. Reembolsos são localizados pela coluna parent.
Se Você Fez Downgrade para EDD 2.11 e Está Executando a Migração Novamente
Como não podemos antecipar todos os cenários com integrações, o EDD permite que as lojas façam downgrade para o EDD 2.11 e depois retornem para a versão 3.x quando estiverem prontas. Nesses casos, sugerimos que você esvazie as tabelas recém-criadas e, em seguida, execute a migração como se fosse a primeira vez. Você provavelmente precisará usar o comando CLI para executar a migração usando --force, pois o EDD pode já ter marcado a migração como concluída.
Antes de esvaziar ou excluir quaisquer tabelas do banco de dados, certifique-se de ter um backup completo do seu banco de dados. Pratique uma migração em um site de staging antes de confirmar em produção.
Aqui está uma lista de tabelas que são recém-criadas para o 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
As tabelas customers, customermeta e notifications já existiam no EDD 2.x. Não as esvazie. Se você usa uma extensão como Commissions, Recurring Payments ou Software Licensing, essas extensões também registram tabelas personalizadas com edd no nome e não devem ser esvaziadas.
Para migrar todos os dados da loja, use este comando (pode ser necessário usar o sinalizador --force para permitir que ele seja executado novamente):
wp edd v30_migration
