Documentation · Guide d'intégration

Migration de l'environnement de staging vers la production

Ce document explique comment migrer la configuration de l'extension ADP Car Market Hub depuis un site de staging WordPress vers un site de production (live). Il détaille les réglages qui doivent être mis à jour, les données transitoires à effacer, la manière de reconfigurer les importations planifiées et les tâches cron, ainsi que la validation du site en production avant d'activer les importations automatisées.

Quand utiliser ce document

Utilisez ce document si vous :

  • Passez pour la première fois d'un environnement de staging entièrement configuré et testé au domaine de production.
  • Copiez une base de données de production vers le staging et devez savoir quoi modifier sur le staging pour éviter toute interférence avec le site en production.
  • Effectuez une migration de serveur ou un changement de domaine sur un site qui exécute déjà l'extension en production.
  • Coordonnez le déploiement de modifications de configuration (design, réglages, surcharges de mapping) développées sur le staging.

Le public cible est un administrateur WordPress ou un développeur d'agence qui comprend comment les bases de données et les systèmes de fichiers WordPress sont déplacés entre les environnements. Une connaissance pratique de wp-config.php et de SSH ou d'un panneau de contrôle d'hébergement est utile.

Aperçu

L'extension stocke l'ensemble de sa configuration sous forme d'options WordPress dans la base de données (table wp_options) et stocke les publications de véhicules importés, les leads, les événements d'analyse et les abonnements aux alertes de recherche dans des tables et types de publication distincts. Lorsqu'une base de données est déplacée entre deux environnements — par exemple, en copiant la base de données de staging vers la production —, toutes ces données sont transférées avec elle.

Une base de données copiée conserve des valeurs qui sont correctes pour l'environnement source mais incorrectes ou risquées pour l'environnement de destination. Les exemples les plus importants sont :

  • Les identifiants API (URL de base, Seller IDs, Client ID, Client Secret). Sur le staging, vous utilisez peut-être un environnement de bac à sable (sandbox) API ou des identifiants de test à sécurité réduite. Le site en production a besoin des identifiants de production réels du concessionnaire.
  • Le jeton cron (cron token). Le jeton qui authentifie le point de terminaison REST cron de l'extension est spécifique à l'environnement. Utiliser le jeton de staging sur le site en production, ou inversement, signifie que la tâche cron du serveur appelle la mauvaise URL ou utilise le mauvais secret.
  • Les URL cibles des webhooks. Les webhooks de staging pointent souvent vers des récepteurs de test. Les webhooks de production doivent pointer vers le CRM de production ou le point de terminaison de notification final.
  • L'URL du site WordPress. WordPress stocke sa propre URL dans les options siteurl et home. Celles-ci doivent correspondre au domaine de production avant que les URL des points de terminaison REST de l'extension et toutes les autres URL absolues ne se résolvent correctement.
  • Les données de cache transitoires (transients). Les jetons d'accès OAuth mis en cache, les verrous d'exécution d'importation et la file d'attente des images contiennent un état de staging qui n'a aucun sens ou qui est nuisible sur le site en production.
  • Les événements cron planifiés. Les événements WP-Cron qui ont été planifiés sur le staging portent des horodatages relatifs au staging et doivent être replanifiés sur le site en production.

Chacun de ces points est traité étape par étape ci-dessous.

Prérequis

