Ambienti di staging

Ogni installazione di WordPress su Kinsta può avere il proprio ambiente di staging gratuito, completamente separato dal sito di produzione. È l’ideale per testare le nuove versioni di WordPress, i plugin, il codice e il lavoro di sviluppo in generale. Create un sito di sviluppo in pochi minuti e condividitelo con il team.

Se volete aggiungere altri ambienti di staging, se avete bisogno di un ambiente di staging che si avvicini di più al vostro ambiente live o se avete bisogno di testare o sviluppare un sito ad alta intensità di risorse, date un’occhiata al nostro add-on Ambienti di Staging Premium.

Ambiente di staging WordPress standard

Creare un ambiente di staging WordPress

Abbiamo reso la creazione di un sito di staging WordPress il più semplice possibile. In MyKinsta, cliccate su Siti WordPress nel pannello di navigazione a sinistra. Vedrete un elenco dei vostri siti/installazioni. Selezionate il sito per il quale volete creare un ambiente di staging, cliccate sul selettore Ambiente accanto al nome del sito e selezionate Crea nuovo ambiente dal menu a tendina.

Nella finestra modale/pop-up che appare, date un nome all’ambiente, selezionate Ambiente standard e cliccate sul pulsante Crea ambiente.

Il nome dell’ambiente deve avere una lunghezza compresa tra 3 e 12 caratteri.

Successivamente, vi verrà chiesto di selezionare il tipo di ambiente che volete creare. Avrete tre opzioni.

1. Clona un ambiente esistente: questa opzione permette di clonare un ambiente esistente (live o un ambiente di staging Premium) nel nuovo ambiente di staging standard.
2. Installa un nuovo WordPress: questa opzione installa un sito WordPress vuoto e completamente funzionante, pronto per essere utilizzato immediatamente.
3. Non installare WordPress (ambiente vuoto): questa opzione installa tutto il software necessario per far funzionare un sito WordPress (server web, PHP, MySQL, ecc.) ma non installa WordPress stesso. Si tratta di una buona opzione per gli utenti che migrano a Kinsta con Duplicator o che configurano un’installazione Bedrock/Trellis con una struttura di file personalizzata.

Opzione 1 – Clona un ambiente esistente

L’opzione Clona un ambiente esistente permette di clonare qualsiasi ambiente esistente (live o ambiente di staging Premium) nel nuovo ambiente di staging Standard.

Nome dell’ambiente

Se volete cambiare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere lungo tra i 3 e i 12 caratteri.

Ambiente da clonare

Scegliete un ambiente esistente da clonare nel nuovo ambiente di staging Standard.

Opzione 2 – Nuova installazione WordPress

L’opzione Nuova installazione WordPress include diversi campi per personalizzare il vostro sito. Ecco cosa dovete sapere su ogni campo.

Nome dell’ambiente

Se volete cambiare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere tra i 3 e 12 caratteri.

Titolo del sito WordPress

Questa opzione permette di impostare il titolo del vostro sito WordPress. A seconda del tema, sarà visibile ai visitatori del sito nella scheda del browser e in altri luoghi. Potete modificare il titolo del sito nelle impostazioni di WordPress dopo la creazione del sito.

Nome utente amministratore di WordPress

Lo utilizzerete per accedere all’installazione di WordPress. In seguito potrete aggiungere altri utenti. Vi consigliamo di scegliere un nome utente diverso da “admin” per garantire la massima sicurezza.

Password amministratore WordPress

Utilizzerete questa password per accedere alla vostra installazione. Applichiamo automaticamente password sicure per proteggere gli utenti. Potete utilizzare l’opzione genera nuova password (icona di ricarica) se volete crearne una nuova. Ecco come cambiare la password di WordPress in seguito.

Email dell’amministratore di WordPress

WordPress utilizza l’indirizzo e-mail dell’amministratore per inviare notifiche importanti.

Seleziona una lingua

Selezionate la lingua che desiderate utilizzare in WordPress. Non è obbligatorio scrivere i contenuti nella stessa lingua dell’interfaccia di WordPress, quindi sentitevi liberi di scegliere la vostra lingua madre, anche se state scrivendo contenuti in inglese.

Installa WordPress Multisito

Selezionate questa casella se desiderate creare un’installazione WordPress Multisito. Una volta selezionata, potete scegliere tra un’installazione su sottodominio o su sottodirectory.

Installa WooCommerce

Se state creando un sito di ecommerce, WooCommerce è il plugin di ecommerce più diffuso. Selezionate questa casella per installarlo automaticamente.

Installa Yoast SEO

Yoast SEO è il plugin SEO più popolare per WordPress, con oltre 3 milioni di installazioni e una valutazione di 5 stelle su 5. Selezionate questa casella per installarlo automaticamente.

Installa Easy Digital Downloads

Se state creando un sito per vendere prodotti digitali, Easy Digital Downloads è una soluzione eCommerce completa per la vendita di prodotti digitali. Selezionate questa casella per installarla automaticamente.

Opzione 3 – Non installare WordPress (Ambiente vuoto)

