Ignorer les commandes et produits WooCommerce

By , Founder · Updated

Si tu utilises la dernière version de WooCommerce, tu peux activer les tables WooCommerce personnalisées (HPOS) et ignorer la plupart des étapes de cet article pour suivre des instructions plus simples.

Lis plutôt ces deux articles :
– Comment transférer les produits et clients WooCommerce du site live vers le site de staging
– Comment exclure les commandes WooCommerce de la copie vers le site live avec HPOS

Comment empêcher les commandes et produits WooCommerce d’être écrasés lors du déploiement

Chaque fois que tu utilises WP STAGING pour déployer des données du site de staging vers le site live, tu dois t’assurer que les commandes, clients et produits WooCommerce sur le site live ne sont en aucune façon affectés et restent intacts.

Quelle est donc la meilleure façon d’éviter que ces données soient écrasées lors du processus de déploiement ?

La réponse courte est : tu ne peux pas empêcher ces données d’être copiées sur ton site de staging, et tu ne peux pas fusionner automatiquement les commandes et produits WooCommerce du site live et du staging. Mais heureusement, il existe un moyen de ne pas perdre tes commandes et produits sur le site de production, mais cela nécessite un travail manuel.

Important : Certains Plugins prétendent pouvoir fusionner automatiquement, mais ne les crois pas. Nous les avons tous testés, et il est techniquement impossible d’effectuer une telle fusion automatiquement et de manière fiable.

 

Pire encore, certains Plugins prétendent pouvoir effectuer une telle fusion, pour finalement constater que les commandes et produits ont été écrasés sans aucun avertissement. Cela peut donc détruire l’intégrité des données, et tu ne t’en rendrais même pas compte si tu ne vérifies pas chaque commande et produit après une telle fusion.

D’abord, nous devons comprendre où WooCommerce et WordPress stockent les commandes, les produits, les données utilisateurs comme les adresses clients, et toutes les autres données comme les articles et pages :

  • Les commandes et produits sont stockés dans les tables wp_posts et wp_postmeta, séparés par un champ de type de publication personnalisé nommé « orders ».
  • WordPress lui-même stocke également la plupart de ses données comme les pages, articles, entrées de menu et tout le reste dans les mêmes tables wp_posts et wp_postmeta
  • Les utilisateurs sont stockés dans wp_users et wp_usermeta

De nombreuses autres tables personnalisées WooCommerce contiennent des données comme les taux de taxe, les éléments de commande et les paramètres généraux de WooCommerce.

Chaque nom de table du site de staging commence par le préfixe  wpstg(x)_

Les noms de tables WooCommerce commencent par le même préfixe, mais commencent également par _woocommerce comme wpstg(x)_woocommerce_

Le x dans le préfixe de table est le numéro de ton site de staging. Donc si tu as plusieurs sites de staging, ce numéro sera incrémenté comme wpstg1_, wpstg2_ et ainsi de suite.

Si tu veux migrer des données spécifiques de ton site de staging vers le site de production sans affecter aucune des données transactionnelles, tu as trois options :

Option 1) Exporte les commandes, les données utilisateurs et autres données transactionnelles depuis le site live et importe-les dans le site de staging avant de migrer le staging vers le live.
Cela te permet de copier l’ensemble du site de staging.
C’est la méthode recommandée si tu n’as pas de connaissance de la structure interne de la base de données. Nous expliquons ci-dessous comment procéder.

Option 2) Exclue toutes les tables de base de données sauf la table _options et sélectionne uniquement les dossiers de Plugins et Themes que tu veux déployer sur le site de staging. Cette approche garantit que tu n’écrases ni ne perds jamais de données sur le site de production générées après la création du site de staging. La plupart des Plugins stockent également leurs paramètres dans la table _options. Cela migrera donc aussi les paramètres des Plugins vers le site live.
Important : Toutes les autres données manquantes incluses dans les tables _posts et _postmeta devront être recréées manuellement sur le site live après le déploiement.

Option 3) Exclue toutes les tables de base de données modifiées du processus de déploiement. Si tu choisis cette voie, tu ne migreras pas l’ensemble du site de staging, y compris ses données !
Selon les tables exclues (ex. : _posts, _postmeta), cela peut entraîner des images manquantes et même des éléments de mise en page sur ton site de production. Cela se produit principalement si tu utilises un éditeur visuel comme WPBakery (anciennement Visual Composer) ou Elementor car ces éditeurs stockent leurs designs dans les tables de base de données _posts et _postmeta.

Note : L’option 1 est la méthode recommandée.

La meilleure option est d’exporter tes commandes et données de produits en utilisant un Plugin d’export/import séparé sur le site de production, puis d’importer les données dans le site de staging avant d’effectuer le déploiement.

Avant d’exporter et d’importer des commandes de ton site live vers le live, il est fortement recommandé de créer un autre site de staging pour tester l’ensemble du processus avant d’effectuer l’import et l’export sur le site de staging principal !


