Storage Server met WordPress gebruiken: wat werkt en wat niet

De map wp-content/uploads is het deel van WordPress dat ongeremd groeit. Afbeeldingen, pdf-bestanden, video's, en van elke afbeelding ook nog meerdere formaten die WordPress automatisch aanmaakt. Na een paar jaar staan daar tientallen gigabytes, en de ruimte op de webserver is de duurste die u kunt kopen.

Een Storage Server kost daarvan een fractie. De vraag is alleen wat er werkelijk te verplaatsen valt. Op internet staat daarover veel wat in de praktijk niet werkt. Dit artikel scheidt de drie gevallen netjes.

De drie gevallen op een rij

Over het laatste punt struikelen de meesten. Daarom eerst de ongemakkelijke waarheid.

Waarom er voor de mediabibliotheek geen plugin is

De bekende plugins die bestanden van WordPress naar externe opslag verhuizen, spreken allemaal dezelfde taal: S3. Ze maken verbinding met Amazon S3 of een compatibele dienst, uploaden het bestand daarheen, verwijderen de lokale kopie en vervangen het adres in het bericht door een openbaar adres van die dienst.

Precies dat valt niet over te zetten naar een Storage Server, en wel om twee redenen:

• De opslag spreekt SMB, SFTP en WebDAV, maar geen S3.
• Er is geen openbaar adres per bestand. Elke toegang is aangemeld, er kan dus geen link bestaan die de browser van de bezoeker rechtstreeks opvraagt.

Er zijn losse plugins die met FTP werken, maar geen enkele met noemenswaardige verspreiding en actueel onderhoud die de mediabibliotheek volledig via SFTP of WebDAV verplaatst. Wie er een vindt, moet voor het gebruik naar de datum van de laatste update en het aantal actieve installaties kijken.

De weg die werkt: koppelen in plaats van verplaatsen

Op een eigen server met rootrechten draait u de zaak om. In plaats van WordPress te leren met vreemde opslag te praten, brengt u de opslag naar de plek waar WordPress toch al naartoe schrijft:

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

Regel 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

Daarna de bestaande bestanden verhuizen en de map vervangen:

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 merkt daar niets van, voor de toepassing is het een heel normaal pad. De oude map blijft als uploads.alt staan tot u hebt gecontroleerd dat alles werkt. Pas dan verwijderen, niet eerder.

De valkuil daarbij: miniaturen

WordPress maakt van elke afbeelding meerdere formaten en laadt die bij elke paginaweergave. Staan die kleine bestanden op de netwerkopslag, dan komt per bestand de netwerklatentie erbij, en een galerij met veertig afbeeldingen wacht veertig keer.

Twee oplossingen, beide goed:

• Een tussenopslag ervoor zetten, bijvoorbeeld een cache in de webserver die de uitgeleverde bestanden lokaal bewaart.
• Alleen de originelen op de opslag leggen en de aangemaakte formaten lokaal laten. Dat is iets meer werk, maar het is de netste weg voor sites met veel afbeeldingen.

Back-ups: het snelste resultaat

Als u maar één ding doet, doe dan dit. Een back-up op dezelfde server is geen back-up: wordt de schijf gewist of de website versleuteld, dan is de back-up mee verdwenen. Op gescheiden opslag overleeft hij.

De gratis plugin WPvivid kan in de basisversie via SFTP naar de opslag back-uppen, met een schema en een bewaarregel. De volledige handleiding daarvoor staat in WordPress-back-ups op de Storage Server.

Op een eigen server gaat het nog beter, namelijk met rsync of BorgBackup rechtstreeks uit een taakplanning. Dan draagt u alleen de wijzigingen over, en BorgBackup dedupliceert daarbovenop.

Grote downloads uitleveren

Voor bestanden die bezoekers moeten downloaden is de opslag ideaal: ze worden zelden gelezen, ze zijn groot, en ze hoeven niet snel te zijn maar alleen aan te komen. De toegang loopt via een klein script dat vooraf de rechten controleert:

<?php
// in de functions.php of als eigen plugin
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Meld u eerst aan', '', ['response' => 403]);
    }

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

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

Het voorbeeld gaat uit van gekoppelde opslag. Zonder koppeling vervangt u readfile() door een SFTP- of WebDAV-aanvraag, zoals beschreven in Storage Server voor uw eigen website gebruiken.

Het neveneffect is aangenaam: omdat het bestand nooit een openbaar adres heeft, kan niemand de link doorsturen. De rechtencontrole is niet te omzeilen.

Wat er op shared hosting overblijft

Op shared hosting is WebDAV via HTTPS de betrouwbaarste weg, omdat poort 443 praktisch nooit geblokkeerd is. SFTP werkt ook, maar loopt bij ons op poort 23, en niet elke aanbieder staat uitgaande verbindingen op zulke poorten toe. Dat kijkt u het beste even na voordat u bestelt.

Eén subaccount per doel

Elke Storage Server staat tot 100 subaccounts toe, elk met een eigen startmap, een eigen wachtwoord en eigen protocolrechten. Voor WordPress betekent dat er minstens twee:

• Eén account voor de website, dat alleen /uploads ziet.
• Eén account voor de back-ups, dat alleen /backup ziet.

Wordt de website ooit overgenomen, dan vindt de aanvaller in wp-config.php de inloggegevens van het eerste account. De back-ups blijven onaangeroerd, omdat dit account ze helemaal niet kent. Met één enkel hoofdaccount zou op dit punt alles verloren zijn.

Als meerdere gebruikers eigen ruimte nodig hebben

Een Storage Server kent geen quotum per subaccount. Een account blijft in zijn map, maar kan daar het hele tarief volschrijven. Wie klanten, fotografen of redacteuren elk een begrensd volume wil geven, zet er daarom een toepassing voor die dat overneemt. Nextcloud is daarvoor de meest voor de hand liggende keuze, het brengt gebruikers, quota en deellinks mee: Nextcloud met de Storage Server verbinden.

Welk tarief past

Voor één enkele WordPress-site met back-ups is Storage-1 in de regel lang genoeg. Wie de mediabibliotheken van meerdere sites verplaatst of met video werkt, komt snel bij Storage-2 of Storage-3 uit. Alle tarieven staan in Duitsland, komen zonder installatiekosten, worden op prepaidbasis afgerekend en hebben geen minimale looptijd. Overstappen naar het volgende, grotere tarief kan altijd, zonder de gegevens aan te raken.