Reconnaître une copie et préserver l’identité du site public
Après un clonage, Jetpack affiche une invitation à déplacer les réglages, à créer une connexion ou à rester en mode sans risque. Avant de choisir, notez l’adresse où vous voyez l’avertissement et l’adresse que les visiteurs doivent continuer à utiliser. Demandez si la copie doit être jetée après les essais, devenir un deuxième site indépendant ou remplacer officiellement l’ancien domaine. Ces opérations partent parfois de la même sauvegarde, mais elles n’ont pas la même destination pour les statistiques et les abonnés.
Jetpack rattache sa connexion à une identité utilisée par WordPress.com. La copie peut avoir hérité de la configuration de connexion alors qu’elle répond à une autre adresse. L’avertissement indique que Jetpack a relevé une situation qu’il ne peut pas trancher automatiquement. Un historique vide sur la copie ne suffit pas à conclure que les données du site public ont disparu. Vérifiez l’adresse à laquelle vous consultez les statistiques et identifiez le site de référence avant toute opération sur la connexion.
Un accès de rédaction suffit pour noter l’adresse et le texte de l’avertissement. Le choix dans Jetpack appartient au compte qui administre le site et sa connexion. Si l’hébergeur a fourni la copie, demandez aussi comment il distingue la recette de la production. Gardez dans le ticket l’heure, les deux adresses et l’usage prévu. Laissez les jetons de connexion, cookies et listes d’abonnés dans leur périmètre habituel.
Déterminer quelle adresse répond à quelle installation
Ouvrez le tableau de bord de la copie depuis son adresse propre. Relevez l’adresse finale et vérifiez un repère de recette, comme le titre ajouté par l’hébergeur. Ouvrez ensuite la production dans un onglet distinct depuis son adresse habituelle. Le même nom de site peut apparaître dans les deux administrations parce qu’il a été copié. Comparez donc les adresses, le repère d’environnement et, si vous en avez la charge, les informations du panneau d’hébergement. Si l’adresse de la copie redirige vers la production, faites corriger ce trajet avant de régler Jetpack.
Vérifiez également l’adresse WordPress et l’adresse du site dans Réglages > Général lorsque votre rôle permet de les lire. Les deux peuvent volontairement différer si WordPress est installé dans un sous-dossier. Utilisez ce relevé pour identifier l’installation et documenter l’écart. Une adresse inattendue peut venir de la configuration, du proxy ou d’une redirection. Modifier ces champs pendant le diagnostic de Jetpack introduirait une deuxième cause d’écart.
Prenez un point de comparaison public. Avec un compte déjà autorisé à consulter Jetpack pour la production, ouvrez les statistiques de cette installation et choisissez une période passée où des données existent. Notez l’adresse affichée et un repère de période sans copier les données de fréquentation dans le dossier partagé. Vous pourrez ensuite vérifier que les mêmes données restent accessibles depuis la production. Si vous ne gérez pas cette connexion, demandez seulement une confirmation de continuité au propriétaire.
Approche 1. Garder une copie temporaire en mode sans risque
Pour une copie destinée aux essais locaux et appelée à disparaître, choisissez de rester en mode sans risque lorsque l’avertissement le propose. Vérifiez une dernière fois que le navigateur montre la copie. Selon l’interface, l’avertissement peut se trouver sur l’écran Jetpack, dans Réglages > Connecteurs ou dans un dialogue réouvrable depuis la barre d’administration. La documentation Jetpack indique que rester en mode sans risque masque l’avertissement principal. La disparition du message après ce choix ne prouve donc pas que toutes les fonctions connectées sont revenues.
Sur la copie, essayez les actions qui ne nécessitent pas la connexion Jetpack. Ouvrez une page de test, modifiez une phrase fictive si votre recette prévoit une écriture et vérifiez l’aperçu. Avec un navigateur de visiteur autorisé, vérifiez aussi la protection d’accès à la copie. Le mode sans risque répond à la relation avec les services Jetpack. Il ne remplace pas un contrôle d’accès au site de recette, ni l’isolement des courriels et des intégrations d’autres extensions.
Si l’essai dépend d’une fonction Jetpack connectée, identifiez-la avant de choisir un autre mode. Lorsque Jetpack détecte un conflit d’identité, il suspend les nouvelles synchronisations vers WordPress.com. Un essai local de rédaction ou de rendu peut réussir alors que la synchronisation d’une fonction distante n’est pas disponible dans ce contexte. Vérifiez la fonction dont vous avez besoin avant d’en tirer une conclusion pour la production. Une connexion indépendante ne se justifie que si la copie doit réellement utiliser les services associés à sa propre identité.
- Confirmer l’adresse de la copie avant de choisir le mode sans risque.
- Comparer une page de recette et une période passée des statistiques du site public.
- Noter les fonctionnalités connectées qui n’entrent pas dans la recette.
Approche 2. Déclarer la préproduction dans la configuration qui lui appartient
Si vous conservez la recette pour plusieurs cycles, demandez à l’hébergeur s’il définit déjà le type d’environnement. Certains hébergeurs le font au moment du clonage. Avec un accès d’administration seul, transmettez l’adresse de recette au support et demandez la valeur effective. Une copie qui s’appelle recette dans le panneau ne suffit pas à établir la valeur que WordPress reçoit. Si le panneau propose un réglage géré par l’hébergeur, conservez ce réglage comme source de référence.
Avec un accès aux fichiers, relevez d’abord la déclaration existante et le mécanisme de déploiement de la copie. Dans WordPress, le type peut venir d’une variable d’environnement ou d’une constante. Une constante valide et définie prend le dessus sur la variable système. Vérifiez donc la configuration fournie par l’hébergeur avant d’ajouter une ligne. Si une déclaration existe déjà et doit être corrigée, modifiez cette déclaration plutôt que d’en créer une seconde. Sauvegardez une copie privée de la version précédente du fichier et relevez l’adresse de l’installation associée.
Sur une copie auto-hébergée dont vous gérez le fichier, placez la ligne suivante dans le fichier wp-config.php de la copie, avant le chargement de wp-settings.php. Elle doit se trouver dans le bloc PHP existant. Le type staging décrit une préproduction. Gardez la modification hors des fichiers qui peuvent être poussés vers le site public. Si vous utilisez un déploiement avec une configuration commune et des variables propres à chaque site, appliquez le réglage dans la configuration de l’environnement de recette. Pour un réseau multisite, vérifiez la portée de la configuration avant de changer un fichier partagé par tous les sous-sites.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Vérifier le type effectif et le comportement de l’avertissement
Rechargez le tableau de bord de recette après la modification. Avec un accès technique déjà autorisé, vous pouvez demander à WP-CLI d’afficher le type que WordPress résout, par exemple avec wp --path=/srv/recette/wordpress --url=https://recette.example eval 'echo wp_get_environment_type(), PHP_EOL;'. Adaptez le chemin et l’adresse. Le résultat attendu est staging sur la copie. Si la configuration de l’hébergeur diffère entre le terminal et la requête web, confirmez aussi la valeur du côté web avec son support. L’exécution en terminal ne suffit pas à établir à elle seule la valeur reçue par le processus qui sert l’administration.
Sur une copie connectée que Jetpack reconnaît comme préproduction, le choix de déplacer les réglages vers la copie doit être indisponible si le dialogue s’affiche. Il peut aussi ne pas y avoir d’avertissement à résoudre. Vérifiez alors le type dans le contexte web et l’état affiché dans Jetpack, sans provoquer un conflit d’identité pour faire apparaître un message. Si l’option de déplacement reste proposée, contrôlez l’adresse, la configuration web effective et la présence éventuelle d’une personnalisation de la détection. Relevez l’écart avant de modifier la connexion.
Documentez le test du déploiement avant le prochain transfert de la recette vers le site public. Dans une copie, une modification de wp-config.php peut être volontaire. Le même fichier déployé en production peut faire identifier le site public comme staging. Comparez les deux configurations d’environnement avant un transfert et demandez au propriétaire de vérifier le type effectif de production après celui-ci. Si la copie remplace une autre recette, contrôlez de nouveau le type sur la nouvelle installation. Le résultat de l’ancien test dépendait de l’ancien chemin et de sa configuration.
Distinguer une connexion indépendante d’un déménagement
Si le deuxième site doit vivre séparément, une nouvelle connexion lui donne sa propre identité Jetpack. Sur la copie autorisée, identifiez l’adresse de recette et ouvrez le dialogue Jetpack. Si un essai connecté est prévu, le propriétaire choisit « Créer une nouvelle connexion », utilise le compte prévu pour la recette et confirme que l’adresse rattachée à la nouvelle identité est celle de la copie. Il rouvre ensuite son écran de production pour vérifier l’adresse et l’historique de référence. Pour un essai de rédaction ou de mise en page, conservez le mode sans risque lorsque la copie n’a pas besoin de services connectés.
Le choix de déplacer les réglages correspond à un déménagement réel. Dans ce cas, la nouvelle adresse doit remplacer l’ancienne et le propriétaire veut y retrouver la continuité des statistiques et des abonnements. Vérifiez d’abord que la bascule de domaine est prévue et que les deux adresses ont été identifiées. Une recette parallèle et une production ouverte en même temps constituent deux environnements distincts. Le fait que la recette soit plus récente ne suffit pas à justifier un déplacement.
Si la mauvaise action a déjà été validée, relevez ce qui a été sélectionné, l’heure, les adresses et le premier effet observé sur la production. Évitez les déconnexions et reconnexions successives qui rendraient plus difficile l’attribution de l’historique. Le propriétaire peut ensuite soumettre le constat au support Jetpack par son circuit habituel. Une sauvegarde de la base WordPress renseigne l’état local au moment de la copie, tandis que les statistiques et abonnements connectés dépendent aussi de l’identité enregistrée chez le service. Restaurer la base seule ne constitue donc pas une preuve de retour de ces données.
Tester une opération complète sur la copie autorisée
Sur votre copie autorisée, créez une page brouillon intitulée « Repère Jetpack recette 27 ». Avec le compte de rédaction prévu, ajoutez la phrase fictive « Cette page sert à vérifier le rendu de la recette », enregistrez-la et rouvrez son aperçu. Vérifiez que la barre d’adresse montre la copie et que la phrase apparaît. Sur un navigateur de visiteur, contrôlez aussi que la protection d’accès se comporte comme prévu. Supprimez le brouillon fictif à la fin de la recette ou rétablissez la version de départ si vous avez utilisé une page témoin existante.
Avec le propriétaire, comparez le point de référence de production relevé au départ. Rouvrez la même période de statistiques depuis l’adresse de production et vérifiez que l’interface indique toujours le bon site. Si l’installation utilise les abonnements, demandez au propriétaire de confirmer que le service reste rattaché à la bonne adresse depuis son propre écran. Ce contrôle ne demande pas d’envoyer une notification aux abonnés. Si la recette exige un vrai envoi de test, faites-le dans un environnement dont le propriétaire a validé l’identité et les destinataires de test, puis notez séparément ce que cet envoi prouve.
En cas d’écart, recherchez le premier contrôle qui a changé. Si la page de recette s’ouvre mais que le mauvais site apparaît dans les statistiques de production, conservez les deux adresses et l’heure. Si la production est correcte et qu’une fonction de la copie est indisponible en mode sans risque, rapprochez-la de la liste des fonctions suspendues. Distinguer ces cas permet d’arrêter les essais au bon moment ou de les poursuivre sans toucher à la connexion publique.
Revenir au réglage prévu pour la copie
Si vous avez changé le type d’environnement par erreur, restaurez sa valeur précédente avec le même mécanisme. Pour une variable gérée par l’hébergeur, revenez au réglage du panneau. Pour une constante propre à la copie, restaurez uniquement la ligne ou le fichier dont vous aviez pris une version avant l’essai. Vérifiez l’adresse et le type effectif après ce retour. Si la copie reste distincte de la production, faites confirmer par le responsable le comportement que Jetpack doit garder avant de retirer une protection de préproduction.
Si le propriétaire a créé une connexion indépendante uniquement pour l’essai, vérifiez d’abord l’adresse et l’identité de la copie. Sur les versions qui proposent Réglages > Connecteurs, ouvrez les détails de la carte Jetpack et utilisez la déconnexion du site de recette. Selon la version, cette action se trouve dans My Jetpack. Rouvrez ensuite l’écran Jetpack de production et comparez le site et la période de référence. Si les réglages ont été déplacés entre deux adresses par erreur, conservez les observations et faites traiter l’identité connectée séparément par le propriétaire. La restauration de wp-config.php rétablit la configuration locale et ne transfère pas l’historique du service.
Pour clôturer la recette, laissez trois informations dans le dossier. Indiquez le type effectif de la copie, le choix Jetpack qui y a été retenu et le résultat de la comparaison sur la production. Précisez aussi si cette copie doit être réutilisée, reconstruite ou retirée. Lors du prochain clonage, ces repères permettront de distinguer un nouvel avertissement légitime d’un retour imprévu à la configuration de production.
