Ambienti di staging
Ogni installazione di WordPress su Kinsta può avere il proprio ambiente di 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 vs. 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 thread | Come nell’ambiente live | 2 |
| Limite di memoria PHP | Come nell’ambiente live | Come nell’ambiente live |
| Memoria PHP per thread | Come nell’ambiente live | Il numero massimo di thread in un ambiente di staging standard è 2 e la memoria per thread corrisponde a quella dell’ambiente live. Ad esempio, se l’ambiente live ha un pool di memoria di 2 GB con 4 thread PHP, ogni thread avrà un limite di memoria di 512 MB. Nell’ambiente di staging standard, ci sarebbero 2 thread PHP, ciascuno con un limite di memoria di 512 MB. Questo vale solo per i piani che hanno accesso all’add-on delle prestazioni di PHP. |
| 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 semplificato al massimo la creazione di un sito di staging WordPress. In MyKinsta, si fa clic su Siti WordPress nel menu di navigazione a sinistra. Verrà visualizzato un elenco dei siti/installazioni. Si seleziona il sito per cui si desidera creare un ambiente di staging, si fa clic sul tipo di ambiente, ad esempio Live, e si seleziona Crea nuovo ambiente. È anche possibile fare clic sulla casella Vai a o cerca e selezionare 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.
- Clonare un ambiente esistente: questa opzione permette di clonare un ambiente esistente (live o qualsiasi ambiente di staging Premium) nel nuovo ambiente di staging.
- Installare un nuovo WordPress: questa opzione installa un sito WordPress vuoto e completamente funzionante, pronto per essere utilizzato immediatamente.
- 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: clonare 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: installare 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’ installaziones u 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.
Opzione 3: 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 potrebbe richiedere alcuni minuti. Quando è pronto, all’interno del sito, si fa clic sul tipo di ambiente, ad esempio Live, e si seleziona l’ambiente di staging. È anche possibile fare clic sulla casella Vai a o cerca per selezionare 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.
Spostare l’ambiente in produzione
Quando sei pronto a trasferire il tuo ambiente di staging in produzione, segui i passaggi indicati in Trasferimento degli ambienti. Puoi anche trasferire qualsiasi ambiente di produzione o staging su qualsiasi altro sito.
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: clonare 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. Cancellare un add-on ambiente di staging Premium cancella l’add-on.
Se rimuovete l’add-on per l’ambiente di staging premium e siete nei primi 30 giorni del vostro piano di hosting WordPress, una tariffa prorata per l’add-on sarà aggiunta alla vostra prossima fattura per il periodo di tempo in cui è stato attivato. Se il vostro piano di hosting WordPress è attivo da più di 30 giorni, riceverete un credito prorata per il costo dell’add-on sul vostro saldo dell’account per i giorni rimanenti del periodo di fatturazione corrente. Il credito viene automaticamente utilizzato per compensare il dovuto a Kinsta della prossima fattura. Per ulteriori informazioni, date un’occhiata alla nostra Garanzia di rimborso per l’Hosting WordPress.
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 di 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 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 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 thread, 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. 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 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:
- Create un sito di staging.
- Andate sul sito di staging e cambiate la versione di PHP sul sito di staging.
- 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.