L’opzione Non installare WordPress è utile per gli utenti che hanno bisogno di un ambiente vuoto per la migrazione di Duplicator o per testare l’installazione personalizzata di Bedrock/Trellis.

Nome dell’ambiente

Se volete cambiare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere lungo tra i 3 e i 12 caratteri.

Creare l’ambiente standard di staging

Quando siete pronti, cliccate sul pulsante Crea ambiente.

Accedere all’ambiente di staging

La creazione del nuovo ambiente può richiedere alcuni minuti. Quando è pronto, potete selezionare il nuovo Ambiente di Staging Standard nel menu a tendina del selettore Ambiente accanto al nome del sito.

Ogni ambiente ha un cerchio colorato accanto al suo nome: verde per Live, nero per Staging Standard e arancione per Staging Premium. Avrete a disposizione un pannello di controllo separato con le informazioni sulla connessione, i DNS, i backup, gli strumenti e i plugin per il vostro ambiente di staging.

Per visitare rapidamente il vostro sito di staging, andate alla scheda Domini del vostro ambiente di staging e cliccate sul link Apri URL. potete anche accedere rapidamente all’amministrazione di WordPress del vostro sito di staging cliccando sul link Apri pannello WordPress.

Struttura dell’URL e dominio

La struttura URL predefinita del vostro ambiente di staging standard segue questo formato:

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

Se avete un sito di staging più vecchio, il vostro URL potrebbe assomigliare a uno di questi:

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

Potete anche aggiungere un dominio personalizzato al vostro sito di staging se preferite usare un dominio personalizzato.

Note aggiuntive

Se avete abilitato l’SSL sul vostro sito live e clonato il sito in staging, l’SSL sarà abilitato anche sul vostro sito in staging.

Potete avviare phpMyAdmin direttamente da MyKinsta. Nella scheda Info, cliccate sul link Apri phpMyAdmin. La struttura dell’URL per lo staging di phpMyAdmin segue questo formato:

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

Cancellare e aggiornare l’ambiente di staging

Se avete bisogno di rimuovere il vostro sito di staging, andate su Siti WordPress > nome sito e passate all’ambiente di staging. Scorrete fino in fondo alla pagina e cliccate sul pulsante Elimina ambiente.

Nella finestra modale/pop-up che appare, confermate di aver capito cosa verrà eliminato, digitate il nome del sito seguito da un trattino e dalla parola “staging” (SITENAME-environmentname) nell’apposito campo, quindi cliccate sul pulsante Elimina ambiente.

Per aggiornare il vostro ambiente di staging, cancellatelo, createne uno nuovo e scegliete l’opzione 1 – Clona un ambiente esistente. Questo nuovo ambiente di staging clonato conterrà la versione più recente del vostro database di produzione e i file per i test.

In alternativa, potete ripristinare un backup dal sito di produzione a quello di staging. Il vantaggio di questo metodo è che se avete aggiunto un dominio personalizzato, questo non verrà cancellato e non dovrete aggiungerlo ogni volta che aggiornerete lo staging.

Passare dallo staging alla versione live

Per sovrascrivere il database o i file del vostro sito live o per sovrascrivere l’intero sito con il vostro sito di staging, potete utilizzare la funzione push staging to live.

Ripristinare un backup di WordPress nello staging

Potete anche ripristinare il vostro sito WordPress da un backup direttamente nell’ambiente di staging esistente. Scoprite come ripristinare un backup di WordPress in staging. Nota: tutti i backup di staging rimarranno intatti quando si ripristina un backup live in staging.

Riavviare l’ambiente di staging

In alcune situazioni, possiamo bloccare un ambiente di staging come parte di un processo di risoluzione dei problemi del server. Se vi accorgete che l’ambiente di staging è stato bloccato e vedete un errore 501 not implemented, un errore 502 o un errore 521 andando sul sito, potete riavviare l’ambiente di staging in MyKinsta andando nella pagina Info del vostro sito e cliccando su Avvia ambiente di staging.

Se non riuscite a riavviare l’ambiente di staging o non vedete il pulsante in MyKinsta, aprite una nuova chat con il nostro team di supporto per ricevere ulteriore assistenza.

Note importanti

Quando utilizzate l’ambiente di staging, ci sono diverse cose importanti da tenere presenti.

1. Impostazioni della cache della pagina per i siti di staging

Poiché gli ambienti di staging sono destinati allo sviluppo, al debug e ai test, la cache a pagina intera e la OPcache di Kinsta sono disattivate per impostazione predefinita. Se eseguite dei test di velocità del sito web, vedrete tempi di caricamento più alti della media perché le pagine non vengono servite dalla cache. Se volete abilitare la cache su un sito di staging, cliccate sul pulsante Abilita cache nella pagina Strumenti dell’ambiente di staging del vostro sito. Quando la cache è abilitata su un sito di staging, il pulsante Cancella cache sarà abilitato e potrà essere usato per cancellare la cache.

2. Credenziali dell’ambiente di staging

