WordPress Kritik Hata: "Bu Web Sitesinde Kritik Bir Hata Oluştu" Nasıl Çözülür?

Adım 1: Kurtarma Modu Bağlantısıyla Panele Girmek

Panele erişim yoksa ilk ve en zahmetsiz yol, yönetici e-postasındaki kurtarma modu bağlantısını kullanmaktır. Bu modda hataya yol açan eklenti veya tema yalnızca bağlantıyı kullanan kişinin tarayıcısı için duraklatılır; site ziyaretçiler için hata vermeye devam eder.

1. E-postadaki bağlantıya tıklanır ve yönetici hesabıyla giriş yapılır.
2. Panelin üst kısmındaki uyarıdan sorunlu eklenti ya da tema görülür; Eklentiler ekranında ilgili eklenti duraklatılmış olarak işaretlenir.
3. Sorunlu eklenti devre dışı bırakılır; güncel bir sürümü varsa güncellenir, yoksa yerine uyumlu bir alternatif aranır.
4. Yönetici çubuğundaki kurtarma modundan çıkış düğmesiyle mod kapatılır.
5. Site, oturum açılmamış gizli bir tarayıcı penceresinden kontrol edilir.

Duraklatma yalnızca kurtarma modundaki oturum için geçerlidir ve sitenin geneline etki etmez. Eklenti devre dışı bırakılmadan moddan çıkılırsa site herkes için hata vermeyi sürdürür. Gizli pencerede yapılan kontrol, WordPress kritik hata ekranının ziyaretçiler için de kalktığını görmenin en kolay yoludur.

Adım 2: WP_DEBUG_LOG ile Hata Günlüğünü Okumak

E-posta gelmediyse ya da hatanın kaynağı net değilse hata günlüğü, sorunun hangi dosya ve satırdan çıktığını gösteren en güvenilir kaynaktır. WordPress’in hata ayıklama belgesi, günlüğü açmak için wp-config.php dosyasına şu satırların eklenmesini önerir:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Bu ayarla hatalar ekranda gösterilmez, wp-content klasöründeki debug.log dosyasına yazılır. Site bir kez daha açılıp hata tetiklendiğinde dosyanın son satırlarında “PHP Fatal error” ile başlayan kayıt ve hatayı üreten dosyanın yolu görülür. Yolda wp-content/plugins altında bir klasör adı geçiyorsa sorun o eklentidedir, wp-content/themes geçiyorsa temadadır.

WordPress belgeleri hata ayıklama araçlarının canlı sitelerde değil, yerel ve hazırlık kurulumlarında kullanılmasını önerir. Site Sağlığı ekranı da hataların herkese açık olabilecek bir dosyaya yazıldığı konusunda ayrıca uyarı verir. Sorun bulunduktan sonra bu satırlar kaldırılır ya da false yapılır, debug.log dosyası da sunucudan silinir.

Adım 3: Panele Girilemiyorsa Eklentileri FTP ile Devre Dışı Bırakmak

Kurtarma bağlantısı yoksa eklentiler, FTP ya da hosting panelindeki dosya yöneticisiyle eklenti klasörünün adı değiştirilerek topluca devre dışı bırakılabilir. WordPress adı değişen klasördeki eklentileri bulamadığı için yüklemez; panele erişim olmadığında resmi belgelerde önerilen yöntem de budur.

1. FTP istemcisiyle ya da hosting panelinin dosya yöneticisiyle sitenin kök dizinine girilir, ardından wp-content klasörü açılır.
2. plugins klasörünün adı plugins_old olarak değiştirilir.
3. Site yenilenir; açılıyorsa sorun eklentilerden birindedir.
4. Klasörün adı yeniden plugins yapılır; eklentiler panelde devre dışı görünür ve tek tek etkinleştirilir.
5. Her etkinleştirmeden sonra site kontrol edilir; hatayı geri getiren eklenti kapalı bırakılır.

Hata günlüğü sorunlu eklentiyi zaten gösteriyorsa bütün klasör yerine yalnızca o eklentinin klasörünü yeniden adlandırmak yeterlidir. Bu yöntem eklenti dosyalarını silmez ve geri alınabilir; çoğu eklentide ayarlar veritabanında durduğu için eklenti yeniden etkinleştirildiğinde geri gelir.

