Environnements de staging

Chaque installation WordPress chez Kinsta peut disposer de son propre environnement de staging WordPress gratuit, complètement séparé du site de production. C’est idéal pour tester les nouvelles versions de WordPress, les extensions, le code et le travail de développement en général. Créez un site de développement en quelques minutes et partagez-le avec votre équipe.

Si vous souhaitez ajouter des environnements de staging supplémentaires, si vous avez besoin d’un environnement de test plus proche de votre environnement de production, ou si vous avez besoin d’effectuer des tests ou des développements de sites gourmands en ressources, consultez notre module d’environnement de staging premium.

Environnement de staging standard ou premium

Vous pouvez ajouter jusqu’à 5 environnements de staging premium, qui comprennent plus de ressources et de fonctionnalités que les environnements standard. Le tableau suivant montre les différences entre les environnements Standard et Premium :

	Premium	Standard
Travailleurs PHP	Identique à votre environnement réel	1
CPU	12	1
RAM	8 Go	8 Go
CDN	Oui	Non
Cache Edge	Oui, peut être activé	Non

En savoir plus sur notre environnement de test Premium.

Créez un environnement de staging WordPress Standard ou Premium

Nous avons rendu la création d’un site de staging WordPress aussi simple que possible. Dans MyKinsta, cliquez sur Sites WordPress dans la navigation de gauche. Vous verrez une liste de vos sites/installations. Sélectionnez le site pour lequel vous souhaitez créer un environnement de staging, cliquez sur la case « Aller à » ou « Rechercher », et sélectionnez «  Créer un nouvel environnement ».

Dans le modal/pop-up Créer un nouvel environnement qui apparaît, sélectionnez l’environnementStandard ou Premium et cliquez sur Continuer.

Ensuite, vous êtes invité à sélectionner le type d’environnement que vous souhaitez créer. Trois options s’offrent à vous.

1. Cloner un environnement existant : Cette option vous permet de cloner un environnement existant (live ou tout environnement de staging Premium) dans le nouvel environnement de staging.
2. Installer un nouveau WordPress : Cette option installe un site WordPress vierge entièrement fonctionnel, prêt à être utilisé immédiatement.
3. Environnement vide (sans WordPress) : Cette option installe tous les logiciels nécessaires au fonctionnement d’un site WordPress (serveur web, PHP, MySQL, etc.) mais n’installe pas WordPress lui-même. C’est une bonne option pour les utilisateurs qui migrent vers Kinsta avec Duplicator ou qui mettent en place une installation Bedrock/Trellis avec une structure de fichiers personnalisée.

Option 1 – Cloner un environnement existant

L’option Cloner un environnement existant vous permet de cloner n’importe quel environnement existant (live ou Premium staging) vers le nouvel environnement de staging.

• Nom de l’environnement : saisissez un nom pour l’environnement de préparation ; ce nom doit comporter entre 3 et 12 caractères.
• Environnement à cloner : Choisissez un environnement existant à cloner dans le nouvel environnement de transit.

Option 2 – Installer un nouveau WordPress

L’option Installer un nouveau WordPress comprend plusieurs champs permettant de personnaliser votre site. Voici ce que vous devez savoir sur chaque champ.

• Nom de l’environnement : Saisissez un nom pour l’environnement de staging ; il doit comporter entre 3 et 12 caractères.
• Titre du site WordPress : Cette option vous permet de définir le titre de votre site WordPress. En fonction de votre thème, il sera visible par les visiteurs du site dans l’onglet du navigateur et à d’autres endroits. Vous pouvez modifier le titre du site dans les réglages de WordPress après la création du site.
• Nom d’utilisateur de l’administrateur WordPress : vous l’utiliserez pour vous connecter à votre installation WordPress. Vous pourrez ajouter des utilisateurs supplémentaires par la suite. Nous vous recommandons de choisir un nom d’utilisateur autre que « admin » pour une sécurité maximale.
• Mot de passe administrateur WordPress : Vous utiliserez ce mot de passe pour vous connecter à votre installation. Nous appliquons automatiquement des mots de passe forts pour protéger les utilisateurs. Vous pouvez utiliser l’option générer un nouveau mot de passe (icône de rechargement) si vous en voulez un nouveau. Voici comment vous pouvez modifier votre mot de passe WordPress ultérieurement.
• Adresse e-mail de l’administrateur de WordPress : WordPress utilise l’adresse e-mail de l’administrateur pour envoyer des notifications importantes.
• Sélectionnez une langue : Sélectionnez la langue que vous souhaitez utiliser dans WordPress. Vous n’êtes pas obligé d’écrire votre contenu dans la même langue que votre interface WordPress, alors n’hésitez pas à choisir votre langue maternelle, même si vous écrivez votre contenu en anglais.
• Installer un WordPress multisite : Cochez cette case si vous souhaitez créer une installation WordPress Multisite. Une fois sélectionnée, vous pouvez choisir entre une installation par sous-domaine ou par sous-répertoire.
• Installer WooCommerce : Si vous créez un site de commerce électronique, WooCommerce est l’extension de commerce électronique le plus populaire. Cochez cette case pour l’installer automatiquement.
• Installer Yoast SEO : Yoast SEO est l’extension SEO la plus populaire pour WordPress, avec plus de 3 millions d’installations et une note de 5 étoiles sur 5. Cochez cette case pour l’installer automatiquement.
• Installer Easy Digital Downloads : Si vous créez un site pour vendre des produits numériques, Easy Digital Downloads est une solution complète de commerce électronique pour la vente de produits numériques. Cochez cette case pour l’installer automatiquement.

