Environnements de staging

Dernière mise à jour 25 mars 2024

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 staging 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 ci-dessous.

Environnement de staging WordPress standard

Créer un environnement de staging WordPress

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 le sélecteur d’environnement à côté du nom du site, et sélectionnez Créer un nouvel environnement dans le menu déroulant.

Création d'un nouvel environnement Kinsta dans MyKinsta. — Création d’un nouvel environnement Kinsta dans MyKinsta.

Dans la fenêtre modale Créer un nouvel environnement qui apparaît, donnez un nom à votre environnement, sélectionnez Environnement standard et cliquez sur le bouton Créer un environnement.

Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Choisissez de créer un environnement de staging standard.

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

Cloner un environnement existant : Cette option vous permet de cloner un environnement existant (production ou tout environnement de staging premium) dans le nouvel environnement de staging standard.
Installer un nouveau WordPress : Cette option installe un site WordPress vierge entièrement fonctionnel, prêt à être utilisé immédiatement.
Ne pas installer WordPress (environnement vide) : 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 (production ou environnement de staging premium) vers le nouvel environnement de staging standard.

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Environnement à cloner

Choisissez un environnement existant à cloner dans le nouvel environnement de staging standard.

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.

Installez un nouveau WordPress dans votre environnement de staging

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Titre du site WordPress

Ceci 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 de l’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 changer votre mot de passe WordPress plus tard.

Adresse e-mail de l’administrateur 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 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 en sous-domaine ou en sous-répertoire.

Installer WooCommerce

Si vous créez un site de commerce électronique, WooCommerce est l’extension de commerce électronique la 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 eCommerce complète pour la vente de produits numériques. Cochez cette case pour l’installer automatiquement.

Option 3 – Ne pas installer WordPress (environnement vide)

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

Créez un nouvel environnement vide sans WordPress.

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Création de l’environnement de staging standard

Lorsque vous êtes prêt, cliquez sur le bouton Créer un environnement.

Accéder à votre environnement staging

La création du nouvel environnement peut prendre quelques minutes. Lorsqu’il est prêt, vous pouvez sélectionner le nouvel environnement de préparation standard dans le menu déroulant du sélecteur d’environnement situé à côté du nom du site.

Sélectionnez l'environnement de staging standard. — Sélectionnez l’environnement de staging standard.

Chaque environnement a un code couleur autour de son nom : vert pour la production, noir pour le staging standard, et orange pour le staging premium. 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 standard suit le format suivant :

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

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

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 en production 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

Supprimer et rafraîchir l’environnement de staging

Si vous avez besoin de supprimer votre site de démonstration, allez dans Sites WordPress > Nom du site et passez à l’environnement de staging. Descendez au bas de la page et cliquez sur le bouton 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 le bouton Supprimer l’environnement.

Supprimez un environnement de staging dans MyKinsta.

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 actualiserez l’environnement de staging.

Transférer le site de staging vers le site en production

Pour écraser la base de données ou les fichiers de votre site en production, ou pour écraser le site entier avec votre site de staging, vous pouvez utiliser la fonction « pousser le staging vers le site en production ».

Restaurer une sauvegarde WordPress vers le site de staging

Vous pouvez également restaurer votre site WordPress à partir d’une sauvegarde directement dans votre environnement de staging existant. Découvrez 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 en production 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.

Redémarrez votre environnement de staging dans MyKinsta.

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.

Remarques importantes

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

1. Réglages du cache de page 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 plus élevés que la moyenne puisque les pages ne sont pas servies à partir du cache. Si vous souhaitez activer la mise en cache sur un site de staging, cliquez sur le bouton Activer la mise en cache dans la page Outils de l’environnement de staging de votre site. Lorsque la mise en cache est activée sur un site de staging, le bouton Vider le cache est activé et peut être utilisé pour vider le cache.

Activez la mise en cache pour un environnement de staging.

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églage WordPress et d’un en-tête HTTP que nous ajoutons automatiquement.

Vous pouvez voir le réglage 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.

L'indexation par les moteurs de recherche est désactivée sur le site de staging. — L’indexation par les moteurs de recherche est désactivée sur le site de staging.

Les URL temporaires de Kinsta et les URL de 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, elles pourraient commencer à partager sur les réseaux sociaux en utilisant l’URL de votre site de démonstration, qui ressemblerait à : https://stg-sitename-environmentname.kinsta.cloud. Cela pourrait alors fausser vos analyses.

Certaines extensions, comme l’extension Jetpack, s’exécutent automatiquement en mode de staging sur les environnements de staging de Kinsta. Vous verrez un message : « Vous utilisez Jetpack sur un serveur de staging ». 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 de staging 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 extension ou de contacter l’équipe de support de votre extension.