Se l’ambiente di staging è un clone del vostro sito di produzione, le credenziali di accesso all’amministrazione di WordPress saranno le stesse sia per il sito live che per quello di staging, a meno che non le modifichiate dopo aver creato l’ambiente di staging.

3. SEO

Per impostazione predefinita, l’indicizzazione è disattivata per i siti di staging, in modo da non danneggiare la SEO del vostro sito live/produzione. Questo avviene grazie alla combinazione di un’impostazione di WordPress e di un’intestazione HTTP che aggiungiamo automaticamente.

Potete vedere l’impostazione di WordPress andando su Impostazioni > Lettura nella bacheca di WordPress del vostro sito di staging. L’opzione per scoraggiare l’indicizzazione del sito da parte dei motori di ricerca è selezionata accanto a Visibilità dei motori di ricerca.

Gli URL temporanei di Kinsta e gli URL di staging hanno anche un’intestazione HTTP che limita i robot X-Robots-Tag: noindex, nofollow, nosnippet, noarchive, il che significa che gli URL temporanei non saranno indicizzati dai motori di ricerca. Queste intestazioni non possono essere rimosse dagli URL temporanei o di staging di Kinsta. Se volete rimuovere queste intestazioni dal sito di staging, dovrete aggiungere un dominio personalizzato.

4. Plugin

Se utilizzate plugin di programmazione social come CoSchedule o Social Networks Auto Poster, vi consigliamo di disattivarli sul vostro sito di staging. In caso contrario, potrebbero iniziare a condividere sui social network utilizzando l’URL del vostro sito di staging, che avrà un aspetto simile a: https://stg-sitename-environmentname.kinsta.cloud. Questo potrebbe falsare le vostre statistiche.

Alcuni plugin, come il plugin Jetpack, vengono eseguiti automaticamente in modalità staging sugli ambienti di staging di Kinsta. Vedrete un messaggio: “Stai eseguendo Jetpack su un server di staging”. Durante la modalità di staging, il vostro sito di staging si comporterà praticamente come il vostro sito di produzione, tranne che per il fatto che i dati non vengono trasmessi a WordPress.com e che non potete disconnettere il sito di staging (per evitare che un problema possa avere un impatto negativo sul vostro sito di produzione).

I plugin con licenza per nome di dominio possono richiedere un dominio personalizzato (invece di un sottodominio di staging di Kinsta) per funzionare correttamente. Nota: una volta aggiunto un nome di dominio personalizzato al vostro sito di staging, potrebbe essere necessario aggiornare le impostazioni di gestione della licenza del plugin o contattare il team di assistenza del plugin.

5. Prendere nota dell’URL di accesso

Se clonate il vostro sito in staging e utilizzate un plugin WordPress che modifica l’URL di accesso predefinito, la parte personalizzata dell’URL verrà copiata sul sito di staging. Esempio: http://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin

6. Lo staging deve essere usato solo per lo sviluppo e i test

L’ambiente di staging standard ha solo 2 worker PHP, non ha l’opzione di attivare il CDN di Kinsta e può andare in stand-by dopo 24 ore di inattività. Di conseguenza, deve essere utilizzato solo per lo sviluppo e i test. Gli ambienti di staging (Standard e Premium) non sono progettati per essere utilizzati per siti di produzione live e potrebbero esserci cose che non funzionano correttamente. Kinsta non è responsabile se si cerca di utilizzare un ambiente di staging per un sito in produzione.

7. Spazio su disco escluso dal totale del piano

Per offrirvi il massimo spazio possibile, i siti di staging sono esclusi dalla nostra reportistica quando calcoliamo l’utilizzo totale dello spazio su disco. Solo i siti live contano nell’utilizzo dello spazio su disco.

8. Cron Job

I cron job del server dell’ambiente live non sono attivi nell’ambiente di staging (anche se clonate il vostro sito live nello staging), quindi i cron job del sito live non verranno attivati nell’ambiente di staging. Inoltre, se modificate il crontab nell’ambiente di staging e fate il push dello staging nell’ambiente live, questo sovrascriverà il crontab dell’ambiente live.

9. Multisito

Se gestite una rete WordPress multisito, il nostro ambiente di staging potrebbe funzionare o meno, a seconda di come è configurato il vostro multisito.

• Se si tratta di un multisito con sottodirectory (example.com, example.com/subsite1, example.com/subsite2), funzionerà bene con il nostro ambiente di staging.
• Se si tratta di un sottodominio multisito (example.com, subsite1.example.com, subsite2.example.com), funzionerà bene, a patto che i sotto-siti non richiedano HTTPS.
  • Se si tratta di un sottodominio multisito che richiede l’HTTPS, dovrete aggiungere un dominio personalizzato con un certificato SSL wildcard al vostro sito di staging in modo che i sottodomini possano essere coperti da un certificato SSL. Questo perché il certificato SSL fornito per l’URL di staging predefinito può coprire solo il sottodominio di staging (ad esempio stg-sitename-environmentname.kinsta.cloud), quindi qualsiasi altro sottodominio (ad esempio subsite.stg-sitename-environmentname.kinsta.cloud) non può essere coperto.