Option 3 – Environnement vide (sans WordPress)

L’option Environnement vide est utile pour les utilisateurs qui ont besoin d’un environnement vierge pour la migration Duplicator ou les tests d’installation Bedrock/Trellis.

• Nom de l’environnement : Saisissez un nom pour l’environnement de staging ; il doit comporter entre 3 et 12 caractères.

Création de l’environnement de staging

Lorsque vous êtes prêt, cliquez sur Continuer. Si vous créez un environnement de staging Premium, confirmez l’abonnement récurrent et cliquez sur Créer un environnement Premium.

Accès à votre environnement de staging

La création du nouvel environnement peut prendre quelques minutes. Lorsqu’il est prêt, cliquez sur la case « Aller à » ou « Rechercher » et sélectionnez l’environnement.

Vous pouvez également accéder à l’environnement de test à partir de la liste des sites WordPress.

Chaque environnement a un code couleur autour de son nom : vert pour Live, noir pour Standard staging, et orange pour Premium staging. Vous disposerez alors d’un panneau de contrôle distinct contenant les informations de connexion, les DNS, les sauvegardes, les outils et les extensions pour votre environnement de staging.

Pour visiter rapidement votre site de staging, allez dans l’onglet Domaines de votre environnement de staging et cliquez sur le lien Ouvrir l’URL. Vous pouvez également accéder rapidement à l’administration WordPress de votre site de staging en cliquant sur le lien Ouvrir l’administration WordPress.

Structure de l’URL et domaine

La structure URL par défaut de votre environnement de staging suit le format suivant :

• Standard : https://stg-sitename-environmentname.kinsta.cloud
• Premium : https://env-sitename-environmentname.kinsta.cloud

Si vous disposez d’un site de staging plus ancien, votre URL peut ressembler à l’une des URL suivantes :

• https://staging-sitename-environmentname.kinsta.cloud
• https://staging-sitename.kinsta.cloud
• https://staging-sitename.kinsta.com

Vous pouvez également ajouter un domaine personnalisé à votre site de staging si vous préférez utiliser un domaine personnalisé.

Remarques supplémentaires

Si vous avez activé le SSL sur votre site live et que vous clonez le site sur le site de staging, le SSL sera également activé sur votre site de staging.

Vous pouvez lancer phpMyAdmin depuis MyKinsta. Dans l’onglet Info, cliquez sur le lien Ouvrir phpMyAdmin. La structure de l’URL pour phpMyAdmin staging suit ce format :

https://mysqleditor-stg-sitename-environmentname.kinsta.cloud

Actualiser l’environnement de staging

Si vous apportez des modifications à votre site réel après avoir créé l’environnement de staging et que vous souhaitez refléter ces modifications dans l’environnement de test, vous pouvez utiliser une poussée sélective pour mettre à jour votre environnement de staging. Ainsi, vous n’avez pas besoin de supprimer et de recréer l’environnement de staging, ce qui vous permet de gagner du temps et de conserver les sauvegardes de l’environnement de staging.

Pousser l’environnement vers le live ou le staging

Vous pouvez pousser votre environnement WordPress de staging vers votre environnement live si vous êtes satisfait des changements que vous avez faits et que vous voulez qu’ils soient appliqués à votre site live.

Vous pouvez également pousser votre environnement réel vers votre environnement de staging. Ceci est utile pour rafraîchir l’environnement de staging afin de refléter les changements effectués dans votre environnement de staging.

Grâce à la fonction de poussée sélective, vous disposez d’un contrôle granulaire sur ce qui doit être poussé. Plus précisément, vous pouvez pousser :

• uniquement vos fichiers,
• uniquement votre base de données,
• des fichiers et des dossiers spécifiques,
• des tables spécifiques de la base de données,
• tout.

Pousser des environnements peut se faire en quelques clics, mais veuillez lire les notes ci-dessous avant de procéder. Elles contiennent des informations essentielles sur le processus.

Notes importantes

