Ambienti di staging

Ogni installazione WordPress su Kinsta può disporre di un proprio ambiente di staging WordPress gratuito, completamente separato dal sito di produzione live. Ciò è particolarmente utile per testare nuove versioni di WordPress, plugin, codice e lo sviluppo generale. È possibile creare un sito di sviluppo in pochi minuti e condividerlo con il proprio team.

Se desideri aggiungere ulteriori ambienti di staging, hai bisogno di un ambiente di staging che corrisponda più da vicino al tuo ambiente live o devi eseguire test o sviluppi del sito che richiedono molte risorse, dai un’occhiata al nostro add-on per ambienti di staging Premium.

Staging Standard vs. Premium

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

Scopri 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, clicca su Siti nella barra di navigazione a sinistra. Vedrai un elenco dei tuoi siti/installazioni. Seleziona il sito per cui desideri creare un ambiente di staging, clicca sul tipo di ambiente, ad esempio Live, e seleziona Crea nuovo ambiente. Puoi anche cliccare sulla casella Vai a o cerca e selezionare Crea nuovo ambiente.

Nel pop-up/modale Crea nuovo ambiente che appare, seleziona Ambiente standard o Ambiente premium e fai clic su Continua.

Successivamente, ti verrà richiesto di selezionare il tipo di ambiente che desideri creare. Sono disponibili tre opzioni.

1. Clona un ambiente esistente: questa opzione consente di clonare un ambiente esistente (live o qualsiasi ambiente di staging Premium) nel nuovo ambiente di staging.
2. Installa nuovo WordPress: questa opzione installa un sito WordPress vuoto completamente funzionante, pronto per essere utilizzato immediatamente.
3. Ambiente vuoto (senza WordPress): questa opzione installa tutto il software necessario per eseguire un sito WordPress (server web, PHP, MySQL, ecc.), ma non installa WordPress stesso. Questa è una buona opzione per gli utenti che desiderano migrare a Kinsta con Duplicator o configurare un’installazione Bedrock/Trellis con una struttura di file personalizzata.

Opzione uno: clonare un ambiente esistente

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

• Nome dell’ambiente: inserisci un nome per l’ambiente di staging; deve essere composto da 3 a 12 caratteri.
• Ambiente da clonare: seleziona un ambiente esistente da clonare nel nuovo ambiente di staging.

Opzione due: installare un nuovo WordPress

L’opzione Installa nuovo WordPress include diversi campi per personalizzare il sito. Ecco cosa è necessario sapere su ciascun campo.

• Nome dell’ambiente: inserisci un nome per l’ambiente di staging; deve essere composto da 3 a 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 punti. È possibile modificare il titolo del sito nelle impostazioni di WordPress dopo la creazione del sito.
• Nome utente amministratore WordPress: lo utilizzerai per accedere all’installazione WordPress. Potrai aggiungere altri utenti in un secondo momento. Consigliamo di scegliere un nome utente diverso da “admin” per garantire la massima sicurezza.
• Password amministratore WordPress:utilizzerai questa password per accedere alla tua installazione. Imponiamo automaticamente password complesse per proteggere gli utenti. Puoi utilizzare l’opzione genera nuova password (icona di ricarica) se desideri una nuova password. Ecco come puoi modificare la tua password WordPress in un secondo momento.
• Email amministratore WordPress: WordPress utilizza l’indirizzo email dell’amministratore per inviare notifiche importanti.
• Seleziona una lingua: Seleziona la lingua che desideri utilizzare in WordPress. Non è necessario scrivere i contenuti nella stessa lingua dell’interfaccia di WordPress, quindi sentiti libero di scegliere la tua lingua madre, anche se scrivi contenuti in inglese.
• Installa WordPress multisito: seleziona questa casella se desideri creare un’installazione WordPress Multisite. Una volta selezionata, puoi scegliere tra un’installazione sottodominio o sottodirectory.
• Installa WooCommerce: Se stai creando un sito web di e-commerce, WooCommerce è il plugin di e-commerce più popolare disponibile. Seleziona 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. Seleziona questa casella per installarlo automaticamente.
• Installa Easy Digital Downloads: se stai creando un sito per vendere prodotti digitali, Easy Digital Downloads è una soluzione e-commerce completa per la vendita di prodotti digitali. Seleziona questa casella per installarlo automaticamente.

