php.ini Ayarları Referansı; Her Direktif Varsayılan Değeri ve Pratik Etkisiyle

php.ini Dosyanız Neden Komşunuzunkinden Farklı?

Fatal error: Allowed memory size of 134217728 bytes exhausted hatası veren bir site ile aynı hatayı 268435456 sayısıyla gören bir site aynı soruna sahip değildir. İlki 128 megabaytla sınırlandırılmıştır, ikincisi 256 ile. İkisi de bellek sınırına takılıyor, ancak sınırlarını başka biri belirlemiş. Paylaşımlı hostingde ana php.ini ayarları sizin kontrolünüzde değildir; gördüğünüz şey üç katmanın sonucudur: PHP'nin kendisine derlenmiş değer, sunucunun ana dosyasındaki değer ve sitenizin kök dizinine koyduğunuz .user.ini veya özel php.ini dosyasındaki değer. Bu makale her direktifin ne yaptığını, varsayılan değerinin ne olduğunu ve paylaşımlı ortamda değiştirme izninizin olup olmadığını söyler.

Bellek ve Çalıştırma Direktifleri; Hataların %90'ının Kaynağı

memory_limit

Bir betiğin tüketebileceği bellek sınırı. PHP 8.x'te varsayılan değer 128M'dir, ancak birçok paylaşımlı hosting bunu 256M yapar. WordPress exhausted hatası veriyorsa, ilk suçlu kalitesiz bir eklentidir, bu ayar değil. Paylaşımlı hostingde bu sayıyı gelişigüzel artırmak, tüm sunucuyu çökertmenin bir yoludur; bu yüzden 256 megabayttan fazlasına ihtiyacınız varsa, sorun başka yerdedir.

Paylaşımlı hostingde genellikle sağlayıcının belirlediği sınıra kadar (örneğin 512 megabayt) artırabilirsiniz. Üstüne çıkamazsınız. İnsanların yaptığı hata şudur: sayıyı izin verilen sınıra kadar artırırlar, hata birkaç gün kaybolur, sonra 503 Service Unavailable hatasıyla karşılaşırlar çünkü tüm site CPU sınırını aşmıştır. Daha fazla bellek, daha fazla işlem demektir ve daha fazla işlem, CPU'dan daha büyük pay demektir. Sorunu log alarak çözün, sınırı büyüterek değil.

max_execution_time

Her betiğin çalışmasına izin verilen süre, saniye cinsinden. PHP'de varsayılan 30'dur; paylaşımlı hostingde genellikle 60 veya 120'dir. Görüntü işleme veya toplu e-posta için bir betiğin bu süreden fazlasına ihtiyacı varsa, doğru yol cron job kullanmaktır, bu sayıyı artırmak değil. 300 saniye çalışan bir betik, paylaşımlı hostingde komşularınızı da yavaşlatır.

PHP 8'de bu değerin yalnızca betiğin kendi çalışması için hesaplandığını, girdi için bekleme süresini kapsamadığını unutmayın. Yani betik harici bir API'nin yanıtını bekliyorsa, bu zamanlayıcı durur. Çoğu kişi bunu bilmez ve timeout'un I/O'dan kaynaklandığını sanır.

max_input_vars

Bir isteğin sahip olabileceği maksimum girdi değişkeni sayısı (GET, POST ve Cookie). Varsayılan 1000'dir. 1.200 alanlı bir form, son 200 alanı sessizce siler. Hiçbir hata görmezsiniz; sadece veriler kaybolur. Bu, saatlerce süren hata ayıklamanın nedeni olan sessiz hatalardan biridir.

Paylaşımlı hostingde genellikle 2000 veya 3000'e kadar artırabilirsiniz. Daha yükseği, gerçek bir ihtiyaçtan çok kötü form tasarımının işaretidir.

Yükleme Direktifleri; Son Kullanıcının Hata Gördüğü Yer

upload_max_filesize ve post_max_size