• Nous vous recommandons d’utiliser la fonctionnalité « Pousser l’environnement » avec précaution, en particulier lors du transfert d’une version de staging à une version en ligne. Lancez le processus pendant les périodes de faible trafic et ayez un développeur à votre disposition en cas de problème. Si vous avez besoin de l’aide d’un développeur, il existe plusieurs endroits où vous pouvez en engager un.
• Nous créons automatiquement une sauvegarde afin que vous puissiez revenir en arrière si nécessaire. Remarque : si votre site est un site de commerce électronique ou un autre site dynamique qui évolue rapidement, des données peuvent être perdues entre le moment où vous effectuez la poussée et le moment où la sauvegarde est restaurée.
• Les réglages de l’environnement (redirections, géolocalisation, configuration PHP et Nginx, etc.) sont inclus dans la poussée (même si seuls les fichiers ou la base de données sont sélectionnés) et écraseront complètement les réglages de l’environnement.
• Une fois qu’un transfert de staging à live est terminé, purgez tout cache intégré dans votre thème ou vos extensions, videz le cache de votre navigateur et testez votre site pour vous assurer qu’il fonctionne comme prévu.
• Lors du transfert de votre base de données, si vous cochez l’option Exécuter la recherche et le remplacement, le domaine sera automatiquement remplacé par le domaine de l’environnement vers lequel vous effectuez le transfert.
• Si vous sélectionnez Tous les fichiers et dossiers, tous les fichiers seront transférés, y compris les extensions, les thèmes et les fichiers contenus dans wp-content/uploads.
• Toute URL codée en dur dans le code de votre thème ou de votre extension devra être mise à jour avec l’URL de l’environnement.
• Si la protection par mot de passe (.htpasswd) est active dans l’environnement à partir duquel vous effectuez le transfert, elle ne sera pas appliquée à l’environnement vers lequel vous effectuez le transfert. Vous devez l’activer dans l’environnement après le transfert.
• Lorsque vous utilisez WooCommerce, MyKinsta ne fait pas la différence entre les nouvelles commandes des clients et les anciennes lorsque vous poussez la version de staging vers la version live. Lorsque vous initiez une poussée vers le site live, si vous poussez tous les fichiers et dossiers, MyKinsta copie votre site staging sur le site live exactement comme il est, tout en écrasant les fichiers et la base de données. Pour contourner ce problème, vous pouvez soit
  • Pousser le site de staging vers le site live avec une poussée sélective et ne pousser que les fichiers afin que votre base de données ne soit pas écrasée.
  • Pousser sélectivement les tables de la base de données et exclure les tables WooCommerce nécessaires.
  • Pousser les fichiers de la base de données de live vers staging avant de pousser le staging vers live pour vous assurer que vous avez les données les plus à jour.

  Pour plus d’informations sur ce qui est inclus dans chaque table de la base de données WooCommerce, reportez-vous à la description de la base de données WooCommerce. Vous pouvez discuter de cette tâche avec votre développeur web. Si vous n’en avez pas ou si vous n’êtes pas sûr, veuillez consulter notre article sur la façon d’engager un développeur WordPress.

• Lorsque vous passez de l’environnement de staging à l’environnement réel, vérifiez deux fois le site de staging et résolvez toutes les erreurs avant de passer à l’environnement réel.
• Les environnements de staging sont destinés au développement et aux tests uniquement. Ils ne sont pas conçus pour être utilisés comme des sites de production en direct, et il peut y avoir des choses qui ne fonctionnent pas comme prévu. Kinsta n’est pas responsable si vous essayez d’utiliser un environnement de staging pour un site en production.
• Pousser un environnement n’affecte pas l’environnement à partir duquel vous le poussez, et il restera séparé des autres environnements. Après avoir transféré un site de staging vers un site en ligne, vous pouvez continuer à développer et à tester les modifications dans l’environnement de staging sans affecter votre site en ligne jusqu’à ce que vous transfériez à nouveau les modifications vers un site en ligne.
• Pousser d’un site staging vers un site live n’interférera pas avec le CDN de Kinsta s’il fonctionne sur votre site live, mais nous recommandons de vider le cache du CDN après la poussée (Sites WordPress > nom du site > Cache > CDN > Vider le cache CDN).
• Poussez de staging vers live avec prudence si votre site est un réseau multisite. Pousser la base de données peut fonctionner ou non, selon la façon dont le multisite est configuré. Si vous utilisez la poussée sélective et la poussée Toutes les tables de la base de données ou Toutes les tables de la base de données et Tous les fichiers et dossiers, l’ensemble du contenu de la base de données sera poussé vers le live et affectera tous les sites (le site principal et les sous-sites) de votre réseau multisite.
• Si vous utilisez une configuration WordPress non standard, telle que Bedrock ou Trellis, Kinsta peut ne pas être en mesure de localiser la variable DB_PASSWORD et, par conséquent, n’est pas en mesure de mettre à jour le mot de passe de la base de données lorsque vous mettez en ligne l’environnement de staging. Dans ce cas, lorsque vous mettez l’environnement en ligne, vous devez mettre à jour manuellement le fichier dans lequel vous définissez DB_PASSWORD avec le nouveau mot de passe de la base de données tel que défini dans MyKinsta.

Pousser un environnement avec une poussée sélective

Suivez les étapes ci-dessous pour pousser votre environnement vers un autre environnement. Le flux de travail pour la poussée sélective vous permet de choisir ce qui doit être poussé.

1. Sélectionner votre environnement

Connectez-vous à MyKinsta, cliquez sur Sites WordPress, et cliquez sur l’environnement à partir duquel vous voulez pousser. Si vous avez ajouté un environnement de staging Premium, vous aurez plus d’un environnement de staging à choisir.