Avant de commencer la migration :

  • Une sauvegarde actuelle et restaurable de la base de données de staging et de la base de données de production doit exister. Ne migrez jamais sans une sauvegarde de l'état actuel de chaque site.
  • L'installation WordPress de production répond aux exigences de l'extension. Voir la Configuration requise pour le système technique.
  • Vous avez accès au fichier wp-config.php du serveur de production et au service cron du serveur si le cron système est utilisé.
  • Vous connaissez les identifiants API de production (URL de base de l'API, Seller IDs, Client ID, Client Secret) et les avez reçus via un canal sécurisé. Voir la Configuration des identifiants API.
  • Si le site de production utilise un domaine différent de celui de staging, le changement de domaine est prêt à être appliqué aux options d'URL de WordPress en même temps que la copie de la base de données.

Instructions étape par étape

Suivez ces étapes dans l'ordre. Les étapes 1 à 5 concernent la préparation sur l'environnement de staging avant la copie de la base de données. Les étapes 6 et suivantes s'appliquent au site de production une fois que la base de données ou l'extension est en place.

Étape 1 — Désactiver les importations automatisées sur le staging avant la migration

Si le site de staging a des importations automatisées activées, désactivez-les avant de copier la base de données. Cela évite qu'une situation ne se produise où les deux environnements partagent le même état de planification et tentent tous deux de lancer des importations en même temps.

  1. Sur le site de staging, ouvrez Car Market Hub → Référence des importations et des limites.
  2. Désactivez l'option Importation automatique et enregistrez.
  3. Si une tâche cron serveur pointe vers le point de terminaison REST du site de staging, désactivez ou supprimez également cette tâche cron.

Étape 2 — Effectuer des sauvegardes

Avant d'apporter des modifications à l'un ou l'autre des sites :

  1. Effectuez une sauvegarde de la base de données du site de staging.
  2. Effectuez une sauvegarde de la base de données du site de production.
  3. Si le site de production contient déjà des données de véhicules importées et des images téléversées, effectuez également une sauvegarde complète du système de fichiers de wp-content/uploads/.

Étape 3 — Copier la base de données

Copiez la base de données de staging vers le serveur de production en utilisant votre méthode préférée (export/import depuis le panneau de contrôle de l'hébergement, WP-CLI db export / db import, SSH + mysqldump, ou une extension telle que Duplicator ou All-in-One WP Migration). La procédure exacte dépend de votre environnement d'hébergement.

Si les domaines diffèrent entre le staging et la production, exécutez un rechercher-remplacer pour mettre à jour toutes les occurrences de l'URL de staging vers l'URL de production. En utilisant WP-CLI :

wp search-replace 'https://staging.example.com' 'https://www.example.com' --all-tables

Exécutez cette commande sur la base de données de production, et non sur celle de staging. Effectuez une sauvegarde avant de l'exécuter.

Étape 4 — Copier les fichiers de l'extension

Les fichiers de l'extension se trouvent dans wp-content/plugins/adp-car-market-hub/. Si les sites de staging et de production exécutent la même version de l'extension, cette étape peut être ignorée. Si les versions diffèrent, copiez le répertoire de l'extension du staging vers la production (ou effectuez la mise à jour vers la même version via l'administration WordPress sur les deux sites avant la migration).

Ne copiez pas wp-config.php du staging vers la production. Les deux fichiers wp-config.php contiennent des identifiants de base de données et des constantes spécifiques à l'environnement différents, et ils doivent rester indépendants.

Étape 5 — Copier les surcharges de thème le cas échéant

Si le thème sur le site de staging contient des fichiers de surcharge de modèle pour l'extension (par exemple single-as24ci_car.php ou archive-as24ci_car.php à la racine du thème), copiez ces fichiers au même emplacement dans le thème de production. Consultez le Guide de surcharge de modèle pour plus de détails sur les surcharges de modèles.

Si aucune surcharge de modèle n'existe dans le thème, ignorez cette étape.

Étape 6 — Mettre à jour les identifiants API de production

Après la copie de la base de données, la table wp_options de production contient toujours les identifiants qui ont été enregistrés sur le staging. Remplacez-les par les identifiants de production.

  1. Sur le site de production, ouvrez Car Market Hub → Référence des réglages.
  2. Dans la carte Connexion API & Réglages Généraux, saisissez les valeurs de production pour : - URL de base de l'API — l'URL HTTPS de l'environnement de production AutoScout24. - Seller ID — le ou les Seller ID de production du concessionnaire. Les ID multiples sont séparés par des virgules. - Client ID — l'identifiant client OAuth de production. - Client Secret — le secret client OAuth de production. Le champ Client Secret n'est pas pré-rempli lorsque la page des réglages est ouverte ; vous devez toujours saisir à nouveau la valeur lorsque vous la modifiez.
  3. Enregistrez les réglages.
  4. Effacez le jeton d'accès OAuth mis en cache s'il en existe un provenant de la session de staging. Le jeton est stocké sous forme de transient WordPress as24ci_access_token. Vous pouvez l'effacer depuis Car Market Hub → Outils (recherchez une action Effacer le cache des jetons), ou en exécutant : `` wp transient delete as24ci_access_token ``
  5. Exécutez le Test de connexion sur Car Market Hub → Outils. Ne continuez pas tant que le test n'a pas réussi. Consultez Test de connexion.

Étape 7 — Mettre à jour les URL des webhooks

Si des webhooks sont configurés, la configuration de staging peut pointer vers un récepteur de test :

  1. Ouvrez Car Market Hub → Référence des leads et localisez la section Webhooks.
  2. Mettez à jour l'URL du webhook de nouveau lead et l'URL du webhook de nouvelle importation vers les points de terminaison du récepteur de production, ou effacez-les si les webhooks ne sont pas utilisés en production.
  3. Mettez à jour le Secret du webhook si le récepteur de production utilise une valeur de secret différente. Consultez Intégration des webhooks.

Étape 8 — Confirmer la configuration de l'IA managée

Si l'assistant IA est activé :

  1. Confirmez avec AD Promotion que la configuration managée Google Gemini dans AS24CI\Ai_Config est provisionnée pour l'environnement de production. Le client ne saisit pas de fournisseur d'IA, de modèle ou de clé API dans le back-office WordPress, et aucune clé d'IA n'est migrée via la copie de la base de données.
  2. Visitez Car Market Hub → Référence de l'Assistant IA et confirmez que la fonctionnalité est signalée comme configurée.

Étape 9 — Effacer les données temporaires (transients) obsolètes

La base de données migrée peut contenir des valeurs temporaires (transients) de l'environnement de staging qui ne doivent pas être transférées en production :

  1. Effacez le verrou de lancement d'importation, s'il est défini. Cela évite que le site de production ne voie un état obsolète "importation déjà en cours" provenant d'un lancement sur le staging : `` wp transient delete as24ci_cron_import_running ``
  2. Effacez le verrou du gestionnaire de file d'attente d'images, s'il est défini : `` wp transient delete as24ci_image_queue_running ``
  3. Optionnellement, effacez la file d'attente d'images elle-même si la file d'attente d'images de staging contient des tâches d'images de l'environnement de staging. La file d'attente d'images est stockée sous forme d'option WordPress (as24ci_image_queue) plutôt que de transient. Vous pouvez l'effacer depuis Car Market Hub → Système & AideEffacer la file d'attente d'images, ou depuis la ligne de commande : `` wp option delete as24ci_image_queue wp option delete as24ci_image_queue_last_run ``
  4. Supprimez toutes les autres listes de modèles d'IA mises en cache issues d'appels API de staging précédents. Celles-ci sont stockées sous forme de transients avec le préfixe as24ci_. Sur WP-CLI, vous pouvez les inspecter avec wp transient list --search="as24ci_".

Étape 10 — Régénérer le jeton cron

Le jeton cron du staging ne doit pas être utilisé en production. Un jeton différent empêche les tâches cron de staging de déclencher accidentelquement des importations de production.

  1. Sur le site de production, ouvrez Car Market Hub → Référence des importations et des limites.
  2. Dans la carte Automatisation, cliquez sur Régénérer le jeton. L'extension génère un nouveau jeton aléatoire de 32 caractères et l'enregistre.
  3. Notez le nouveau jeton ; vous en aurez besoin à l'étape 11.

Si vous utilisez le point de terminaison REST avec le jeton dans l'URL, la nouvelle URL de déclenchement est affichée sur la même carte. L'ancienne URL renverra une erreur 403 après la régénération.

Étape 11 — Reconfigurer la configuration cron de production

Après la régénération du jeton, toute tâche cron serveur qui pointait vers l'URL de staging est invalide. Reconfigurez la configuration cron de production :

  1. Si vous utilisez le mode cron serveur, mettez à jour la ou les tâches cron du serveur avec la nouvelle URL de déclenchement de production. Consultez Configuration du Cron Serveur pour le format exact de la commande.
  2. Si vous utilisez le mode WP-Cron, confirmez que la constante DISABLE_WP_CRON dans wp-config.php est définie de manière appropriée : - Si le site de production utilise le cron serveur, ajoutez ou confirmez define( 'DISABLE_WP_CRON', true ); dans wp-config.php. - Si le site de production s'appuie sur WP-Cron, supprimez ou commentez DISABLE_WP_CRON de wp-config.php s'il était défini pour le staging.
  3. Réactivez les importations automatisées sur Car Market Hub → Référence des importations et des limites une fois que tous les identifiants et la configuration cron ont été validés.

Étape 12 — Vérifier les pages par défaut

Lorsque l'extension est activée pour la première fois, elle crée deux pages WordPress (Archive des véhicules / Cars et Comparer les véhicules) et stocke leurs ID de publication dans les options as24ci_page_archive_id et as24ci_page_compare_id. Si la base de données de production était auparavant vide, les ID de page migrés sont ceux créés sur le staging et font référence à des publications de staging. Après la copie de la base de données, ces pages existent sur le site de production, mais leurs identifiants (slugs) et leur contenu doivent être vérifiés.

  1. Dans WordPress → Pages, confirmez que la page d'archive des véhicules (slug par défaut : cars) et la page Comparer les véhicules existent et sont publiées.
  2. Visitez les deux pages sur le front-end et confirmez qu'elles s'affichent correctement.
  3. Si les pages sont manquantes ou si leurs ID pointent vers des publications supprimées, désactivez et réactivez l'extension pour les recréer (confirmez que l'option Créer les pages par défaut est activée dans Car Market Hub → Référence des réglages avant la réactivation).