İlki yüklenen her dosyanın boyut sınırıdır, ikincisi POST isteğinin tüm gövdesinin sınırıdır. Varsayılanlar sırasıyla 2M ve 8M'dir. Paylaşımlı hostingde genellikle 64M ve 128M'dir. Altın kural: post_max_size her zaman upload_max_filesize'den büyük olmalıdır, çünkü istek gövdesi dosyayı artı formdaki diğer alanları içerir.

İnsanların yaptığı hata şudur: yalnızca upload_max_filesize'i artırırlar, sonra 30 megabaytlık dosya yükleme 413 Request Entity Too Large veya boş bir PHP hatasıyla sonuçlanır. Gerçek sınır, bu iki ayar ile web sunucusu sınırı (örneğin Nginx'te client_max_body_size) arasındaki en küçük sayıdır. Üçünü de koordine etmelisiniz.

max_file_uploads

Tek bir istekteki maksimum dosya sayısı. Varsayılan 20'dir. Kullanıcının 30 görsel yüklemesi gereken bir formunuz varsa, geri kalanı sessizce silinir. Paylaşımlı hostingde bu değeri değiştirmek genellikle mümkündür, ancak 50 veya 100'e çıkarmak bellek ve çalışma süresi üzerinde gerçek bir baskı oluşturur.

Güvenlik Direktifleri; Burada Varsayılanlara Güvenilmez

display_errors

Geliştirme ortamında hataları görmek için On olmalıdır. Production ortamında Off olmalıdır. PHP 8'de varsayılan değer On'dur, ancak paylaşımlı hostingler genellikle Off yapar ve hataları error_log'a yazar. WordPress beyaz ekran hatası görüyorsanız ve hiçbir mesaj görüntülenmiyorsa, önce bu ayarı kontrol edin.

Paylaşımlı hostingde bu değeri .user.ini üzerinden değiştirmek genellikle mümkündür, ancak sağlayıcı sunucu düzeyinde Off yapmışsa, override edemezsiniz. Bu durumda hata logunu okumalısınız. WordPress ve PHP'de Beyaz Ekranı Giderme rehberi tam olarak bu yolu gösterir.

disable_functions

Tamamen devre dışı bırakılmış fonksiyonların listesi. Paylaşımlı hostingde exec, shell_exec, system ve passthru gibi tehlikeli fonksiyonlar genellikle devre dışıdır. Bu bir güvenlik kısıtlamasıdır, bir eksiklik değil. Bir eklenti bu fonksiyonlara ihtiyaç duyuyorsa, o eklenti paylaşımlı hosting için tasarlanmamış demektir.

İnce bir nokta: mail() gibi bazı fonksiyonlar devre dışı olmayabilir ancak ciddi şekilde kısıtlanmış olabilir. Sitenizin e-postaları spam'e düşüyorsa veya hiç gönderilmiyorsa, önce bunu kontrol edin, SMTP ayarlarını değil.

Çalıştırma Direktifleri; Paylaşımlı Hosting ile Özel Sunucu Arasındaki Fark

opcache.enable

PHP ara kod önbelleği. On olduğunda, betikler ilk çalıştırmadan sonra derlenmez ve doğrudan bellekten çalışır. Gerçek farkı burada görürsünüz: opcache devre dışı bir site, aynı sitenin opcache etkin halinden 3 ila 5 kat daha yavaştır. Paylaşımlı hostingde genellikle On'dur ve kapatamazsınız. Kapalıysa, sağlayıcı bilerek devre dışı bırakmıştır, çünkü opcache paylaşımlı hostingde sunucu belleğini tüketir.

Özel sunucudaysanız, opcache.memory_consumption değerini 128 veya 256 megabayta ayarlayın ve opcache.revalidate_freq'i 2 ile 5 saniye arasında yapılandırın. Sıfır koymayın; bu, dosyanın her seferinde değişip değişmediğini kontrol eder ve önbelleği pratikte etkisiz kılar.

realpath_cache_size

Dosyaların gerçek yollarının önbelleği. PHP 8'de varsayılan 4096K'dır. Binlerce include dosyası olan bir site, bu önbellek küçükse her seferinde yolları diskten okur. Paylaşımlı hostingde bu değere erişiminiz yoktur; özel sunucuda 8192K'ya çıkarabilirsiniz. Fark hissedilir, ancak opcache kadar değil.