2. Pousser l’environnement

Dans l’environnement, cliquez sur Pousser l’environnement et sélectionnez Pousser vers l’environnement dans le menu déroulant.

3. Sélectionner les fichiers et les tables de base de données à transférer

Dans la fenêtre popup/modale Pousser vers l’environnement qui apparaît, choisissez parmi les options suivantes :

• Fichiers > Tous les fichiers et dossiers : Pousse tous les fichiers et dossiers vers l’environnement sélectionné.
• Fichiers > Fichiers et dossiers spécifiques : Choisissez exactement les fichiers et dossiers que vous souhaitez transférer dans l’environnement sélectionné. Vous pouvez utiliser la zone de texte pour définir un chemin/dossier/fichier spécifique à transférer. Pour plus d’informations sur l’utilisation de chaque fichier dans WordPress, référez-vous à notre guide complet sur les fichiers WordPress et comment les utiliser.
• Base de données > Toutes les tables de la base de données : Pousse toutes les tables de la base de données dans l’environnement sélectionné.
• Base de données > Tables spécifiques de la base de données : Choisissez exactement les tables de la base de données que vous souhaitez transférer dans l’environnement sélectionné. Pour plus d’informations sur la base de données de WordPress, reportez-vous au Guide du débutant pour la base de données de WordPress : Qu’est-ce que c’est et comment y accéder.

Saisissez le nom du site pour confirmer et cliquez sur Pousser vers l’environnement.

Voici quelques points à garder à l’esprit :

• La durée du processus dépend de la taille de votre site web.
• MyKinsta vous informera lorsque le processus sera terminé.
• Lorsque vous passez de la phase d’essai à la phase d’exploitation, votre site web subira quelques secondes d’arrêt lors des dernières étapes du processus.
• Les réglages de l’environnement (redirections, géolocalisation, configuration PHP et Nginx, etc.) sont inclus dans la poussée (même si seuls Fichiers ou Bases de données sont sélectionnés) et écraseront complètement les réglages de l’environnement.

Cas d’utilisation et exemples de flux de travail

Vous trouverez ci-dessous quelques exemples de cas où vous souhaiteriez pousser uniquement les fichiers, uniquement la base de données, ou les deux.

Pousser uniquement tous les fichiers et dossiers

• Modifications apportées directement aux fichiers du thème (y compris HTML, CSS ou PHP) qui n’enregistrent aucune donnée dans la base de données.
• Téléchargement d’un fichier qui n’a pas besoin d’être inclus dans la médiathèque de WordPress.
• Si vous avez une extension personnalisée sur votre site et que vous apportez des modifications aux fichiers qui n’affectent pas la base de données (qui n’enregistre pas ou ne modifie pas les données dans la base de données).

Pousser des fichiers et des dossiers spécifiques

• Si vous apportez des modifications à un thème unique, vous pouvez transférer le dossier spécifique du thème dans le dossier themes.
• Si vous testez une nouvelle version d’une extension sur le staging, vous pouvez pousser le dossier spécifique de l’extension dans le dossier plugins.
• Vous pouvez répercuter les modifications apportées à des réglages ou à des fichiers de configuration spécifiques en définissant le chemin/dossier/fichier à répercuter dans la zone de texte.

Pousser la base de données uniquement

Remarque : toutes les modifications apportées à la base de données du site en direct depuis la création du site de staging seront perdues, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites de commerce électronique, les inscriptions sur les sites d’adhésion et les messages sur les forums.

• Création ou modification d’un nouvel article ou d’une nouvelle page qui n’inclut aucun média téléchargé (image, vidéo ou autre fichier téléversé).
• Modification de la mise en page d’une page ou d’un article par l’intermédiaire d’une extension de construction.
• Modification du titre ou du slogan du site.

Pousser des tables de base de données spécifiques

• Si vous testez un thème ou une extension WordPress personnalisée sur l’environnement de staging qui nécessite une mise à jour d’une table de base de données spécifique dans votre environnement réel.
• Si vous réorganisez des tables de données spécifiques ou corrigez des problèmes avec les tables dans votre environnement de staging et que vous ne voulez pousser que les nouvelles tables dans l’environnement réel.
• Si vous modifiez les données relatives aux utilisateurs ou aux rôles des utilisateurs dans l’environnement de staging et que vous souhaitez uniquement transférer les tables de la base de données des utilisateurs dans l’environnement live.

Tout pousser

Remarque : Toutes les modifications apportées à la base de données du site en direct depuis la création du site de staging seront perdues, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites de commerce électronique, les inscriptions sur les sites d’adhésion et les messages sur les forums.

• La création d’un nouveau contenu comprenant des médias téléversés (images, vidéos ou autres fichiers téléverse extension).
• Modifications apportées à votre thème dans la personnalisation et dans les fichiers du thème.
• Installation et test d’une nouvelle extension ou d’une version actualisée d’une extension.

Suppression et rafraîchissement de l’environnement de staging