• Se si tratta di un multisito con mappatura del dominio (carica diversi sottositi su domini completamente diversi, ad esempio example.com, example1.com, example2.com), non funzionerà senza una significativa configurazione manuale.
  • Opzione 1: disattivare la mappatura dei domini e tornare alla configurazione standard di sottodirectory/sottodomini. Eseguire un cerca e sostituisci nel database manualmente.
  • Opzione 2: creare dei sottodomini di staging per ogni dominio live, aggiungerli tutti al sito di staging ed eseguire manualmente un cerca e sostituisci nel database.

10. Posta elettronica

Gli ambienti di staging hanno l’invio di email (email transazionali) abilitato per impostazione predefinita. Se effettuate un ordine sul sito di staging, riceverete le relative e-mail dal sito di staging. Se non volete che le email transazionali vengano inviate dal vostro ambiente di staging, potete utilizzare un plugin come Disable Emails per impedire al sito di inviare email.

Ambienti di staging premium

Con il componente aggiuntivo Ambiente di Staging Premium di Kinsta, potete aggiungere fino a cinque ambienti di staging Premium al vostro sito WordPress. Anche se un ambiente di staging standard funziona per la maggior parte dei test, l’utilizzo di un ambiente di staging Premium è ideale per i test o lo sviluppo di un sito che richiede molte risorse.

Ogni ambiente di staging Premium ha 12 CPU, 8 GB di memoria e lo stesso numero di PHP Worker che avete per il sito live (in base al vostro piano). Potete anche attivare il CDN di Kinsta per un ambiente di testing Premium. Con un ambiente di test che corrisponde perfettamente al vostro ambiente live, potete anche eseguire test di velocità del sito web sul sito di prova.

Includendo l’ambiente di testing standard gratuito, potete disporre di un totale di 6 ambienti per il testing e lo sviluppo, completamente separati dal vostro sito live.

Aggiungere un ambiente di staging Premium

In MyKinsta, cliccate su Siti WordPress nella navigazione a sinistra. Vedrete un elenco dei vostri siti/installazioni. Selezionate il sito per il quale volete creare un ambiente di staging Premium, cliccate sul selettore Ambiente accanto al nome del sito e selezionate Crea nuovo ambiente dal menu a tendina.

Il componente aggiuntivo Premium per l’ambiente di staging può essere acquistato al prezzo di $20/mese per ambiente (prorata). Potete acquistare fino a 5 add-on per ambienti di staging premium. Ogni componente aggiuntivo di ambiente di staging Premium è automaticamente prorogato e l’abbonamento apparirà nel ciclo di fatturazione successivo.

Nella finestra modale/pop-up Crea un nuovo ambiente, date un nome al vostro ambiente, selezionate Ambiente Premium e cliccate sul pulsante Crea ambiente.

Il nome dell’ambiente deve avere una lunghezza compresa tra 3 e 12 caratteri.

Successivamente, vi verrà chiesto di selezionare il tipo di ambiente che volete creare. Ci sono tre opzioni:

1. Clona un ambiente esistente: questa opzione permette di clonare un ambiente esistente (live, Standard Staging o un altro ambiente Premium Staging) nel nuovo ambiente Premium Staging.
2. Installa un nuovo WordPress: questa opzione installa un sito WordPress vuoto e completamente funzionante, pronto per essere utilizzato immediatamente.
3. Non installare WordPress (ambiente vuoto): questa opzione installa tutto il software necessario per far funzionare un sito WordPress (server web, PHP, MySQL, ecc.) ma non installa WordPress stesso. Si tratta di una buona opzione per gli utenti che migrano a Kinsta con Duplicator o che configurano un’installazione Bedrock/Trellis con una struttura di file personalizzata.

Opzione 1 – Clona un ambiente esistente

L’opzione Clona un ambiente esistente permette di clonare qualsiasi ambiente esistente (live, Standard Staging o altro ambiente Premium Staging) nel nuovo ambiente Premium Staging.

Nome dell’ambiente

Se volete cambiare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere tra i 3 e i 12 caratteri.

Ambiente da clonare

Scegliete un ambiente esistente da clonare nel nuovo ambiente staging Premium.

Opzione 2 – Nuova installazione WordPress

L’opzione Nuova installazione WordPress include diversi campi per personalizzare il vostro sito. Ecco cosa c’è da sapere su ogni campo.

Nome dell’ambiente

Se volete modificare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere compreso tra 3 e 12 caratteri.

Titolo del sito WordPress

Questa opzione permette di impostare il titolo del vostro sito WordPress. A seconda del tema, sarà visibile ai visitatori del sito nella scheda del browser e in altri luoghi. Potete modificare il titolo del sito nelle impostazioni di WordPress dopo la creazione del sito.

Nome utente amministratore di WordPress

Lo utilizzerete per accedere all’installazione di WordPress. In seguito potrete aggiungere altri utenti. Vi consigliamo di scegliere un nome utente diverso da “admin” per garantire la massima sicurezza.