Paylaşımlı Hostingde Hiç Değiştiremeyeceğiniz Direktifler

Aşağıdaki liste, %99 paylaşımlı hostingde sunucu düzeyinde kilitlenmiş ve .user.ini'ye ne yazarsanız yazın etkisiz kalacak direktiflerdir:

• allow_url_fopen — genellikle On'dur ve kapatamazsınız
• open_basedir — dizin erişim kısıtlaması, sağlayıcı tarafından ayarlanır
• session.save_path — oturumların kaydedildiği yol
• error_log — hata log dosyasının yolu
• extension — PHP eklentilerinin yüklenmesi

Bunları phpinfo'da değerlerinin dosyanızda yazdığınızdan farklı olduğunu görüyorsanız, kilitlenmişlerdir. Bu kısıtlamalarla savaşmak zaman kaybıdır. Ya bu kısıtlamalarla çalışın ya da daha fazla erişime sahip bir ortama geçin.

Paylaşımlı Hostingde Ayar Değiştirmenin Doğru Yolu

cPanel hostinglerde .user.ini dosyası public_html kökünde geçerlidir ve ayarları tüm alt dizinlere de yayılır. Yalnızca belirli bir alt dizini değiştirmek istiyorsanız, dosyayı oraya koyun. Sözdizimi basittir:

memory_limit = 256M
max_execution_time = 120
upload_max_filesize = 64M
post_max_size = 128M
max_input_vars = 3000
display_errors = Off

Değişiklikten sonra, <?php phpinfo(); ?> içeren bir test dosyasıyla yeni değerin uygulanıp uygulanmadığını kontrol edin. Uygulanmadıysa, sağlayıcı kilitlemiş demektir. Bu yöntemi ücretsiz webmaster araçlarıyla da kontrol edebilirsiniz.

Hızlı Karşılaştırma: Bilmeniz Gereken Direktifler

Sık Sorulan Sorular

php.ini dosyam nerede?

cPanel paylaşımlı hostingde genellikle public_html kökünde .user.ini dosyası oluşturmalısınız. Kesin yolu bulmak için <?php phpinfo(); ?> içeren bir test dosyası oluşturun ve Loaded Configuration File değerine bakın.

php.ini değişikliklerim neden uygulanmıyor?

İki yaygın nedeni vardır: ya değiştirdiğiniz direktif sunucu düzeyinde kilitlenmiştir (örneğin disable_functions) ya da değişiklikten sonra PHP'yi sıfırlamadınız. Paylaşımlı hostingde .user.ini değişiklikleri genellikle anında uygulanır, ancak uygulanmazsa birkaç dakika bekleyin veya panelden "Restart PHP" seçeneğini kullanın.

WordPress için hangi php.ini ayarları kritiktir?

memory_limit en az 128 megabayt, max_execution_time en az 60 saniye ve upload_max_filesize en az 32 megabayt. Siteniz bu üç sayıyla çalışıyorsa ve hâlâ hata veriyorsa, sorun PHP'de değil; kötü bir eklenti veya temadadır. Paylaşımlı Hostingde WordPress Optimizasyonu rehberi daha net bir yol gösterir.

php.ini ile .htaccess arasındaki fark nedir?

.htaccess, Apache web sunucusu ayarlarını kontrol eder (yönlendirme ve rewrite gibi), php.ini ise PHP dilinin kendi ayarlarını. upload_max_filesize gibi bazı ayarlar her ikisinde de görülebilir, ancak hostinginiz Nginx ise .htaccess hiç çalışmaz ve yalnızca .user.ini geçerlidir.

Son bir not: Herhangi bir değişiklikten önce mevcut değeri phpinfo ile kaydedin. Site daha sonra bozulursa, yapacağınız ilk şey aynı değerleri geri getirmektir. Referans noktası olmadan, sonraki her değişiklik bir kumardır.