Si vous devez supprimer votre site de test, allez sur Sites WordPress et sélectionnez l’environnement de staging que vous souhaitez supprimer. Descendez au bas de la page et cliquez sur Supprimer l’environnement.

Dans la fenêtre modale qui s’affiche, confirmez que vous comprenez ce qui sera supprimé, saisissez le nom du site suivi d’un tiret et du mot « staging » (SITENAME-environmentname) dans le champ prévu à cet effet, puis cliquez sur Supprimer l’environnement.

Pour rafraîchir votre environnement de staging, supprimez-le, créez-en un nouveau et choisissez l’option 1 – Cloner un environnement existant. Ce nouvel environnement de staging cloné contiendra la version la plus récente de votre base de données de production et des fichiers pour les tests.

Vous pouvez également restaurer une sauvegarde de votre site de production vers l’environnement de staging. L’avantage de cette méthode est que si vous avez ajouté un domaine personnalisé, il ne sera pas supprimé et vous n’aurez pas besoin de l’ajouter à chaque fois que vous actualisez l’environnement de staging.

Restaurer une sauvegarde de WordPress dans le staging

Vous pouvez restaurer votre site WordPress à partir d’une sauvegarde directement dans votre environnement de staging existant. Regardez comment restaurer une sauvegarde WordPress dans l’environnement de staging. Note : Toutes les sauvegardes de l’environnement de staging resteront intactes lors de la restauration d’une sauvegarde live vers l’environnement de staging.

Redémarrer l’environnement de staging

Dans certaines situations, nous pouvons arrêter un environnement de staging dans le cadre d’un processus de dépannage du serveur. Si vous remarquez que votre environnement de staging a été arrêté et que vous voyez une erreur 501 non implémentée, une erreur 502 ou une erreur 521 lorsque vous visitez votre site, vous pouvez redémarrer l’environnement de staging dans MyKinsta en allant sur la page Info de votre site et en cliquant sur Démarrer l’environnement de staging.

Si vous ne pouvez pas redémarrer votre environnement de staging ou si vous ne voyez pas le bouton dans MyKinsta, veuillez ouvrir une nouvelle discussion avec notre équipe de support pour plus d’assistance.

Retirer un environnement de staging

Une fois que vous avez terminé vos tests ou votre développement, vous pouvez supprimer l’environnement de staging. Si vous utilisez un environnement de staging Premium, vous ne serez facturé que pour la période pendant laquelle il est actif ; lorsque vous supprimez l’environnement de staging Premium, cela annule l’environnement de staging et met fin à la facturation supplémentaire.

Dans MyKinsta, cliquez sur Sites WordPress et sélectionnez l’environnement que vous souhaitez supprimer.

Descendez au bas de la page et cliquez sur Supprimer l’environnement.

Dans la fenêtre modale qui s’affiche, confirmez que vous comprenez ce qui sera supprimé, saisissez le nom du site suivi d’un tiret et le nom de l’environnement (SITENAME-EnvironmentName) dans le champ prévu à cet effet, puis cliquez sur Supprimer l’environnement.

Si vous utilisez un environnement de staging Premium, une fois que l’environnement de staging a été supprimé, l’abonnement au module est automatiquement supprimé de Entreprise > Mon Plan dans MyKinsta.

Remarques importantes

Lorsque vous utilisez l’environnement de staging, il y a plusieurs choses importantes à savoir.

1. Réglages du cache des pages pour les sites de staging

Les environnements de staging étant destinés au développement, au débogage et aux tests, le cache pleine page et OPcache de Kinsta sont désactivés par défaut. Si vous effectuez des tests de vitesse sur votre site web, vous verrez des temps de chargement supérieurs à la moyenne puisque les pages ne sont pas servies à partir du cache. Si vous souhaitez activer la mise en cache sur un site de mise en scène dans l’environnement de mise en scène, cliquez sur Mise en cache > Mise en cache du serveur > Activer. Lorsque la mise en cache est activée sur un site de staging, la fonction Vider le cache est activée et peut être utilisée pour vider le cache. Si vous disposez d’un environnement de staging Premium, vous pouvez également activer la mise en cache CDN et le cache Edge.

2. Informations d’identification de l’environnement de staging

Si l’environnement de staging est un clone de votre site de production, vos identifiants de connexion à l’administration de WordPress seront les mêmes pour votre site de production et votre site de staging, à moins que vous ne les changiez après avoir créé votre environnement de staging.

3. SEO

Par défaut, l’indexation est désactivée pour les sites de staging, afin qu’ils ne nuisent pas au référencement de votre site de production. Cela se fait grâce à la combinaison d’un réglagee WordPress et d’un en-tête HTTP que nous ajoutons automatiquement.

Vous pouvez voir le paramètre WordPress en allant dans Réglages > Lecture dans le tableau de bord WordPress de votre site de staging. L’option visant à décourager les moteurs de recherche d’indexer le site est cochée à côté de Visibilité pour les moteurs de recherche.