Password amministratore WordPress

Utilizzerete questa password per accedere all’installazione. Applichiamo automaticamente password sicure per proteggere gli utenti. Potete utilizzare l’opzione genera nuova password (icona di ricarica) se ne volete creare una nuova. Ecco come cambiare la password di WordPress in seguito.

Email dell’amministratore di WordPress

WordPress utilizza l’indirizzo e-mail dell’amministratore per inviare notifiche importanti.

Seleziona una lingua

Selezionate la lingua in cui desiderate utilizzare WordPress. Non è obbligatorio scrivere i contenuti nella stessa lingua dell’interfaccia di WordPress, quindi scegliete pure la vostra lingua madre, anche se state scrivendo contenuti in inglese.

Installa WordPress Multisito

Selezionate questa casella se desiderate creare un’installazione WordPress Multisito. Una volta selezionata, potete scegliere tra un’installazione su sottodominio o su sottodirectory.

Installa WooCommerce

Se state creando un sito di ecommerce, WooCommerce è il plugin di ecommerce più diffuso. Selezionate questa casella per installarlo automaticamente.

Installa Yoast SEO

Yoast SEO è il plugin SEO più popolare per WordPress, con oltre 3 milioni di installazioni e una valutazione di 5 stelle su 5. Selezionate questa casella per installarlo automaticamente.

Installa Easy Digital Downloads

Se state creando un sito per vendere prodotti digitali, Easy Digital Downloads è una soluzione eCommerce completa per la vendita di prodotti digitali. Selezionate questa casella per installarla automaticamente.

Opzione 3 – Non installare WordPress (Ambiente vuoto)

L’opzione Non installare WordPress è utile per gli utenti che hanno bisogno di un ambiente vuoto per la migrazione di Duplicator o per testare l’installazione personalizzata di Bedrock/Trellis.

Nome dell’ambiente

Se volete cambiare il nome dell’ambiente, potete farlo qui. Il nome dell’ambiente deve essere lungo tra i 3 e i 12 caratteri.

Creare l’ambiente di Staging Premium

Quando sarete pronti, cliccate sul pulsante Crea ambiente. Confermate quindi l’abbonamento ricorrente per l’ambiente di Staging Premium e cliccate sul pulsante Aggiungi abbonamento.

Accedere all’ambiente di staging premium

La creazione del nuovo ambiente può richiedere alcuni minuti. Quando sarà pronto, potrete selezionare il nuovo ambiente di staging premium nel selettore dell’ambiente accanto al nome del sito.

Ogni ambiente ha un cerchio colorato accanto al suo nome: verde per Live, nero per Staging Standard e arancione per Staging Premium. Per il vostro ambiente di staging, avrete a disposizione un pannello di controllo separato con le informazioni sulla connessione, i DNS, i backup, gli strumenti e i plugin.

Per visitare rapidamente il vostro sito di staging, andate alla scheda Domini del vostro ambiente di staging e cliccate sul link Apri URL. Potete anche accedere rapidamente all’amministrazione di WordPress del vostro sito di staging cliccando sul link Apri pannello WordPress.

Struttura dell’URL e dominio

La struttura URL predefinita del vostro ambiente di staging Premium segue questo formato:

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

Potete anche aggiungere un dominio personalizzato al vostro sito di staging se preferite usare un dominio personalizzato.

Eseguire il push da un ambiente di staging Premium a un altro ambiente

Ogni ambiente di staging può essere spinto verso un altro ambiente di staging o verso il vostro ambiente live.

Con la funzione Selective Push, avete un controllo granulare su cosa spostare dal vostro ambiente di staging a un altro ambiente. In particolare, potete eseguire il push:

• solo i vostri file,
• solo il vostro database,
• o entrambi.

Per maggiori dettagli, consultate la nostra guida su come eseguire il Push da Staging a Live. Il procedimento è lo stesso; dovrete solo scegliere l’ambiente in cui effettuare il push dall’ambiente di staging Premium.

Rimuovere un ambiente di Staging Premium

Una volta terminati i test o lo sviluppo, potete rimuovere l’ambiente di staging Premium e l’abbonamento in MyKinsta. Il componente aggiuntivo ambiente di staging Premium verrà addebitato solo per il periodo in cui è attivo. Cancellate il componente aggiuntivo eliminando l’ambiente di staging Premium per interrompere la fatturazione aggiuntiva.

In MyKinsta, cliccate su Siti WordPress nella navigazione a sinistra. Vedrete un elenco dei vostri siti/installazioni. Selezionate il sito da cui volete rimuovere l’Ambiente di Staging Premium, cliccate sul selettore Ambiente accanto al nome del sito e selezionate l’ambiente dal menu a tendina.

Scorrete fino in fondo alla pagina e cliccate sul pulsante Elimina ambiente.

Nella finestra modale/pop-up che appare, confermate di aver capito cosa verrà eliminato, digitate il nome del sito seguito da un trattino e il nome dell’ambiente (SITENAME-EnvironmentName) nell’apposito campo, quindi cliccate sul pulsante Elimina ambiente.