Opzione tre – Ambiente vuoto (senza WordPress)

L’opzione Ambiente vuoto è utile per gli utenti che necessitano di un ambiente vuoto per una migrazione con Duplicator o per testare l’installazione personalizzata di Bedrock/Trellis.

• Nome dell’ambiente: inserisci un nome per l’ambiente di staging; deve essere composto da 3 a 12 caratteri.

Creazione dell’ambiente di staging

Quando è tutto pronto, fai clic su Continua. Se stai creando un ambiente di staging Premium, conferma l’abbonamento ricorrente e fai clic su Crea ambiente Premium.

Accesso all’ambiente di staging

La creazione del nuovo ambiente potrebbe richiedere alcuni minuti. Una volta pronto, all’interno del sito, fai clic sul tipo di ambiente, ad esempio Live, e seleziona l’ambiente di staging. Puoi possibile fare clic sulla casella Vai a o cerca per selezionare l’ambiente.

È inoltre possibile accedere all’ambiente di staging dall’elenco Siti.

Ogni ambiente è contrassegnato da un cerchio colorato accanto al nome: verde per Live, nero per Staging standard e arancione per Staging premium. Avrai quindi a disposizione un pannello di controllo separato con informazioni sulla connessione, DNS, backup, strumenti e plugin per il tuo ambiente di staging.

Per visitare rapidamente il tuo sito di staging, vai alla scheda Domini nel tuo ambiente di staging e clicca sul link Apri URL. Puoi anche accedere rapidamente all’amministrazione WordPress del tuo sito di staging cliccando sul link Apri WP Admin.

Struttura dell’URL e dominio

La struttura predefinita dell’URL del tuo ambiente di staging segue questo formato:

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

Se si dispone di un sito di staging più vecchio, l’URL potrebbe essere simile a uno di questi:

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

È anche possibile aggiungere un dominio personalizzato al sito di staging, se preferisci utilizzare un dominio personalizzato.

Note aggiuntive

Se hai abilitato l’SSL sul tuo sito live e cloni il sito su staging, il certificato SSL sarà abilitato anche sul tuo sito di staging.

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

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

Aggiornare l’ambiente di staging

Se apporti modifiche al sito live dopo aver creato l’ambiente di staging e desideri far riflettere tali modifiche nello staging, è possibile utilizzare un push selettivo per aggiornare l’ambiente di staging. In questo modo, non sarà necessario eliminare e ricreare l’ambiente di staging, risparmiando tempo e conservando eventuali backup di staging.

Push dell’ambiente su live

Quando è il momento di trasferire l’ambiente di staging in produzione, segui i passaggi indicati in Trasferimento degli ambienti. È anche possibile trasferire qualsiasi ambiente di produzione o staging su qualsiasi altro sito.

Eliminare e aggiornare l’ambiente di staging

Se è necessario rimuovere il sito di staging, accedi a Siti e seleziona l’ambiente di staging che desideri rimuovere. Scorri fino alla fine della pagina e fai clic su Elimina ambiente.

Nella finestra modale/pop-up che appare, confermare di aver compreso cosa verrà eliminato, digitare il nome del sito seguito da un trattino e dalla parola “staging” (NOME DEL SITO-nome dell’ambiente) nel campo fornito, quindi fare clic su Elimina ambiente.

Per aggiornare l’ambiente di staging, eliminalo, creane uno nuovo e seleziona l’Opzione 1 – Clonare un ambiente esistente. Questo ambiente di staging appena clonato conterrà la versione più recente del database di produzione e dei file per il test.