Les URL temporaires de Kinsta et les URLsde staging ont également un en-tête HTTP X-Robots-Tag: noindex, nofollow, nosnippet, noarchive qui restreint les robots, ce qui signifie que les URL temporaires ne seront pas indexées par les moteurs de recherche. Ces en-têtes ne peuvent pas être supprimés des URL temporaires ou des URL de staging de Kinsta. Si vous souhaitez que ces en-têtes soient supprimés du site de staging, vous devrez y ajouter un domaine personnalisé.

4. Plugins

Si vous utilisez des extensions de planification sociale tels que CoSchedule ou Social Networks Auto Poster, il est recommandé de désactiver ces extensions sur votre site de staging. Sinon, ils pourraient commencer à partager sur les réseaux sociaux en utilisant l’URL de votre site de staging, qui ressemblerait à : https://stg-sitename-environmentname.kinsta.cloud. Cela pourrait alors fausser vos analyses.

Certaines extensions, comme l’extensions Jetpack, s’exécutent automatiquement en mode staging sur les environnements de staging de Kinsta. Vous verrez un message : « You are running Jetpack on a staging server » Lorsque vous êtes en mode staging, votre site de staging agira comme votre site de production dans pratiquement tous les domaines, sauf qu’aucune donnée n’est transmise à WordPress.com, et que vous ne pouvez pas déconnecter le site de staging (pour éviter un problème qui conduirait à des problèmes avec votre site de production).

Les extensions sous licence de nom de domaine peuvent nécessiter un domaine personnalisé (au lieu d’un sous-domaine d’essai Kinsta) pour fonctionner correctement. Note : une fois que vous avez ajouté un nom de domaine personnalisé à votre site de staging, vous pouvez avoir besoin de mettre à jour les réglages où vous gérez la licence de votre extensions ou de contacter l’équipe de support de votre extnsion.

5. Noter votre URL de connexion

Si vous clonez votre site sur le site de staging et que vous utilisez une extension WordPress qui modifie votre URL de connexion par défaut, la partie personnalisée de l’URL sera copiée sur le site de staging. Exemple : http://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin

6. L’environnement de staging ne doit être utilisé que pour le développement et les tests

L’environnement de staging standard ne dispose que de 2 workers PHP, n’a pas d’option pour activer le CDN de Kinsta, et peut se mettre en veille après 24 heures d’inactivité. Par conséquent, il ne doit être utilisé que pour le développement et les tests. Les environnements de staging (Standard et Premium) ne sont pas conçus pour être utilisés pour des sites de production en direct, et il peut y avoir des choses qui ne fonctionnent pas correctement. Kinsta n’est pas responsable si vous essayez d’utiliser un environnement de staging pour un site en production.

7. Espace disque exclu du total du plan

Pour vous donner le plus d’espace possible, les sites de staging sont exclus de nos rapports lorsque nous calculons votre utilisation totale d’espace disque. Seuls les sites en ligne sont pris en compte dans le calcul de votre utilisation d’espace disque.

8. Tâches cron

Les tâches cron du serveur de l’environnement live ne sont pas actives dans l’environnement de staging (même si vous clonez votre site live sur le staging), donc les tâches cron du site live ne s’exécuteront pas sur l’environnement de staging. De plus, si vous modifiez la crontab de votre environnement de staging et que vous transférez l’environnement de staging vers votre environnement réel, la crontab de votre environnement réel sera écrasée.

9. Multisite

Si vous utilisez un réseau WordPress multisite, il se peut qu’il ne fonctionne pas avec notre environnement de staging, en fonction de la façon dont votre multisite est configuré.

• S’il s’agit d’un multisite à sous-répertoire (exemple.com, exemple.com/subsite1, exemple.com/subsite2), il fonctionnera parfaitement avec notre environnement de staging.
• S’il s’agit d’un multisite de sous-domaines (exemple.com, subsite1.example.com, subsite2.example.com), il fonctionnera correctement, à condition que les sous-sites n’aient pas besoin de HTTPS.
  • S’il s’agit d’un multisite à sous-domaines nécessitant le HTTPS, vous devrez ajouter un domaine personnalisé avec un certificat SSL de type wildcard à votre site de staging afin que les sous-domaines puissent être couverts par un certificat SSL. En effet, le certificat SSL fourni pour l’URL de staging par défaut ne peut couvrir que le sous-domaine de préparation (par exemple stg-sitename-environmentname.kinsta.cloud), de sorte que tout niveau de sous-domaine supplémentaire (par exemple subsite.stg-sitename-environmentname.kinsta.cloud) ne peut pas être couvert.
• S’il s’agit d’un multisite mappé sur un domaine (charge différents sous-sites sur des domaines complètement différents, par exemple exemple exemple.com, exemple1.com, exemple2.com), cela ne fonctionnera pas sans une configuration manuelle importante.
  • Option 1 : Désactivez le mappage de domaine et revenez à la configuration standard des sous-répertoires/sous-domaines. Effectuez manuellement une recherche et un remplacement dans la base de données.
  • Option 2 : Mettez en place des sous-domaines d’essai pour chaque domaine actif, ajoutez-les tous au site de staging et effectuez manuellement une recherche et un remplacement dans la base de données.

