Usar um Storage Server com o WordPress: o que funciona e o que não

O diretório wp-content/uploads é a parte do WordPress que cresce sem travões. Imagens, ficheiros PDF, vídeos, e de cada imagem vários tamanhos que o WordPress cria automaticamente. Depois de alguns anos estão aí dezenas de gigabytes, e o espaço no servidor web é o mais caro que se pode comprar.

Um Storage Server custa uma fração disso. A única questão é o que se pode realmente mover para fora. Na internet há muito escrito sobre isto que na prática não funciona. Este artigo separa os três casos com clareza.

Os três casos em resumo

O último ponto é aquele em que a maioria tropeça. Por isso, primeiro a verdade incómoda.

Porque é que não existe plugin para a biblioteca de multimédia

Os plugins de externalização conhecidos para o WordPress falam todos a mesma língua: S3. Ligam-se ao Amazon S3 ou a um serviço compatível, carregam o ficheiro para lá, apagam a cópia local e substituem o endereço no artigo por um endereço público do serviço.

Exatamente isso não se pode transpor para um Storage Server, e por duas razões:

• O armazenamento fala SMB, SFTP e WebDAV, mas não S3.
• Não existe um endereço público por ficheiro. Cada acesso é autenticado, não pode portanto haver uma ligação que o navegador do visitante abra diretamente.

Existem plugins isolados que trabalham com FTP, mas nenhum com difusão apreciável e manutenção atual que mova a biblioteca de multimédia por completo por SFTP ou WebDAV. Quem encontrar um deve olhar, antes de o usar, para a data da última atualização e para o número de instalações ativas.

O caminho que funciona: montar em vez de mover para fora

Num servidor próprio com privilégios de root inverte-se a questão. Em vez de ensinar o WordPress a falar com armazenamento alheio, leva-se o armazenamento até ao sítio onde o WordPress já escreve de qualquer forma:

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

Entrada em /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

Depois, mudar os ficheiros existentes e substituir o diretório:

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

O WordPress não nota nada, para a aplicação é um caminho totalmente normal. O diretório antigo fica como uploads.alt até ter verificado que tudo funciona. Apague-o só então, não antes.

A armadilha aqui: as miniaturas

O WordPress cria de cada imagem vários tamanhos e carrega-os em cada visita de página. Se esses ficheiros pequenos estiverem no armazenamento em rede, acresce a latência de rede por ficheiro, e uma galeria com quarenta imagens espera quarenta vezes.

Duas soluções, as duas boas:

• Colocar uma cache à frente, por exemplo uma cache no servidor web que mantenha localmente os ficheiros entregues.
• Colocar no armazenamento apenas os originais e deixar localmente os tamanhos criados. É um pouco mais de trabalho, mas é o caminho mais limpo para páginas com muitas imagens.

Backups: o benefício mais rápido

Se fizer apenas uma coisa, faça esta. Um backup no mesmo servidor não é um backup: se o disco for apagado ou o site for encriptado, vai com ele. Em armazenamento separado, sobrevive.

O plugin gratuito WPvivid pode, na versão base, guardar o backup no armazenamento por SFTP, com agendamento e regra de retenção. O guia completo está em Backups do WordPress no Storage Server.

Num servidor próprio consegue-se ainda melhor, ou seja, com rsync ou BorgBackup diretamente a partir de uma tarefa agendada. Aí transfere apenas as alterações, e o BorgBackup ainda desduplica por cima.

Entregar downloads grandes

Para ficheiros que os visitantes devem descarregar, o armazenamento é ideal: são lidos poucas vezes, são grandes, e não têm de ser rápidos, apenas de chegar. O acesso passa por um pequeno script que antes verifica a permissão:

<?php
// no functions.php ou como plugin próprio
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Inicie sessão, por favor', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Ficheiro não encontrado', '', ['response' => 404]);
    }

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

O exemplo parte de um armazenamento montado. Sem o montar, substitui readfile() por uma chamada SFTP ou WebDAV, como se descreve em Usar um Storage Server para o seu site.

O efeito secundário é agradável: como o ficheiro nunca tem um endereço público, ninguém pode passar a ligação a outros. A verificação de permissões não se pode saltar.

O que sobra em alojamento partilhado

Em alojamento partilhado, o WebDAV sobre HTTPS é o caminho mais fiável, porque a porta 443 praticamente nunca está bloqueada. O SFTP funciona igualmente, mas no nosso caso vai pela porta 23, e nem todos os fornecedores permitem ligações de saída em portas assim. Isso convém verificar brevemente antes de encomendar.

Uma subconta por finalidade

Cada Storage Server permite até 100 subcontas, cada uma com o seu próprio diretório inicial, a sua própria palavra-passe e os seus próprios protocolos autorizados. Para o WordPress isso significa pelo menos duas:

• Uma conta para o site, que só vê /uploads.
• Uma conta para os backups, que só vê /backup.

Se um dia o site for comprometido, o atacante encontra no wp-config.php as credenciais da primeira conta. Os backups ficam intactos, porque essa conta nem sequer os conhece. Com uma única conta principal, nesse ponto estaria tudo perdido.

Quando vários utilizadores precisam de espaço próprio

Um Storage Server não conhece nenhuma quota por subconta. Uma conta fica no seu diretório, mas aí pode encher todo o tarifário. Quem quiser dar a clientes, fotógrafos ou redatores um contingente limitado a cada um coloca à frente uma aplicação que assuma essa tarefa. O Nextcloud é a opção mais evidente para isso, traz utilizadores, quotas e ligações de partilha: Ligar o Nextcloud ao Storage Server.

Que tarifário encaixa

Para um único site WordPress com backups, o Storage-1 costuma bastar por muito tempo. Quem mover para fora as bibliotecas de multimédia de várias páginas ou trabalhar com vídeo chega depressa ao Storage-2 ou ao Storage-3. Todos os tarifários estão na Alemanha, vêm sem taxa de instalação, são faturados em regime PrePaid e não têm período mínimo de contrato. Passar para o tarifário seguinte maior é possível em qualquer momento, sem tocar nos dados.