Una volta eliminato l’ambiente di staging Premium, l’abbonamento al componente aggiuntivo verrà automaticamente rimosso da Azienda > Il mio piano in MyKinsta.

DOMANDE FREQUENTI

Cosa si intente per pro rata?

Quando addebitiamo un servizio come il componente aggiuntivo Ambiente di Staging Premium pro rata, significa che vi verrà addebitato il costo in base al tempo di utilizzo del servizio per quel ciclo di fatturazione mensile.

Esempio di addebito pro rata

Dovete lanciare una nuova funzionalità sul vostro sito e volete testarla con tutta la potenza del vostro piano. Create un ambiente di staging Premium, aggiungete la nuova funzione e la testate per un’ora. Tutto sembra perfetto, per cui trasferite la modifica all’ambiente live e cancellate l’ambiente di prova Premium.

• 1 mese di un ambiente di staging Premium costa 20 dollari.
• Basato su un mese di 30 giorni, questo ciclo di fatturazione ha un totale di 720 ore.
  30 * 24 = 720
• Ogni ora di utilizzo costa 0,03 dollari.
  $20 / 720 = $0.03
• La prossima fattura includerà gli 0,03 dollari dovuti per l’ora in cui un ambiente di staging premium è stato aggiunto al vostro piano.

Esempio di addebito pro rata

Acquistate un ambiente di staging Premium a metà del vostro ciclo di fatturazione mensile e lo utilizzate fino alla fine del ciclo stesso. Vi verrà addebitato il costo di metà mese di utilizzo (circa 10 dollari, ripartiti al secondo).

È possibile cambiare il nome di un Ambiente di Staging Premium?

Sì. Passate all’ambiente che volete rinominare e cliccate sull’icona di modifica (matita) nella sezione Nome dell’ambiente nel campo Nome dell’ambiente.

Inserite il nuovo nome e cliccate sul pulsante Rinomina ambiente.

Questa operazione cambierà il nome dell’ambiente visualizzato nella sezione degli ambienti, ma non influirà sul dominio kinsta.cloud generato durante la creazione dell’ambiente iniziale.

È possibile ripristinare un backup in un ambiente di staging?

Sì, ma prima è necessario creare un ambiente di staging Standard o Premium. In passato, era possibile creare un ambiente di staging automaticamente quando si ripristinava un backup. Con l’introduzione degli Ambienti di Staging Premium, dovrete creare l’ambiente di staging prima di ripristinarvi un backup.

Chi ha accesso agli Ambienti di Staging Premium?

Gli sviluppatori e gli amministratori del sito hanno accesso agli ambienti di staging Premium che sono stati creati, ma non possono creare o eliminare un ambiente di staging Premium. Solo il proprietario o l’amministratore di un’azienda possono creare o eliminare un ambiente di staging Premium.

Lo staging consuma spazio su disco?

No. Per offrirvi il massimo spazio possibile, i siti di staging sono esclusi dai nostri report quando calcoliamo l’utilizzo totale dello spazio su disco. Solo i siti live contano per il vostro limite di spazio su disco.

Passare dallo staging al live

Avete la possibilità di eseguire il push dell’ambiente di staging di WordPress verso l’ambiente live quando sarete soddisfatti delle modifiche apportate e volete che vengano applicate al vostro sito live. Grazie alla funzione Selective Push, potete avere un controllo granulare sulle modifiche da inviare al sito live.

In passato, il push da staging a live era un processo che prevedeva che l’ambiente di staging sovrascrivesse completamente il sito live durante il push. Con Selective Push, potete scegliere cosa far passare dall’ambiente di staging al sito live. In particolare, ora potete eseguire il push di:

• solo i file,
• solo il database,
• o entrambi.

Il passaggio dallo staging alla versione live può essere effettuato in pochi clic, ma prima di procedere leggete le note qui sotto: contengono informazioni essenziali sul processo.

Note importanti