In alternativa, è possibile ripristinare un backup dal sito di produzione allo staging. Il vantaggio di questo metodo è che, se è stato aggiunto un dominio personalizzato, questo non verrà eliminato e non sarà necessario aggiungerlo ogni volta che si aggiorna lo staging.

Ripristinare un backup di WordPress allo staging

È possibile ripristinare il proprio sito WordPress da un backup direttamente all’ambiente di staging esistente. Scopri come ripristinare un backup WordPress su staging. Nota: tutti i backup di staging rimarranno intatti quando si ripristina un backup live su staging.

Riavviare l’ambiente di staging

In determinate situazioni, potremmo arrestare un ambiente di staging come parte di un processo di risoluzione dei problemi del server. Se noti che l’ambiente di staging è stato arrestato e viene visualizzato un 501 not implemented , un errore 502 o un errore 521 quando visiti il sito, puoi riavviare l’ambiente di staging in MyKinsta andando alla pagina Info del tuo sito e cliccando su Avvia ambiente di staging.

Se non riesci a riavviare il tuo ambiente di staging o non vedi il pulsante in MyKinsta, ti invitiamo ad aprire una nuova chat con il nostro team di assistenza per ulteriore supporto.

Rimuovere un ambiente di staging

Una volta terminati i test o lo sviluppo, puoi rimuovere l’ambiente di staging. L’eliminazione di un add-on per ambienti di staging Premium comporta la cancellazione dell’add-on.

Se rimuovi l’add-on ambiente di staging premium e sei nei primi 30 giorni del tuo piano di hosting WordPress, alla tua prossima fattura verrà aggiunto un costo pro-rata per l’add-on per il periodo di tempo in cui è stato abilitato. Se il tuo piano di hosting WordPress è attivo da più di 30 giorni, riceverai un credito pro-rata per i costi dell’add-on sul saldo del tuo account per i giorni rimanenti del periodo di fatturazione corrente. Il credito verrà automaticamente utilizzato per compensare l’importo dovuto a Kinsta sulla tua prossima fattura. Per ulteriori informazioni, consulta la nostra Garanzia di rimborso per l’hosting WordPress.

In MyKinsta, clicca su Siti e seleziona l’ambiente che desideri rimuovere.

Scorri fino alla fine della pagina e clicca su Elimina ambiente.

Nella finestra modale/pop-up che appare, conferma di aver compreso cosa verrà eliminato, inserisci il nome del sito seguito da un trattino e il nome dell’ambiente (NOME SITO-Nome Ambiente) nel campo fornito, quindi fai clic su Elimina ambiente.

Se utilizzi un ambiente di staging Premium, una volta eliminato l’ambiente di staging, l’abbonamento all’add-on verrà automaticamente rimosso da Impostazioni azienda > Il mio piano in MyKinsta.

Note importanti

Quando si utilizza l’ambiente di staging, è necessario tenere presente diversi aspetti importanti.

1. Impostazioni della cache delle pagine per i siti di staging

Poiché gli ambienti di staging sono destinati allo sviluppo, debug e test, la cache a pagina intera e OPcache di Kinsta sono disabilitati di default. Se si eseguono test di velocità del sito web, si noteranno tempi di caricamento superiori alla media poiché le pagine non vengono servite dalla cache. Se desideri abilitare la cache su un sito di staging all’interno dell’ambiente di staging, fai clic su Cache > Cache del server > Abilita. Quando il caching è abilitato su un sito di staging, l’opzione Svuota cache sarà abilitata e potrà essere utilizzata per svuotare la cache. Se si dispone di un ambiente di staging Premium, è possibile abilitare anche la cache CDN e edge caching.

2. Credenziali dell’ambiente di staging

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

3. SEO

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

È possibile visualizzare l’impostazione di WordPress andando su Impostazioni > Lettura nella dashboard di WordPress del sito di staging. L’opzione per scoraggiare i motori di ricerca dall’indicizzare il sito è selezionata accanto a Visibilità motori di ricerca.

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

