Caricare i file sul server in automatico quando salvi

Il giro classico per modificare un sito che sta su un server FTP è sempre lo stesso: salvi, passi al programma FTP, cerchi il file, lo trascini dall’altra parte, torni all’editor, ricarichi il browser. Venti volte all’ora. Il caricamento automatico al salvataggio toglie la parte centrale: lavori su una copia locale, e ogni file che salvi viene mandato nello stesso punto sul server.

Non è la stessa cosa che modificare direttamente un file remoto, dove apri un singolo file dal server e lo riscrivi lì. Il caricamento automatico osserva un’intera cartella locale (il progetto che hai già aperto nell’editor) e porta fuori i tuoi salvataggi.

Come funziona, qualunque strumento usi

Tutte le soluzioni fanno le stesse tre cose:

1. Osservano una cartella locale. Su macOS passano da FSEvents, lo stesso servizio di notifica del file system che usano Spotlight e Time Machine: finché non salvi, non costa nulla.
2. La abbinano a una cartella remota. ~/Siti/cliente/wp-content/themes/acme/ in locale corrisponde a /public_html/wp-content/themes/acme/ sul server. Un file in css/main.css sotto la prima va in css/main.css sotto la seconda, e le cartelle mancanti vengono create strada facendo.
3. Caricano ciò che è cambiato. Solo i file che il sistema segnala come modificati, non il confronto dell’intero albero. Per questo sono rapide anche su un sito grande, e per questo non sostituiscono una sincronizzazione completa delle cartelle.

Gli strumenti differiscono nei dettagli, ed è lì che le cose possono andare storte.

Le trappole

I file temporanei. Molti editor salvano in modo «atomico»: scrivono index.php.sb-1234 o .index.php.swp e poi lo rinominano sopra l’originale. Un osservatore ingenuo carica il temporaneo, lascia spazzatura sul server o manda un file scritto a metà. Uno fatto bene aspetta un istante che il salvataggio si assesti e ignora i nomi temporanei noti.

Ciò che non deve mai salire. .git/, node_modules/, .DS_Store, il tuo .env locale. Ogni strumento ha bisogno di un elenco di esclusioni, e va controllato prima del primo salvataggio, non dopo.

Le cancellazioni. Se cancelli un file in locale, deve sparire anche dal server? Sembra logico, ma anche un git checkout su un altro ramo, o il salvataggio atomico di un editor, «cancellano» file per una frazione di secondo. Propagare le cancellazioni in automatico è il modo in cui sparisce un file in produzione. L’impostazione sicura è non cancellare mai sul server e fare pulizia a mano, o con una sincronizzazione di cui hai letto l’anteprima.

Lavorare in produzione. Ogni salvataggio va online. Un errore di sintassi in functions.php butta giù un sito WordPress nel momento in cui premi ⌘S. Il caricamento automatico è perfetto su un server di staging; in produzione tienilo per le modifiche piccole di cui sei sicuro.

Opzione 1: un’estensione dell’editor

Se vivi dentro un solo editor, la sua estensione è l’opzione più integrata.

• VS Code — la diffusa estensione «SFTP» legge un file .vscode/sftp.json con host, protocollo, percorso remoto e "uploadOnSave": true. Gestisce FTP e SFTP, e ignore accetta pattern glob.
• IDE JetBrains (PhpStorm, WebStorm) — in Tools ▸ Deployment ▸ Configuration si definiscono server e mappatura dei percorsi; l’opzione di caricamento automatico dei file modificati li manda poi a ogni salvataggio.
• Sublime Text e Nova hanno plug-in equivalenti o una pubblicazione integrata.

Il limite: la configurazione vive dentro ogni progetto e dentro ogni editor. Se cambi editor, o ritocchi un’immagine con Pixelmator, quei salvataggi non vanno da nessuna parte.

Opzione 2: uno script con fswatch

Per chi vuole fare da sé, fswatch (brew install fswatch) segnala i cambiamenti e lftp o rsync fanno il trasferimento:

# Manda via SFTP i file cambiati ogni volta che qualcosa cambia in ./sito
fswatch -o ./sito | while read _; do
  lftp -e "mirror -R --only-newer --exclude-glob .git/ ./sito /var/www/html; quit" sftp://deploy@example.com
