Ambienti di staging

Ogni installazione di WordPress su Kinsta può avere il proprio ambiente staging WordPress 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. È possibile creare un sito di sviluppo in pochi minuti e condividerlo con il proprio 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 Ambiente di Staging Premium.

Staging standard e Premium

È possibile aggiungere fino a 5 ambienti di staging Premium, che includono più risorse e più funzioni rispetto agli ambienti Standard. La seguente tabella mostra le differenze tra lo staging Standard e quello Premium:

	Premium	Standard
PHP worker	Come nell’ambiente live	1
CPU	12	1
RAM	8 GB	8 GB
CDN	Sì	No
Edge Caching	Sì, può essere abilitato	No

Scoprite di più sul nostro add-on per ambienti di staging Premium.

Creare un ambiente di staging WordPress Standard o Premium

Abbiamo reso la creazione di un sito di staging WordPress il più semplice possibile. 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, cliccate sulla casella Vai a o cerca e selezionate Crea nuovo ambiente.

Nella finestra modale/pop-up Crea nuovo ambiente, selezionate l’ambiente Standard o Premium e cliccate su Continua.

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

1. Clonare un ambiente esistente: questa opzione permette di clonare un ambiente esistente (live o qualsiasi ambiente di staging Premium) nel nuovo ambiente di staging.
2. Installare un nuovo WordPress: questa opzione installa un sito WordPress vuoto e completamente funzionante, pronto per essere utilizzato immediatamente.
3. Ambiente vuoto (senza WordPress): 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 Uno – Clona un ambiente esistente

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

• Nome dell’ambiente: inserite un nome per l’ambiente di staging; deve essere lungo tra i 3 e i 12 caratteri.
• Ambiente da clonare: scegliete un ambiente esistente da clonare nel nuovo ambiente di staging.

Opzione due – Installa nuovo WordPress

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

• Nome dell’ambiente: inserite un nome per l’ambiente di staging; deve essere lungo tra i 3 e i 12 caratteri.
• Titolo del sito WordPress: consente di impostare il titolo del 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 alla vostra 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 di amministrazione di WordPress: utilizzerete questa password per accedere alla vostra installazione. Applichiamo automaticamente password forti per proteggere gli utenti. Potete utilizzare l’opzione genera nuova password (icona di ricarica) se ne volete una nuova. Ecco come cambiare la password di WordPress in seguito.
• Email di amministrazione di WordPress: WordPress utilizza l’indirizzo e-mail dell’amministratore per inviare notifiche importanti.
• Seleziona 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’ installazionesu 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 un punteggio 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.

Terza opzione – Ambiente vuoto (senza WordPress)

L’opzione Ambiente vuoto è 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: inserite un nome per l’ambiente di staging; deve essere lungo tra i 3 e i 12 caratteri.

Creare l’ambiente di staging

Una volta pronti, cliccate su Continua. Se state creando un ambiente di staging Premium, confermate l’abbonamento ricorrente e cliccate su Crea ambiente Premium.

Accedere all’ambiente di staging

La creazione del nuovo ambiente può richiedere alcuni minuti. Quando è pronto, cliccate sulla casella Vai a o cerca e selezionate l’ambiente.

Potete accedere all’ambiente di staging anche dall’elenco dei siti WordPress.

Ogni ambiente ha un cerchio colorato con il 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 alla bacheca 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 segue questo formato:

• Standard: https://stg-sitename-environmentname.kinsta.cloud
• Premium: https://env-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 usarne uno.

Note aggiuntive

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

Potete lanciare 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

Aggiornare l’ambiente di staging

Se dopo aver creato l’ambiente di staging apportate delle modifiche al vostro sito live e volete rifletterle nello staging, potete utilizzare un push selettivo per aggiornare l’ambiente di staging. In questo modo, non dovrete cancellare e ricreare l’ambiente di staging, risparmiando tempo e conservando i backup dello staging.

Eseguire il push dell’ambiente in live o in staging

Potete eseguire il push dell’ambiente di staging di WordPress verso l’ambiente live se siete soddisfatti delle modifiche apportate e volete che vengano applicate al vostro sito live.

Potete anche inviare l’ambiente live all’ambiente di staging. Questo è utile per aggiornare l’ambiente di staging in modo da riflettere le modifiche apportate nell’ambiente live.

Con la funzione Push selettivo, avete un controllo granulare su come eseguire il push. In particolare, potete scegliere di eseguire il push:

• solo dei file,
• solo del vostro database,
• di file e cartelle specifiche,
• di tabelle specifiche del database,
• di tutto.

Il push degli ambienti può essere effettuato in pochi clic, ma prima di procedere leggete le note che seguono: contengono informazioni essenziali sul processo.

Note importanti

