Bien que la plupart des boutiques migrent d'EDD 2.11 vers 3.x sans problème, si vous migrez vos données et constatez que certaines commandes semblent manquantes, des outils peuvent vous aider à résoudre le problème.
Avant d'exécuter une migration, assurez-vous que les données de votre boutique sont sauvegardées. Il est fortement recommandé de tester la migration sur une copie locale ou de staging de votre site avant de le faire en production.
Si vous concluez que certaines commandes sont manquantes dans les nouvelles tables, la première étape consiste à déterminer lesquelles. Vous devrez pouvoir consulter directement vos tables de base de données à l'aide de PHPMyAdmin ou d'un outil similaire. Vous avez probablement une idée des commandes qui pourraient manquer, soit en connaissant l'ID spécifique, soit en connaissant une plage de dates approximative.
La première étape consiste à rechercher dans votre table wp_posts les paiements manquants (dans EDD 2.x, nous utilisons la terminologie des paiements ; dans EDD 3.x, ce sont maintenant des commandes). Le post_type sera edd_payment et vous devez trouver l'ID des paiements qui n'ont pas migré avec succès.
Une fois que vous avez noté un ID de paiement, l'étape suivante consiste à rechercher dans la table wp_edd_orders une commande portant le même ID. Si elle n'existe pas, la migration de la commande manquante est assez simple ; si elle existe, vous pourriez avoir un conflit. Vous voudrez examiner attentivement la commande et voir quel est le type. Habituellement, ce qui s'est passé, c'est qu'un enregistrement de remboursement a été créé avec le prochain ID disponible et cela a empêché le paiement d'origine de migrer. Si le type de commande est refund, alors c'est très gérable, car l'ID du remboursement n'a pas vraiment d'importance.
Migration des commandes avec CLI
Une fois que vous connaissez l'ID d'une commande manquante, vous devrez exécuter une migration de commande partielle. Il est utile de commencer par vous assurer que vous connaissez toutes les données de paiement d'origine. Vous pouvez utiliser cette commande CLI pour les afficher :
wp edd display_legacy_payment_data 1234
Remplacez 1234 par l'ID de paiement d'origine que vous avez trouvé dans la table des posts. Cela affichera tout ce qu'EDD sait sur le paiement d'origine. Cela peut être utile car les données sont stockées différemment dans EDD 3.x.
La commande de migration de commande par défaut est simplement celle-ci :
wp edd migrate_payments
Sans options, elle parcourra chaque objet paiement et le migrera, en terminant par le marquage de la migration de commande comme terminée, puis en recalculant les ventes/gains pour tous les téléchargements de la boutique. Une fois qu'EDD a marqué la migration de commande comme terminée, vous devez ajouter des indicateurs pour exécuter une autre migration ; sinon, EDD ne le fera pas.
Cette commande accepte plusieurs indicateurs qui modifieront son comportement :
--force: Cela forcera la migration à s'exécuter à nouveau, même si elle a déjà été exécutée. Les commandes existantes ne seront pas écrasées. Une confirmation est requise.--destroy: This will force the migration to run again, even if it’s already been run. Existing orders/order meta/order items/etc which match a payment ID will be deleted and the payment will be migrated again. A confirmation is required, because this is a destructive action.- Cette option est utile lorsque les commandes de remboursement ont été insérées dans la table des commandes à la place d'un identifiant de paiement existant. Les remboursements seront automatiquement régénérés avec le prochain identifiant disponible dans la table des commandes.
- Si la commande existante n'est pas un remboursement et semble être une commande entièrement différente de celle que vous essayez de migrer, une confirmation supplémentaire est requise, car cela détruira probablement des données qui ne pourront pas être récupérées.
--id: This will run a partial migration on a specific payment ID (the ID in the WP posts table, which may be different from the displayed order number).- Ce drapeau ne peut pas être utilisé avec les drapeaux de début/fin.
- Il peut être combiné avec forcer/détruire.
- La migration de la commande ne sera pas marquée comme terminée.
--start: This will run a partial migration beginning with (and including) a specific payment ID.- Ce drapeau peut être utilisé avec ou sans le drapeau de fin.
- Ce drapeau ne peut pas être utilisé avec le drapeau d'identifiant.
- Il peut être combiné avec forcer/détruire.
- La migration de la commande ne sera pas marquée comme terminée.
--end: This will run a partial migration ending with (and including) a specific payment ID.- Ce drapeau peut être utilisé avec ou sans le drapeau de début.
- Ce drapeau ne peut pas être utilisé avec le drapeau d'identifiant.
- Il peut être combiné avec forcer/détruire.
- La migration de la commande ne sera pas marquée comme terminée.
Donc, si vous voulez tester la re-migration d'une commande, si vous avez confirmé que (c'est le plus probable) le paiement d'origine a été « remplacé » dans la table des commandes par un remboursement, vous pouvez exécuter cette commande :
wp edd migrate_payments --force --destroy --id=1234
L'exécution de cette commande supprimera de force la commande avec l'ID 1234. Ensuite, elle migrera le paiement 1234 à sa place. Si la commande 1234 était un remboursement, elle trouvera la commande d'origine correspondante (disons la commande/paiement 123), puis supprimera la commande 123 et relancera la migration pour le paiement 123, ce qui régénérera l'objet de commande de remboursement. L'ID réel de tout remboursement n'a pas d'importance, donc la régénération des remboursements n'est pas un problème. Les remboursements sont localisés par la colonne parent.
Si vous êtes passé à EDD 2.11 et que vous relancez la migration
Parce que nous ne pouvons pas anticiper tous les scénarios avec les intégrations, EDD permet aux boutiques de revenir à EDD 2.11, puis de revenir à la version 3.x lorsqu'elles sont prêtes. Dans ces cas, nous vous suggérons de vider les tables nouvellement créées, puis de lancer la migration comme si c'était la première fois. Vous devrez probablement utiliser la commande CLI pour exécuter la migration avec --force car EDD a peut-être déjà marqué la migration comme terminée.
Avant de vider ou de supprimer des tables de base de données, assurez-vous d'avoir une sauvegarde complète de votre base de données. Testez une migration sur un site de staging avant de la déployer en production.
Voici une liste des tables nouvellement créées pour 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
Les tables customers, customermeta et notifications existaient dans EDD 2.x. Ne les videz pas. Si vous utilisez une extension telle que Commissions, Paiements Récurrents ou Licences de Logiciels, ces extensions enregistrent également des tables personnalisées avec « edd » dans le nom et ne doivent pas être vidées.
Pour migrer toutes les données du magasin, utilisez cette commande (vous devrez peut-être utiliser le drapeau --force pour lui permettre de s'exécuter à nouveau) :
wp edd v30_migration