5. Notez 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. Le staging ne doit être utilisé que pour le développement et les tests

L’environnement de staging standard n’a que 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 production sont pris en compte dans le calcul de votre consommation d’espace disque.

8. Tâches Cron

Les tâches cron du serveur de l’environnement en production ne sont pas actives dans l’environnement de staging (même si vous clonez votre site en production sur le staging), donc les tâches cron du site en production 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 votre site de staging vers votre environnement de production, la crontab de votre environnement de production 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.

Environnements de staging Premium

Avec le module d’environnement de staging premium de Kinsta, vous pouvez ajouter jusqu’à cinq environnements de staging premium à votre site WordPress. Alors qu’un environnement de staging standard fonctionnera toujours pour la plupart des tests, l’utilisation d’un environnement de staging premium est idéale pour les tests ou le développement de sites à forte intensité de ressources.

Chaque environnement de staging premium dispose de 12 CPU, de 8 Go de mémoire et du même nombre de workers PHP que vous avez pour votre site en production (en fonction de votre plan). Vous pouvez également activer le CDN de Kinsta pour un environnement de staging premium. Avec un environnement de staging qui correspond étroitement à votre environnement en production, vous pouvez également effectuer des tests de vitesse sur votre site de staging.

En incluant l’environnement de staging standard gratuit, cela vous permet d’avoir un total de 6 environnements de staging et de développement qui sont complètement séparés de votre site en production.

Ajouter un environnement de staging premium

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 premium, cliquez sur le sélecteur d’environnement à côté du nom du site, et sélectionnez Créer un nouvel environnement dans le menu déroulant.

Le module d’environnement de staging premium peut être achetée pour 20 $ par mois par environnement (au prorata). Vous pouvez acheter jusqu’à 5 modules premium. Chaque module d’environnement de staging premium est automatiquement calculé au prorata, et l’abonnement apparaîtra sur votre prochain cycle de facturation.

Dans la fenêtre contextuelle Créer un nouvel environnement qui s’affiche, donnez un nom à votre environnement, sélectionnez Environnement premium et cliquez sur le bouton Créer un environnement.

Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Choisissez de créer un environnement premium.

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

Cloner un environnement existant : Cette option vous permet de cloner un environnement existant (production, staging standard ou autre environnement de staging premium) dans le nouvel environnement de staging premium.
Installer un nouveau WordPress : Cette option installe un site WordPress vierge entièrement fonctionnel, prêt à être utilisé immédiatement.
Ne pas installer WordPress (environnement vide) : 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 (production, staging standard, ou autre environnement de staging premium) vers le nouvel environnement de staging premium.

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Environnement à cloner

Choisissez un environnement existant à cloner dans le nouvel environnement de staging premium.

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.

Installez un nouveau WordPress dans votre environnement premium.

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Titre du site WordPress

Nom d’utilisateur de l’administrateur WordPress

Mot de passe de l’administrateur de WordPress

Adresse e-mail de l’administrateur de WordPress

WordPress utilise l’adresse e-mail de l’administrateur pour envoyer des notifications importantes.

Sélectionner une langue

Sélectionnez la langue dans laquelle vous souhaitez utiliser 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 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 en sous-domaine ou en sous-répertoire.

Installer WooCommerce

Si vous créez un site de commerce électronique, WooCommerce est l’extension la 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

Option 3 – Ne pas installer WordPress (environnement vide)

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

Nom de l’environnement

Si vous souhaitez modifier le nom de l’environnement, vous pouvez le faire ici. Le nom de l’environnement doit comporter entre 3 et 12 caractères.

Création de l’environnement de staging premium

Lorsque vous êtes prêt, cliquez sur le bouton Créer un environnement. Ensuite, confirmez l’abonnement récurrent pour votre environnement de staging premium et cliquez sur le bouton Ajouter un abonnement.

Accéder à votre environnement de staging premium

La création du nouvel environnement peut prendre quelques minutes. Lorsqu’il est prêt, vous pouvez sélectionner le nouvel environnement de staging premium dans le menu déroulant du sélecteur d’environnement situé à côté du nom du site.

Chaque environnement a un code couleur autour de son nom : vert pour la production, noir pour le staging standard et orange pour le staging premium. Vous aurez alors un panneau de contrôle séparé avec vos informations de connexion, DNS, sauvegardes, outils et extensions pour votre environnement de staging.

Structure d’URL et domaine

La structure URL par défaut de votre environnement de staging Premium suit ce format :