Vérifiez ce comportement dans la version actuelle de l'extension avant de vous y fier, car le comportement de création de page peut varier.

Étape 13 — Régénérer les règles de permaliens

Après tout changement de domaine ou mise à jour d'URL WordPress, régénérez les règles de permaliens WordPress afin que l'URL de l'archive des véhicules et les URL des pages de détails des véhicules se résolvent correctement :

  1. Dans WordPress, ouvrez Réglages → Permaliens.
  2. Sans rien modifier, cliquez sur Enregistrer les modifications. Cela régénère les règles de réécriture .htaccess.
  3. Visitez la page d'archive des véhicules et une page de véhicule individuel pour confirmer qu'elles se chargent sans erreurs 404.

Étape 14 — Valider le site de production

Effectuez les contrôles de validation suivants après la migration :

  1. Test de connexion. Ouvrez Car Market Hub → Outils et lancez le Test de connexion. Confirmez qu'il réussit avec l'API de production. Consultez Test de connexion.
  2. Onglet Système & Aide. Ouvrez Car Market Hub → Système & Aide et passez en revue tous les indicateurs de diagnostic. Résolvez tous les badges rouges ou orange.
  3. Importation manuelle. Déclenchez une importation manuelle depuis Car Market Hub → Référence des importations et des limitesLancer maintenant. Confirmez que l'importation se termine sans erreur.
  4. Page d'archive des véhicules. Visitez l'URL de l'archive des véhicules et confirmez que les véhicules importés apparaissent avec les images, les prix et les étiquettes corrects.
  5. Page de véhicule individuel. Cliquez pour accéder à une page de détails de véhicule et confirmez que la mise en page complète des détails, la galerie et le formulaire de contact sont fonctionnels.
  6. Première importation planifiée. Après avoir activé la planification automatisée, attendez le premier lancement déclenché par le cron et confirmez que l'onglet Système & Aide affiche un horodatage récent pour la Dernière exécution d'importation.
  7. Journaux. Ouvrez Car Market Hub → Référence des journaux et confirmez qu'il n'y a pas d'erreurs d'authentification, d'échecs d'API ou d'autres erreurs inattendues lors du premier lancement en production.

