File Manager'a giriyorsunuz ve public_html'in yanında hiç oluşturmadığınız birkaç klasör daha görüyorsunuz: mail, logs, tmp, etc, ssl. Gereksiz göründüğü için birini siliyorsunuz ve yarım saat sonra site açılmıyor ya da gönderilen e-postalar geri dönmüyor. Bu makale tam da o an için: her klasörün içinde ne var, hangilerini kullanıcı değiştirebilir ve hangilerine dokunmadan bırakmalısınız.
Host klasör yapısı: sunucu gözünden değil, kullanıcı gözünden
FTP veya SSH ile hesabınıza girdiğinizde, kendi adınızı taşıyan bir klasöre düşersiniz. Gerçek yolu şuna benzer:
/home/USERNAME/Bu klasör hesabınızın köküdür ve cPanel'de Home Directory olarak bilinir. Altındaki her şey aynı hesaba aittir ve sunucudaki diğer hesapları etkilemez. Ancak altındaki tüm klasörler aynı seviyede değildir. Üç kategori vardır: web sunucusunun doğrudan hizmet verdiği klasörler, diğer servislerin (Mail, DNS, Cron) kullandığı klasörler ve yalnızca barındırma motorunun dokunduğu klasörler.
public_html tam olarak neyi sunar
Hesabın ana alan adı public_html'e eşlenmiştir. Yani https://example.com/wp-login.php isteği /home/USER/public_html/wp-login.php dosyasına ulaşır. Ek alan adı (Addon Domain) oluşturursanız, cPanel varsayılan olarak alan adıyla aynı adı taşıyan bir klasör oluşturur ve onu Document Root olarak kaydeder; örneğin public_html/shop. Bu eşleme klasörün kendisinde değil, web sunucusunun yapılandırma dosyasında yazılıdır, dolayısıyla Document Root'u değiştirmeden klasörü taşımak siteyi 404'e götürür.
Çoğu kişinin bilmediği bir nokta: hem index.php hem de index.html varsa, hangisinin çalışacağını web sunucusunun öncelik sırası belirler ve bu sıra Apache ile LiteSpeed'de aynı değildir. Sitenin eski HTML sürümünü yükledikten sonra yeni PHP sürümü görüntülenmiyorsa, önce bunu kontrol edin.
Kurcalanmaması gereken klasörler
Bunları ne silin, ne yeniden adlandırın, ne de izinlerini değiştirin:
| Klasör | Görevi | Bozarsanız ne olur |
|---|---|---|
mail | Posta kutusu, filtreler ve Maildir yapılandırması | Mevcut e-postalar kaybolur veya gönderim kesilir |
etc | Alan adları, Cron, SSL yapılandırması ve kullanıcı dosyaları | Alan adı hesaptan ayrılır, Cron'lar bozulur |
logs | Web sunucusu erişim ve hata günlükleri | Hata ayıklama körleşir; genellikle kendini yeniden oluşturur |
ssl | Alan adlarının anahtarı ve sertifika zinciri | HTTPS bozulur ve tarayıcı uyarı verir |
tmp | Geçici PHP dosyaları ve yarım kalan yüklemeler | Yükleme hataları ve tuhaf session'lar |
.trash | File Manager geri dönüşüm kutusu | Alan boşalır ama geri getirme mümkün olmaz |
En çok kurban veren klasör logs'tur, çünkü boyutu artar ve kullanıcının yer açmak için ilk sildiği şeydir. İçindeki dosyaları silmek zararsızdır; klasörün kendisini silmek değil. Web sunucusu günlük yazamazsa, yapılandırmaya bağlı olarak istekleri 500 hatasıyla reddedebilir.
Gizli klasörleri ls -la ile görün
File Manager varsayılan olarak nokta ile başlayan dosyaları göstermez. SSH ile şunları görün:
ls -la ~/
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -hİkinci komutun çıktısı genellikle şaşırtıcıdır: .cagefs veya .wp-cli ya da Composer önbelleği gibi bir klasör birkaç yüz megabayt olabilir. Kesin tüketim rakamını cPanel içinden Disk Usage bölümünde de görürsünüz, ancak o rapor 24 saate kadar önbelleğe alınır; anlık rakam için du'ya güvenin.
Dosya izinleri ve sahiplik: 500 hatası tam buradan gelir
Pratikte işe yarayan kural: klasörler 755, dosyalar 644. wp-config.php gibi hassas yapılandırma dosyalarını 600 yapın. Şu komutla hepsini birden düzeltin:
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;Sahipliğe dokunmayın. Paylaşımlı hosting'de dosyalar hesap sahibine ait olmalıdır; chown ile onları başka bir kullanıcıya verirseniz PHP artık yazma iznine sahip olmaz ve WordPress yükleme veya güncelleme sırasında "Could not create directory" mesajı verir. Burada şu hata yapılır: kullanıcı erişim hatasını gidermek için tüm klasörü 777 yapar. Site açılır, ancak o andan itibaren sunucudaki herhangi bir script dosyalarınızın üzerine yazabilir ve genellikle birkaç hafta sonra public_html/uploads içine yüklenmiş bir shell ile karşılaşırsınız.
Host klasör yapısı ve inode tüketimi
Her dosya ve her klasör bir inode tüketir. Düzenli olmayan klasör yapısı, disk boyutundan daha hızlı bir şekilde sizi üst sınıra ulaştırır. Orta düzey eklentilere sahip bir WordPress kurulumu genellikle 15.000 ila 40.000 inode alır; sayfa önbelleği veya yedek sürümlerini public_html içinde tutarsanız bu sayı birkaç katına çıkar. Kesin sayım ve hangi klasörün sorumlu olduğunu anlamak için Hosting'de inode sınırı: Neyi tüketir ve nasıl sayarız yazısına bakın. Pratik çözüm basittir: önbellek, günlük ve yedek klasörlerini public_html dışına taşıyın.
Hangi klasörler public_html dışında olmalı
- Yedek sürümler ve
.sqlveya.tar.gzdosyaları - Eklenti önbellek klasörleri ve eklenti taşımaya izin veriyorsa
wp-content/cache - Veritabanı şifresi içeren yapılandırma dosyaları
- Henüz yayına hazır olmayan geliştirme projeleri
public_html içindeki her dosya, bir yerde ona bağlantı vermemiş olsanız bile internetten talep edilebilir. Sitenin kökündeki bir backup.sql, basit bir Google aramasıyla bulunur.
Ek alan adı, alt alan adı ve klasörleri
Alt alan adları varsayılan olarak public_html altında oluşturulur; örneğin blog.example.com için public_html/blog. Bu, blog sitesindeki bir güvenlik açığının ana sitenin dosyalarına da ulaşabileceği anlamına gelir, çünkü ikisi de aynı kök Document Root altındadır. Güvenlik sizin için önemliyse, alt alan adını public_html dışında oluşturun, örneğin /home/USER/blog ve Document Root'u elle ona yönlendirin.
Maliyetini de söyleyeyim: bazı eklentiler ve dosya yönetim araçları göreli yolları public_html'e göre varsayar ve standart dışı yapıyla bozulurlar. Basit bir siteniz varsa ve özel bir teknik yöneticiniz yoksa, cPanel'in varsayılan yapısı daha az sorun çıkarır. Farklı güvenlik ihtiyaçlarına sahip birden fazla siteyi barındıran projeler için yolları ayırmak değerlidir.
Siteyi paylaşımlı hosting'den bir özel sunucuya taşıdığınızda bu yapı değişir: /home/USER yerine /var/www ve bağımsız VirtualHost'larla karşılaşırsınız. Taşımadan önce her alan adının klasör listesini ve Document Root yolunu not edin; taşımadan sonra genellikle geride kalan tek şey public_html dışındaki dosyalardır.
Sık sorulan sorular
public_html'in adını değiştirebilir miyim?
Hayır, ne File Manager'dan ne de FTP'den. Bu klasörün adı web sunucusu yapılandırmasında ana alan adının Document Root'u olarak kayıtlıdır. Değiştirirseniz site 404 hatasıyla veya hosting'in varsayılan sayfasıyla açılır. Gerçekten başka bir yola ihtiyacınız varsa, Document Root'un cPanel içinden veya destekten değiştirilmesini istemelisiniz.
.htaccess dosyası nerede ve neden görünmüyor?
public_html kökünde bulunur ve nokta ile başladığı için File Manager onu gizli gösterir. File Manager ayarlarında Show Hidden Files seçeneğini etkinleştirin veya ls -la ile görün. Bu dosya URL yeniden yazma kurallarını, yönlendirmeleri ve erişim kısıtlamalarını tutar; içindeki tek bir yanlış karakter tüm siteyi 500 hatasına götürür.
mail klasörü neden çok yer kaplıyor?
Çünkü okunmamış e-postalar ve ekler ayrı bir alanda değil, aynı hesapta saklanır. POP3 kutunuz varsa ve e-postaları indirmiyorsanız, bu klasör disk kotasını doldurana kadar büyür. du -sh ~/mail/* ile hangi alan adının sorumlu olduğunu görün ve cPanel içinden kutuyu boşaltın veya kotasını sınırlayın.
tmp içindeki önbellek ve session dosyaları ne zaman silinir?
Çoğu paylaşımlı hosting'de tmp klasörü düzenli ve otomatik olarak temizlenir; genellikle birkaç saatte bir ila bir günde bir. Dolayısıyla ihtiyaç duyduğunuz hiçbir veriyi orada tutmayın. PHP session'larını tmp içine yazıyorsanız ve kullanıcılar sebepsizce çıkış yapıyorsa, session yolunu daha kalıcı bir klasöre taşıyın.
Klasör yapısında herhangi bir değişiklik yapmadan önce tam bir yedek alın ve her alan adının Document Root yolunu not edin. Bir klasörün ne işe yaradığından emin değilseniz, ona dokunmayın; silmek hiçbir zaman acil değildir, ama geri getirmek her zaman mümkün değildir.