10. E-mail

L’envoi d’e-mail (e-mail transactionnel) est activé par défaut dans les environnements de staging. Si vous passez une commande sur le site de staging, vous recevrez les e-mails correspondants du site de staging. Si vous ne souhaitez pas que des e-mails transactionnels soient envoyés depuis votre environnement de staging, vous pouvez utiliser une extension telle que Disable Emails pour empêcher le site d’envoyer des e-mails.

FAQ

Qu’est-ce que le calcul au prorata ?

Lorsque nous calculons le prorata d’un service tel que l’environnement de staging Premium, cela signifie que vous serez facturé sur la base de la durée d’utilisation du service pour ce cycle de facturation mensuel.

Exemple de prorata

Vous avez une nouvelle fonctionnalité à déployer sur votre site et vous souhaitez la tester avec toute la puissance de votre plan. Vous créez un environnement de staging Premium, ajoutez la nouvelle fonctionnalité et la testez pendant une heure. Tout se passe bien, vous transférez donc la modification dans votre environnement réel et supprimez l’environnement de test Premium.

• 1 mois d’environnement de staging Premium coûte 20 $.
• Sur la base d’un mois de 30 jours, ce cycle de facturation compte 720 heures au total.
  30 * 24 = 720
• Chaque heure d’utilisation coûte 0,03 $.
  $20 / 720 = $0.03
• Votre prochaine facture inclura les 0,03 $ dus pour l’heure d’ajout d’un environnement de staging Premium à votre plan.

Exemple de prorata

Vous achetez un environnement de démonstration Premium au milieu de votre cycle de facturation mensuel et l’utilisez jusqu’à la fin de ce cycle. Vous serez facturé pour la moitié d’un mois d’utilisation (environ 10 $, au prorata de la seconde).

Puis-je changer le nom d’un environnement de staging ?

Oui. Accédez à l’environnement que vous souhaitez renommer et cliquez sur l’icône d’édition (crayon) dans la zone de saisie du nom de l’environnement Nom de l’environnement dans le champ Nom de l’environnement.

Saisissez le nouveau nom et cliquez sur Renommer l’environnement.

Cela modifiera le nom de l’environnement affiché dans le sélecteur d’environnement, mais n’affectera pas le domaine kinsta.cloud généré lors de la création de l’environnement initial.

Puis-je restaurer une sauvegarde dans un environnement de staging ?

Oui, mais vous devez d’abord créer un environnement de staging Standard ou Premium. Dans le passé, il était possible de créer un environnement de staging automatiquement lors de la restauration d’une sauvegarde. Avec l’introduction des environnements de staging Premium, vous devrez d’abord créer l’environnement de staging avant de restaurer une sauvegarde.

Vous pouvez également transférer des modifications de votre site réel vers votre site de staging, et si vous ne souhaitez mettre à jour que certains fichiers ou tables de base de données, vous pouvez procéder à une poussée sélective.

Qui a accès aux environnements de staging Premium ?

Les développeurs et les administrateurs de sites ont accès aux environnements de staging Premium qui ont été créés, mais ils ne peuvent pas créer ou supprimer un environnement de staging Premium. Seul le propriétaire ou l’administrateur de l’entreprise peut créer ou supprimer un environnement de staging Premium.

Le staging utilise-t-il mon espace disque ?

Non. Pour vous offrir le plus d’espace possible, les sites de staging sont exclus de nos rapports lorsque nous calculons votre utilisation totale de l’espace disque. Seuls les sites actifs sont pris en compte dans le calcul de votre limite d’espace disque.

Si je teste un plugin sur l’environnement staging et que je ne transfère que les fichiers sur le site live, cela créera-t-il les tables de base de données correspondantes pour le plugin ?

Si vous installez une extension sur votre site de staging qui n’a jamais été installée sur le site réel, pousser seulement les fichiers de l’environnement de staging vers le site réel ne créera pas les tables de la base de données pour cette extension.

Cela signifie également que les réglages que vous avez configurés dans l’extension ne seront pas transférés sur le site réel (à moins que les réglages ne soient enregistrés dans un fichier en dehors de la base de données, comme un fichier JSON, par exemple).

Selon la façon dont l’extension est codée, l’activation (d’abord la désactivation si nécessaire) de l’extension sur le site live peut créer la structure de la base de données.

Si je ne transfère que les fichiers vers le site live, cela signifie-t-il que l’ancienne base de données (dans le site staging) n’écrasera pas la base de données live, et que seuls les fichiers seront écrasés ?

Oui, lorsque vous ne transférez que les fichiers, cela signifie que la base de données sur le site live reste inchangée et que seuls les fichiers sur le site live seront écrasés.

Cela signifie-t-il que je peux travailler sur des modifications de conception sur mon site de démonstration et les transférer sur mon site en ligne sans perdre de nouveaux abonnés ou clients sur mon site en ligne ?