done

Funziona con qualsiasi editor, e su un server SSH rsync è anche meglio. Però ogni modifica lancia il mirror dell’intero albero, le password finiscono negli script o richiedono configurazione in più, ed esclusioni ed errori sono a carico tuo.

Opzione 3: un client di trasferimento con caricamento automatico

Un client che ha già la connessione, le credenziali e una coda di trasferimento può occuparsi anche di osservare la cartella, indipendentemente dall’editor che usi.

In Upstream ti colleghi al sito, apri la cartella locale nel pannello di sinistra e quella remota corrispondente nel pannello di destra. Poi attivi Caricamento automatico al salvataggio dal menu Trasferimenti (⌃⌘U). Da quel momento:

• ogni file salvato in quella cartella locale entra nella normale coda di trasferimento: lo vedi salire, con velocità e nuovi tentativi, e finisce nello storico;
• i temporanei degli editor (Vim, Emacs, Office, i salvataggi atomici di TextEdit e Xcode, .DS_Store) vengono saltati, e così tutto ciò che corrisponde al tuo .syncignore: di default le cartelle nascoste come .git/ e node_modules/;
• le cartelle remote mancanti vengono create prima dei file;
• sul server non viene mai cancellato nulla;
• si spegne da solo quando ti scolleghi, così non manda mai file a un server che avevi dimenticato aperto.

Funziona allo stesso modo con FTP, FTPS, SFTP e bucket S3. Il caricamento automatico fa parte di Upstream FULL, con una prova gratuita di 7 giorni.

Passo per passo

1. Parti da una copia locale identica al server — scarica la cartella una volta, o parti dal repository del progetto. I due alberi devono avere la stessa struttura.
2. Escludi ciò che non deve mai salire — metti nella radice locale un .syncignore (o l’equivalente del tuo strumento) con .env, le cache di build e tutto ciò che è privato.
3. Punta i due lati sulla stessa cartella — la cartella del tema locale da una parte, quella remota dall’altra. Se non corrispondono, i file finiscono nel posto sbagliato.
4. Attiva il caricamento e salva un file — controlla che sia arrivato dove ti aspettavi prima di metterti al lavoro.
5. Ogni tanto fai una sincronizzazione completa — il caricamento automatico vede solo i salvataggi fatti mentre è acceso. I file cambiati da un git pull mentre era spento richiedono una sincronizzazione con anteprima.

Domande frequenti

Che differenza c’è tra caricamento automatico e sincronizzazione delle cartelle?

Il caricamento automatico manda solo i file che salvi, nel momento in cui li salvi, e non cancella mai nulla sul server. La sincronizzazione confronta su richiesta gli interi alberi locale e remoto, e può anche cancellare o scaricare. Usa il primo mentre lavori e la seconda per rimettere tutto in pari.

Il caricamento automatico funziona con SFTP e S3, o solo con FTP?

Dipende dallo strumento. Le estensioni degli editor di solito supportano FTP e SFTP; Upstream supporta FTP, FTPS, SFTP e bucket compatibili S3 con lo stesso interruttore.

Se cancello un file in locale, sparisce anche dal server?

Nella maggior parte degli strumenti solo se lo attivi, e di solito è meglio di no. Un cambio di ramo o il salvataggio atomico di un editor rimuovono file per un istante, e propagare quelle cancellazioni può cancellare file in produzione. Upstream non cancella mai sul server con il caricamento automatico.

Perché sul server è comparso un file .swp o .tmp?

L’osservatore ha caricato un temporaneo dell’editor prima che venisse rinominato. Aggiungi i pattern all’elenco delle esclusioni (*.swp, *.tmp, *~), oppure usa uno strumento che ignora i temporanei e aspetta che il salvataggio finisca.

È sicuro caricare in automatico su un sito in produzione?

Per CSS, template e contenuti di solito sì. Per i file PHP o di configurazione, un refuso diventa un errore online nel momento in cui salvi. Quando puoi, lavora su una copia di staging e tieni aggiornati i backup del server.