Yoğun bakımda mekanik ventilatörle solutulan bir hastanın takibinde hekimlerin en çok çekindiği teknik tuzaklardan biri "Sessiz Hipoventilasyon"dur (Silent Hypoventilation). Hekim hastanın akciğer kapasitesine göre cihazı ayarlar: "Her nefeste 700 mililitre hava (tidal volüm) verilecek."
Fakat cihazın içindeki fabrika çıkışlı mekanik bir güvenlik subapı (pop-off valve) 400 mililitrenin üzerindeki tüm havayı sessizce, hiçbir alarm çalmadan, tek bir bip sesi dahi çıkarmadan dışarı tahliye etmektedir!
Dışarıdan bakan hemşire cihazın çalıştığını görür, ekranda yeşil ışık yanmaktadır. Ancak hastanın ciğerlerine giden hava yetersizdir. Hasta saatler içinde yavaş yavaş hipoksiye girer, kanda karbondioksit birikir, asidoz başlar ve hasta sessizce bilincini kaybeder. Felaketi korkunç kılan şey, sistemin arıza anında bağırmayıp hiçbir şey olmamış gibi davranmasıdır.
Yazılım mimarisinde ve PHP ekosisteminde de web yöneticilerinin saçını başını yolduran en sinsi, en esrarengiz hata tam olarak bu sessiz tahliye felaketidir: PHP'nin max_input_vars güvenlik sınırının verileri sessizce budaması (Truncation).
Büyük bir e-ticaret sitesinin veya kurumsal holding portalının içerik yöneticisi saatlerdir WordPress paneli üzerinde ter dökmektedir. Sitenin üst kısmında devasa bir "Mega Menü" inşa etmektedir:
Kategoriler, alt kategoriler, marka listeleri, mega açılır menüler...
Menüde tam 90 adet madde vardır. Her bir maddenin başlığı, linki, CSS sınıfı, açılır menü ikonu, yetki seviyesi tek tek girilmiştir.
Yönetici sağ alttaki mavi "Menüyü Kaydet" butonuna basar.
Sayfa yenilenir. Ekranda yeşil bir bildirim çıkar: "Menü başarıyla güncellendi."
Fakat yönetici menü ağacına baktığında şok geçirir:
Menünün ilk 60 maddesi yerli yerindedir; ancak son 30 madde sanki hiç yazılmamış gibi tamamen buharlaşmıştır!
Yönetici "Herhalde internetim koptu" diyerek o 30 maddeyi büyük bir sabırla tekrar tek tek ekler. Tekrar "Kaydet" der. Sayfa yenilenir; son 30 madde yine yok!
Yönetici çıldırır. Bu kez bir varyantlı ürün eklemeyi dener: Bir tişörtün 5 farklı bedeni, 8 farklı rengi ve 3 farklı kumaş tipi vardır. WooCommerce varyantları oluşturur, stokları ve fiyatları girer. "Kaydet"e basar; renklerin yarısı kaybolur!
Hemen hosting firmasına ecel terleri dökerek bilet açılır:
"ACİL! Veritabanınızda kesinlikle bir bozulma var! Sitede menü veya ürün kaydediyorum, sistem son girdiğim 30 veriyi siliyor! Veritabanınız verileri yutuyor, sabahtan beri emeğim çöp oldu! Derhal bu hatayı düzeltin!"
Sistem mühendisi veritabanını inceler; MySQL'de tek bir hata bile yoktur. Disk dolmamıştır, tablolar kilitlenmemiştir.
Peki o son 30 menü maddesi nereye kaybolmuştur?
Cevap, PHP'nin php.ini dosyasının derinliklerindeki tek bir satırda gizlidir:
max_input_vars = 1000
2011 yılında güvenlik araştırmacıları, PHP'nin HTTP POST verilerini işlerken Hash Collision (özet çakışması) saldırılarına maruz kalabildiğini ve küçük bir istekle CPU'nun %100 kilitlenebildiğini keşfetti. PHP geliştiricileri buna bir savunma mekanizması olarak max_input_vars parametresini icat etti.
Bu parametre der ki: "Bir HTML formundan gelen toplam input/select/checkbox değişkeni sayısı 1.000'i aşarsa, sistem güvenliğini korumak için 1.000'den sonrasını kabul etme!"
Ve en acımasız kısım şudur: PHP motoru bu sınırı aştığında ekrana bir hata basmaz! Kullanıcıya "Formun çok büyüktü, kestim" demez! Sadece PHP hata günlüğüne (error_log) sessiz bir uyarı fırlatır:
[26-Feb-2026 16:04:12 UTC] PHP Warning: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.
Ve 1.001'inci değişkenden itibaren gelen tüm verileri sessizce bir kağıt öğütücü gibi çöpe atar!
Kullanıcı zanneder ki "Ben alt tarafı 80 tane menü ekledim, 80 nerede 1.000 nerede?"
İşte gözden kaçan matematiksel tuzak buradadır! WordPress menü yöneticisinde tek bir menü elemanı, form içinde sadece tek bir değişken üretmez. Tek bir menü kutucuğu arka planda şu gizli input alanlarını gönderir:
menu-item-db-id[142]
menu-item-object-id[142]
menu-item-object[142]
menu-item-parent-id[142]
menu-item-position[142]
menu-item-type[142]
menu-item-title[142]
menu-item-url[142]
menu-item-classes[142]
menu-item-target[142]
menu-item-attr-title[142]
menu-item-description[142]
Tek bir menü maddesi tarayıcıdan sunucuya tam 12 ila 15 adet form değişkeni fırlatır!
Basit bir çarpma işlemi:
80 menü maddesi × 14 değişken = Tam 1.120 değişken!
Form "Kaydet" butonuna basıldığı an, ilk 70 menü maddesi (yaklaşık 980 değişken) PHP'nin o 1.000 limitli kapısından geçer. Geriye kalan son 10 menü maddesinin 140 değişkeni ise o mekanik subap tarafından sessizce uzay boşluğuna fırlatılır! Kullanıcı sayfayı yenilediğinde menünün sonunun kesildiğini görür.
Bu gizemli veri kaybını saniyeler içinde ortadan kaldırmak için sunucu yapılandırmasında şu cerrahi dokunuş yapılmalıdır:
php.ini veya cPanel PHP Selector Üzerinden Limiti Artırmak:
Sunucunun php.ini dosyasını açın (veya cPanel > MultiPHP INI Editor sekmesine girin). Değeri kurumsal e-ticaret ve mega menü standartlarına çekin:
max_input_vars = 5000
Eğer siteniz 200'den fazla varyant içeren devasa ürünler barındırıyorsa bu değeri güvenle 10000 seviyesine çıkarabilirsiniz.
.user.ini veya .htaccess ile Yerel Ayar:
Eğer kök php.ini dosyasına erişiminiz yoksa, sitenizin ana dizinindeki .user.ini dosyasına şu satırı yazın:
max_input_vars = 5000
Veya Apache PHP modülü çalışıyorsa .htaccess içine:
php_value max_input_vars 5000
Mega Menü Eklentilerini İncelemek: Menülerinizi yüzlerce ham link olarak WordPress'in yerel menü yöneticisine yığmak yerine, JSON tabanlı modern mega menü eklentileri (Örn: Max Mega Menu) kullanarak form yükünü hafifletmek.
Sessiz hipoventilasyon hastayı nasıl hissettirmeden boğuyorsa, max_input_vars limiti de form verilerini öyle çaktırmadan budar. Bir sistemde hata mesajı çıkmaması, her şeyin yolunda olduğu anlamına gelmez. Mimarinin görünmeyen emniyet subaplarını bilmeyen her geliştirici, kaybolan verilerinin arkasından hayalet hikayeleri anlatmaya mahkûmdur.