Chiunque gestisca un sito WordPress sa bene quella sensazione: stai per aggiornare un plugin, modificare un file functions.php o installare un nuovo tema, e per un secondo hai il dubbio. E se qualcosa va storto? Un sito down, una pagina bianca, un conflitto tra plugin che manda in tilt l’intera installazione. Lavorare direttamente in produzione è un rischio che, con gli strumenti giusti, non ha più ragione di esistere. Laragon permette di replicare in locale un sito WordPress già attivo, testare ogni modifica in un ambiente identico a quello reale, e tornare online solo quando si è sicuri al cento percento del risultato. Questa guida mostra come farlo passo dopo passo, partendo dal backup del sito di produzione fino all’ambiente locale funzionante, pronto per debug, aggiornamenti e sviluppo sicuro.

Laragon – Guida: Configurare WordPress

Prima di cominciare: cosa serve

Prima di mettere mano a qualsiasi file, è utile avere tutto pronto. Lato server di produzione, servirà accesso al pannello di controllo dell’hosting (cPanel, Plesk, o similari) oppure accesso FTP/SFTP e accesso al database via phpMyAdmin o riga di comando. Lato locale, Laragon deve essere già installato e funzionante – se non lo è ancora, la guida di riferimento è quella pubblicata in precedenza su questo sito. Servirà anche un client FTP come FileZilla per il trasferimento dei file, e opzionalmente un editor di testo come VS Code o Notepad++ per modificare i file di configurazione.

Step 1 – Backup del database di Produzione

Il punto di partenza è sempre il database. Tutto ciò che WordPress contiene – articoli, pagine, impostazioni, utenti, metadati – vive nel database, e portarlo in locale è il primo passo obbligatorio. Se già disponi di un plugin che si occupa automaticamente del backup del DB, puoi usare quello per ottenere la copia più fresca; solitamente esporta già in un formato compatibile (anche compresso). Altrimenti, accedi al pannello del tuo hosting e apri phpMyAdmin. In teoria è sufficiente un backup standard, ma controlla sempre attentamente le opzioni di esportazione. Se il database è molto grande e phpMyAdmin va in timeout, l’alternativa è usare il plugin WP All Export o, se hai accesso SSH, il comando da terminale: mysqldump -u nomeutente -p nomedeldb > backup.sql. In alternativa, plugin come UpdraftPlus o All-in-One WP Migration possono esportare database e file in un unico pacchetto.

Step 2 – Backup dei file di WordPress

Dopo il DB, passiamo ai file. La cartella da scaricare è la radice dell’installazione WordPress, tipicamente public_html o una sottocartella con il nome del dominio sul server. Connettiti via FTP o SFTP con FileZilla e scarica l’intera cartella in locale, ad esempio in C:\backup-sito\files\.

Step 3 – Creare il progetto in Laragon

Con i file di backup pronti, è il momento di configurare l’ambiente locale. Apri Laragon e verifica che la versione PHP selezionata corrisponda a quella usata sul server di produzione – una discrepanza di versione è la causa più comune di malfunzionamenti in locale. Per verificare la versione PHP del sito live, puoi creare temporaneamente un file phpinfo.php nella radice del sito con il contenuto <?php phpinfo(); ?> e aprirlo dal browser (ricordati di eliminarlo subito dopo). Per cambiare versione PHP in Laragon: tasto destro sull’icona nella system tray -> PHP -> seleziona la versione corrispondente.

Ora crea una nuova cartella nella directory C:\laragon\www\ con il nome che vuoi usare come dominio locale. Ad esempio, se il tuo sito si chiama miosito.it, puoi chiamare la cartella miosito – Laragon la renderà accessibile automaticamente come http://miosito.test. Copia tutti i file WordPress scaricati in questa cartella, rispettando la struttura originale.

Step 4 – Creare il database locale e importarlo

Apri il browser e vai su http://localhost/phpmyadmin (oppure clicca su Database nel menu di Laragon). Crea un nuovo database con lo stesso nome usato in produzione – puoi trovarlo nel file wp-config.php sotto la voce DB_NAME. La collation consigliata è utf8mb4_unicode_ci, che è lo standard attuale di WordPress. Seleziona il database appena creato, clicca su Importa, scegli il file .sql scaricato in precedenza e avvia l’importazione. Su database di grandi dimensioni, se phpMyAdmin mostra un errore di timeout, usa la riga di comando di Laragon: apri il terminale integrato (tasto destro system tray -> Terminal) e digita mysql -u root -p nomedeldb < C:\backup-sito\backup.sql. In generale, le credenziali di MySQL di Laragon sono “root” come username e password vuota.

Step 5 – Modificare wp-config.php