4. Plugin

Se si utilizzano plugin di pianificazione social come CoSchedule o Social Networks Auto Poster, si consiglia di disattivarli sul sito di staging. In caso contrario, potrebbero iniziare a condividere sui social network utilizzando l’URL di staging, che avrà un aspetto simile a: https://stg-sitename-environmentname.kinsta.cloud. Ciò potrebbe alterare le statistiche.

Alcuni plugin, come il plugin Jetpack, verranno eseguiti automaticamente in modalità staging sugli ambienti di staging di Kinsta. Verrà visualizzato il messaggio: ”Stai utilizzando Jetpack su un server di staging”. In modalità staging, il tuo sito di staging funzionerà in modo praticamente identico al tuo sito di produzione, tranne per il fatto che nessun dato verrà trasmesso a WordPress.com e non potrai disconnettere il sito di staging (per evitare problemi che potrebbero causare difficoltà al tuo sito di produzione).

I plugin con licenza per nome di dominio potrebbero richiedere un dominio personalizzato (anziché un sottodominio di staging Kinsta) per funzionare correttamente. Nota: una volta aggiunto un nome di dominio personalizzato al tuo sito di staging, potrebbe essere necessario aggiornare le impostazioni in cui gestisci la licenza del plugin o contattare il team di supporto del plugin.

5. Prendere nota dell’URL di accesso

Se cloni il tuo sito su staging e utilizzi un plugin WordPress che modifica il tuo 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 dovrebbe essere utilizzato solo per lo sviluppo/test

L’ambiente di staging Standard dispone solo di 2 thread PHP, non offre la possibilità di abilitare il CDN di Kinsta e potrebbe andare in standby dopo 24 ore di inattività. Di conseguenza, dovrebbe essere utilizzato esclusivamente per lo sviluppo e il 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 tenta di utilizzare un ambiente di staging per un sito live.

7. Spazio su disco escluso dal totale del piano

Per offrire il maggior spazio possibile, i siti di staging sono esclusi dai nostri rapporti quando si calcola l’utilizzo totale dello spazio su disco. Solo i siti live vengono conteggiati ai fini dell’utilizzo dello spazio su disco.

8. Utilizzo della larghezza di banda CDN incluso nel piano

L’utilizzo della larghezza di banda CDN dagli ambienti Premium Staging è incluso nel calcolo della larghezza di banda CDN totale.

9. Cron job

I cron job del server dall’ambiente live non sono attivi nell’ambiente di staging (anche se si clona il sito live nello staging) , pertanto i cron job del sito live non verranno eseguiti nell’ambiente di staging. Inoltre, se si modifica il crontab nell’ambiente di staging e si trasferisce lo staging all’ambiente live, il crontab dell’ambiente live verrà sovrascritto.

10. Multisito

Se si utilizza una rete multisito WordPress, potrebbe non funzionare con il nostro ambiente di staging, a seconda di come è configurato il multisito.

• Se si tratta di un multisito con sottodirectory (esempio.com, esempio.com/sottosito1, esempio.com/sottosito2) o di un multisito con sottodominio (esempio.com, sottosito1.esempio.com, sottosito2.esempio.com), funzionerà correttamente con il nostro ambiente di staging. Tutti i sottodomini sono coperti dal certificato SSL gratuito di Kinsta.
• 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 configurazione manuale significativa.
  • Opzione 1: disattivare la mappatura del dominio e tornare alla configurazione standard della sottodirectory/sottodominio. Eseguire manualmente una ricerca e sostituzione nel database.
  • Opzione 2: configurare sottodomini di staging per ogni dominio live, aggiungerli tutti al sito di staging ed eseguire manualmente una ricerca e sostituzione nel database.

11. E-mail