https://env-sitename-environmentname.kinsta.cloud

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

Transférer un environnement de staging premium vers un autre environnement

Tout environnement de staging peut être poussé vers un autre environnement de staging ou vers votre environnement en production.

Choisir un environnement vers lequel transférer.

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

uniquement vos fichiers,
uniquement votre base de données,
ou les deux.

Pour plus de détails, consultez notre guide sur la façon de passer du staging vers la production. Le processus est le même ; vous devrez simplement choisir l’environnement vers lequel vous souhaitez pousser depuis votre environnement de staging premium.

Supprimer un environnement de staging premium

Une fois que vous avez terminé vos tests ou votre développement, vous pouvez supprimer l’environnement de staging premium et l’abonnement dans MyKinsta. Le module d’environnement de staging premium sera facturé uniquement pour la période pendant laquelle il est actif. Annulez le module en supprimant l’environnement de staging premium pour arrêter la facturation supplémentaire.

Dans MyKinsta, cliquez sur Sites WordPress dans la navigation de gauche. Vous verrez une liste de vos sites/installations. Sélectionnez le site dont vous souhaitez supprimer l’environnement de staging premium, cliquez sur le sélecteur d’environnement à côté du nom du site, et sélectionnez l’environnement dans le menu déroulant.

Sélectionnez l'environnement premium que vous souhaitez supprimer. — Sélectionnez l’environnement premium que vous souhaitez supprimer.

Descendez au bas de la page et cliquez sur le bouton 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 le bouton Supprimer l’environnement.

Confirmez la suppression de l'environnement premium. — Confirmez la suppression de l’environnement premium.

Une fois que l’environnement de staging premium a été supprimé, l’abonnement au module sera automatiquement supprimé de Entreprise > Mon plan dans MyKinsta.

FAQ

Qu’est-ce que le calcul au prorata ?

Lorsque nous calculons le prorata d’un service comme 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 semble parfait, vous transférez donc le changement dans votre environnement de production et supprimez l’environnement de staging 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 staging 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 premium ?

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

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

Renommer l'environnement premium. — Renommer l’environnement premium.

Cela changera 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 initiale de l’environnement.

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 d’y restaurer une sauvegarde.

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 d’espace disque. Seuls les sites actifs sont pris en compte dans votre limite d’espace disque.

Passer du staging à la production

Vous avez la possibilité de pousser votre environnement de staging WordPress vers votre environnement en production si vous êtes satisfait des modifications que vous avez apportées et que vous souhaitez qu’elles soient appliquées à votre site réel. Grâce à la fonction de poussée sélective, vous avez un contrôle granulaire sur ce qui doit être poussé en production.

Auparavant, le passage de l’environnement de staging à l’environnement en production tout ou rien, l’environnement de staging complètement le site en production pendant le passage. Avec la fonction de poussée sélective, vous pouvez choisir ce qui doit être poussé de votre environnement de staging vers votre site en production. Plus précisément, vous pouvez maintenant pousser :

uniquement vos fichiers,
uniquement votre base de données,
ou les deux.

Le passage du staging à la production 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.

Remarques importantes

Nous vous recommandons d’utiliser la fonctionnalité « Pousser vers la production » avec précaution, de l’initier pendant les périodes de faible trafic et d’avoir un développeur à portée de main, au cas où. 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 sauvegarde et celui où elle est restaurée.
Les réglages d’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 d’environnement du site en production.
Une fois le transfert 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, votre domaine de staging sera automatiquement remplacé par le domaine de votre site en production.
Si vous sélectionnez l’option Fichiers, 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 pour correspondre à l’URL du site en production.
Si la protection par mot de passe (.htpasswd) est active dans votre environnement de staging, elle ne sera pas transférée dans l’environnement réel. Si vous avez besoin de cette protection, vous devez l’activer sur le site en production
Lorsque vous utilisez WooCommerce, MyKinsta ne fait pas la différence entre les nouvelles commandes des clients et les anciennes lorsque vous passez de l’environnement de staging à l’environnement en production. Lorsque vous lancez une poussée vers la production, MyKinsta copie votre site de staging sur le site en production exactement comme il est tout en écrasant les fichiers et la base de données. Pour contourner ce problème, vous pouvez exporter les commandes sur le site en production, les transférer sur le site en production, puis réimporter les commandes/clients sur l’environnement en production. Vous devrez 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 manière d’engager un développeur WordPress.
Vérifiez à nouveau le site de staging et résolvez les éventuelles erreurs avant de le mettre en ligne.
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, 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 de production.
Le passage à la production n’affecte pas l’environnement de staging, et il restera séparé du site en production. Après la mise en production, vous pouvez continuer à développer et à tester les changements dans l’environnement de staging sans affecter votre site en production jusqu’à ce que vous mettiez à nouveau les changements en ligne.
Pousser vers la production n’interfèrera pas avec le CDN de Kinsta s’il fonctionne sur votre site en production, mais nous recommandons de vider le cache du CDN après la poussée (WordPress Sites > nom du site > CDN > Vider le cache CDN).
Poussez vers la production avec précaution si votre site est un réseau multisite. Pousser la base de données peut ou non fonctionner, selon la façon dont le multisite est configuré. Si vous utilisez la poussée sélective et poussez la base de données ou la base de données et les fichiers, l’ensemble du contenu de la base de données sera poussé en production et affectera tous les sites (le site principal et les sous-sites) de votre réseau multisite.

