php.ini Ayarları ve En Önemli Direktifler

WordPress panelinizde "Yüklemeye çalıştığınız dosya php.ini'de izin verilen boyutu aşıyor" uyarısını gördüyseniz, bir eklenti kurulumu yarıda "Allowed memory size exhausted" hatasıyla patladıysa ya da uzun süren bir içe aktarma işlemi tam bitmeden "Maximum execution time exceeded" diyerek kesildiyse, sorunun kaynağı neredeyse her zaman aynı yerdedir: php.ini. Bu dosya, sunucunuzda çalışan PHP yorumlayıcısının davranışını belirleyen ayar dosyasıdır ve bir web uygulamasının ne kadar bellek kullanabileceğinden, ne büyüklükte dosya kabul edeceğine, bir isteğin kaç saniye çalışabileceğine kadar onlarca kritik davranışı tek başına yönetir.

İyi haber şu ki php.ini'yi anlamak için PHP geliştiricisi olmanıza gerek yok. Aslında yüzlerce direktifin sadece bir avucu gündelik hayatta işinize yarar; geri kalanı çoğu kullanıcı için varsayılan değerinde kalabilir. Bu rehberde önce php.ini'nin ne olduğunu ve neyi etkilediğini netleştireceğiz, sonra en sık ihtiyaç duyacağınız direktifleri tek tek örneklerle açıklayacağız. Ardından paylaşımlı hosting kullanıcılarının SSH ya da kök erişimine ihtiyaç duymadan bu ayarları nasıl değiştirebileceğini, cPanel'in MultiPHP INI Editor aracının hem Temel hem de Editör modunu adım adım göstereceğiz. Amacımız, bir hatayla karşılaştığınızda hangi direktifi kaç yaparsanız sorunun çözüleceğini kestirebilecek düzeye gelmeniz.

php.ini Nedir ve Neyi Etkiler#

php.ini, PHP başlatıldığında okuduğu düz metin yapılandırma dosyasıdır. İçinde anahtar = değer biçiminde yazılmış direktifler bulunur ve her direktif, PHP'nin belirli bir davranışını kontrol eder. Bir istek geldiğinde sunucu PHP'yi çalıştırır, PHP de ilk iş olarak bu dosyadaki ayarları belleğe yükler ve tüm kodu bu sınırlar dahilinde işletir. Yani bir eklentinin ne kadar bellek isteyebileceğini kod değil, php.ini belirler.

