Usare uno Storage Server con WordPress: cosa funziona e cosa no

La directory wp-content/uploads è la parte di WordPress che cresce senza freni. Immagini, file PDF, video, e di ogni immagine diverse dimensioni che WordPress genera da sé. Dopo qualche anno lì ci sono decine di gigabyte, e lo spazio sul server web è il più costoso che si possa comprare.

Uno Storage Server costa una frazione di quel prezzo. La domanda è soltanto cosa si può davvero spostare. In rete si legge molto che nella pratica non funziona. Questo articolo separa i tre casi in modo pulito.

I tre casi in breve

L'ultimo punto è quello su cui inciampano i più. Perciò prima la verità scomoda.

Perché per la libreria media non esiste un plugin

I plugin di esternalizzazione più noti per WordPress parlano tutti la stessa lingua: S3. Si collegano ad Amazon S3 o a un servizio compatibile, caricano lì il file, cancellano la copia locale e sostituiscono l'indirizzo nell'articolo con un indirizzo pubblico del servizio.

Proprio questo non si può trasferire su uno Storage Server, e per due motivi:

• Lo storage parla SMB, SFTP e WebDAV, ma non S3.
• Non esiste un indirizzo pubblico per ogni file. Ogni accesso è autenticato, quindi non può esistere un link che il browser del visitatore richiama direttamente.

Esistono singoli plugin che lavorano con FTP, ma nessuno con una diffusione degna di nota e una manutenzione attuale che sposti completamente la libreria media via SFTP o WebDAV. Chi ne trova uno dovrebbe guardare, prima di usarlo, la data dell'ultimo aggiornamento e il numero di installazioni attive.

La strada che funziona: montare invece di spostare

Su un server proprio con permessi di root si ribalta la cosa. Invece di insegnare a WordPress a parlare con uno storage esterno, si porta lo storage nel punto in cui WordPress scrive comunque:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=LA_TUA_PASSWORD\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Voce in /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Poi trasferire i file esistenti e sostituire la directory:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

WordPress non si accorge di niente, per l'applicazione è un percorso del tutto normale. La vecchia directory resta come uploads.alt finché non hai verificato che tutto funziona. Cancellala solo allora, non prima.

La trappola in questo caso: le anteprime

WordPress genera di ogni immagine diverse dimensioni e le carica a ogni visita di pagina. Se questi file piccoli stanno sullo storage in rete, per ogni file si aggiunge la latenza di rete, e una galleria con quaranta immagini aspetta quaranta volte.

Due soluzioni, entrambe buone:

• Mettere davanti una cache, per esempio una cache nel server web che tiene in locale i file consegnati.
• Mettere sullo storage solo gli originali e lasciare in locale le dimensioni generate. È un po' più di lavoro, ma è la via più pulita per pagine con molte immagini.

Backup: il vantaggio più rapido

Se fai una sola cosa, fai questa. Un backup sullo stesso server non è un backup: se il disco viene cancellato o il sito viene cifrato, se ne va con esso. Su storage separato sopravvive.

Il plugin gratuito WPvivid può salvare sullo storage via SFTP già nella versione base, con pianificazione e regola di conservazione. La guida completa sta in Backup di WordPress sullo Storage Server.

Su un server proprio si fa ancora meglio, cioè con rsync o BorgBackup direttamente da un'attività pianificata. Così trasferisci solo le modifiche, e BorgBackup in più deduplica.

Consegnare download grandi

Per i file che i visitatori devono scaricare lo storage è ideale: si leggono raramente, sono grandi, e non devono essere veloci, devono solo arrivare. L'accesso passa da un piccolo script che prima verifica il permesso:

<?php
// nel file functions.php o come plugin a parte
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Accedi prima di continuare', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('File non trovato', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

L'esempio parte da uno storage montato. Senza montaggio sostituisci readfile() con una chiamata SFTP o WebDAV, come è descritto in Usare uno Storage Server per il tuo sito.

L'effetto collaterale è piacevole: dato che il file non ha mai un indirizzo pubblico, nessuno può passare il link a qualcun altro. La verifica dei permessi non si può aggirare.

Cosa resta su hosting condiviso

Su hosting condiviso WebDAV via HTTPS è la via più affidabile, perché la porta 443 non è praticamente mai bloccata. Anche SFTP funziona, da noi però gira sulla porta 23, e non tutti i provider permettono connessioni in uscita su porte di questo tipo. Conviene verificarlo brevemente prima di ordinare.

Un sotto-account per ogni scopo

Ogni Storage Server consente fino a 100 sotto-account, ognuno con directory iniziale propria, password propria e permessi di protocollo propri. Per WordPress significa almeno due:

• Un account per il sito, che vede solo /uploads.
• Un account per i backup, che vede solo /backup.

Se un giorno il sito viene compromesso, chi attacca trova nel file wp-config.php le credenziali del primo account. I backup restano intatti, perché quell'account non li conosce affatto. Con un unico account principale, a quel punto sarebbe andato via tutto.

Quando più utenti hanno bisogno di spazio proprio

Uno Storage Server non conosce nessuna quota per sotto-account. Un account resta nella sua directory, ma lì può riempire tutta la tariffa. Chi vuole dare a clienti, fotografi o redattori un contingente limitato a testa mette perciò davanti un'applicazione che se ne occupa. Nextcloud è la più immediata, porta con sé utenti, quote e link di condivisione: Collegare Nextcloud allo Storage Server.

Quale tariffa è quella giusta

Per un singolo sito WordPress con i backup, Storage-1 basta di regola per molto tempo. Chi sposta le librerie media di più siti o lavora con i video arriva in fretta a Storage-2 o Storage-3. Tutte le tariffe si trovano in Germania, non hanno costi di attivazione, vengono fatturate su base PrePaid e non hanno vincoli di durata. Il passaggio alla tariffa immediatamente superiore è possibile in qualsiasi momento, senza toccare i dati.