Pousser le staging vers la production avec la poussée sélective

Suivez les étapes ci-dessous pour mettre en production votre environnement de staging WordPress. Le flux de travail pour la poussée sélective vous permet de choisir ce que vous allez pousser de votre site de staging vers votre site en production.

Étape 1

Connectez-vous à MyKinsta, cliquez sur Sites WordPress, et cliquez sur le site vers lequel vous voulez pousser. Utilisez le sélecteur d’environnement à côté du nom du site pour sélectionner l’environnement de staging à partir duquel vous voulez pousser. Si vous avez ajouté un environnement de staging premium, vous aurez plus d’un environnement de staging à choisir.

Changez pour un environnement de staging WordPress dans MyKinsta.

Étape 2

Une fois que vous êtes dans l’environnement de préparation, cliquez sur le menu Actions de l’environnement et sélectionnez Pousser vers la production dans le menu déroulant.

Poussez l'environnement de staging en production dans MyKinsta avec la poussée sélective. — Poussez l’environnement de staging en production dans MyKinsta avec la poussée sélective.

Étape 3

Dans la popup/modale Pousser vers la production qui apparaît, choisissez Fichiers, Base de données, ou cochez les deux – en fonction de ce que vous souhaitez pousser vers la production. Saisissez le nom du site pour confirmer et cliquez sur le bouton Pousser vers la production.

Utilisez la fonction de poussée sélective pour pousser les fichiers du staging vers la production.

Voici quelques points à garder à l’esprit :

Le temps nécessaire pour compléter le processus dépend de la taille de votre site web.
MyKinsta vous informera lorsque le processus sera terminé.
Votre site web subira un temps d’arrêt de quelques secondes lors des dernières étapes du processus.
Les réglages d’environnement (redirections, géolocalisation, configuration PHP et Nginx, etc.) sont inclus dans la poussée (même si seuls Fichiers ou Base de données sont sélectionnés) et écraseront complètement les réglages d’environnement du site en production.

Cas d’utilisation et exemples de flux de travail

Vous trouverez ci-dessous quelques exemples de cas où vous souhaiteriez pousser uniquement des fichiers, uniquement la base de données, ou les deux. Gardez à l’esprit les points suivants lors de la poussée du staging vers la production :

Les réglages d’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 d’environnement du site en production.

Pousser uniquement les fichiers

Modifications apportées directement aux fichiers du thème (y compris HTML, CSS ou PHP) qui ne sauvegardent aucune donnée dans la base de données.
Téléversement 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 uniquement la base de données

Remarque : toutes les modifications apportées à la base de données du site en production 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 tout

Remarque : toutes les modifications apportées à la base de données du site réel depuis la création du site de démonstration 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éversés).
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.

Questions fréquemment posées (FAQ)

Q : Si je teste une extension dans l’environnement de staging et que je ne transfère que les fichiers dans l’environnement en production, cela créera-t-il les tables de base de données correspondantes pour l’extension ?

Si vous installez une extension sur votre site de staging qui n’a jamais été installée sur le site en production, pousser seulement les fichiers de l’environnement de staging vers le site en production 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 en production (à 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 en production peut créer la structure de la base de données.

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

Oui, cela signifie que la base de données du site en production reste inchangée et que seuls les fichiers du site en production seront écrasés.

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

Oui, tant que vos modifications ne concernent que les fichiers (pas de modifications dans le tableau de bord de WordPress – y compris les réglages des extensions, des thèmes ou des personnalisations), vous pouvez les transférer en toute sécurité sur le site en production 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.

Q : Puis-je utiliser la poussée sélective pour changer la version PHP de mon site ?

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

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

Q : 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 en production. 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 de production 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 en production plutôt que de pousser la base de données.

Q : 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 la production 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 staging 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 staging vers le site en production.