Staging: testare le modifiche prima di pubblicarle sul sito live

Aggiornare un plugin, cambiare tema o installare una nuova funzione direttamente sul sito che i visitatori vedono ogni giorno è un rischio che non serve correre. Basta un conflitto tra due plugin, o una versione di PHP non compatibile, per trasformare un aggiornamento di routine in un sito rotto davanti a tutti.

1. Cos'è un ambiente di staging

Un ambiente di staging è una copia del sito, separata da quella pubblica, dove puoi installare, modificare e rompere qualsiasi cosa senza che nessun visitatore se ne accorga. WordPress riconosce ufficialmente questo concetto attraverso la costante WP_ENVIRONMENT_TYPE, che puoi definire in wp-config.php con i valori local, development, staging oppure production. Se non la imposti, WordPress considera il sito in produzione per impostazione predefinita.

// wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

// in un plugin o nel functions.php del tema
if ( 'staging' === wp_get_environment_type() ) {
    // qui puoi disattivare l'invio reale di email,
    // le integrazioni di pagamento o le notifiche push
}

Fonte: Developer.WordPress.org, Common APIs Handbook (wp-config.php) e riferimento della funzione wp_get_environment_type().

2. La regola che rende utile lo staging: la parità con il sito reale

Un ambiente di staging serve solo se riproduce fedelmente quello reale. Se lo staging gira su una versione di PHP diversa, con plugin mancanti o con un contenuto ridotto rispetto al sito pubblico, i test che ci fai sopra non sono affidabili: un problema può non manifestarsi in staging e comparire solo dopo la pubblicazione, oppure il contrario.

• Stessa versione di PHP: è il primo controllo consigliato prima di alzare la versione di PHP in produzione: verificare la compatibilità in un ambiente non pubblico.
• Stessi plugin e stesso tema: attivi e aggiornati alla stessa versione, altrimenti un conflitto reale può restare invisibile.
• Volume di contenuti realistico: uno staging con tre articoli di prova non mette alla prova le query, le cache o i tempi di caricamento come farebbe un database vero.

3. Quando lo staging non è un optional

Non serve per ogni piccola modifica, ma diventa quasi obbligatorio in alcune situazioni precise.

• Prima di un aggiornamento importante del core: un salto di versione maggiore di WordPress può cambiare comportamenti su cui temi o plugin datati facevano affidamento.
• Prima di aggiornare la versione di PHP: è il caso più citato nella documentazione ufficiale: testare la compatibilità in un ambiente non di produzione prima del passaggio definitivo.
• Prima di modifiche dirette al codice: interventi manuali su wp-config.php, su un file del tema o su regole del server vanno sempre verificati fuori dal sito pubblico.
• Con page builder o plugin che estendono l'amministrazione: sono tra i più sensibili ai conflitti dopo un aggiornamento, ed è utile verificarne la tenuta prima che lo veda un cliente.

4. Come si crea, in pratica

Le strade più comuni sono due. Molti hosting gestiti includono uno strumento di staging con un clic, che duplica automaticamente file e database su un sottodominio protetto da password. In alternativa, si può clonare manualmente il sito su un sottodominio o una sottocartella dedicata, copiando database e file wp-content, e impostando la costante WP_ENVIRONMENT_TYPE su staging nel nuovo wp-config.php. In entrambi i casi lo staging non deve essere raggiungibile dai motori di ricerca: protezione tramite password e opzione «Scoraggia i motori di ricerca dall'indicizzare questo sito», in Impostazioni, Lettura, sono la base minima.

In sintesi

Uno staging non elimina il rischio, lo sposta dove nessun visitatore può vederlo.