Gli ambienti di staging hanno l’invio di e-mail (e-mail transazionali) abilitato di default. Se effettui un ordine sul sito di staging, riceverai le relative e-mail dal sito di staging. Se non desideri che le email transazionali vengano inviate dall’ambiente di staging, puoi utilizzare un plugin come Disable Emails per impedire al sito di inviare email.

Domande frequenti

Che cos’è il calcolo pro-rata?

Quando ripartiamo proporzionalmente un servizio come l’add-on Premium per l’ambiente di staging, ti verrà addebitato un costo in base al tempo di utilizzo del servizio per quel ciclo di fatturazione mensile.

Esempio di prorata

Hai una nuova funzionalità da implementare sul tuo sito e desideri testarla sfruttando appieno il tuo piano. Crei un ambiente di staging Premium, aggiungi la nuova funzionalità e la testi per 1 ora. Tutto sembra funzionare correttamente, quindi trasferisci la modifica al tuo ambiente live ed elimini l’ambiente di staging Premium.

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

Esempio di ripartizione pro-rata

Acquisti un ambiente di staging Premium a metà del tuo ciclo di fatturazione mensile e lo utilizzi fino alla fine di tale ciclo. Ti verrà addebitato un mese e mezzo di utilizzo (circa 10 $, ripartiti proporzionalmente al secondo).

È possibile modificare il nome di un ambiente di staging?

Sì. Passa all’ambiente che desideri rinominare e, nella pagina Info, fai clic sull’icona di modifica (matita) nel campo Nome ambiente.

Inserisci il nuovo nome e fai clic su Rinomina ambiente.

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

È possibile ripristinare un backup in un ambiente di staging?

Sì, ma è necessario creare prima un ambiente di staging Standard o Premium. In passato era possibile creare automaticamente un ambiente di staging durante il ripristino di un backup. Con l’introduzione degli ambienti di staging Premium, è necessario creare l’ambiente di staging prima di ripristinare un backup.

È anche possibile trasferire le modifiche dal sito live al sito di staging e, se si desidera aggiornare solo determinati file o tabelle del database, è possibile eseguire un trasferimento selettivo.

Chi ha accesso agli ambienti di staging Premium?

Gli sviluppatori sito e gli amministratori 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 azienda o l’amministratore azienda possono creare o eliminare un ambiente di staging Premium.

Lo staging occupa spazio sul mio disco?

No. Per offrirti il maggior spazio possibile, i siti di staging sono esclusi dai nostri rapporti quando calcoliamo l’utilizzo totale dello spazio su disco. Solo i siti live vengono conteggiati ai fini del limite di spazio su disco.

Se provo un plugin nell’ambiente di staging e trasferisco solo i file al sito live, verranno create le tabelle di database corrispondenti per il plugin?

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

Ciò significa anche che qualsiasi impostazione configurata nel plugin non verrà trasferita al live (a meno che le impostazioni non siano salvate in un file esterno al database, come ad esempio un file JSON).

A seconda di come è codificato il plugin, abilitarlo (disabilitando prima se necessario) sul sito live potrebbe creare la struttura del database.

Se trasferisco solo i file sul sito live, questo significa che il vecchio database (in staging) non sovrascriverà quello live e solo i file verranno sovrascritti?

Sì, quando si trasferiscono solo i file, ciò significa che il database sul sito live rimane invariato e solo i file sul sito live verranno sovrascritti.

Questo significa che posso lavorare sulle modifiche di progettazione sul mio sito di staging e trasferirle sul sito live senza perdere nuovi abbonati o clienti sul mio sito live?

Sì, purché le modifiche siano apportate solo ai file (senza modifiche nella dashboard di WordPress, incluse le impostazioni dei plugin, dei temi o del personalizzatore), è possibile trasferirle in modo sicuro sul sito live senza trasferire il database. Quando si trasferiscono le modifiche sul sito live, selezionare File e assicurarsi che Database non sia selezionato.

È possibile escludere o sincronizzare gli ordini o i dati WooCommerce quando si trasferiscono dallo staging al live?