• Vi consigliamo di utilizzare la funzionalità Invia a Live con cautela, di avviarla in momenti di scarso traffico e di avere uno sviluppatore a portata di mano per ogni evenienza. Se avete bisogno dell’assistenza di uno sviluppatore, ci sono diversi posti dove potete assumerne uno.
• Creiamo un backup automatico in modo che possiate fare un rollback se necessario. Nota: se il vostro sito live è un e-commerce o un altro sito dinamico e in rapida evoluzione, i dati potrebbero andare persi tra il momento in cui effettuate il push e quello in cui il backup viene ripristinato.
• Le impostazioni dell’ambiente (reindirizzamenti, geolocalizzazione, configurazione di PHP e Nginx, ecc.) sono incluse nel push (anche se si seleziona solo File o Database ) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.
• Una volta completato il push, svuotate la cache del tema o dei plugin, cancellate la cache del browser e verificate che il sito funzioni come previsto.
• Durante il push del database, se selezionate l’opzione Esegui ricerca e sostituzione, il dominio di staging verrà automaticamente sostituito con il dominio del sito live.
• Selezionando File, verranno inviati tutti i file, compresi i plugin, i temi e i file all’interno di wp-content/uploads.
• Qualsiasi URL codificato nel codice del vostro tema o del vostro plugin dovrà essere aggiornato con l’URL del sito live.
• Se nell’ambiente di staging è attiva la protezione con password (.htpasswd), questa non verrà trasferita nell’ambiente live. Se avete bisogno di questa impostazione sul vostro sito live, dovrete abilitarla sul sito live stesso.
• Quando utilizzate WooCommerce, MyKinsta non distingue tra gli ordini dei nuovi clienti e quelli più vecchi quando si passa dall’ambiente di staging a quello live. Quando avviate un push to live, MyKinsta copia il vostro sito di staging sul sito live esattamente com’è, sovrascrivendo i file e il database. Per ovviare a questo problema, potete esportare gli ordini sul sito live, eseguire l’invio a live e poi reimportare gli ordini/clienti nell’ambiente live. Dovrete discutere di questa operazione con il vostro sviluppatore web. Se non ne avete uno o non vi sentite sicuri a procedere da soli, consultate il nostro articolo su come assumere uno sviluppatore WordPress.
• Controllate a fondo il sito di staging e risolvete eventuali errori prima di passare all’ambiente live.
• Gli ambienti di staging sono destinati esclusivamente allo sviluppo e ai test. Non sono progettati per essere utilizzati come siti di produzione live e potrebbero esserci cose che non funzionano come previsto. Kinsta non è responsabile se si cerca di utilizzare un ambiente di staging per un sito live.
• Il passaggio alla versione live non influisce sull’ambiente di staging, che rimarrà separato dal sito live. Dopo il passaggio alla versione live, potete continuare a sviluppare e testare le modifiche nell’ambiente di staging senza influenzare il vostro sito live fino a quando non le sposterete nuovamente nella versione live.
• Il push non interferisce con il CDN di Kinsta se è in funzione sul vostro sito live, ma vi consigliamo di cancellare la cache del CDN dopo il push (Siti WordPress > nome sito > CDN > Svuota cache CDN).
• Fate attenzione se il vostro sito è un network multisito. Il push del database può funzionare o meno, a seconda di come è impostato il multisito. Se utilizzate il push selettivo ed eseguite il push del database o del database e dei file, il push dell’intero contenuto del database verrà eseguito in tempo reale e interesserà tutti i siti (il sito principale e i sottositi) della rete multisito.

Eseguire il push dallo staging al live con il push selettivo

Seguite questi passi per portare l’ambiente di staging di WordPress in modalità live. Il flusso di lavoro per il push selettivo permette di scegliere cosa spostare dal sito di staging al sito live.

Passo 1

Accedete a MyKinsta, cliccate su Siti di WordPress e cliccate sul sito di cui volete eseguire il push. Usate il selettore dell’ambiente accanto al nome del sito per selezionare l’ambiente di staging da cui volete effettuare il push. Se avete aggiunto un ambiente di staging Premium, avrete più di un ambiente di staging tra cui scegliere.

Passo 2

Una volta entrati nell’ambiente di staging, cliccate sul menu delle azioni dell’ambiente e selezionate Invia a live dal menu a tendina.

Passo 3

Nel pop-up/modale Invia a Live che appare, scegliete File, Database o selezionate entrambi, a seconda di ciò che desiderate inviare al live. Digitate il nome del sito per confermare e cliccate sul pulsante Invia a Live.

Alcune cose da tenere a mente sono:

