Storage Server'ı WordPress ile kullanma: ne işler, ne işlemez

wp-content/uploads dizini, WordPress'in frensiz büyüyen bölümüdür. Görseller, PDF dosyaları, videolar, buna ek olarak her görselden WordPress'in otomatik ürettiği birkaç boyut. Birkaç yıl sonra orada onlarca gigabayt yatar ve web sunucusundaki alan, satın alınabilecek en pahalı alandır.

Storage Server bunun çok küçük bir kesri kadar tutar. Soru yalnızca şu: Gerçekte neler taşınabilir? İnternette bu konuda, pratikte işlemeyen pek çok şey yazıyor. Bu yazı üç durumu temiz biçimde birbirinden ayırıyor.

Üç duruma genel bakış

Son nokta, çoğu kişinin tökezlediği noktadır. Bu yüzden önce rahatsız edici gerçek.

Medya kitaplığı için neden bir eklenti yok

WordPress için bilinen taşıma eklentilerinin hepsi aynı dili konuşur: S3. Amazon S3 ya da onunla uyumlu bir hizmete bağlanır, dosyayı oraya yükler, yerel kopyayı siler ve yazıdaki adresi hizmetin herkese açık bir adresiyle değiştirir.

Tam bunu bir Storage Server'a aktarmak mümkün değil, hem de iki sebepten:

• Depolama SMB, SFTP ve WebDAV konuşur, ama S3 konuşmaz.
• Dosya başına herkese açık bir adres yoktur. Her erişim kimlik doğrulamalıdır, yani ziyaretçinin tarayıcısının doğrudan çağırdığı bir bağlantı olamaz.

FTP ile çalışan tek tek eklentiler var, ama medya kitaplığını SFTP ya da WebDAV üzerinden eksiksiz taşıyan, kayda değer yaygınlığa ve güncel bakıma sahip olanı yok. Bir tane bulan kişi, kullanmadan önce son güncelleme tarihine ve etkin kurulum sayısına bakmalıdır.

İşleyen yol: taşımak değil, bağlamak

Root erişimi olan kendi sunucunuzda işi tersine çevirirsiniz. WordPress'e yabancı bir depolamayla konuşmayı öğretmek yerine, depolamayı WordPress'in zaten yazdığı yere getirirsiniz:

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

/etc/fstab dosyasına kayıt:

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

Ardından var olan dosyaları taşıyın ve dizini değiştirin:

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 bunu hiç fark etmez, uygulama için bu sıradan bir yoldur. Eski dizin, her şeyin çalıştığını denetleyene kadar uploads.alt olarak yerinde kalır. Ancak o zaman silin, daha önce değil.

Buradaki tuzak: önizleme görselleri

WordPress her görselden birkaç boyut üretir ve onları her sayfa çağrısında yükler. Bu küçük dosyalar ağ depolamasında duruyorsa dosya başına ağ gecikmesi eklenir ve kırk görselli bir galeri kırk kez bekler.

İki çözüm, ikisi de iyi:

• Önüne bir ara bellek koymak, örneğin sunulan dosyaları yerelde tutan, web sunucusundaki bir önbellek.
• Yalnızca özgün dosyaları depolamaya koymak ve üretilen boyutları yerelde bırakmak. Bu biraz daha fazla iş, ama çok görselli sayfalar için en temiz yol.

Yedeklemeler: en hızlı fayda

Yalnızca tek bir şey yapacaksanız, bunu yapın. Aynı sunucudaki bir yedek, yedek değildir: Disk silinir ya da web sitesi şifrelenirse o da birlikte gider. Ayrı bir depolamada ise hayatta kalır.

Ücretsiz eklenti WPvivid, temel sürümünde SFTP ile depolamaya yedekleyebilir, hem de zaman planı ve saklama kuralıyla. Bunun eksiksiz anlatımı WordPress yedeklerini Storage Server'a alma yazısında.

Kendi sunucunuzda daha da iyisi mümkün, yani doğrudan bir zaman planından rsync ya da BorgBackup ile. O zaman yalnızca değişiklikleri aktarırsınız ve BorgBackup ayrıca tekilleştirme yapar.

Büyük indirmeleri sunma

Ziyaretçilerin indirmesi gereken dosyalar için depolama ideal: Nadiren okunur, büyüktür ve hızlı olmaları değil, yalnızca ulaşmaları gerekir. Erişim, önce izni denetleyen küçük bir betik üzerinden işler:

<?php
// functions.php içinde ya da ayrı bir eklenti olarak
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Lütfen oturum açın', '', ['response' => 403]);
    }

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

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

Örnek, bağlanmış bir depolamayı varsayıyor. Bağlamadan çalışıyorsanız readfile() yerine, Storage Server'ı kendi web siteniz için kullanma yazısında anlatılan bir SFTP ya da WebDAV çağrısını koyarsınız.

Yan etkisi hoş: Dosyanın hiçbir zaman herkese açık bir adresi olmadığı için kimse bağlantıyı başkasına veremez. İzin denetimi atlatılamaz.

Paylaşımlı hostingde ne kalıyor

Paylaşımlı hostingde HTTPS üzerinden WebDAV en güvenilir yoldur, çünkü 443 numaralı port neredeyse hiçbir zaman kapalı değildir. SFTP de işler, ama bizde 23 numaralı portta çalışır ve her sağlayıcı böyle portlara giden bağlantılara izin vermez. Bunu sipariş öncesinde kısaca kontrol etmek gerekir.

Her amaç için bir alt hesap

Her Storage Server 100 taneye kadar alt hesaba izin verir, her biri kendi başlangıç dizini, kendi parolası ve kendi protokol izinleriyle. WordPress için bu en az iki tane demek:

• Web sitesi için bir hesap, yalnızca /uploads dizinini gören.
• Yedeklemeler için bir hesap, yalnızca /backup dizinini gören.

Web sitesi bir gün ele geçirilirse saldırgan wp-config.php içinde ilk hesabın erişim bilgilerini bulur. Yedekler dokunulmamış kalır, çünkü bu hesap onları hiç bilmez. Tek bir ana hesapla bu noktada her şey giderdi.

Birden fazla kullanıcı kendine ait alana ihtiyaç duyarsa

Storage Server alt hesap başına kota tanımaz. Hesap kendi dizininde kalır, ama orada bütün tarifeyi doldurabilir. Müşterilere, fotoğrafçılara ya da editörlere ayrı ayrı sınırlı bir pay vermek isteyen kişi, bu yüzden önüne bunu üstlenen bir uygulama koyar. Nextcloud bunun için en yakın seçenek, kullanıcıları, kotaları ve paylaşım bağlantılarını yanında getirir: Nextcloud'u Storage Server ile bağlama.

Hangi tarife uygun

Yedeklemeleri olan tek bir WordPress sitesi için Storage-1 kural olarak uzun süre yeter. Birden fazla sitenin medya kitaplığını taşıyan ya da videoyla çalışan kişi, hızla Storage-2 ya da Storage-3'e varır. Bütün tarifeler Almanya'da durur, kurulum ücreti olmadan gelir, ön ödemeli esasa göre faturalanır ve asgari sözleşme süresi yoktur. Bir üst tarifeye geçiş, verilere dokunmadan her zaman mümkündür.