Oui, tant que vos modifications ne concernent que des fichiers (pas de modifications dans le tableau de bord de WordPress – y compris les réglages des extensions, des thèmes ou des personnalisateurs), vous pouvez les transférer en toute sécurité sur le site live sans transférer la base de données. Lorsque vous transférez les modifications, sélectionnez Fichiers et assurez-vous que la base de données n’est pas sélectionnée.

Puis-je exclure ou synchroniser des commandes ou des données WooCommerce lors du transfert de staging vers live ?

Oui, lorsque vous poussez staging vers live avec une poussée  sélective, vous pouvez pousser uniquement les fichiers afin que votre base de données ne soit pas écrasée, ou vous pouvez pousser sélectivement les tables de la base de données et exclure les tables WooCommerce nécessaires. Pour plus d’informations sur ce qui est inclus dans chaque table de la base de données de WooCommerce, référez-vous à la description de la base de données de WooCommerce. Si vous n’êtes pas sûr des tables à pousser, nous vous recommandons de travailler avec un développeur.

Puis-je transférer un seul site de staging à live si j’ai un Multisite ?

Oui, lorsque vous transférez la version staging à la version live avec une poussée sélective, vous pouvez choisir de ne transférer que les tables de la base de données pour l’un des sous-sites. Pour savoir quelles tables de base de données sont incluses dans WordPress, reportez-vous au Guide du débutant pour la base de données de WordPress : Qu’est-ce que c’est et comment y accéder. Dans les fichiers, les dossiers plugins et themes sont partagés par tous les sites, mais le dossier uploads peut être séparé par site ; vous pouvez donc choisir de ne pousser que les uploads pour le sous-site requis. Si vous n’êtes pas sûr des tables ou des fichiers à pousser, nous vous recommandons de travailler avec un développeur.

Puis-je utiliser la pousséesélective pour changer la version PHP de mon site ?

Oui, vous pouvez utiliser staging pour tester et pousser une nouvelle version PHP vers votre environnement live, mais il n’est pas strictement nécessaire de pousser depuis staging vers live pour mettre à jour votre version PHP. Voici un bref aperçu de la façon dont vous pouvez changer la version de PHP sans passer de l’environnement staging à l’environnement live :

1. Créez un site de staging.
2. Allez sur le site de staging et modifiez la version de PHP sur le site de staging.
3. Si tout va bien et fonctionne comme prévu sur le site de démonstration (veillez à tester votre site de manière approfondie), changez la version de PHP sur le site réel.

J’ai effectué des modifications CSS dans le tableau de bord de WordPress et j’ai transféré les fichiers. Pourquoi ne vois-je pas mes modifications, même après avoir vidé tout le cache ?

En fonction du type de changement effectué et de l’endroit où ces informations sont stockées, vous pouvez avoir besoin de pousser la base de données ou d’effectuer ces changements manuellement sur le site réel. Par exemple, si vous avez ajouté ou modifié du CSS dans un bloc ou un widget dans le tableau de bord de WordPress, cela sera probablement sauvegardé dans la base de données.

Si vous modifiez quelque chose dans le tableau de bord de WordPress, à l’exception des modifications effectuées avec l’éditeur de thème (Apparence > Éditeur de thème), cette information est généralement stockée dans la base de données.

Remarque : toutes les modifications apportées à la base de données du site réel depuis la création du site de staging seront perdues, y compris, mais sans s’y limiter, les commentaires, le nouveau contenu, les achats sur les sites de commerce électronique, les inscriptions sur les sites d’adhésion et les articles de forum. Dans ce cas, nous vous recommandons d’effectuer les mêmes modifications manuellement sur le site réel plutôt que de pousser la base de données.

Comment la poussée sélective fonctionne-t-elle avec un réseau multisite ?

Si vous utilisez la poussée sélective pour ne pousser que les fichiers, cela fonctionnera bien, quel que soit le type de réseau multisite. Si vous ne repoussez que la base de données ou la base de données et les fichiers, cela peut fonctionner ou non, en fonction de la configuration de votre réseau multisite:

• S’il s’agit d’un multisite à sous-répertoire (exemple.com, exemple.com/subsite1, exemple.com/subsite2), la poussée vers le live fonctionnera comme prévu.
• S’il s’agit d’un multisite de sous-domaine (exemple.com, subsite1.example.com, subsite2.example.com), il fonctionnera correctement, à condition que les sous-sites ne requièrent pas HTTPS.
• S’il s’agit d’un multisite à mappage de domaine (chargement de différents sous-sites sur des domaines complètement différents, par exemple, exemple.com, exemple1.com, exemple2.com), il ne fonctionnera pas sans une configuration manuelle importante.
  • Option 1 : Désactivez le mappage de domaine et revenez à la configuration standard des sous-répertoires/sous-domaines. Effectuez manuellement une recherche et un remplacement dans la base de données.
  • Option 2 : Configurez des sous-domaines de mise à l’essai pour chaque domaine actif, ajoutez-les tous au site de staging et effectuez manuellement une recherche et un remplacement dans la base de données pour mettre à jour chaque domaine après avoir transféré le site de stagingmise à l’essai vers le site actif.