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 :

En savoir plus sur notre environnement de test Premium.

Créez un environnement de staging WordPress Standard ou Premium

Nous avons simplifié au maximum la création d’un site de staging WordPress. Dans MyKinsta, cliquez sur Sites WordPress dans le menu de 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 type d’environnement, par exemple Live, et sélectionnez Créer un nouvel environnement. Vous pouvez également cliquer sur le champ Aller à ou rechercher et sélectionner 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. Une fois qu’il est prêt, dans le site, cliquez sur le type d’environnement, par exemple Live, et sélectionnez l’environnement de staging. Vous pouvez également cliquer sur la case Aller à ou rechercher pour sélectionner 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 live

Lorsque vous êtes prêt à pousser votre environnement de staging, suivez les étapes décrites dans la section Pousser les environnements. Vous pouvez également pousser n’importe quel environnement de staging ou de production vers n’importe quel autre site.

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.

Si vous supprimez le module d’environnement de staging premium et que vous êtes dans les 30 premiers jours de votre plan d’hébergement WordPress, des frais proportionnels pour le module seront ajoutés à votre prochaine facture pour la période pendant laquelle il a été activé. Si votre plan d’hébergement WordPress est actif depuis plus de 30 jours, vous recevrez un crédit proportionnel pour les frais du module sur le solde de votre compte pour les jours restants de la période de facturation en cours. Le crédit est automatiquement utilisé pour compenser les sommes dues à Kinsta sur votre prochaine facture. Pour plus d’informations, veuillez vous référer à notre garantie de remboursement pour l’hébergement WordPress.

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 threads 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 en sous-répertoire (exemple.com, exemple.com/sous-site1, exemple.com/sous-site2) ou d’un multisite en sous-domaine (exemple.com, sous-site1.exemple.com, sous-site2.exemple.com), cela fonctionnera parfaitement avec notre environnement de staging. Tous les sous-domaines sont couverts par le certificat SSL gratuit de Kinsta.
• 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. Passez à l’environnement que vous souhaitez renommer, puis sur la page Info, cliquez sur l’icône d’édition (crayon) 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.