Adım 4: Tema, PHP Sürümü ve Bellek Limitini Kontrol Etmek

Eklentiler devre dışıyken WordPress kritik hata ekranı sürüyorsa sıradaki şüpheliler aktif tema, sunucudaki PHP sürümü ve WordPress’e ayrılan bellek miktarıdır. Bu üç kontrol, hata günlüğündeki mesajla birlikte değerlendirildiğinde sorunu büyük ölçüde daraltır.

Varsayılan temaya geçiş

Panele erişim varsa Görünüm > Temalar ekranından Twenty serisinden bir varsayılan temaya geçilir; erişim yoksa wp-content/themes klasöründe aktif temanın klasör adı değiştirilir. Site varsayılan temayla açılıyorsa sorun temada ya da alt temanın functions.php dosyasına eklenen kodda aranır. Sunucuda en az bir varsayılan temanın yüklü durması bu adımı kolaylaştırır.

PHP sürümü

WordPress’in sunucu gereksinimleri sayfası PHP 8.3 veya üstünü önerir; WordPress PHP 7.4 ve üzeri sürümlerle de çalışır, ancak bu eski sürümlerin resmi destek süresi dolmuştur. Hosting firması PHP sürümünü yükselttikten sonra hata başladıysa eski bir eklenti ya da tema yeni sürümle uyumsuz olabilir. Geçici çözüm hosting panelinden önceki sürüme dönmek, kalıcı çözüm ise uyumsuz bileşeni güncellemek ya da değiştirmektir.

Bellek limiti

Hata günlüğünde “Allowed memory size exhausted” ifadesi geçiyorsa PHP’ye ayrılan bellek yetmiyor demektir. WordPress varsayılan olarak tek sitelerde belleği 40 MB’a, çoklu site kurulumlarında 64 MB’a çıkarmayı dener; wp-config.php belgesine göre limit şu satırla artırılabilir:

define( 'WP_MEMORY_LIMIT', '96M' );

Satır, wp-config.php içinde wp-settings.php dosyasının çağrıldığı satırdan önce eklenir. Bazı hosting firmaları bu artışa izin vermez; o durumda limitin hosting tarafında yükseltilmesi gerekir. Paylaşımlı pakette bellek sık sık yetmiyorsa paket seçimi de gözden geçirilir; seçenekler hosting fiyatları sayfasında yer alır.

Adım 5: Hiçbiri İşe Yaramazsa Yedekten Geri Dönmek

Kaynak bulunamıyorsa ya da dosyalar zarar görmüşse, WordPress kritik hata durumundan en güvenli çıkış hatadan önce alınmış temiz bir yedeğe dönmektir. WordPress’in yedekleme belgesi, sitenin tam olarak geri yüklenebilmesi için hem dosyaların hem de veritabanının yedeğinin gerektiğini vurgular.

• Hosting yedekleri: Hosting panelindeki otomatik yedeklerden tarih seçilerek dosyalar ve veritabanı birlikte geri yüklenir.
• Eklentiyle alınan yedekler: Uzak depoya (bulut, ayrı sunucu) gönderilmiş kopyalar, sunucudaki dosyalar bozulduğunda da erişilebilir kalır.
• Yedeğin tarihi: Hatanın başladığı andan sonra alınmış bir yedeğe dönmek sorunu geri getirir; hatadan önceki son temiz kopya seçilir.
• Yeni içerik kaybı: Yedek tarihinden sonra eklenen yazılar, siparişler ve form kayıtları geri dönüşte kaybolabilir.

E-ticaret sitelerinde yedekten dönmeden önce son siparişlerin dışa aktarılması önerilir. Çekirdek dosyalarının bozulduğu durumlarda wp-admin ve wp-includes klasörlerinin temiz bir WordPress paketinden yeniden yüklenmesi de resmi hata belgesinde geçen bir yöntemdir.

Sık Yapılan Hatalar: Rastgele Müdahale mi, Sistemli Teşhis mi?

WordPress kritik hatayı uzatan şey çoğu zaman hatanın kendisi değil, kaynağı bulunmadan yapılan aceleci müdahalelerdir. Genel uygulamalarla sistemli teşhis yaklaşımı arasındaki fark aşağıdaki tabloda yan yana durur:

Bir başka yaygın hata, çekirdek dosyalarına ya da ana temanın dosyalarına doğrudan kod eklemektir. Bu değişiklikler ilk güncellemede silinir ya da yeni bir çakışmaya yol açar; özel kodun alt temada veya ayrı bir eklentide tutulması daha sağlıklıdır.

WordPress Kritik Hata İçin Ne Zaman Uzmana Başvurulmalı?

Panel ve dosya erişimi yoksa, hata günlüğü anlaşılmıyorsa ya da hata kötü amaçlı kod şüphesi taşıyorsa uzman desteği zaman ve veri kaybı riskini azaltır. Kendi başına müdahalenin riskli hale geldiği durumlar şunlardır:

• FTP, hosting paneli ya da yedek erişim bilgileri bilinmiyorsa
• Hata bir e-ticaret sitesinde sipariş ve ödeme akışını durdurduysa
• Günlükte tanınmayan dosya adları, okunamayan şifreli kod parçaları ya da beklenmeyen yönlendirmeler görülüyorsa
• Eklenti, tema, PHP ve bellek adımlarından sonra hata sürüyorsa
• Sorun özel yazılmış bir tema ya da eklentinin kodundaysa

Hack kaynaklı hatalarda yalnızca eklentiyi kapatmak yetmez; arka kapı kalırsa sorun kısa sürede geri döner. Bu tür durumlar hacklenmiş WordPress siteyi kurtarma hizmetinin kapsamına girer. Hack izi taşımayan diğer arızalarda izlediğimiz yol WordPress problem çözme sayfasında anlatılır.

Tekrarlanmaması İçin Bakım Düzeni ve Hazırlık Ortamı

WordPress kritik hatanın tekrar yaşanma riskini en çok azaltan iki alışkanlık, güncellemeden önce yedek almak ve güncellemeleri önce hazırlık (staging) ortamında denemektir. WordPress yedekleme belgesi, veritabanının düzenli olarak ve her yükseltmeden önce yedeklenmesini önerir; küçük siteler için haftalık, yoğun siteler için günlük yedek sıklığından söz eder.

• Güncelleme öncesi dosya ve veritabanını kapsayan tam yedek, farklı konumlarda birden fazla kopya
• Güncellemelerin toplu değil gruplar halinde yapılması, her gruptan sonra ön yüz, form ve ödeme adımının kontrolü
• Site Sağlığı ekranının düzenli izlenmesi; eski PHP sürümü ve bekleyen güncelleme uyarılarının ertelenmemesi
• Kullanılmayan eklenti ve temaların kaldırılması
• Kurtarma e-postası bu adrese geldiği için yönetici e-posta adresinin güncel ve erişilebilir tutulması

Hazırlık ortamı, canlı sitenin ziyaretçilere kapalı bir kopyasıdır. WordPress 5.5 ile gelen ortam türleri özelliği, WP_ENVIRONMENT_TYPE sabitiyle bir kurulumun “staging” olarak işaretlenmesini ve eklentilerin bu bilgiye göre davranabilmesini sağlar. Güncelleme önce bu kopyada denenir, sorun çıkmazsa canlıya alınır.

Onur Freelance WordPress bakımında süreç nasıl işler?

2019’dan beri Maltepe merkezli çalışan Onur Freelance olarak WordPress bakımında önce yedek, sonra test, en son canlı güncelleme sırasını izliyoruz. Kritik hata çıktığında da aynı sıra geçerlidir: siteye dokunmadan önce mevcut durumun kopyası alınır, ardından hata günlüğüyle kaynağa inilir.

Yıllık WordPress bakım ve güncelleme hizmetinde çekirdek, eklenti ve tema güncellemeleri kontrollü yapılır; güncelleme sonrası temel sayfalar, iletişim formları ve varsa ödeme adımı kontrol edilir. Yapılan her işlem kayıt altına alınır, böylece bir sorun çıktığında hangi değişiklikten sonra başladığı görülebilir. Bakım ücreti sitenin büyüklüğüne ve kapsamına göre aylık 500–2.000 TL arasındadır; kapsam ön görüşmede netleşir.

Her arızanın aynı sürede çözüleceğini söylemiyoruz; süre, hatanın kaynağına ve erişim bilgilerinin hazır olup olmadığına göre değişir. Kurulum, taşıma ve hız gibi diğer işler WordPress hizmetleri sayfasında listelenir.