Questo è il passaggio più delicato. Il file wp-config.php contiene le credenziali di connessione al database e deve essere aggiornato per puntare all’ambiente locale anziché a quello di produzione. Aprilo con un editor di testo e modifica le seguenti voci:

php
define( 'DB_NAME', 'nomedeldb' );       // stesso nome del db locale creato
define( 'DB_USER', 'root' );            // utente di default in Laragon
define( 'DB_PASSWORD', '' );            // password vuota di default in Laragon
define( 'DB_HOST', 'localhost' );       // invariato

Se il file originale contiene righe che definiscono WP_HOME o WP_SITEURL, commentale o rimuovile per ora: queste verranno gestite direttamente nel database nel passaggio successivo. È buona pratica aggiungere anche queste due righe per disabilitare temporaneamente gli aggiornamenti automatici in locale e evitare interferenze:

php
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'DISALLOW_FILE_MODS', false );

Step 6 – Aggiornare gli URL nel database

Il database importato contiene ancora tutti i riferimenti all’URL del sito di produzione (es. http://miosito.it). Questi vanno sostituiti con l’URL locale (http://miosito.test), e la sostituzione deve essere fatta in modo intelligente – non con un semplice trova/sostituisci – perché WordPress serializza molti dati nel database e un replace manuale romperebbe la struttura.

Se vuoi fare una cosa veloce, puoi semplicemente aggiornare WP_HOME e WP_SITEURL con l’indirizzo locale (http://miosito.test): questi sono i riferimenti necessari per far funzionare Wodpress in locale, ma link messi manualmente o con reference assoluta punteranno all’istanza remota. Se vuoi allineare tutto, invece, il modo più sicuro e rapido è usare il tool Better Search Replace, disponibile come plugin WordPress gratuito. Installalo dall’interno di WordPress (che a questo punto dovrebbe già essere accessibile su http://miosito.test), apri Better Search Replace, inserisci nel campo “Search for” il vecchio URL (http://miosito.it) e nel campo “Replace with” il nuovo (http://miosito.test). Seleziona tutte le tabelle, attiva l’opzione Run as dry run per vedere un’anteprima senza applicare modifiche, verifica il risultato e poi riesegui senza dry run. Ricorda di controllare anche la versione http:// senza s, se il sito di produzione usava entrambe.

In alternativa, da phpMyAdmin è possibile aggiornare manualmente le due voci più critiche nella tabella wp_options: le righe con option_name uguale a siteurl e home. Questo metodo minimo funziona per i casi più semplici, ma su siti con page builder o plugin che memorizzano URL serializzati nel database (come Elementor, Divi o WooCommerce) è fortemente sconsigliato: Better Search Replace è la scelta più sicura.

Step 7 – Debug, Test e Workflow sicuro

A questo punto il sito dovrebbe essere accessibile e funzionante su http://miosito.test. Prima di iniziare qualsiasi modifica, è buona pratica attivare la modalità debug di WordPress per intercettare errori che in produzione potrebbero essere silenziosi. Aggiungi queste righe a wp-config.php:

php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con questa configurazione, gli errori vengono scritti nel file /wp-content/debug.log senza essere mostrati a schermo – utile per individuare warning PHP, conflitti tra plugin o chiamate a funzioni deprecate. Da qui in poi, l’ambiente locale è il posto giusto dove effettuare aggiornamenti di plugin e temi prima di applicarli in produzione, testare modifiche al codice di temi child o al file functions.php, verificare la compatibilità con una nuova versione di PHP prima di aggiornarla sul server live, riprodurre e diagnosticare errori che si manifestano solo in certi contesti, e sviluppare nuove funzionalità da zero senza toccare il sito reale.

Una volta verificato che tutto funziona correttamente in locale, il trasferimento delle modifiche verso la produzione avviene invertendo il processo: si esporta il database locale con phpMyAdmin, si esegue nuovamente un Better Search Replace per sostituire l’URL locale con quello di produzione, e si caricano i file modificati via FTP. Oppure, per un workflow più strutturato, si usa il controllo versione con Git per gestire le modifiche al codice e si sincronizza solo il database quando necessario.

Un ambiente affidabile per un sito sempre sicuro

Questo workflow può sembrare lungo alla prima esecuzione, ma diventa rapido e automatico dalla seconda volta in poi. Il beneficio reale è quello di eliminare il rischio operativo dalle operazioni di manutenzione: ogni modifica al sito viene testata in un ambiente identico alla produzione, con la garanzia che ciò che funziona in locale funzionerà anche online. Per chi gestisce siti di clienti o portali con traffico costante, questa è semplicemente la differenza tra lavorare con consapevolezza e lavorare sperando che vada bene.