WooCommerce : pourquoi il est difficile de migrer entre la mise en scène et la production… et comment contourner ce problème

Bien que nous soyons à l’aise de déclarer notre expertise dans WordPress, ce n’est pas le cas. sans défis. Un problème assez frustrant est l’architecture de la base de données utilisée pour WooCommerce. Plus précisément, divers enregistrements sont stockés dans le wp_posts tableau dans WordPress, et leur type de publication les catégorise. Voici une liste de quelques types de publications courants utilisés, ainsi qu’une brève description de chacun :

1. Produit: Type de poste product est utilisé pour stocker des informations sur les produits individuels dans votre boutique WooCommerce. Cela inclut le nom du produit, le prix, la description et plus de détails.
2. Variation du produit: Type de poste product_variation représente différentes variations du produit, telles que les options de taille ou de couleur. Ceux-ci sont liés au produit principal.
3. Commande: Type de poste shop_order stocke des informations sur les commandes des clients, y compris le statut de la commande, les détails du client et les articles commandés.
4. Remboursement de la commande: Type de poste shop_order_refund suit les remboursements associés à des commandes spécifiques.
5. Coupon: Type de poste shop_coupon stocke les détails sur les coupons et les réductions qui peuvent être appliqués aux commandes.
6. Acheter le webhook: Type de poste shop_webhook est utilisé pour stocker des informations liées aux webhooks, qui peuvent être utilisées pour déclencher des actions en réponse aux événements de votre boutique WooCommerce.
7. Abonnement à la boutique: Type de poste shop_subscription Cela est pertinent si votre magasin propose des produits par abonnement et stocke des informations sur les abonnements des clients.
8. Renouvellement de l’abonnement à la boutique: Type de poste shop_subscription_renewal est utilisé pour enregistrer les renouvellements d’abonnement.
9. Changer d’abonnement: Type de poste shop_subscription_switch suit les modifications ou les changements dans les produits d’abonnement.
10. Abonnement à la boutique en attente de paiement: Type de poste shop_subscription_pending_payment représente les ordres de souscription avec des paiements en attente.
11. Échec de l’abonnement à la boutique: Type de poste shop_subscription_failed est utilisé pour enregistrer les paiements d’abonnement échoués.
12. Évaluation du produit: Type de poste product_review est utilisé pour stocker les avis des clients sur les produits. Chaque avis est traité comme une publication distincte, comprenant les informations sur l’évaluateur, le texte de l’avis et les notes du produit associé.

Si vous concevez ou implémentez un nouveau thème pour WordPress, vous transférez généralement une copie du site et de la base de données vers un environnement de développement ou de développement local. Pendant ce temps, le site continue de collecter les commandes et autres événements applicables au commerce électronique.

Conflits de base de données dans wp_posts

En d’autres termes, des enregistrements créés en production entreront en conflit avec eux. Exemple : vous ajoutez une nouvelle page lors de la préparation et le prochain ID incrémentiel est 6702. Cependant, il existe une commande dans votre environnement de production qui utilise le même ID incrémentiel de 6702. Cela pose quelques problèmes :

• Numéros de commande ne sont pas séquentiels. Si vous avez une commande de 5 et que vous créez ensuite 3 pages, votre prochain identifiant de commande est 9. L’affichage de votre identifiant de commande ne vous donne aucun aperçu du nombre de commandes que vous avez exécutées sur votre site.
• Numéros de commande ne peut pas être modifié ! WooCommerce utilise cet identifiant et le communique directement à votre client dans toutes les factures et références de commande ultérieures.

Il est assez troublant que les ingénieurs de WooCommerce n’aient pas utilisé de champ supplémentaire pour les commandes, à la fois séquentiel et unique, mais différent de leur identifiant interne. En d’autres termes, l’ID 6702 aurait pu être la facture 4322… et facilement ajouté entre des bases de données avec un ID différent dans wp_posts. Les produits le font avec un facultatif UGS domaine, mais il n’est pas non plus entièrement intégré à la plate-forme pour l’utiliser comme clé primaire.

J’admire la simplicité de cette approche pour étendre la plateforme au commerce. Cela dit, je suis également choqué qu’ils ne soient pas allés plus loin pour résoudre ce problème. Cela signifie qu’il n’existe pas de moyen simple de prendre un environnement de test et de le synchroniser avec la production pour le mettre en ligne avec un nouveau thème.

Comment résoudre ce problème

Il existe une solution à ce problème, mais elle n’est pas simple. Suite d’importation et d’exportation pour WooCommerce est la solution que j’ai utilisée et cela en fait un processus beaucoup plus gérable.

Étape 1 : Exportez les données de commande en cours depuis votre environnement de production

Dans votre environnement de production, vous pouvez exporter chacun des types de publication critiques. Vous pouvez également utiliser un filtrage avancé… comme utiliser la date de la dernière commande dans votre zone de préparation pour inclure uniquement les commandes après la désynchronisation de vos données.

Étape 2 : Importez les données de commande actuelles dans votre environnement de préparation

Vous pouvez ensuite importer ces données dans le format de fichier par défaut dans votre environnement intermédiaire, en vous assurant de ne pas écraser les données actuelles de la base de données.

Étape 3 : Résoudre les identifiants conflictuels

Au fur et à mesure que le plugin parcourt les enregistrements à importer, il signalera s’il existe ou non des conflits sur des identifiants spécifiques. C’est à ce moment-là que ça devient un peu plus difficile.

Se connecter directement au MySQL base de données, j’ai dû rechercher ces identifiants dans la wp_posts table pour déterminer de quel type de disque il s’agissait. S’il s’agissait d’une page ou d’un article, je les ai simplement copiés pour m’assurer qu’ils utilisaient un nouvel identifiant. Si c’était autre chose, je devais déterminer comment y faire face.

Une fois tous les conflits éliminés, j’ai réimporté les données et tous les enregistrements ont été importés avec succès. Une fois tous les conflits de données résolus, j’ai pu pousser la mise en scène en production. Une fonctionnalité intéressante du plugin était que je n’avais pas besoin de recharger l’importation, je pouvais simplement réexécuter l’importation dans l’onglet historique.