PHP Hataları: Hangi Hata Ne Anlama Geliyor ve Nasıl Okunur?

PHP hataları site sahiplerini korkutur çünkü hepsi aynı görünür: uzun, İngilizce, dosya yolu dolu bir metin. Oysa bu satırlar rastgele değildir. Her hata türü size farklı bir şey söyler ve hangisinin siteyi durdurduğunu, hangisinin sadece gürültü olduğunu ayırt etmek bir günlük iş ile bir haftalık işi birbirinden ayırır.

Bu yazı iki kitleye birden yazıldı: neyin ciddi olduğunu anlamak isteyen site sahibine ve hatayı doğru okumak isteyen geliştiriciye. Rakam vermiyoruz, teşhis anlatıyoruz.

PHP Hata Türleri ve Ciddiyet Sırası

Fatal error — çalışma durur

En ciddisidir. PHP o isteği yürütemez ve durur; ziyaretçi ya beyaz ekran ya da 500 hatası görür. Tipik satır şuna benzer: "Fatal error: Uncaught Error: Call to undefined function ... in /path/file.php on line 42". Buradaki üç bilgi altındır: ne olmadığı (tanımsız fonksiyon), hangi dosya ve hangi satır. Site sahibi olarak bunu bir yere not almanız bile teknik ekibin işini yarı yarıya kısaltır.

En sık üç sebebi: bir eklenti kaldırıldığı hâlde koda referansı kalmış olması, PHP sürümüyle birlikte bir fonksiyonun kaldırılmış olması, ve iki eklentinin aynı isimde fonksiyon tanımlaması.

Warning — çalışır ama bir şey eksik

Sayfa yüklenir ama bir işlem başarısız olmuştur. Örneğin bir dosya okunamamış, bir bağlantı kurulamamıştır. Ziyaretçi çoğu zaman fark etmez, ama arka planda bir iş yapılmıyordur. Formdan mail gitmemesi genellikle burada gizlenir: gönderim başarısız olur, warning günlüğe düşer, ziyaretçiye başarı mesajı gösterilir.

Notice ve Deprecated — bugün değil, yarın kırılır

Notice, "olmayan bir şeye eriştin ama idare ettim" demektir. Deprecated ise "bu kullanım artık eskidi, gelecek sürümde çalışmayacak" uyarısıdır. İkisi de siteyi durdurmaz. Ancak deprecated uyarılarını biriktirmek, bir sonraki PHP yükseltmesinde sitenin toptan çökmesi demektir. Bunları "gürültü" diye kapatmak yaygın ama pahalı bir alışkanlıktır.

Memory exhausted — sınır doldu

"Allowed memory size of X bytes exhausted" satırı, PHP'ye ayrılan belleğin bittiğini söyler. İlk refleks sınırı artırmaktır ve bu çoğu zaman yanlıştır. Doğru soru şudur: bu sayfa neden bu kadar bellek istiyor? Yanıt genellikle ya tek seferde binlerce kaydı belleğe çeken bir sorgu, ya devasa bir görselin işlenmesi, ya da sonsuz döngüye giren bir kancadır. Sınırı artırmak semptomu erteler; asıl sorun büyüyerek geri gelir.

Maximum execution time — süre doldu

Bir işlem izin verilen süreyi aştığında gelir. Toplu içe aktarma, yedekleme ve büyük veri işlemlerinde normaldir; normal bir sayfa görüntülemesinde geliyorsa ciddi bir performans sorunu vardır.

Hata Günlüğü Nasıl Okunur?

Hatanın ziyaretçiye gösterilmesi asla doğru değildir; dosya yolları ve kod yapısı saldırgana bilgi verir. Doğru kurulum, hataların bir günlük dosyasına yazılması ve ziyaretçiye genel bir hata sayfası gösterilmesidir.

Günlüğü okurken sıralama önemlidir:

1. En eski hatadan başlayın, en yenisinden değil. Sonraki hataların çoğu ilk hatanın sonucudur.
2. Yığın izini (stack trace) sondan başa okuyun. En alttaki satır işin nereden başladığını, en üstteki satır nerede patladığını söyler. Suçlu genellikle ikisinin arasındadır.
3. Tekrar sayısına bakın. Saatte binlerce kez tekrarlayan bir warning, tek seferlik bir fatal error'dan daha çok kaynak yakıyor olabilir.
4. Kendi kodunuz mu, üçüncü taraf mı? Dosya yolu eklenti klasörünü gösteriyorsa sorumluluk o eklentinin geliştiricisindedir; tema klasörünü gösteriyorsa iş sizdedir.

PHP Sürüm Yükseltmelerinde Ne Kırılır?

Hosting firmaları PHP sürümünü zaman zaman yükseltir, bazen haber vermeden. Eski kod yeni sürümde çalışmadığında site bir gecede çöker. Sürüm geçişlerinde en sık gördüğümüz kırılmalar:

• Kaldırılan fonksiyonlar. Yıllar önce yaygın olan bazı fonksiyonlar önce "deprecated" ilan edildi, sonra tamamen kaldırıldı. Onları kullanan eski temalar fatal error verir.
• Sıkılaşan tip kuralları. Eskiden sessizce tolere edilen tip uyuşmazlıkları artık hata üretir. Sayı beklenen yere metin gönderen eski kodlar burada patlar.
• Dinamik özellik tanımı. Sınıfta tanımlı olmayan bir özelliğe değer atamak artık uyarı üretiyor; eski eklentilerde bu kalıp çok yaygındır.
• Veritabanı sürücüsü değişiklikleri. Çok eski kodlar artık desteklenmeyen bağlantı yöntemlerini kullanır ve bağlantı hiç kurulamaz.
• Değiştirilen varsayılan ayarlar. Hata gösterimi, oturum ayarları ve karakter kodlaması gibi varsayılanların değişmesi, hiçbir kod değişmeden davranışı değiştirir.

Doğru geçiş yöntemi şudur: sitenin bir kopyası yeni PHP sürümüyle ayrı bir ortamda çalıştırılır, hata günlüğü temizlenir, kritik akışlar (form, ödeme, arama, giriş) tek tek denenir; ancak sonra canlıya geçilir. Bu iş bir gün sürer ve bir haftalık kesintiyi önler.

Hata Mesajı Yokken Teşhis

Bazen ekranda hiçbir şey yoktur — ne hata, ne içerik. Böyle durumlarda sırayla şunlara bakılır: sunucunun kendi hata günlüğü, PHP-FPM havuz günlüğü, web sunucusunun erişim kaydı (isteğin gerçekten geldiğini görmek için) ve veritabanı yavaş sorgu kaydı. Beyaz ekran yazımızda bu sıralamayı adım adım anlattık.

Biz Nasıl Yaklaşıyoruz?

Devraldığımız her projede ilk iş hata günlüğünü okumaktır. Sebebi şu: günlük, sitenin gerçek sağlık raporudur. Sahibinin "her şey yolunda" dediği bir sitede saatte yüzlerce warning birikiyorsa, orada henüz görünmeyen ama yaklaşan bir arıza vardır.

Kendi projelerimizde hata günlüğünü sıfırda tutmayı hedefliyoruz. "Zararsız uyarı" diye biriktirilen satırlar, bir sonraki sürüm yükseltmesinde toplu kırılmaya dönüşüyor. Bakım aboneliğinde hata günlüğü takibi bu yüzden standart kalemdir — arıza çıktığında değil, arıza sinyali verdiğinde müdahale ediyoruz.

Hata Günlüğü Nerede Durur? Katman Katman

"Günlüğe bak" tavsiyesi, günlüğün nerede olduğunu bilmiyorsanız işe yaramaz. Bir istek sırasında birden fazla günlük yazılır ve her biri farklı bir katmanı anlatır:

• Uygulama günlüğü: Sitenin kendi tuttuğu hata kaydı. Genellikle site kök dizininde veya içerik klasöründe durur. PHP hatalarının çoğu buraya düşer.
• PHP işlem havuzu günlüğü: PHP-FPM tarafında tutulur. Bellek aşımı, zaman aşımı ve işlem çökmeleri burada görünür — uygulama günlüğüne hiç yansımayabilir.
• Web sunucusu hata günlüğü: Yapılandırma hataları, izin sorunları ve 500 döndüren isteklerin kaydı.
• Web sunucusu erişim günlüğü: İsteğin gerçekten sunucuya ulaşıp ulaşmadığını gösterir. Ziyaretçi "sayfa açılmıyor" diyorsa ama erişim kaydında istek yoksa sorun sunucudan önce, ağ veya DNS tarafındadır.
• Veritabanı yavaş sorgu günlüğü: Belirli bir sürenin üzerinde çalışan sorguları kaydeder. Yavaşlık şikâyetlerinde ilk bakılacak yerdir.

Doğru katmandan başlamak teşhis süresini belirgin biçimde kısaltır. Yanlış günlüğe saatlerce bakmak, bu işte en sık kaybedilen zamandır.

Hataları Üretime Çıkmadan Yakalamak

Profesyonel yaklaşım, hatayı canlıda görmeyi beklemek değil, çıkmadan yakalamaktır. Bunun üç pratik yolu var:

Kopya ortamda hata gösterimini açık tutmak. Geliştirme ortamında tüm uyarılar görünür olmalı; canlıda ise yalnızca günlüğe yazılmalıdır. Böylece deprecated uyarıları geliştirici tarafından görülür, müşteriye ulaşmaz.

Sürüm yükseltmesini önce kopyada denemek. Yeni PHP sürümünde site açılıyor diye iş bitmez; hata günlüğünde yeni satır olup olmadığına bakmak gerekir. Sessizce çalışan ama uyarı üreten bir site, bir sonraki sürümde çökecek olan sitedir.

Hata sayısını izlemek. Günlük hata sayısını takip etmek, kod kalitesinin en dürüst göstergesidir. Sayı artmaya başladıysa, henüz kimse şikâyet etmemiş olsa bile bir şey bozulmaya başlamıştır. Devraldığımız projelerde ilk yaptığımız iş bu sayacı sıfıra indirmektir.

Bu İşi Biz Yaparsak Ne Kadar Tutar?

Fiyatı tahmin etmenize gerek yok, bize sormanıza da. Sitemizdeki hesaplayıcıda ihtiyacınız olan kalemleri işaretliyorsunuz, toplam anında ekranda çıkıyor. Form doldurmak, teklif beklemek yok.

Fiyatı bir dakikada hesaplayın →