• Vi consigliamo di usare la funzionalità Esegui il push dell’ambiente con cautela, soprattutto quando si tratta di passare da staging a live. Iniziate il processo in orari di scarso traffico e tenete a disposizione uno sviluppatore in caso di problemi. Se avete bisogno dell’assistenza di uno sviluppatore, ci sono diversi posti dove potete trovarne 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.
• Una volta completata l’operazione di push dallo staging alla versione live, svuotate la cache del tema o dei plugin, svuotate la cache del browser e testate il sito per verificare che funzioni come previsto.
• Durante il trasferimento del database, se selezionate l’opzione Esegui ricerca e sostituzione, il dominio verrà automaticamente sostituito con il dominio dell’ambiente in cui state eseguendo il trasferimento.
• Selezionando Tutti i file e le cartelle, 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 plugin dovrà essere aggiornato con l’URL dell’ambiente.
• Se la protezione con password (.htpasswd) è attiva nell’ambiente da cui state effettuando il push, non verrà applicata all’ambiente in cui state effettuando il push. Dovete attivarla nell’ambiente dopo il push.
• Quando utilizzate WooCommerce, MyKinsta non distingue tra gli ordini dei nuovi clienti e quelli più vecchi quando eseguite il push dello staging verso la versione live. Quando avviate un push verso il sito live, se eseguite il push di tutti i file e le cartelle MyKinsta copia il vostro sito di staging sul sito live esattamente com’è, sovrascrivendo i file e il database. Per ovviare a questo problema, potete
  • eseguire il push dello staging al sito live con un push selettivo dei soli file in modo che il database non venga sovrascritto.
  • Eseguire il push selettivo delle tabelle del database ed escludere le tabelle di WooCommerce necessarie.
  • Eseguire il push dei file del database dal live allo staging prima di eseguire il push dello staging al live per assicurarvi di avere i dati più aggiornati.

  Per informazioni su cosa è incluso in ogni tabella del database di WooCommerce, consultate la Descrizione del database di WooCommerce. Dovrete discutere di questo compito con il vostro sviluppatore web. Se non ne avete uno o non siete sicuri di cosa fare, consultate il nostro articolo su come assumere uno sviluppatore WordPress.

• Quando eseguite il push dallo staging alla versione live, controllate due volte il sito di staging e risolvete eventuali errori prima di passare alla versione 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 nel caso in cui doveste cercare di utilizzare un ambiente di staging per un sito live.
• Il push di un ambiente non influisce sull’ambiente da cui viene eseguito e rimarrà separato dagli altri ambienti. Dopo aver spinto un sito di staging verso la versione live, Potete continuare a sviluppare e testare le modifiche nello staging senza influenzare il vostro sito live fino a quando non eseguirete nuovamente il push delle modifiche alla versione live.
• Il push da staging a live non interferisce con il CDN di Kinsta se è in funzione sul vostro sito live, ma vi consigliamo di svuotare la cache del CDN dopo il push (Siti WordPress > nome sito > Cache > CDN > Svuota cache CDN).
• Eseguite il push dallo staging alla versione live con cautela se il vostro sito è un network multisito. Il push del database può funzionare o meno, a seconda di come è impostato il multisito. Se eseguite il push selettivo e il push di Tutte le tabelle del database o di Tutte le tabelle del database e di Tutti i file e le cartelle, l’intero contenuto del database sarà portato in diretta e interesserà tutti i siti (il sito principale e i sottositi) della rete multisito.
• Se usate una configurazione di WordPress non standard, come Bedrock o Trellis, Kinsta potrebbe non essere in grado di localizzare la variabile DB_PASSWORD e, quindi, non essere in grado di aggiornare la password del database quando si esegue il push dell’ambiente di staging alla versione live. In questo caso, quando l’ambiente viene reso operativo, dovete aggiornare manualmente il file in cui definite DB_PASSWORD con la nuova password del database definita in MyKinsta.

Eseguire il push di un ambiente con un push selettivo

Seguite i passi qui in basso per eseguire il push del vostro ambiente verso un altro ambiente. Il flusso di lavoro per il push selettivo permette di scegliere gli elementi di cui eseguire il push.

1. Selezionare l’ambiente

Accedete a MyKinsta, cliccate su Siti WordPress e cliccate sull’ambiente da cui volete effettuare il push. Se avete aggiunto un ambiente di staging Premium, avrete a disposizione più di un ambiente di staging tra cui scegliere.

2. Eseguire il push dell’ambiente

Nell’ambiente, cliccate su Esegui il push dell’ambiente e selezionate Invia a ambiente dal menu a tendina.

3. Selezionare i file e le tabelle del database da inviare

Nel pop-up Invia a ambiente che appare, scegliete tra i:

