Utiliser un Storage Server avec WordPress : ce qui marche et ce qui ne marche pas

Le répertoire wp-content/uploads est la partie de WordPress qui grossit sans frein. Images, fichiers PDF, vidéos, et de chaque image plusieurs tailles que WordPress génère automatiquement. Au bout de quelques années, des dizaines de gigaoctets s'y accumulent, et l'espace sur le serveur web est le plus cher qu'on puisse acheter.

Un Storage Server coûte une fraction de ce prix. La seule question est de savoir ce qui peut réellement être déporté. On lit à ce sujet beaucoup de choses qui ne fonctionnent pas en pratique. Cet article sépare proprement les trois cas.

Les trois cas en un coup d'œil

Le dernier point est celui sur lequel la plupart des gens butent. Commençons donc par la vérité qui dérange.

Pourquoi il n'existe pas de plugin pour la médiathèque

Les plugins de déport connus pour WordPress parlent tous la même langue : S3. Ils se connectent à Amazon S3 ou à un service compatible, y téléversent le fichier, suppriment la copie locale et remplacent l'adresse dans l'article par une adresse publique du service.

C'est précisément ce qui ne se transpose pas à un Storage Server, et pour deux raisons :

• Le stockage parle SMB, SFTP et WebDAV, mais pas S3.
• Il n'y a pas d'adresse publique par fichier. Chaque accès est authentifié, il ne peut donc pas exister de lien que le navigateur du visiteur appelle directement.

Il existe quelques plugins qui travaillent en FTP, mais aucun avec une diffusion notable et une maintenance à jour qui déporte entièrement la médiathèque via SFTP ou WebDAV. Si vous en trouvez un, regardez avant de l'utiliser la date de la dernière mise à jour et le nombre d'installations actives.

La voie qui fonctionne : monter au lieu de déporter

Sur un serveur root avec les droits root, on retourne le problème. Au lieu d'apprendre à WordPress à parler à un stockage étranger, on amène le stockage à l'endroit où WordPress écrit de toute façon :

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

Entrée dans /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

Ensuite, déplacer les fichiers existants et remplacer le répertoire :

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 ne s'en aperçoit pas, pour l'application c'est un chemin tout à fait ordinaire. L'ancien répertoire reste en place sous le nom uploads.alt jusqu'à ce que vous ayez vérifié que tout fonctionne. Ne le supprimez qu'après, pas avant.

Le piège au passage : les vignettes

WordPress génère de chaque image plusieurs tailles et les charge à chaque affichage de page. Si ces petits fichiers se trouvent sur le stockage réseau, le temps de trajet réseau s'ajoute pour chaque fichier, et une galerie de quarante images attend quarante fois.

Deux solutions, bonnes toutes les deux :

• Placer un cache en amont, par exemple un cache dans le serveur web qui garde les fichiers diffusés en local.
• Ne placer que les originaux sur le stockage et laisser les tailles générées en local. C'est un peu plus de travail, mais c'est la voie la plus propre pour les sites avec beaucoup d'images.

Les sauvegardes : le bénéfice le plus rapide

Si vous ne faites qu'une seule chose, faites celle-ci. Une sauvegarde sur le même serveur n'est pas une sauvegarde : si le disque est effacé ou le site web chiffré, elle disparaît avec lui. Sur un stockage séparé, elle survit.

Le plugin gratuit WPvivid peut sauvegarder en SFTP sur le stockage dans sa version de base, avec planification et règle de conservation. Le guide complet figure dans Sauvegardes WordPress vers le Storage Server.

Sur un serveur root, cela marche encore mieux, à savoir avec rsync ou BorgBackup directement depuis une tâche planifiée. Vous ne transférez alors que les modifications, et BorgBackup déduplique en plus.

Diffuser de gros téléchargements

Pour les fichiers que les visiteurs doivent télécharger, le stockage est idéal : ils sont rarement lus, ils sont volumineux, et ils n'ont pas besoin d'être rapides, seulement d'arriver. L'accès passe par un petit script qui vérifie d'abord l'autorisation :

<?php
// dans le fichier functions.php ou comme plugin séparé
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Veuillez vous connecter', '', ['response' => 403]);
    }

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

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

L'exemple part d'un stockage monté. Sans montage, vous remplacez readfile() par une récupération SFTP ou WebDAV, telle qu'elle est décrite dans Utiliser un Storage Server pour son site web.

L'effet secondaire est agréable : comme le fichier n'a jamais d'adresse publique, personne ne peut faire circuler le lien. Le contrôle d'autorisation ne peut pas être contourné.

Ce qui reste sur un hébergement mutualisé

Sur un hébergement mutualisé, WebDAV via HTTPS est la voie la plus fiable, parce que le port 443 n'est pratiquement jamais bloqué. SFTP fonctionne également, mais il tourne chez nous sur le port 23, et tous les hébergeurs n'autorisent pas les connexions sortantes sur de tels ports. Mieux vaut le vérifier rapidement avant la commande.

Un sous-compte par usage

Chaque Storage Server autorise jusqu'à 100 sous-comptes, chacun avec son propre répertoire de départ, son propre mot de passe et ses propres autorisations de protocole. Pour WordPress, cela veut dire au moins deux :

• Un compte pour le site web, qui ne voit que /uploads.
• Un compte pour les sauvegardes, qui ne voit que /backup.

Si le site web est un jour compromis, l'attaquant trouve dans wp-config.php les identifiants du premier compte. Les sauvegardes restent intactes, parce que ce compte ne les connaît même pas. Avec un unique compte principal, tout serait perdu à cet endroit.

Quand plusieurs utilisateurs ont besoin de leur propre espace

Un Storage Server ne connaît aucun quota par sous-compte. Un compte reste dans son répertoire, mais il peut y remplir tout le forfait. Pour donner à des clients, des photographes ou des rédacteurs un contingent limité chacun, on place donc en amont une application qui s'en charge. Nextcloud est la plus évidente pour cela, elle apporte les utilisateurs, les quotas et les liens de partage : Connecter Nextcloud au Storage Server.

Quel forfait convient

Pour un seul site WordPress avec ses sauvegardes, Storage-1 suffit en règle générale pour longtemps. Qui déporte les médiathèques de plusieurs sites ou travaille avec de la vidéo arrive vite à Storage-2 ou Storage-3. Tous les forfaits se trouvent en Allemagne, viennent sans frais de mise en service, sont facturés en PrePaid et n'ont pas de durée minimale. Le passage au forfait immédiatement supérieur est possible à tout moment, sans toucher aux données.