Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Kritik hata ekranı kök nedeni söylemez; yalnız WordPress’in çalışmayı durduran bir PHP hatası yakaladığını bildirir. Doğru çözüm, aynı isteğin zaman damgasını debug.log veya PHP-FPM/Apache logundaki dosya ve satır bilgisiyle eşleştirip yalnız hatalı bileşeni geri almak, güncellemek ya da devre dışı bırakmaktır.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
wp core version
php -v
wp plugin status
wp theme status
tail -n 120 wp-content/debug.log
wp core verify-checksumsWordPress’in fatal error handler’ı, eklenti veya tema kodu, uyumsuz PHP sürümü, bellek tükenmesi, eksik sınıf/fonksiyon, bozuk çekirdek dosyası ya da özel kod hatası nedeniyle çalışabilir. Ekrandaki genel mesaj yerine `Uncaught Error`, `Allowed memory size exhausted`, `Parse error` veya `TypeError` ile başlayan son fatal kaydın dosya yolu ve satır numarası esas alınmalıdır.
Yönetici e-postasına gelen bağlantı, hatalı eklenti veya temayı o oturum için duraklatıp panele erişim sağlayabilir. Bağlantı yoksa e-posta teslimatı ve yönetici adresi ayrıca kontrol edilmelidir.
WordPress logu uygulama bağlamını, PHP-FPM/Apache/LiteSpeed logu ise WordPress başlamadan önceki fatal hataları gösterebilir. Aynı zaman aralığı birlikte incelenmelidir.
Logdaki yol `wp-content/plugins`, `themes`, `mu-plugins` veya özel snippet dizinini gösteriyorsa önce yalnız ilgili bileşen üzerinde işlem yapılmalıdır.
Hata güncelleme veya PHP sürüm değişiminden sonra başladıysa uyumluluk analizinin temelini oluşturur. WP-CLI WordPress’i yükleyemiyorsa `--skip-plugins --skip-themes` seçenekleri yardımcı olabilir.
wp core version
php -v
wp --infoCanlı sitede hata ayrıntılarını ziyaretçiye göstermeden `wp-content/debug.log` dosyasına yazın. Sabitleri wp-config.php içinde WordPress’in son düzenleme satırından önce ekleyin ve iş bitince gözden geçirin.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Tarayıcıda hatayı yeniden üretip hemen ardından WordPress ve sunucu loglarını okuyun. Dosya yolu, satır, hata sınıfı ve stack trace başlangıcını kaydedin.
tail -n 160 wp-content/debug.log
tail -n 160 /var/log/php-fpm/error.log
tail -n 160 /usr/local/apache/logs/error_logChecksum kontrolü çekirdek dosyaları WordPress.org değerleriyle karşılaştırır; wp-content içindeki özel dosyaları doğrulamaz. Dil ve sürüm parametreleri kurulumla eşleşmelidir.
wp core verify-checksums
wp core verify-checksums --include-rootVeritabanı ile wp-content ve wp-config.php dosyalarını aynı yedek setinde koruyun. Yedek arşivini web kökünün dışında tutun; mümkünse son çalışan kod sürümünü veya deployment paketini ayrıca saklayın.
Yönetici e-postasındaki kurtarma bağlantısıyla panele girildiğinde WordPress hatalı uzantıyı işaretleyebilir. Bu ekranı kanıt olarak kullanın; eklentiyi silmeden önce sürüm, değişiklik zamanı ve hata kaydını not edin.
Yol bir eklentiye, aktif temaya, mu-plugin’e, özel snippet’e, WordPress çekirdeğine veya vendor paketine mi ait belirleyin. Belirsizse stack trace içindeki ilk proje dosyasını inceleyin.
WP-CLI çalışıyorsa ilgili eklentiyi slug ile devre dışı bırakın. Yönetim ve WP-CLI yoksa yalnız logda görülen eklenti klasörünü geçici yeniden adlandırın. Tüm eklentileri topluca kapatmak son seçenek olmalıdır.
PHP sürümü, eklenti/tema sürümü ve WordPress sürümünün destek matrisini kontrol edin. Son güncellemeyi geri alın, desteklenen sürüme güncelleyin veya hatalı özel kodu staging ortamında düzeltip yeniden yayınlayın.
Önbelleği temizledikten sonra hatayı üreten URL’yi, wp-admin girişini, form/ödeme/AJAX işlemini ve cron görevini tekrar çalıştırın. Yeni fatal kayıt oluşmadığını doğrulayın.
WP_DEBUG ayarlarını politika gereği eski haline getirin, log erişimini kısıtlayın ve kök neden, yapılan değişiklik, geri dönüş noktası ve test sonucunu kayıt altına alın.
İstek PHP bellek limitini tüketmiştir. Yalnız limiti yükseltmek yerine hangi eklenti, sorgu veya işlemde tüketimin arttığını log/profil ile belirleyin.
Eksik dosya, yanlış yükleme sırası, başarısız Composer autoload, yarım güncelleme veya uyumsuz sürüm olabilir. Stack trace içindeki ilk proje dosyasını ve deployment bütünlüğünü kontrol edin.
PHP dosyasında sözdizimi hatası vardır; çoğunlukla son manuel düzenleme veya eksik dağıtım dosyasıdır. İlgili dosyayı `php -l` ile kontrol edip çalışan sürümle karşılaştırın.
Fonksiyonun beklediği veri tipi ile gönderilen değer uyuşmaz. Hatanın başladığı sürüm değişimini, hook parametrelerini ve PHP sürümüyle gelen daha katı tip denetimini inceleyin.
WordPress çalışmayı durduran bir PHP fatal hatası yakaladığında genel ekranı gösterir. Gerçek neden eklenti, tema, özel kod, bellek, sürüm uyumsuzluğu veya bozuk dosya olabilir; log olmadan hangisi olduğu söylenemez.
Yönetici e-posta adresini, SMTP/yerel posta teslimatını ve spam klasörünü kontrol edin. E-posta olmadan da FTP/SSH, WP-CLI ve PHP loglarıyla teşhis yapılabilir; kurtarma bağlantısı tek yöntem değildir.
Log bileşeni göstermiyorsa kontrollü karşılaştırma için kullanılabilir; ancak ödeme, güvenlik, cache ve üyelik gibi işlevleri kesebilir. Önce son fatal kaydı ve son değişiklikleri incelemek daha doğru olur.
Yalnız hata gerçekten bellek tükenmesiyse geçici veya kalıcı etkisi olabilir. Sürekli yükselen tüketim, sonsuz döngü, ağır sorgu veya bozuk eklenti varsa kök neden ayrıca giderilmelidir.
Doğru WordPress sürümü ve dili kullanılıp wp-content ile wp-config.php korunursa çekirdek onarımı yapılabilir. Önce checksum ile gerçekten çekirdek bozulması olup olmadığını doğrulayın ve tam yedek alın.
Kurulum, sunucu, script ve teknik destek ihtiyaçlarınız için Eka Yazılım ve Bilişim Sistemleri ile iletişime geçebilirsiniz.