• File > Tutti i file e le cartelle: esegue il push di tutti i file e le cartelle nell’ambiente selezionato.
• File > File e cartelle specifici: scegliete esattamente i file e le cartelle che volete inviare all’ambiente selezionato. Potete usare l’area di testo per definire un percorso/cartella/file specifico da spingere. Per maggiori informazioni sull’utilizzo di ogni file di WordPress, consultate la nostra Guida completa sui file di WordPress e sul loro utilizzo.
• Database > Tutte le tabelle del database: esegue il push di tutte le tabelle del database nell’ambiente selezionato.
• Database > Tabelle specifiche del database: scegliete esattamente le tabelle del database che volete inviare all’ambiente selezionato. Per maggiori informazioni sul database di WordPress, consultate la Guida per principianti al database di WordPress: Cos’è e come accedervi.

Inserite il nome del sito per confermare e cliccate su Invia a ambiente.

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.
• Quando si passa dalla fase di staging a quella live, 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 sono stati selezionati solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente.

Casi d’uso e flussi di lavoro di esempio

Qui di seguito abbiamo illustrato alcuni esempi di quando potreste voler eseguire il push solo dei file, solo del database o di entrambi.

Eseguire il push di tutti i file e le cartelle

• Modifiche apportate direttamente ai file del tema (compresi HTML, CSS o PHP) che non salvano alcun dato nel database.
• Caricamento di 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 di file e cartelle specifici

• Se apportate modifiche a un singolo tema, potete eseguire il push della cartella specifica del tema all’interno della cartella themes.
• Se testate una nuova versione di un plugin in staging, potete spingere la cartella specifica del plugin all’interno della cartella plugins.
• Potete inviare le modifiche al live per specifiche impostazioni o file di configurazione definendo il percorso/cartella/file da inviare nell’area di testo.

Eseguire il push del solo 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 su siti di membership e post su forum.

• Creazione o modifica di un nuovo post o di una pagina che non include alcun media caricato (immagini, video o altri file caricati).
• Modifiche al layout di una pagina o di un post effettuate tramite un plugin builder.
• Modifica del titolo o della tagline del sito.

Eseguire il push di tabelle specifiche del database

• Se state testando un plugin o un tema WordPress personalizzato in staging che richiede l’aggiornamento di una specifica tabella del database nel vostro ambiente live.
• Se riorganizzate tabelle di dati specifiche o risolvete problemi con le tabelle nell’ambiente di staging e volete inviare solo le nuove tabelle all’ambiente live.
• Se modificate i dati relativi agli utenti o i ruoli degli utenti nell’ambiente di staging e volete aggiornare solo le tabelle del database degli utenti nell’ambiente live.

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 su siti di membership e post su forum.

• Creazione di nuovi contenuti che includono media caricati (immagini, video o altri file caricati).
• Modifiche al vostro tema effettuate sia nel Customizer che nei file del tema.
• Installazione e test di un nuovo plugin o di una versione aggiornata di un plugin.

Eliminare e aggiornare l’ambiente di staging

Per rimuovere il vostro sito di staging, andate su Siti WordPress e selezionate l’ambiente di staging che volete rimuovere. Scorrete fino in fondo alla pagina e cliccate su 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 su 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.

Ripristinare un backup di WordPress in staging

Potete 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 rimangono intatti quando si ripristina un backup live in staging.

Riavviare l’ambiente di staging

In alcune situazioni, possiamo interrompere un ambiente di staging come parte di un processo di risoluzione dei problemi del server. Se vi accorgete che il vostro ambiente di staging è stato fermato e vedete un errore 501 non implementato, un errore 502 o un errore 521 quando visitate il vostro 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.

Rimuovere un ambiente di staging

Una volta terminati i test o lo sviluppo, potete rimuovere l’ambiente di staging. Se usate un add-on per l’ambiente di staging Premium, vi verrà addebitato solo il tempo in cui è stato attivo; eliminando l’ambiente di staging Premium, cancellate il componente aggiuntivo e interrompete la fatturazione aggiuntiva.

In MyKinsta, cliccate su Siti WordPress e selezionate l’ambiente che volete rimuovere.

Scorrete fino in fondo alla pagina e cliccate su Elimina ambiente.

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

Se state utilizzando un ambiente di staging Premium, una volta eliminato l’ambiente di staging, l’abbonamento all’add-on viene automaticamente rimosso da Azienda > Il mio piano in MyKinsta.

Note importanti

