Storage Server cu WordPress: ce funcționează și ce nu

Directorul wp-content/uploads este partea din WordPress care crește fără frână. Imagini, fișiere PDF, videoclipuri, iar de la fiecare imagine mai multe dimensiuni, pe care WordPress le creează automat. După câțiva ani se adună acolo zeci de gigabytes, iar spațiul de pe serverul web este cel mai scump pe care îl poți cumpăra.

Un Storage Server costă o fracțiune din asta. Întrebarea este doar ce se poate muta cu adevărat. Pe net se scriu despre asta multe lucruri care în practică nu funcționează. Articolul separă curat cele trei cazuri.

Cele trei cazuri pe scurt

Ultimul punct este cel de care se împiedică cei mai mulți. De aceea, mai întâi adevărul neplăcut.

De ce nu există un plugin pentru biblioteca media

Pluginurile cunoscute de mutare pentru WordPress vorbesc toate aceeași limbă: S3. Se conectează la Amazon S3 sau la un serviciu compatibil, încarcă fișierul acolo, șterg copia locală și înlocuiesc adresa din articol cu o adresă publică a serviciului.

Exact asta nu se poate transpune pe un Storage Server, și anume din două motive:

• Storage-ul vorbește SMB, SFTP și WebDAV, dar nu S3.
• Nu există o adresă publică pentru fiecare fișier. Fiecare acces este autentificat, deci nu poate exista un link pe care browserul vizitatorului să îl deschidă direct.

Există pluginuri izolate care lucrează cu FTP, dar niciunul cu răspândire demnă de menționat și cu întreținere actuală, care să mute complet biblioteca media prin SFTP sau WebDAV. Cine găsește unul ar trebui să se uite, înainte de a-l folosi, la data ultimei actualizări și la numărul de instalări active.

Calea care funcționează: montare în loc de mutare

Pe un server propriu, cu drepturi de root, se întoarce toată treaba. În loc să înveți WordPress să vorbească cu spațiu de stocare străin, aduci storage-ul acolo unde WordPress scrie oricum:

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

Intrarea în /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

Apoi mută fișierele existente și înlocuiește directorul:

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 nu observă nimic, pentru aplicație este o cale absolut normală. Directorul vechi rămâne pe loc ca uploads.alt până ai verificat că totul funcționează. Abia atunci îl ștergi, nu înainte.

Capcana din drum: miniaturile

WordPress creează de la fiecare imagine mai multe dimensiuni și le încarcă la fiecare afișare de pagină. Dacă aceste fișiere mici stau pe spațiul de stocare din rețea, se adaugă latența de rețea pentru fiecare fișier, iar o galerie cu patruzeci de imagini așteaptă patruzeci de ori.

Două soluții, ambele bune:

• Pui un cache în față, de exemplu un cache în serverul web, care ține local fișierele livrate.
• Pui doar originalele pe storage și lași local dimensiunile create. Este un pic mai multă muncă, dar este calea cea mai curată pentru pagini cu multe imagini.

Backupuri: folosul cel mai rapid

Dacă faci un singur lucru, atunci pe acesta. Un backup pe același server nu este un backup: dacă discul este șters sau site-ul criptat, dispare împreună cu el. Pe un storage separat supraviețuiește.

Pluginul gratuit WPvivid poate salva pe storage prin SFTP chiar în versiunea de bază, cu programare și regulă de păstrare. Ghidul complet pentru asta stă în Backupuri WordPress pe Storage Server.

Pe un server propriu merge și mai bine, și anume cu rsync sau BorgBackup direct dintr-o sarcină programată. Atunci transferi doar modificările, iar BorgBackup deduplică în plus.

Livrarea descărcărilor mari

Pentru fișiere pe care vizitatorii trebuie să le descarce, storage-ul este ideal: se citesc rar, sunt mari și nu trebuie să fie rapide, trebuie doar să ajungă. Accesul trece printr-un script mic, care verifică înainte dreptul de acces:

<?php
// în functions.php sau ca plugin propriu
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Te rugăm să te autentifici', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Fișierul nu a fost găsit', '', ['response' => 404]);
    }

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

Exemplul pornește de la un storage montat. Fără montare, înlocuiești readfile() cu un apel SFTP sau WebDAV, așa cum este descris în Storage Server pentru site-ul propriu.

Efectul secundar este plăcut: pentru că fișierul nu are niciodată o adresă publică, nimeni nu poate da linkul mai departe. Verificarea dreptului de acces nu se poate ocoli.

Ce rămâne pe hosting partajat

Pe hosting partajat, WebDAV prin HTTPS este calea cea mai de încredere, pentru că portul 443 nu este practic niciodată blocat. SFTP funcționează de asemenea, dar la noi rulează pe portul 23, și nu orice furnizor permite conexiuni de ieșire pe astfel de porturi. Asta ar trebui verificat scurt înainte de comandă.

Un subcont pentru fiecare scop

Fiecare Storage Server permite până la 100 de subconturi, fiecare cu director de start propriu, parolă proprie și permisiuni de protocol proprii. Pentru WordPress asta înseamnă cel puțin două:

• Un cont pentru site, care vede doar /uploads.
• Un cont pentru backupuri, care vede doar /backup.

Dacă site-ul ajunge să fie compromis, atacatorul găsește în wp-config.php datele de acces ale primului cont. Backupurile rămân neatinse, pentru că acel cont nici nu le cunoaște. Cu un singur cont principal, în acest punct ar fi dispărut tot.

Când mai mulți utilizatori au nevoie de spațiu propriu

Un Storage Server nu cunoaște nicio cotă pe subcont. Un cont rămâne în directorul lui, dar acolo poate umple tot tariful. Cine vrea să dea clienților, fotografilor sau redactorilor câte un contingent limitat pune de aceea în față o aplicație care preia asta. Nextcloud este cea mai la îndemână, aduce utilizatori, cote și linkuri de partajare: Conectarea Nextcloud la Storage Server.

Ce tarif se potrivește

Pentru un singur site WordPress cu backupuri, Storage-1 ajunge de regulă mult timp. Cine mută bibliotecile media ale mai multor site-uri sau lucrează cu video ajunge repede la Storage-2 sau Storage-3. Toate tarifele stau în Germania, vin fără taxă de configurare, se facturează pe bază PrePaid și nu au durată minimă. Trecerea la tariful imediat mai mare este posibilă oricând, fără să atingi datele.