Référence de configuration

Les groupes d'options de l'extension suivants sont pertinents lors de la migration entre environnements. Tous sont stockés sous forme d'options WordPress.

Groupe d'optionsExemples de clésAction sur le site en production après la migration
Identifiants APIas24ci_base_url, as24ci_seller_ids, as24ci_client_id, as24ci_client_secretRemplacer par les valeurs de production.
Jeton cronas24ci_cron_tokenRégénérer sur le site en production. Mettre à jour les tâches cron du serveur.
Configuration de l'IA managéeAS24CI\Ai_Config::MANAGED_GEMINI_API_KEY, MANAGED_GEMINI_MODEL (constantes PHP, pas des options)Confirmer avec AD Promotion que la configuration Gemini managée est provisionnée pour l'environnement de production. Non migré via la copie de base de données.
URL des webhooksas24ci_webhook_url_new_lead, as24ci_webhook_url_new_import, as24ci_webhook_secretMettre à jour avec les URL et le secret du récepteur de production.
Pages de l'extensionas24ci_page_archive_id, as24ci_page_compare_idVérifier que les pages référencées existent et sont publiées.
Planificateuras24ci_auto_import_enabled, as24ci_cron_mode, as24ci_cron_scheduleConfirmer que la planification est configurée pour la production. Désactiver sur le staging avant la migration.
Cache transientas24ci_access_token (transient), as24ci_cron_import_running (transient), as24ci_image_queue_running (transient)Supprimer les transients obsolètes après la migration.
File d'attente d'imagesas24ci_image_queue, as24ci_image_queue_last_runEffacer si la file d'attente contient des données de staging.