Quando usate 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 a scopi di sviluppo, debug e test, la cache a pagina intera e la OPcache di Kinsta sono disattivate per impostazione predefinita. Se esegui dei test di velocità del sito web, vedrai 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 all’interno dell’ambiente di staging, cliccate su Cache > Cache del server > Abilita. Quando la cache è abilitata su un sito di staging, viene attivata la funzione Svuota cache, che può essere utilizzata per cancellare la cache. Se disponete di un ambiente di staging Premium, potete anche abilitare la cache CDN e l’Edge 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 abbiate modificate dopo la creazione dell’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 usate plugin per la 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 qualcosa possa causare problemi al 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 usate 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 PHP worker, 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 elementi 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. Lavori cron

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 ed eseguite 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 sottositi 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: disattivate la mappatura dei domini e tornate alla configurazione standard di sottodirectory/sottodomini. Eseguite una ricerca e una sostituzione nel database manualmente.
  • Opzione 2: create dei sottodomini di staging per ogni dominio live, aggiungeteli tutti al sito di staging ed eseguite manualmente una ricerca e una sostituzione 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 dall’ambiente di staging, potete utilizzare un plugin come Disable Emails per impedire al sito di inviare email.

DOMANDE FREQUENTI

Cosa si intende per prorata?

Quando applichiamo una tariffa prorata a un servizio come l’add-on ambiente di staging Premium, significa che addebiteremo il costo in base al tempo di utilizzo del servizio per quel ciclo di fatturazione mensile.

Esempio di prorata

È necessario 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 staging Premium.

• 1 mese di ambiente di staging Premium costa 20 dollari.
• Basandosi 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 l’ambiente di staging Premium è stato aggiunto al vostro piano.

Esempio di prorata

Acquistate un ambiente di staging Premium a metà del vostro ciclo di fatturazione mensile e lo usate 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?

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 su Rinomina ambiente.

Questa operazione cambierà il nome dell’ambiente visualizzato nel selettore Ambiente, ma non influirà sul dominio kinsta.cloud generato durante la creazione dell’ambiente iniziale.

Si può 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 automaticamente un ambiente di staging quando si ripristinava un backup. Con l’introduzione degli ambienti di staging Premium, dovrete creare l’ambiente di staging prima di ripristinare un backup.

Potete anche effettuare il push delle modifiche dal vostro sito live al sito di staging e, se volete aggiornare solo alcuni file o tabelle del database, potete effettuare un push selettivo.

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 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.

Se si testa un plugin nell’ambiente di staging e poi si esegue il push dei soli 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.

Se si inviano solo i file al sito live, significa che il vecchio database (in staging) non sovrascriverà quello live, ma solo i file?

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

Ciò significa che è possibile lavorare sulle modifiche al design del 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 dashboard 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 alla versione live, selezionate File e assicuratevi che Database non sia selezionato.

È possibile escludere o sincronizzare gli ordini o i dati di WooCommerce quando si passa dallo staging alla versione live?

Sì, quando si passa dallo staging alla versione live con un push selettivo, è possibile eseguire il push dei soli file in modo da non sovrascrivere il database, oppure eseguire il push selettivo delle tabelle del database ed escludere le tabelle WooCommerce necessarie. Per informazioni su cosa è incluso in ogni tabella del database di WooCommerce, consultate la Descrizione del database di WooCommerce. Se non siete sicuri delle tabelle di cui eseguire il push, vi consigliamo di rivolgervi a uno sviluppatore.

È possibile eseguire il push di un solo sito dallo staging alla versione live se si ha un Multisito?

Sì, quando si esegue il push dello staging alla versione live con un push selettivo, è possibile scegliere di eseguire il push solo delle tabelle del database di uno dei sottositi. Per sapere quali tabelle del database sono incluse in WordPress, consultate Una guida per principianti al database WordPress: Cos’è e come accedervi. Nei file, le cartelle dei plugin e dei temi sono condivise da tutti i siti, ma la cartella degli uploads può essere separata per sito; pertanto, potete scegliere di inviare solo gli uploads per il sottosito richiesto. Se non siete sicuri delle tabelle o dei file di cui eseguire il push, vi consigliamo di collaborare con uno sviluppatore.

È possibile 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 nel vostro 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.

Dopo aver apportato modifiche ai CSS nella dashboard di WordPress ed aver eseguito il push dei file le modifiche non vengono visualizzate, anche dopo aver svuotato la cache. Perché?

A seconda del tipo di modifica apportata e di dove sono memorizzate le informazioni, potrebbe essere necessario eseguire 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 dashboard di WordPress, probabilmente questo verrà salvato nel database.

Se apportate delle modifiche a qualcosa nella dashboard 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.

Come funziona il push selettivo in una rete multisito?

Se usate il push selettivo per eseguire il push dei soli file, funzionerà bene, indipendentemente dal tipo di rete multisito. Se invece eseguite il push solo del database o del database e dei 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), il push to 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. Fate una ricerca e una sostituzione nel database manualmente.
  • Opzione 2: create dei sottodomini di staging per ogni dominio live, aggiungeteli tutti al sito di staging ed eseguite manualmente una ricerca e una sostituzione nel database per aggiornare ogni dominio dopo aver trasferito lo staging al sito live.