Burada karıştırılmaması gereken önemli bir nokta var: php.ini sunucu tarafında, uygulamanızın kodundan tamamen bağımsız çalışır. WordPress, Laravel, Joomla ya da kendi yazdığınız bir PHP betiği fark etmez; hepsi aynı php.ini sınırlarına tabidir. Uygulama içindeki ayarlar (örneğin WordPress'in "maksimum yükleme boyutu") aslında php.ini'den okunan değerlerin yansımasıdır. Dolayısıyla "eklentiden ayarı büyüttüm ama değişmedi" durumunun sebebi, gerçek sınırın php.ini'de olmasıdır.

Bir sunucuda tek bir php.ini olmayabilir. Çoğu paylaşımlı hosting ortamında her PHP sürümünün kendi yapılandırması vardır ve kullanıcı bazında ek dosyalarla (örneğin .user.ini veya cPanel'in ürettiği ayar dosyaları) bu değerler geçersiz kılınabilir. Bu yüzden hangi PHP sürümünü kullandığınızı bilmek önemlidir; farklı sürümlerin ayarları birbirinden ayrıdır. PHP sürümünüzü nasıl seçip yöneteceğinizi merak ediyorsanız PHP sürüm yönetimi rehberimiz konuya detaylı giriyor.

Aktif ayarları görmek için en pratik yol bir phpinfo() sayfasıdır. Dizininize aşağıdaki içerikle küçük bir dosya koyabilirsiniz.

<?php
// info.php — kontrol bittikten sonra bu dosyayı silin
phpinfo();

Bu sayfa hangi php.ini'nin yüklendiğini ("Loaded Configuration File"), her direktifin Local Value (yerel) ve Master Value (ana) değerlerini gösterir. İncelemeniz bittiğinde dosyayı mutlaka silin; sunucu ve PHP yapılandırmanızı dışarıya açık bırakmak güvenlik riskidir.

Bellek ve Yürütme Sınırları#

Günlük hayatta en sık dokunacağınız direktifler, bir isteğin kullanabileceği kaynakları sınırlayanlardır. Bunlar bir uygulamanın yavaş bir sunucuyu tek başına kilitlemesini engellemek için vardır; ama fazla düşük ayarlanırlarsa meşru işlemler de yarıda kesilir.

memory_limit, tek bir PHP betiğinin ayırabileceği en fazla belleği belirler. Ağır temalar, sayfa oluşturucular (page builder) ve çok sayıda eklenti çalıştıran WordPress kurulumları bu sınıra kolayca dayanır. "Allowed memory size of X bytes exhausted" hatası doğrudan bu direktifi işaret eder. Küçük siteler için 128M çoğunlukla yeter; WooCommerce veya karmaşık kurumsal siteler için 256M ya da 512M mantıklıdır.

max_execution_time, bir betiğin çalışabileceği azami süredir (saniye). Büyük veri içe aktarımları, yedek alma, toplu görsel işleme gibi uzun işlemler bu sınıra takılır ve "Maximum execution time exceeded" hatası verir. Varsayılan genelde 30 saniyedir; ağır bakım işlemleri için geçici olarak 120 veya 300 yapabilirsiniz. Ancak bunu kalıcı olarak çok yükseltmek, takılan bir betiğin kaynakları uzun süre işgal etmesine yol açar; ölçülü olun.

max_input_time, PHP'nin form verilerini ve yüklenen dosyaları ayrıştırmak (parse) için bekleyeceği süredir. Büyük dosya yüklemelerinde max_execution_time yeterli olsa bile bu değer düşükse yükleme başlamadan zaman aşımına uğrayabilir.

Aşağıdaki tablo, tipik senaryolara göre makul başlangıç değerleri sunar.

İni dosyasında bu ayarlar şöyle görünür.

memory_limit = 256M
max_execution_time = 120
max_input_time = 120

Değerlerdeki M megabayt, G gigabayt anlamına gelir. memory_limit = -1 sınırsız demektir; paylaşımlı ortamlarda bunu kullanmaktan kaçının, çünkü hatalı bir döngü tüm belleği tüketebilir.

Dosya Yükleme Boyutu Ayarları#

Medya kütüphanesine bir video ekleyemiyorsanız, bir tema/eklenti zip dosyasını yükleyemiyorsanız ya da bir yedeği geri yükleyemiyorsanız sorun büyük olasılıkla yükleme boyutu direktiflerindedir. Burada üç direktif birlikte çalışır ve aralarındaki ilişkiyi bilmek çok önemlidir.

upload_max_filesize, tek bir yüklenen dosyanın azami boyutudur. post_max_size, tüm POST isteğinin (dosya + form alanları + diğer veriler) toplam azami boyutudur. Kritik kural şudur: post_max_size her zaman upload_max_filesize değerine eşit ya da ondan büyük olmalıdır. Çünkü bir dosya, kendisini saran POST isteğinin içinde gönderilir; POST sınırı daha küçükse dosya sınırını yükseltmeniz hiçbir işe yaramaz.

Pratik bir güvenlik payı için post_max_size değerini upload_max_filesize'ın biraz üzerinde tutmak iyi bir alışkanlıktır. Örneğin 64 MB'lık dosyalara izin vermek istiyorsanız:

upload_max_filesize = 64M
post_max_size = 68M
max_file_uploads = 20

max_file_uploads, tek bir istekte kaç dosyanın aynı anda yüklenebileceğini sınırlar; galeriye toplu görsel yüklerken bu sayıya takılabilirsiniz. Ayrıca dikkat: yükleme boyutunu büyütürken çoğu zaman memory_limit ve max_execution_time değerlerini de birlikte artırmanız gerekir, çünkü büyük dosyanın işlenmesi hem bellek hem de zaman ister. Üç ayarı beraber düşünmek, "boyutu büyüttüm ama hâlâ hata alıyorum" tuzağından sizi kurtarır.

WordPress'te medya kütüphanesindeki "Maksimum yükleme boyutu" ifadesi doğrudan upload_max_filesize ile post_max_size'ın küçük olanını yansıtır. WordPress odaklı bir kurulum işletiyorsanız bu ayarların önden doğru yapılandırıldığı WordPress hosting paketleri bu tür uğraşları en aza indirir.

Form ve Girdi Sınırları#

Görece az bilinen ama özellikle büyük menülere, geniş ürün seçeneklerine ya da kapsamlı ayar sayfalarına sahip sitelerde başınızı ağrıtan bir direktif max_input_vars'tır. Bu değer, PHP'nin tek bir istekte kabul edeceği azami girdi değişkeni sayısını belirler (GET, POST ve çerez alanlarının toplamı).

Sorun sinsidir çünkü genellikle görünür bir hata vermez. Bir WooCommerce ürününü onlarca varyasyonla kaydedersiniz, sayfa başarıyla yenilenir ama son eklediğiniz varyasyonlar sessizce kaybolur. Ya da devasa bir menüyü düzenlersiniz, bir kısmı kaydedilmez. Bunun sebebi PHP'nin sınırı aşan girdileri sessizce atmasıdır. Varsayılan 1000'dir; büyük yapılandırmalar için bunu artırmak gerekir.

max_input_vars = 5000

Buna yakından ilişkili bir direktif max_input_nesting_level'dır; çok derin iç içe dizi yapılarını işleyen formlarda nadiren gerekir, çoğu kullanıcı varsayılanı (64) değiştirmez. Bu tür "sessiz veri kaybı" sorunlarını teşhis ederken önce max_input_vars'a bakın; en çok bu değer suçludur.

Aşağıdaki tablo, girdi sınırlarını hızlı bir referans olarak özetler.

Hata Görüntüleme ve Kayıt Direktifleri#

php.ini'nin en çok yanlış kullanılan bölümü hata yönetimidir ve doğru ayarlanması hem güvenlik hem de teşhis açısından kritiktir. Buradaki temel ayrım şudur: hataları ekranda ziyaretçiye göstermek (display) ile hataları sessizce bir dosyaya kaydetmek (log) tamamen farklı şeylerdir.

display_errors, PHP hatalarının doğrudan tarayıcıya basılıp basılmayacağını belirler. Canlı (production) bir sitede bu kesinlikle Off olmalıdır. Aksi halde bir hata mesajı, dosya yollarınızı, veritabanı yapınızı ve bazen hassas bilgileri ziyaretçiye ve saldırganlara açık eder. error_reporting ise hangi hata seviyelerinin dikkate alınacağını belirler; geliştirme sırasında E_ALL her şeyi gösterirken, canlıda uyarıları bastırmak için E_ALL & ~E_DEPRECATED & ~E_NOTICE gibi bir değer tercih edilebilir.

Hataları görmezden gelmek yerine kaydetmek istersiniz; işte bu yüzden log_errors devrede olmalıdır. error_log ise hata kayıtlarının yazılacağı dosyanın yolunu belirtir. Böylece hatalar ziyaretçiye görünmeden bir dosyaya düşer ve siz sorun çıktığında oraya bakarsınız.

Canlı bir sitede önerilen güvenli yapılandırma şöyledir.

display_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE
error_log = /home/kullanici/logs/php_errors.log

Geliştirme veya hata ayıklama sırasında ise geçici olarak display_errors = On ve error_reporting = E_ALL yaparak her uyarıyı ekranda görebilirsiniz; ancak işiniz bitince mutlaka canlı yapılandırmaya geri dönün. Bir sorunu araştırırken kayıt dosyasına bakmak, körlemesine tahmin etmekten çok daha hızlıdır. Sunucunuzun bakımını bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu tür log takibini ve yapılandırmayı sizin adınıza üstlenir.

cPanel MultiPHP INI Editor ile Düzenleme — Temel Mod#

Paylaşımlı hostingte SSH ya da kök (root) erişiminiz genellikle olmaz; dolayısıyla ana php.ini'yi doğrudan düzenleyemezsiniz. İşte cPanel'in MultiPHP INI Editor aracı tam da bunun için vardır: en sık kullanılan direktifleri, sunucunun ayarlarını bozma riski olmadan hesap düzeyinde değiştirmenizi sağlar. cPanel arayüzüne yeni başladıysanız cPanel nedir rehberimiz genel yerleşimi tanıtır.

Temel mod, sürgü ve açılır menülerle en yaygın direktifleri sunan güvenli seçenektir. Adımlar şöyledir:

1. cPanel'e giriş yapın ve arama kutusuna "MultiPHP" yazarak MultiPHP INI Editor'ü açın.
2. Üstteki Configure PHP INI basic settings (Temel) sekmesinin seçili olduğundan emin olun.
3. Select a location açılır menüsünden ayarı uygulamak istediğiniz alan adını ya da dizini seçin. Birden fazla siteniz varsa doğru olanı seçmek önemlidir.
4. Karşınıza allow_url_fopen, display_errors, max_execution_time, max_input_time, max_input_vars, memory_limit, post_max_size, upload_max_filesize, session.save_path, zlib.output_compression gibi en sık kullanılan direktifler gelir.
5. Değiştirmek istediğiniz direktifin karşısındaki değeri güncelleyin (örneğin memory_limit için 128M yerine 256M yazın veya seçin).
6. Sayfanın altındaki Apply düğmesine basın. Değişiklik anında etkinleşir; sunucuyu yeniden başlatmanıza gerek yoktur.

Temel modun en büyük avantajı, yalnızca güvenle değiştirilebilecek direktifleri göstermesidir; yanlışlıkla kritik bir sunucu ayarını bozmanız pek mümkün değildir. Değişikliği doğrulamak için az önce bahsettiğimiz phpinfo() sayfasına bakabilir ya da doğrudan uygulamanızda (örneğin WordPress'in "Site Sağlığı" bölümünde) yeni değeri görebilirsiniz.

Bir noktaya dikkat edin: bu ayarlar seçtiğiniz PHP sürümüne bağlıdır. PHP sürümünüzü daha sonra değiştirirseniz, INI Editor ayarlarını yeni sürüm için tekrar gözden geçirmeniz gerekebilir.

cPanel MultiPHP INI Editor — Editör Modu#

Temel modda göremediğiniz bir direktifi değiştirmeniz gerekiyorsa ya da birden fazla ayarı topluca girmek istiyorsanız Editor (Editör) modunu kullanırsınız. Bu mod, hesabınıza özel bir INI dosyasını doğrudan metin olarak düzenlemenize izin verir; yani Temel modun sunmadığı herhangi bir direktifi elle ekleyebilirsiniz.

Adımlar şu şekildedir:

1. MultiPHP INI Editor sayfasında üstteki Editor Mode (Editör) sekmesine geçin.
2. Select a location menüsünden düzenlemek istediğiniz alan adını seçin.
3. Açılan metin kutusuna anahtar = değer biçiminde direktiflerinizi yazın. Her direktif ayrı bir satırda olmalıdır.
4. Save düğmesine basın.

Örneğin ağır bir WooCommerce içe aktarımı için birden çok ayarı birlikte tanımlamak isterseniz metin kutusuna şunları yazabilirsiniz.

memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 128M
post_max_size = 132M
max_input_vars = 10000

Editör modunun gücü, esnekliğinde olduğu kadar riskinde de yatar. Temel modun aksine burada geçersiz bir sözdizimi yazarsanız (örneğin yanlış bir birim ya da tanınmayan bir direktif) ayarlar beklenmedik davranabilir. Bu yüzden yalnızca gerçekten ihtiyaç duyduğunuz direktifleri ekleyin, değerleri dikkatle yazın ve her değişiklikten sonra phpinfo() ile sonucu doğrulayın. Bir şeyler ters giderse, eklediğiniz satırları silip Save yaparak varsayılana dönebilirsiniz.

Bir ipucu: upload_max_filesize ve post_max_size arasındaki "POST büyük olmalı" kuralını burada da unutmayın. Editör modunda ikisini birlikte, POST'u biraz daha büyük tutarak yazmak en sağlıklı yöntemdir. Kritik değişikliklerden önce sitenizin bir yedeğini almak da her zaman iyi bir alışkanlıktır; düzenli yedekleme çözümümüz bu güvenlik ağını otomatikleştirir.

Değişiklikleri Doğrulama ve Sık Yapılan Hatalar#

Bir php.ini değişikliğinin gerçekten etkili olup olmadığını doğrulamak, körlemesine güvenmekten çok daha sağlıklıdır. En kesin yol yine phpinfo() çıktısıdır: ilgili direktifin Local Value sütununu kontrol edin. Uygulama tarafında da doğrulama yapabilirsiniz; örneğin WordPress'te Araçlar → Site Sağlığı → Bilgi → Sunucu bölümü PHP bellek sınırını ve yükleme boyutunu listeler.

Uygulamada en sık karşılaşılan tökezlemeleri bilmek zaman kazandırır:

• Yanlış konumu seçmek. MultiPHP INI Editor'de birden fazla alan adınız varsa, ayarı yanlış siteye uygulamış olabilirsiniz. "Location" seçimini iki kez kontrol edin.
• post_max_size'ı unutmak. Yalnızca upload_max_filesize'ı büyütüp POST sınırını olduğu yerde bırakmak, en yaygın "yükleyemiyorum" sebebidir.
• Bellek ve süreyi birlikte artırmamak. Büyük dosyaları kabul ediyor ama işleyemiyorsanız, memory_limit ve max_execution_time değerlerini de büyütmeniz gerekir.
• Yanlış PHP sürümünde düzenleme. Sitenizin çalıştığı sürümden farklı bir sürümün ayarlarını değiştirdiyseniz hiçbir şey değişmiş gibi görünmez.
• Uygulama önbelleği. Bazı sunucularda değişikliğin görünmesi için PHP-FPM önbelleğinin dönmesi birkaç saniye alabilir; hemen görünmezse kısa bir süre bekleyip tekrar bakın.

Bu adımları alışkanlık hâline getirdiğinizde, bir hata mesajıyla karşılaştığınızda paniklemek yerine "bu hangi direktif?" diye düşünüp doğrudan çözüme gidersiniz.

Sıkça Sorulan Sorular#

memory_limit değerini ne kadar yükseltmeliyim?#

İhtiyacınıza göre kademeli ilerleyin. Basit bir tanıtım sitesi ya da blog için 128M çoğu zaman yeterlidir. WooCommerce, çok sayıda eklenti veya ağır sayfa oluşturucular kullanıyorsanız 256M mantıklı bir başlangıçtır; hâlâ bellek tükenme hatası alıyorsanız 512M deneyin. Değeri gereksiz yere çok yüksek tutmak paylaşımlı ortamda önerilmez, çünkü hatalı bir betik tüm belleği işgal edebilir. En doğru yaklaşım, hatayı çözen en düşük değerde kalmaktır.

upload_max_filesize ile post_max_size arasındaki fark nedir?#

upload_max_filesize tek bir yüklenen dosyanın azami boyutunu, post_max_size ise tüm form gönderiminin (dosya artı diğer alanlar) toplam boyutunu belirler. Bir dosya her zaman bir POST isteğinin içinde taşındığı için post_max_size her zaman upload_max_filesize'a eşit ya da ondan büyük olmalıdır. Aksi halde dosya sınırını yükseltmeniz işe yaramaz. Pratikte POST değerini dosya değerinden birkaç megabayt büyük tutmak güvenli bir alışkanlıktır.

Değişiklik yapmama rağmen ayar güncellenmedi, neden?#

Bunun birkaç yaygın sebebi vardır. En sık görüleni, düzenlemeyi sitenizin gerçekte kullandığı PHP sürümünden farklı bir sürüm için yapmış olmanızdır. İkinci ihtimal, MultiPHP INI Editor'de yanlış alan adını seçmenizdir. Üçüncüsü, ayarın bir üst yapılandırma (örneğin sunucu düzeyinde bir kilit) tarafından geçersiz kılınmasıdır. Önce phpinfo() çıktısına bakıp hangi dosyanın yüklendiğini ve direktifin gerçek değerini görün; çoğu durumda sorun bu adımda ortaya çıkar.

Canlı sitede display_errors açık kalırsa ne olur?#

Bu ciddi bir güvenlik ve itibar sorunudur. display_errors = On olduğunda PHP hataları doğrudan ziyaretçinin tarayıcısına basılır; bu mesajlar dosya yollarınızı, veritabanı ayrıntılarını ve bazen hassas verileri açığa çıkarabilir, ayrıca sitenizin profesyonelliğini zedeler. Canlı ortamda mutlaka display_errors = Off ve log_errors = On kullanın; hataları ekranda göstermek yerine bir kayıt dosyasına yazdırın. Yalnızca aktif olarak hata ayıklarken geçici olarak açın ve işiniz bitince kapatın.

php.ini değişikliğinden sonra sunucuyu yeniden başlatmam gerekir mi?#

Paylaşımlı hostingte cPanel MultiPHP INI Editor üzerinden yaptığınız değişiklikler genellikle anında ya da birkaç saniye içinde etkinleşir; sunucuyu yeniden başlatmanıza gerek yoktur. Bazı yapılandırmalarda PHP-FPM önbelleğinin dönmesi kısa bir gecikmeye yol açabilir, bu durumda birkaç dakika beklemek yeterlidir. Kendi sunucunuzu (VDS/VPS ya da özel sunucu) yönetiyorsanız ve ana php.ini'yi elle düzenlediyseniz, değişikliklerin geçerli olması için PHP-FPM ya da web sunucusu servisini yeniden başlatmanız gerekir.

Kapanış#

php.ini korkutucu görünen ama aslında bir avuç kritik direktife indirgenebilen bir konudur. Bellek ve süre sınırlarını (memory_limit, max_execution_time), dosya yükleme üçlüsünü (upload_max_filesize, post_max_size, max_file_uploads), sessiz veri kaybının baş sorumlusu max_input_vars'ı ve hata direktiflerini (display_errors, log_errors) tanıdığınızda, karşılaştığınız hataların büyük çoğunluğunu birkaç dakikada çözebilirsiniz. cPanel'in MultiPHP INI Editor aracı da bu değişiklikleri kök erişimine gerek kalmadan, güvenle yapmanızı sağlar.

Doğru yapılandırılmış bir PHP ortamı, hızlı ve stabil bir sitenin görünmez temelidir. Clou.TR'de sunduğumuz web hosting ve WordPress hosting paketleri, bu direktiflerin çoğu senaryo için önden makul değerlerle geldiği bir altyapı sunar; daha fazla kaynağa ihtiyacınız varsa sanal sunucu ve VDS seçeneklerimizle tam kontrolü elinize alabilirsiniz. Yapılandırma ve bakımı uzmanlara bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer. Sitenizin ihtiyaçlarını konuşmak için bize ulaşın; doğru altyapıyı birlikte kuralım.