Notes opérationnelles

  • Un seul environnement actif à la fois. Après avoir promu le staging en production, désactivez les importations automatisées et toutes les tâches cron du serveur sur le site de staging. Le fait d'avoir les deux environnements connectés aux mêmes identifiants API de production et d'exécuter des importations simultanément peut entraîner des résultats imprévisibles. Utilisez des identifiants API distincts par environnement dans la mesure du possible.
  • Le staging doit utiliser ses propres identifiants. Une fois la base de données copiée sur le staging, remplacez les identifiants API sur le staging par des valeurs d'environnement de test (sandbox) ou de staging. Ne laissez pas d'identifiants de production sur un site de staging. Voir Configuration des identifiants API.
  • Attention avec la synchronisation complète (Full Sync). L'option Full Sync supprime les publications de véhicules locales qui ne sont plus présentes dans la réponse de l'API. N'activez pas la synchronisation complète sur le site de production tant qu'au moins un cycle d'importation complet n'a pas été observé et confirmé comme correct. L'activer avant la première importation propre peut entraîner des suppressions prématurées.
  • Données d'analyse et de leads. La migration copie tous les événements d'analyse et les publications de leads du staging vers la production. Il s'agit d'enregistrements synthétiques ou de test qui peuvent fausser les rapports. Selon les exigences du concessionnaire, vous pouvez supprimer les analyses générées par le staging de la base de données de production avant d'activer le trafic réel. Les données d'analyse sont stockées dans la table de base de données {prefix}as24ci_analytics. Vérifiez avant de purger.
  • Abonnements aux alertes de recherche. Les abonnements aux alertes de recherche de l'extension (nom du visiteur, e-mail, critères de recherche) sont stockés dans la table {prefix}as24ci_search_agents. Les abonnements de test du staging doivent être supprimés de la base de données de production. Il s'agit d'enregistrements de données personnelles qui ne doivent pas être conservés sans but légitime.
  • Structure des permaliens. L'URL de l'archive des véhicules (identifiant par défaut cars) et les URL des véhicules individuels (/cars/{slug}/) dépendent de l'activation des permaliens personnalisés. Confirmez après la migration que Réglages → Permaliens n'est pas configuré sur le mode simple (chaîne de requête).
  • wp-config.php n'est pas migré. Gardez les fichiers wp-config.php indépendants entre les environnements. Les identifiants de base de données, DISABLE_WP_CRON, WP_DEBUG et les autres constantes d'environnement doivent refléter la configuration de l'environnement cible.
  • Répertoire des journaux. L'extension écrit les journaux d'importation et d'erreur dans wp-content/uploads/as24ci-logs/. Les fichiers de journaux de staging se trouveront dans ce répertoire après une migration complète du système de fichiers. Les données de journaux ne sont pas nocives en production mais peuvent prêter à confusion. Vous pouvez effectuer une rotation ou archiver les fichiers de journaux de staging avant d'activer les importations de production si vous préférez un état de départ propre.
  • Invalidation du cache. Après un changement de domaine et une migration de base de données, videz tous les caches d'objets WordPress, les caches de pages, les caches CDN et les caches d'opcode PHP afin que les nouvelles URL et les options fraîches de l'extension soient servies de manière cohérente.