Guide rapide :

  1. Mets ton site en mode maintenance.
  2. Installe le Plugin « WooCommerce Sequential Order Numbers » sur les sites de production et de staging.
  3. Installe le Plugin « Order Export & Order Import for WooCommerce » sur les sites de production et de staging.
  4. Exporte les commandes WooCommerce depuis le site de production.
  5. Supprime toutes les commandes sur le site de staging.
  6. Importe les commandes dans le site de staging.
  7. Déploie le site de staging vers le site de production.

Guide pas à pas

Avant de continuer, tu dois installer deux Plugins tiers :

Tu dois installer le Plugin « WooCommerce Sequential Order Numbers » pour t’assurer que les numéros de commande ne changent pas lors d’une importation.

L’export et l’import de commandes pourrait modifier l’ID de commande des commandes importées, car l’ID de commande WooCommerce est basé sur l’ID de publication WordPress, un numéro unique dans WordPress. Donc si l’ID de publication sur ton site de staging est déjà utilisé par un article ou tout autre élément, la commande importée obtiendrait un nouvel ID. Cela pourrait donc entraîner un nouvel ID de commande pour une commande importée.

Pour conserver l’ID de commande intact, tu dois utiliser le Plugin « WooCommerce Sequential Order Numbers ».

Ce Plugin ajoute une nouvelle entrée de base de données pour stocker l’ID de commande dans un champ séparé. Cela permet à ton site de garder l’ID de commande séparé et indépendant de l’ID de publication.

  • Connecte-toi à ton site de production
  • Va dans WebToffee Import Export > Export 
  • Sélectionne « Order » comme dans cette capture d’écran :

Choisis ensuite « Quick » à l’étape suivante et clique sur « Export ». Cela générera un fichier CSV que tu pourras stocker sur ton ordinateur.

  • Va sur ton site de staging > WooCommerce > Commandes.
  • Sélectionne toutes les commandes, puis déplace-les à la corbeille. (C’est important, car tu vas les réimporter toutes à l’étape suivante, depuis le fichier que tu as exporté ci-dessus depuis le site live).
  1. Va sur ton site de staging.
  2. Ouvre WebToffee Import Export > Import

  3. Choisis ensuite « Quick », télécharge le fichier .csv exporté ci-dessus et clique sur « Import », comme indiqué dans cette capture d’écran :

Après cette étape, toutes les commandes devraient être importées dans le site de staging, et ton site de staging est prêt à être déployé vers le site live en suivant ce guide.

IMPORTANT : Parfois, lors de l’importation de commandes dans le site de staging, un conflit peut survenir entre les IDs de commandes et les IDs de publications/pages/pièces jointes. Cela se produit parce que tu as ajouté de nouveaux articles/pages ou tout autre contenu sur le site de staging.

Si cela se produit, tu verras quelque chose comme sur cette capture d’écran pendant le processus d’importation :

Dans ce cas, tu dois modifier le fichier .csv exporté en utilisant Excel ou LibreOffice Calc. Il convient de mentionner que LibreOffice Calc gère mieux ces fichiers, mais assure-toi de sélectionner l’encodage UTF-8 lors de l’ouverture et de l’enregistrement du fichier. Une fois le fichier ouvert, tu peux soit modifier les IDs de commandes en conflit par un nombre plus élevé qui n’est pas déjà utilisé par les IDs de publications de ton site WordPress, soit supprimer leurs valeurs, et de nouveaux IDs leur seront attribués lors de l’importation :

Réimporte ensuite le fichier, et toutes les commandes devraient être importées avec succès. 

Conseil : tu devras peut-être faire la même chose avec les Produits ou Utilisateurs WooCommerce. Pour ce faire, nous recommandons d’utiliser ces Plugins :

Une autre option pour éviter que les commandes soient écrasées est d’ignorer toutes les tables contenant des commandes et produits WooCommerce lors du déploiement. Tu devras au moins exclure les tables ci-dessous avant de déployer le site de staging vers le site de production :

  • wpstg1_posts
  • wpstg1_postmeta
  • wpstg1_users
  • wpstg1_usermeta
    Toutes les tables commençant par :
  • wpstg1_woocommerce_

Malheureusement, cette sélection de tables exclurait les articles, publications et toutes autres données stockées dans les tables _posts et _postmeta de ton site WordPress. Par exemple, les pages, articles, entrées de menu et autres données liées aux publications seraient exclues et ne seraient pas copiées vers le site de production.

Suis donc cette étape uniquement si tu ne modifies aucune donnée sur ton site de staging que tu dois migrer vers le site de production.

Voir aussi : Référence des tables de base de données WooCommerce.

Mots-clés : WooCommerce, Exclure les commandes WooCommerce, Exclure les produits WooCommerce

Articles connexes

Updated on mai 23, 2026

Rene Hermenau

Auteur : Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.