• Il tempo necessario per completare il processo dipende dalle dimensioni del vostro sito web.
• MyKinsta vi avviserà quando il processo sarà completato.
• Il vostro sito web subirà un downtime di un paio di secondi nelle fasi finali del processo.
• Le impostazioni dell’ambiente (reindirizzamenti, geolocalizzazione, configurazione di PHP e Nginx, ecc.) sono incluse nel push (anche se si seleziona solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.

Casi d’uso e workflow di esempio

Di seguito abbiamo illustrato alcuni esempi di casi in cui potreste voler eseguire il push solo dei file, solo del database o di entrambi. Tenete presente quanto segue quando eseguite il push dello staging verso la versione live:

• Le impostazioni dell’ambiente (reindirizzamenti, geolocalizzazione, configurazione di PHP e Nginx, ecc.) sono incluse nel push (anche se si seleziona solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.

Eseguire il push dei file

• Con modifiche apportate direttamente ai file del tema (compresi HTML, CSS o PHP) che non salvano alcun dato nel database.
• Quando si carica un file che non deve essere incluso nella libreria multimediale di WordPress.
• Se avete un plugin personalizzato sul vostro sito e apportate modifiche ai file che non influiscono sul database (non salvano o alterano i dati nel database).

Eseguire il push del database

Nota: tutte le modifiche apportate al database del sito live dopo la creazione del sito di staging andranno perse, compresi, ma non solo: commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni a siti di membership e post su forum.

• Quando si crea o modifica di un nuovo post o di una pagina che non include alcun media caricato (immagini, video o altri file caricati).
• Quando si eseguono modifiche al layout di una pagina o di un post effettuate tramite un plugin builder.
• Quando si modifica il titolo o la tagline del sito.

Eseguire il push di tutto

Nota: tutte le modifiche apportate al database del sito live dopo la creazione del sito di staging andranno perse, compresi, ma non solo: commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni a siti di membership e post su forum.

• Quando si creano nuovi contenuti che includono media caricati (immagini, video o altri file caricati).
• Con modifiche al vostro tema effettuate sia nel Customizer che nei file del tema.
• Quando si installano e testano nuovi plugin o una versione aggiornata di un plugin.

Domande frequenti (FAQ)

D: Se si prova un plugin nell’ambiente di staging e si esegue il push solo dei file nella versione live, verranno create le tabelle del database corrispondenti al plugin?

Se installate un plugin sul vostro sito di staging che non è mai stato installato sul sito live, il push dei soli file dallo staging al live non creerà le tabelle del database per quel plugin.

Ciò significa anche che tutte le impostazioni configurate nel plugin non verranno trasferite al sito live (a meno che le impostazioni non siano salvate in un file esterno al database, ad esempio in un file JSON).

A seconda di come è codificato il plugin, l’attivazione (prima della disattivazione, se necessario) del plugin sul sito live può creare la struttura del database.

D: Se si esegue il push solo dei file al sito live, allora il vecchio database (in staging) non sovrascriverà quello live, ma solo i file?

Sì, quando si esegue il push solo dei file, il database del sito live rimane invariato e che solo i file del sito live verranno sovrascritti.

D: Questo significa che è possibile lavorare alle modifiche del design sul sito di staging e trasferirle al sito live senza perdere i nuovi abbonati o clienti del sito live?

Sì, a patto che le modifiche vengano apportate solo ai file (nessuna modifica nella bacheca di WordPress, comprese le impostazioni di plugin, temi o customizer), potete tranquillamente inviarle al sito live senza dover modificare il database. Quando inviate le modifiche in modalità live, selezionate File e assicuratevi che Database non sia selezionato.

D: Si può usare il push selettivo per cambiare la versione PHP del sito?

Sì, potete usare lo staging per testare ed eseguire il push di una nuova versione PHP nell’ambiente live, ma non è strettamente necessario eseguire il push dallo staging al live per aggiornare la versione PHP. Ecco una breve panoramica su come modificare la versione di PHP senza eseguire il push dallo staging alla versione live:

1. Create un sito di staging.
2. Andate sul sito di staging e cambiate la versione di PHP sul sito di staging.
3. Se tutto è a posto e funziona come previsto sul sito di staging (assicuratevi di testare accuratamente il vostro sito), cambiate la versione PHP sul sito live.

D: Sono state apportate modifiche ai CSS nella bacheca di WordPress ed è stato eseguito il push dei file. Perché non vengono visualizzate le modifiche, anche dopo aver cancellato tutta la cache?

A seconda del tipo di modifica apportata e di dove sono memorizzate le informazioni, potrebbe essere necessario effettuare il push del database o apportare le modifiche manualmente sul sito live. Ad esempio, se avete aggiunto o modificato il CSS in un blocco o in un widget nella bacheca di WordPress, probabilmente questo verrà salvato nel database.

Se apportate delle modifiche a qualcosa nella bacheca di WordPress, ad eccezione delle modifiche apportate con l’Editor del tema (Aspetto > Editor del tema), di solito queste informazioni vengono salvate nel database.

Nota: tutte le modifiche apportate al database del sito live dopo la creazione del sito di staging andranno perse, compresi, ma non solo: commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni a siti di membership e post sui forum. In questo caso, consigliamo di apportare le stesse modifiche manualmente sul sito live piuttosto che effettuare il push del database.

D: Come funziona il push selettivo in una rete multisito?

Se si usa il push selettivo per eseguire il push dei soli file, funzionerà bene, indipendentemente dal tipo di rete multisito. Se invece si esegue il push solo del database o di database e file, può funzionare o meno, a seconda di come è configurato il vostro multisito:

• Se si tratta di un multisito con sottodirectory (example.com, example.com/subsite1, example.com/subsite2), l’invio al live funzionerà come previsto.
• Se si tratta di un sottodominio multisito (example.com, subsite1.example.com, subsite2.example.com), funzionerà bene, a patto che i sotto-siti non richiedano HTTPS.
• Se si tratta di un multisito con mappatura del dominio (carica diversi sottositi su domini completamente diversi, ad esempio example.com, example1.com, example2.com), non funzionerà senza una significativa configurazione manuale.
  • Opzione 1: disattivate la mappatura dei domini e tornate alla configurazione standard di sottodirectory/sottodomini. Eseguite un cerca e una sostisci nel database manualmente.
  • Opzione 2: create dei sottodomini di staging per ogni dominio live, aggiungeteli tutti al sito di staging ed eseguite manualmente un cerca e sostituisci nel database per aggiornare ogni dominio dopo aver trasferito lo staging al sito live.