Dépannage

SymptômeCause probableCe qu'il faut vérifier
Le test de connexion échoue en production mais a réussi en staging.Les identifiants de production n'ont pas été mis à jour après la copie de la base de données, ou un jeton de staging mis en cache est toujours utilisé.Saisissez à nouveau les identifiants API de production et effacez le transient du jeton d'accès (as24ci_access_token). Exécutez à nouveau le test de connexion.
Le cron du serveur renvoie une erreur 403 "Jeton invalide ou manquant" après la migration.Le jeton cron a été régénéré à l'étape 10 mais la tâche cron du serveur utilise toujours l'ancienne URL de staging.Copiez la nouvelle URL de déclenchement depuis la carte Automatisation et mettez à jour la tâche cron du serveur.
L'archive des véhicules ou les pages de véhicules individuels renvoient une erreur 404 après le changement de domaine.Les règles de permaliens n'ont pas été régénérées depuis le changement d'URL.Ouvrez Réglages → Permaliens et cliquez sur Enregistrer les modifications.
Le staging et la production importent tous les deux en même temps.Les importations automatisées n'ont pas été désactivées sur le staging avant la migration.Désactivez immédiatement les importations automatisées et toutes les tâches cron du serveur sur le site de staging.
Les images des véhicules importés sont manquantes sur le site de production.Les fichiers d'images dans wp-content/uploads/ n'ont pas été copiés du staging vers la production (seule la base de données a été déplacée).Copiez le répertoire wp-content/uploads/ du staging vers la production, ou lancez une nouvelle importation sur le site de production avec l'option Importer les images activée.
Les e-mails de notification de leads sont envoyés à l'adresse destinataire du staging.L'option d'e-mail du destinataire des leads a été copiée du staging et n'a pas été mise à jour.Ouvrez les réglages de Car Market Hub → Leads et mettez à jour l'e-mail du destinataire avec l'adresse de production.
Les données d'analyse affichent des chiffres gonflés provenant de l'activité de test du staging.Les événements d'analyse du staging ont été copiés dans la base de données de production.Supprimez les lignes générées par les tests de la table {prefix}as24ci_analytics, ou notez la date de migration et filtrez les rapports en conséquence.
L'onglet Système & Aide affiche un horodatage obsolète pour "Dernière exécution du cron externe".La tâche cron s'exécute mais utilise la mauvaise URL (URL de staging) ou le mauvais jeton.Mettez à jour l'URL et le jeton de la tâche cron pour correspondre aux valeurs de la carte Automatisation de production.
Les lancements d'importation démarrent mais se terminent immédiatement avec le message "Importation déjà en cours".Un transient de verrouillage d'exécution obsolète a été copié depuis le staging.Supprimez le transient as24ci_cron_import_running et réessayez.

Documents connexes