Sì, quando trasferisci lo staging al live con un trasferimento selettivo, puoi trasferire solo i file in modo che il database non venga sovrascritto, oppure puoi trasferire in modo selettivo le tabelle del database ed escludere le tabelle WooCommerce richieste. Per informazioni su cosa è incluso in ciascuna tabella del database WooCommerce, fare riferimento alla Descrizione del database WooCommerce. Se non sai quali tabelle trasferire, ti consigliamo di collaborare con uno sviluppatore.

È possibile trasferire solo un sito dallo staging al live se si dispone di un multisito?

Sì, quando si trasferisce lo staging al live con un trasferimento selettivo, è possibile scegliere di trasferire solo le tabelle del database per uno dei siti secondari. Per scoprire quali tabelle del database sono incluse in WordPress, consulta la Guida introduttiva al database di WordPress: cos’è e come accedervi. Nei file, le cartelle dei plugin e dei temi sono condivise tra tutti i siti, ma la cartella degli upload può essere separata per sito; pertanto, puoi scegliere di trasferire solo gli upload per il sottosito richiesto. Se non sai quali tabelle o file caricare, ti consigliamo di rivolgerti a uno sviluppatore.

È possibile utilizzare il trasferimento selettivo per modificare la versione PHP del proprio sito?

Sì, è possibile utilizzare lo staging per testare e inviare una nuova versione PHP al proprio ambiente live, ma non è strettamente necessario eseguire un trasferimento dallo staging al live per aggiornare la versione PHP. Ecco una breve panoramica di come modificare la versione PHP senza eseguire il push dallo staging al live:

1. Crea un sito di staging.
2. Accedi al sito di staging e modifica la versione PHP sul sito di staging.
3. Se tutto è corretto e funziona come previsto sul sito di staging (assicurati di testare accuratamente il sito), cambia la versione PHP sul sito live.

Ho apportato modifiche CSS nella dashboard di WordPress e ho inviato i file. Perché non vedo le mie modifiche, anche dopo aver svuotato tutta la cache?

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

Se si apportano modifiche a qualcosa nella dashboard di WordPress, ad eccezione delle modifiche apportate con l’Editor dei temi (Aspetto > Editor dei temi), tali informazioni vengono solitamente memorizzate nel database.

Nota: qualsiasi modifica al database del sito live effettuata dopo la creazione del sito di staging andrà persa, inclusi, a titolo esemplificativo ma non esaustivo: commenti, nuovi contenuti, acquisti su siti di e-commerce, iscrizioni a siti di appartenenza e post nei forum. In questo caso, si consiglia di apportare manualmente le stesse modifiche al sito live piuttosto che eseguire il push del database.

Come funziona il push selettivo con una rete multisito?

Se si utilizza il push selettivo per trasferire solo i file, funzionerà correttamente, indipendentemente dal tipo di rete multisito. Se si trasferisce solo il database o il database e i file, potrebbe funzionare o meno, a seconda di come è configurato il multisito:

• Se si tratta di un multisito con sottodirectory (esempio.com, esempio.com/sottosito1, esempio.com/sottosito2), il push live funzionerà come previsto.
• Se si tratta di un multisito con sottodomini (esempio.com, sottosito1.esempio.com, sottosito2.esempio.com), funzionerà correttamente, a condizione che i sottositi non richiedano HTTPS.
• Se si tratta di un multisito con mappatura di dominio (carica siti secondari diversi su domini completamente diversi, ad esempio example.com, example1.com, example2.com), non funzionerà senza una configurazione manuale significativa.
  • Opzione 1: disattiva la mappatura del dominio e torna alla configurazione standard della sottodirectory/sottodominio. Esegui manualmente una ricerca e sostituzione nel database.
  • Opzione 2: configura sottodomini di staging per ciascun dominio live, aggiungili tutti al sito di staging ed esegui manualmente una ricerca e sostituzione nel database per aggiornare ciascun dominio dopo aver trasferito lo staging al live.