Ölümün WordPress Beyaz Ekranı: İyileşme Rehberi
Yayınlanan: 2023-01-10MacOS ve hatta şimdi Windows gibi WordPress, rezil bir "Beyaz Ölüm Ekranına" veya kısaca "WSOD" a sahiptir. WSOD, bir şeyler ters gittiğinde ortaya çıkar. Bilinmeyen nedenlerle boş veya çoğunlukla boş beyaz bir ekranla karşılaşıyorsunuz. Şimdi ne olacak?
WordPress Beyaz Ölüm Ekranı (WSOD) nedir?
Normal koşullarda bir WordPress sitesinde “Beyaz Ölüm Ekranı” (WSOD) ile karşılaşmanız pek olası değildir. Bu, bir WordPress sitesinin genel ön uç veya arka uç arayüzü yerine görünen boş beyaz bir ekrandır. Bu, WordPress'in çöktüğü ve düzgün yüklenmeyeceği anlamına gelir.
Beyaz Ölüm Ekranı muhtemelen bir şeyin sonucudur WordPress sitenize yaptınız.
Neden? Niye? Ne ters gitti?
WordPress 5.2'nin Mayıs 2019'da piyasaya sürülmesinden bu yana WordPress, sizi WSOD'den korumak için bir Kurtarma Moduna sahiptir. Kurtarma Modu olmadan, uyumluluk sorunları çok sayıda WSOD'ye ve hayal kırıklığına uğramış WordPress kullanıcılarına neden olacaktı. Sunucunuz, yüklemekte olduğunuz bir eklenti, tema veya uzantı tarafından desteklenmeyen bir PHP veya MySQL sürümü kullanıyorsa, sitenizi bozmak yerine Kurtarma Modu alırsınız. Bugün, bir PHP Yetersiz Bellek (OOM) hatası, muhtemelen WSOD korumasını atlayarak sizi tamamen boş bir ekranla bırakan en yaygın kalan senaryodur.
Bugünlerde başka nelerin gerçek bir WSOD'ye neden olabileceğini öğrenmek için WordPress'in ana katılımcısı Marius Jensen ile görüştüm. Marius, konsepti ve özellikleri sonunda WordPress çekirdeğine giren Site Sağlığı (şimdi Sağlık Kontrolü ve Sorun Giderme) eklentisinin yazarıdır. (Kurtarma Modunu ve diğer korumaları bu şekilde elde ettik.) Marius, WordPress'in tamamen boş bir ekranla çökmesini sağlamanın tek yolunun, ölümcül hata işleyicinin olması gerektiği gibi çalışamaması için PHP'nin yürütme akışını kesmek olduğunu onayladı. PHP ile HTTP sunucunuz arasındaki bağlantıyı kesmek bunu başaracaktır. Ekranda herhangi bir sorun giderme geri bildirimi almazsınız. Bu sinir bozucu olurdu, ancak yalnızca WordPress içinde çalışıyorsanız, eklentileri yükleyip yapılandırıyorsanız, bunun olması pek olası değildir.
Ölümün Beyaz Ekranı WordPress'in Hacklendiği Anlamına mı Geliyor?
Hayır, bir WSOD, kötü adamların sizi ele geçirdiği anlamına gelmez. Ancak, nadir durumlarda, bir güvenlik ihlalinin yan etkisi olabilir. Bilgisayar korsanlarının sitenizi ele geçirdiğini düşünüyorsanız, Kathy Zant'ın Saldırıya Uğramış Bir WordPress Sitesini Nasıl Temizlersiniz adlı kılavuzuna bakın.
Bir PHP kodlama hatası, iki veya daha fazla eklenti arasındaki bir çakışma veya sunucu ortamınızdaki bir sorun, bir WSOD'nin en olası nedenleridir. Neyse ki, bunlar felaket değil! Siteniz ve içeriği kaybolmadı. İsterseniz, bir WSOD'yi kendiniz düzeltebilirsiniz.
Bu yazıda, WSOD için olası teşhis ve tedavilerin listesini inceleyeceğiz. WordPress sitenizi nasıl hayata döndüreceğinizi öğreneceksiniz. Ayrıca, WordPress'in daha derin bir düzeyde nasıl çalıştığını da öğreneceksiniz.
Önizlemeyi Görüntüle
Ölümün WordPress Beyaz Ekranı: Bunu Ben mi Yaptım?
Evet. Beyaz Ölüm Ekranı muhtemelen bir şeyin sonucudur WordPress sitenize yaptınız.
Bir WSOD'nin nedeni genellikle yeni kurduğunuz ve etkinleştirdiğiniz bir WordPress eklentisinde bulunur. Ya da yakın zamanda yapılan bir güncellemenin sonucu olabilir. Yeni eklenen veya güncellenen bir eklenti başka bir eklenti ile çakışıyor olabilir. Bu senaryoda, bir eklenti diğeriyle aynı şeyi yapmaya çalışıyor veya çelişkili amaçlar doğrultusunda hareket ediyor.
Bir eklenti, tema veya hatalı çalışan PHP kod parçacıkları önemli bir hataya neden oluyorsa, bir WSOD alabilirsiniz. Kullanmakta olduğunuz PHP sürümüyle uyumlu olmayan bir sözdizimi hatası, hata veya kod içerebilirler. Siz veya sunucunuz PHP sürümünüzü yükselttiyseniz - bu iyi bir şey! — uyumsuz eklentiler hata vermeye başlar ve sitenizi bir WSOD ile çökertebilir. Olması gerektiği gibi WordPress 5.2 veya üstünü kullanıyorsanız, uyumsuzluk sorunları, gerçek bir WSOD'den çok daha yararlı olan Kurtarma Modunu etkinleştirir.
Tipik olarak suçlu, bir eklenti, tema veya özel kodla değiştirilen şeydir.
WSOD, genellikle sitenizin işlevselliğini etkileyen en son (veya çok yakın zamanda) değiştirilenlere bir yanıt olduğundan. Tüm son değişiklikleri gözden geçirin. Bir soruna neden olma olasılığı en yüksek görünen değişikliklere odaklanın. Yeni bir eklenti yüklediyseniz veya bazı tema kodlarını değiştirdiyseniz, neyin yanlış gittiğini görmek için bakılacak ilk yerler bunlardır.
WordPress Yalnızca Çoğunlukla Ölü Olduğunda
Tüm WSOD'ler eşit değildir ve bazıları gerçek WSOD bile değildir.
Tamamen beyaz bir ekran yerine bir çeşit hata mesajı alabilirsiniz. Bir HTTP 500 hatası veya kayıp bir veritabanı bağlantısı hakkında bir sunucu hata mesajı olabilir. WordPress'ten gelen kritik bir hata mesajı olabilir. Veya siteniz ziyaretçiler için normal bir şekilde yüklenebilir, ancak giriş yapmaya çalıştığınızda beyaz bir ölüm ekranı alırsınız. Diğer durumlarda bunun tersi geçerli olabilir: WordPress kontrol panelinde oturum açabilirsiniz, ancak sitenizin halka açık ön ucu herkese boş bir ekran veriyor.
WSOD deneyiminiz bu tanımlardan herhangi birine uyuyorsa, iyi haber! Siteniz yalnızca çoğunlukla ölü. Onu canlandırmak zor olmayacak.
WordPress sitenizi ziyaret ettiğinizde veya oturum açmaya çalıştığınızda kendinizi tamamen boş bir beyaz ekranla karşı karşıya bulursanız, gerçek WSOD budur. Buna neyin sebep olduğunu belirlemek için biraz daha derine inmeniz gerekecek.
WordPress Kurtarma Modu ve Ölümün Beyaz Ekranı
Neyse ki, bir WSOD ile karşılaşan herkes için, onu ortadan kaldırmak için WordPress 5.2'de Kurtarma Modu tanıtıldı. Kurtarma Modu birçok önemli hatayı yakalar ve düzeltmenize yardımcı olur. WordPress çekirdeğinin en son ana sürümünü kullanmıyorsanız, oradan başlayın. Güncel olun!
WordPress'in Kurtarma Modu sayesinde, bir şeyler ters gittiğinde tamamen boş beyaz bir ekran görmek çok nadirdir. WordPress 6.1'den itibaren gri bir ekranın üzerinde aşağıdaki mesajı içeren beyaz bir pencereyi daha sık göreceksiniz:
WordPress'in eski sürümleri, "Site teknik sorunlar yaşıyor" gibi benzer şekilde ifade edilmiş mesajlar gösterecektir.
Bir arka uç /wp-admin URL'sine göz atarsanız, daha fazla bilgi için yönetici e-posta hesabınızı kontrol etmenizi söyleyen bir bildirim de olacaktır:
Diğer durumlarda, sitenizi onarmak için bir tür açıklama ve rehberlik içeren bir "Dahili Sunucu Hatası"nı açıklayan kalın metinli beyaz bir ekran görebilirsiniz.
Kurtarma'ya hoş geldiniz
Bu, Kurtarma Modudur. WordPress, ayağa kalkmasına yardımcı olmanıza yardımcı olmaya çalışıyor.
Yapılacak ilk şey, WordPress Yönetici hesabınızla ilişkili e-posta adresini kontrol etmektir. WordPress, yürüttüğü tüm kodlarda ölümcül PHP hatalarını belirlemeye çalışır.
Mümkünse, WordPress bir eklentiyi veya arızalı başka bir kodu "duraklatacaktır". WordPress, kötü kodun yürütülmesini engelleyecektir. Daha sonra ayrıntıları Yöneticilere e-posta ile bildirecektir.
Kurtarma Modu e-postasında, Kurtarma Modu altında WordPress'te oturum açmak için talimatlar ve geçici bir bağlantı bulacaksınız. (Bu link 24 saat boyunca iyidir. Bundan sonra site hala kritik bir hata yaşıyorsa yenisi gönderilecektir.)
PROFESYONEL İPUCU: Kurtarma Modu e-postasını almazsanız, Yönetici olarak oturum açtığınızda temel site URL'nize aşağıdaki adresi ekleyerek yine de Kurtarma Modunda WordPress'te oturum açabilirsiniz: /wp-login.php?action=entered_recovery_mode .
İşte size daha fazla araştırma fırsatı. Kurtarma Modu, WSOD'nizin nedeni olarak belirli bir eklenti belirlediyse, onu devre dışı bırakın. Bu, sitenizi herkes için yedekleyecektir. Ardından, bu eklenti için bilinen sorunları inceleyebilirsiniz. Bunun için bir güncelleme olup olmadığını kontrol edin. Bakımından sorumlu kişilere ulaşın.
WordPress'te Ölümün Her Beyaz Ekranı Aynı Değildir
Birkaç istisnai durumda, WordPress'in başka bir yerinde veya sunucu ortamınızda bir şeyler ters gitti. Bir güncelleme veya yükleme işlemi durmuş olabilir ve siteniz bakım modunda kalmış olabilir. Siz, barındırma sağlayıcınız veya yüklediğiniz bir eklenti php.ini veya .htaccess dosyalarını beklenmedik sonuçlarla değiştirmiş olabilirsiniz. Mevcut ortamınız, yeni yüklenen bir eklentinin gereksinimlerini desteklemeyebilir.
WordPress Kurtarma Modu bu durumlarla baş edemez, ancak beyaz bir ekranda görünür hata mesajları üretir. Sitenizin ön ucuna erişilemiyor olabilir, ancak yönetici oturum açma ekranı ve arka uç arayüzü normal şekilde çalışıyor olabilir.
Bunlar gerçek WSOD durumları değil ama bir o kadar da sinir bozucu. Genellikle, aşağıdaki koşullardan biri bunlara neden olur:
1. Bakım Modunda Kaldınız
WordPress çekirdeğini, eklentilerini veya temalarını güncellerken WordPress "Bakım Modu"na geçer. Sitenin herhangi bir bölümüne göz atıldığında, aşağıdakileri yazan beyaz bir mesaj penceresiyle birlikte gri bir ekran gösterilir:
Bazen bu bir dakika içinde düzelmez, ancak kalite yönetimli WordPress barındırma bunu fark eder ve otomatik bir işlemle düzeltir. Değişiklik olmadan birkaç dakika beklediyseniz, WordPress'in kurulu olduğu web/uygulama kök klasörünüzdeki .maintenance dosyasını silerek Bakım Modundan çıkabilirsiniz. (Görmek için, dosya adında bir nokta ile başlayan "görünmez" dosyaları görüntülemeyi etkinleştirmeniz gerekebilir.)
Mevcut bir .maintenance dosyası olmadığında, siteniz beklendiği gibi yüklenir.
2. Bir Dosya Yükleme veya Gönderi Boyutu Sınırına Ulaştınız
Çok fazla veri gönderdiğiniz için yükleme, yayınlama sonrası veya form gönderme sürecinde siteniz beyaz bir ekranla zaman aşımına uğrayabilir.
Çözüm: wp-config.php gönderi içeriği sınırınızı artırın:
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000); Çözüm: php.ini dosya yükleme ve gönderi boyutu sınırınızı artırın:
upload_max_filesize = 256M post_max_size = 256 Milyon
Bir gönderi veya herhangi bir form gönderme zaman aşımına uğramadan önceki süreyi (saniye olarak) uzatmak da yardımcı olabilir. PHP'nin betikleri yürütmesi ve girdileri ayrıştırması için gereken süreyi artırmanız da mümkündür. Ek olarak, bir form gönderiminde izin verilen değişken sayısını artırabiliriz. Son olarak, PHP'nin gönderilen verileri çöp olarak ele alacağı süre sınırını belirtebiliriz:
max_execution_time = 300 max_input_time = 300 max_input_vars = 1000 session.gc_maxlifetime = 1000
Veya .htaccess , httpd.conf veya virtualhost içinde:
php_value upload_max_filesize 256M php_value post_max_size 256M php_value max_execution_time 300 php_value max_input_time 300 php_value max_input_vars 1000 php_value session.gc_maxlifetime 1000
Veya WordPress için özel bir kod parçacığında veya bir tema functions.php dosyasında:
@ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set('max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );Bu parametrelerdeki hafıza ve zaman değerleri sadece tavsiye niteliğindedir. Çalıştıklarından emin olmak ve mevcut değerlerini kontrol etmek için WordPress Yönetici arayüzünüzdeki Site Sağlığı aracını kullanın.
Kurtarma Modu ile birlikte WordPress 5.2, Site Sağlığı aracını tanıttı. Sorunları teşhis etmek ve site ayarlarınız ve sunucu ortamınız hakkında teknik bilgi almak için çok yararlıdır. Yönetici Menünüzde Araçlar > Site Sağlığı altında bulun. WordPress için Sağlık Kontrolü ve Sorun Giderme eklentisindeki genişletilmiş özelliklerden de yararlanabilirsiniz.
3. PHP Bellek Dolu
PHP, WordPress çekirdeğinin dayandığı sunucu tarafı betik dilidir. PHP'nin WordPress'i ve etkin eklentilerinizi çalıştırması için yeterli bellek yoksa bir WSOD görünür. Bunun bir hata mesajında veya günlükte belirtildiğini görebilirsiniz.
Barındırma planınıza bağlı olarak, sunucunuzdaki tüm uygulamalar veya belirli bir WordPress örneği için PHP bellek sınırını artırabilirsiniz. Ne yapacağınızdan emin değilseniz ev sahibinizin teknik destek ekibinden yardım isteyin.
wp-config.php
Normalde, WordPress klasörünüzdeki wp-config.php dosyanıza aşağıdaki ayarı eklemek, bu örnekte WordPress için ön uç bellek sınırını 256 MB olarak ayarlayacaktır:
define('WP_MEMORY_LIMIT', '256M'); 128 ila 256 MB fazlasıyla yeterli olacaktır. Ayrıca, wp-config.php aşağıdaki satırı ekleyerek PHP'ye ayrılan maksimum veya arka uç belleği (sonraki örnekte de 256 MB) tanımlayabilirsiniz:
define('WP_MAX_MEMORY_LIMIT', '256M');İkinci sayı, PHP'nin kendisi için kullanabileceği toplam belleği tanımlayan maksimum bellek sınırıdır. İlk sayı, WordPress'in bu daha büyük PHP sınırı içinde çalışan belleğidir. Maksimum PHP bellek sınırı, WordPress uygulama bellek sınırına eşit veya daha yüksek olmalıdır.
php.ini
PHP maksimum bellek sınırını tanımlamanın başka bir yolu, WordPress klasörünüzde bulunan bir php.ini dosyasındaki ayardır:
bellek_limiti = 256M
Satır başında noktalı virgül olmadığından emin olun! Ayrıca, php.ini yalnızca php.ini dosyasının bulunduğu klasörün içinde veya altında çalışan WordPress örneğini (veya başka herhangi bir PHP uygulamasını) etkileyeceğini unutmayın. Sunucunuza veya web köküne erişiminiz varsa, bir php.ini Orada bulunan php.ini dosyası, farklı koşulları belirten kendi php.ini dosyasına sahip olmadıkça, tüm PHP uygulamaları için çevresel ayarları yönetecektir.
.htaccess
HTTP sunucunuz olarak Apache veya Litespeed kullanıyorsanız, PHP bellek sınırını tanımlamanın üçüncü bir yolu, WordPress klasörünüzdeki .htaccess dosyasıdır. Yukarıdaki örneklerde olduğu gibi, .htaccess'in de 256 MB'lık bir maksimum PHP sınırı belirlemek için bunun gibi yorumsuz bir satıra sahip olması gerekir:
php_value bellek_limiti 256M
wp-config.php , php.ini ve .htaccess uygulama ve sunucu ayarlarının sözdizimindeki hatalar da bir WSOD'ye neden olabilir. Sitenizi bozuyorlarsa bunları manuel olarak düzeltmeniz veya orijinal varsayılanlarıyla değiştirmeniz gerekebilir. Bir Apache veya Litespeed web sunucusu kullanıyorsanız, bunların nasıl çalıştığını yöneten .htaccess dosyası birçok WordPress eklentisi tarafından değiştirilebilir. Bu dosyalardan herhangi birinde ortaya çıkan hatalar bir WSOD'yi getirebilir ve sitenizi çökertebilir.
4. HTTP Sunucunuz Çöküyor
HTTP (veya şifreli, güvenli biçimi HTTPS), bir web sunucusunu web sunucusu yapan köprü metni aktarım protokolüdür. Sunucuların istek üzerine web sayfalarını (HTTP belgeleri) istemcilere (tarayıcılar gibi) sunma şeklidir.
WordPress siteleri için yaygın olarak kullanılan HTTP sunucuları Apache, Litespeed ve NGINX'tir. Hata ekranları biraz farklı görünür ve tarayıcıların bunları görüntüleme biçimleri değişebilir, ancak hepsi aynı HTTP hata kodlarını bildirir.
Dahili Sunucu Hatası olarak da bilinen bir HTTP 500 hatası, HTTP sunucunuzda HTTP isteklerini yerine getirmesini engelleyen beklenmeyen bir sorun olduğunu gösterir. Diğer 5xx sunucu hata kodları, özellikle 502 (Kötü Ağ Geçidi), 503 (Hizmet Kullanılamıyor) ve 504 (Ağ Geçidi Zaman Aşımı), sunucunuzun aşırı yüklendiğini veya erişilemez olduğunu gösterir. 500 dahili hatası, sunucunun istenen sayfayı/belgeyi döndürmesini engelleyen arızalar için tümünü yakalamadır.
Tarayıcınız kendi benzersiz HTTP hata ekranlarını sağlayabilir ve kendi özel hata kodlarını görüntüleyebilir. Google Chrome (ve diğer Chromium tabanlı tarayıcılar), Chrome'u kullanırken adres çubuğunuzdaki chrome://network-errors/ adresine göz atarsanız, tüm kendi hata kodlarını dahili olarak listeler ve açıklar.
Sunucu Tarafı Sorunları
WordPress siteleri için yaygın olarak kullanılan HTTP sunucusu yazılımı arasında Apache, Litespeed ve NGINX bulunur. Birçok WordPress sunucusu, performansı en üst düzeye çıkarmak için bunları önbelleğe alma ile kullanır.
Tarayıcınızın sert bir şekilde yenilenmesi veya tarayıcı tanımlama bilgilerinin ve önbelleğinin temizlenmesi 500 hata ekranını ortadan kaldırmıyorsa, bazı kötü sunucu tarafı önbellek dosyalarını alıyor olabilirsiniz. Sunucu tarafı önbelleğe alma, iyi çalışmadığında çok fazla karışıklığa neden olabilir, bu yüzden onu temizlemeyi de denemelisiniz. Barındırma kontrol panelinizde veya WordPress yönetici arayüzünüzde önbellek temizleme kontrolleri olabilir.
Bir HTTP 500 hatasının yaygın nedenleri arasında aşağıdaki sunucu tarafı koşulları yer alabilir:
- PHP bellek limiti aşıldı.
- PHP hataları gösterecek şekilde ayarlanmadığında diğer PHP hataları.
- Sunucu dosyalarına ve klasörlerine erişim için yetersiz izin.
- .htaccess yapılandırma dosyasındaki sözdizimi hataları.
PHP bellek sınırlarını ve bunların nasıl artırılacağını zaten ele aldık. Aşağıdaki bir sonraki bölümde PHP hata ayıklamasını inceleyeceğiz.
Modern, yönetilen WordPress barındırmada yanlış izinler olmamalıdır, ancak bunlar geleneksel paylaşımlı barındırmada yaygındır. Dosyalar 664 veya 644'e, klasörler 775 veya 755'e ve wp-config.php 660, 600 veya 644'e ayarlanmalıdır. WordPress.org'da dosya izinlerini değiştirme hakkında daha fazla bilgi edinin.
.htaccess dosyanızda değişiklik yaptıysanız veya dosyayı değiştiren bir eklenti (sıklıkla veya önbelleğe alma) kullanıyorsanız, dosyadaki hataları gözden geçirmeniz, geri yüklemeniz veya çalışan yeni bir .htaccess dosyası oluşturmanız gerekebilir. WordPress.org'da .htaccess hakkında daha fazla bilgi edinin.
Müşteri Tarafı Sorunları
İstemci tarafında (tarayıcınızda) HTTP 500 hatalarına başka koşullar da neden olabilir:
- Yanlış tarayıcı ayarları.
- Bozuk bir önbellek.
- Tarayıcınızda çalışan bozuk JavaScript dosyaları.
- İnternet bağlantı sorunları.
Mevcut tarayıcınızı sorun olarak ortadan kaldırmak için sitenizi farklı bir tarayıcıya yüklemeyi deneyin. Bir tarayıcı sorununuz varsa, varsayılan ayarlarına sıfırlamayı deneyin. Sitenizle kötü etkileşime girip girmediklerini görmek için yüklediğiniz tüm tarayıcı uzantılarını veya eklentileri devre dışı bırakın.
Sorununuz kötü önbellek dosyalarıyla ilgiliyse, önbelleğe alınmamış WordPress yönetici alanına yine de erişebilirsiniz. Hala WordPress yönetici arayüzünde oturum açabiliyorsanız, orada önbellek temizleme anahtarlarını kullanabilir veya aşağıda açıklanan ek sorun giderme adımlarını deneyebilirsiniz.
Bir HTTP 500 hatasına veritabanındaki bir sorun, bir WordPress sitesindeki bir eklenti veya temadaki bir sorun veya WordPress'in kendisindeki bir sorun neden olabilir.
Bir HTTP 500 hatasını gidermek için, HTTP sunucunuz ve PHP için hata günlüğünü açmalısınız. Ardından her ikisinde de hangi hataların göründüğünü kontrol edin. Ayrıca PHP bellek sınırını kontrol edip potansiyel olarak artırabilir, eklentileri devre dışı bırakabilir ve bu işlemlerden herhangi birinin sitenizi geri getirip getirmediğini görmek için varsayılan bir temaya geçebilirsiniz.
Aşağıda bu adımları daha ayrıntılı olarak ele alacağız. Bunları takip etmek 500 hatasını ortadan kaldırmıyorsa, daha fazla yardım için web barındırıcınızın destek ekibiyle iletişime geçin.
WordPress Gerçekten Öldüğünde
WordPress sitenizin her ön ve arka uç sayfasında tamamen beyaz bir ekran alıyorsanız ve hiçbir hata geri bildirimi görünmüyorsa, bu tam bir WSOD deneyimidir. PHP hata günlüklerinize ve HTTP sunucusu günlüklerinize nasıl erişeceğinizi biliyorsanız, bazı hata mesajları ve teşhis bilgileri alabilirsiniz. WordPress için PHP hata ayıklamasını açmak başka bir seçenektir. Barındırıcınız, hata ayıklamayı sizin için daha erişilebilir hale getirecek bazı araçlara sahip olabilir. Ancak durum böyle değilse, çözümünüzü bulana kadar bu yaygın WSOD tedavileri listesine inebilirsiniz.
WordPress'in Beyaz Ölüm Ekranını Gidermek ve Düzeltmek İçin Bir Ana Kontrol Listesi
WordPress Beyaz Ölüm Ekranını düzeltmek için aşağıdaki adımlardan geçmek sizi bir çözüme götürecektir. Benim deneyimlediğim en yaygın WSOD nedenlerine göre düzenlenmişlerdir, ancak bunları herhangi bir sırayla deneyebilirsiniz.
Özel durumunuzla en alakalı görünen çözümlere öncelik vermek en mantıklısıdır.
Hata kaydı ve hata ayıklama adımı (#2) en teknik adımdır, ancak ayrıntılıdır ve size her zaman WordPress'in neden sona erdiğini söyleyecektir.
Yararlı teşhis ve onarım araçları olabilecek birkaç ücretsiz eklentiye bağlantılar sağladım. Ayrıca, iThemes Security'yi özellikle veri tabanı tarama ve onarım özelliğinin yanı sıra dosya değişikliği algılaması için yararlı bulabilirsiniz. Hatta sunucu ayarlarınıza ve yeteneklerinize daha derin bir bakış için sunucu araçlarına sahiptir.
Son çare olarak, iyi ve yeni bir yedekleme, sitenizi bilinen son iyi durumunda tekrar çevrimiçi duruma getirecektir. Backup Buddy, bu rol için en iyi eklentidir.
Tarayıcı Önbelleğinizi ve Çerezlerinizi Temizleyin
Sitenizin tarayıcınızda ve sunucunuzda önbelleğe alınmış sayfaları size gerçekte olandan farklı bir şey gösterebilir. WordPress'in sitenize yeni ziyaretçiler gösterdiğini gördüğünüzden emin olalım.
Öncelikle, tarayıcınızın önbelleğini ve tanımlama bilgilerini temizleyin. Bu, WordPress'te veya başka bir sitede oturum açtıysanız, kullanıcı oturumunuzu sonlandıracaktır, bu nedenle herhangi bir ziyaretçi gibi bakıyorsunuz.
Ardından, ana makinenizin ve WordPress önbellek eklentilerinin oluşturduğu sunucu tarafı önbelleğini temizlemek için barındırma panelinizi ve WordPress yöneticinizi (varsa) kullanın. Tüm sitenizi ve sunucu önbelleğini kapatmayı deneyin. Tarayıcınızda sert bir yenileme gerçekleştirin. Bu sorunu çözerse, sorun sisteminizde çalışmayan önbellek ayarlarının etkinleştirilmiş olması olabilir. Bir eleme süreciyle, hangilerinin işe yarayıp hangilerinin yaramadığını belirleyebilirsiniz.
2. PHP Hatalarını Arayın
WordPress çekirdeğindeki, temalarındaki veya eklentilerindeki PHP kodu, WordPress'in Beyaz Ölüm Ekranı ile hayaletten vazgeçmesine neden olacak ölümcül bir hata oluşturabilir.
Ölümcül PHP hataları ve bunlara neden olan şeyler hakkında daha fazla bilgi almak için PHP hata bildirimini açıp ekrana, bir günlük dosyasına veya her ikisine birden gönderebilirsiniz. Ölümcül hatalar büyük olasılıkla WSOD'nin kaynağını gösterecektir.
PHP tabanlı bir web uygulaması olarak WordPress, hata ayıklama için PHP'nin hata günlüğü işlevlerinden yararlanmanıza yardımcı olan kendi teşhis raporlama sistemine sahiptir. Açmak ve kontrol etmek için wp-config.php şunu yazan bir satır olduğundan emin olun:
define('WP_DEBUG', doğru);Bunu eklemeniz veya değeri yanlıştan doğruya değiştirmeniz gerekebilir. Bu, WordPress'e PHP hata ayıklamasını açmasını söyler.
WP Debugging eklentisini yükleyip etkinleştirerek de kısayol kullanabilirsiniz. Doğrudan wp-config.php kendiniz değiştirmenize gerek kalmadan WordPress için PHP hata ayıklamasını açacaktır.
Aşağıda gösterilen ek wp-config.php parametreleri, hata ayıklama çıktısını ekrana HTML olarak ve varsayılan olarak "error_log" adlı bir dosya olarak yazdıracaktır:
tanımla('WP_DEBUG_DISPLAY', doğru);
tanımla('WP_DEBUG_LOG', doğru);WordPress'i CSS ve JavaScript bağımlılıklarının optimize edilmemiş sürümlerini bir soruna neden olma ihtimaline karşı kullanmaya zorlamak da yararlı olabilir:
tanımla('SCRIPT_DEBUG', doğru);Hata Ayıklama Çubuğu eklentisi, yararlı bir ek ve tamamlayıcı araçtır. Size güzel bir arayüzde hata ayıklama verilerini gösterecektir.
Bunun olması için php.ini error_reporting NONE dışında bir değer veren error_reporting = E_ALL gibi bir satır olmalıdır. Bu satırın başında noktalı virgül olmamalıdır ; bu, onu etkin bir ayar yerine bir yorum haline getirir. E_ALL kullanıyorsanız her PHP hatasını, uyarısını ve uyarısını alacağınızı unutmayın. Yalnızca WordPress'in çökmesine neden olan önemli çalışma zamanı hatalarını günlüğe kaydetmek için E_ERROR gibi farklı bir değer kullanın.
3. Tema ve Eklenti Çakışmalarını Kontrol Edin
Önceki adımda açıklandığı gibi PHP hataları için hata ayıklama, sizi WSOD'nizin kaynağı olarak net bir temaya veya eklenti dosyasına yönlendirmelidir. Daha az teknik bir eleme süreci yaklaşımıyla da yaklaşabilirsiniz.
Sorun Giderme Temaları
Beyaz Ölüm Ekranı genellikle WordPress temaları ve/veya eklentileri arasındaki çakışmalardan kaynaklanır. Çakışma kaynağını/kaynaklarını belirlemek için, tüm eklentilerinizi devre dışı bırakmayı ve Twenty Twenty-Three gibi WordPress çekirdekli mevcut, değiştirilmemiş varsayılan tema paketlerine geçmeyi deneyebilirsiniz.
Temayla başlayın — test etmesi en basit olanıdır. Etkin temanızı iyi olduğu bilinen, değiştirilmemiş bir varsayılan temaya geçirmek sitenizi tekrar çevrimiçi hale getiriyorsa, sorunun kullanmakta olduğunuz temada olduğunu bilirsiniz.
Varsa temanızın functions.php dosyasına bakın. Yakın zamanda değiştirdiyseniz, bu muhtemelen kederinizin bir kaynağıdır. functions.php dosyası, etkinleştirildiğinde bir temayla kullanım için özel işlevsel kodun eklendiği yerdir. Buradaki hatalı kod ve sözdizimi hataları size bir WSOD verecektir.
Eklentilerde Sorun Giderme
Eklenti klasörlerini geçici olarak /wp-content/plugins/ klasöründen çıkararak komut satırı/SSH veya SFTP aracılığıyla WordPress yöneticisine erişmeden eklentileri devre dışı bırakabilirsiniz. Uygulamam, "A" adında bir eklenti alt klasörü oluşturmaktır, böylece alfabetik olarak sıralanmış /plugins dizininde ilk görünür. Sonra diğer tüm eklenti klasörlerini "A"ya taşıyorum.
Bunu yaptıktan sonra sitenizi yeniden yükleyin. WordPress, tüm eklentiler gitmiş gibi davranacaktır. Hâlâ yüklüler ancak devre dışı bırakıldılar. Beyaz Ölüm Ekranı kaybolursa, eklentilerinizi ve temanızı teker teker yeniden etkinleştirmeyi deneyebilir, hangisinin sitenizin çökmesine neden olduğunu görmek için her seferinde ana sayfanızı yenileyebilirsiniz.
Meks Quick Plugin Disabler, tüm aktif eklentileri hızlı bir şekilde devre dışı bırakan ve ardından komutunuzla WordPress yöneticisinin içinden yeniden etkinleştiren kullanışlı bir araçtır.
4. Bozuk Çekirdek Dosyalarını Onarın
WSOD'niz bozuk çekirdek WordPress dosyalarının sonucu olabilir. Bu pek olası olmasa da, WordPress Panosu Güncellemeleri alanında tek bir tıklamayla WordPress'in en son sürümünü hızlı bir şekilde yeniden yüklemek kolaydır. Bu, eklentilerinize, temalarınıza veya mevcut içeriğinize zarar vermez, bu nedenle temel dosyalarınızın iyi durumda olduğunu doğrulamanın iyi ve kolay bir yoludur.
Yukarıdaki adımlardan hiçbiri yardımcı olmazsa, WSOD, sunucu ortamınızla ilgili erişemeyeceğiniz bir sorundan kaynaklanıyor olabilir. Bu durumda, yardım için barındırma sağlayıcınızla iletişime geçmeniz gerekebilir. Son çare olarak, bir yedeği geri yükleyerek sitenizi "bilinen son iyi" durumuna da döndürebilirsiniz.
WSOD Nasıl Engellenir — WordPress Site Sahipleri ve Kurucuları İçin Tavsiyeler
WordPress gayet iyi çalışıyordu — ve sonra birdenbire Beyaz Ölüm Ekranını aldınız!
Bunun nedeni muhtemelen SİZİN WordPress'in işleyişi için kritik bir şeyi değiştirmiş olmanızdır.
Liquid Web veya Nexcess ile, onunla yaptığınız şeyler için yeterli kaynaklarla uygun şekilde yapılandırılmış, sağlam bir yönetilen WordPress barındırma hesabı kullanıyorsanız, bir WSOD ile WordPress'i kırma yollarının %99'undan kaçınılabilir.
Sorun şu ki site sahipleri bu uygulamalardan kaçınmıyor!
Ne Yapmamalı
- Kovboy Kodlaması. Canlı bir sitede SFTP, komut satırı veya WordPress yöneticisi içindeki kod düzenleyiciler ve komut dosyası yerleştiriciler aracılığıyla işlevsel kod ekleme veya düzenleme. Ufak bir hata siteyi çökertir.
.htaccessvewp-config.phpgibi yapılandırma dosyalarını değiştirmek de bir siteyi çökertebilir. Bunun yerine yerel bir test veya canlı (ancak herkese açık olmayan) hazırlama sitesinde çalışın. - Şüpheli Temaları, Eklentileri ve Uzantıları Yükleme. Canlı bir siteye düşük kaliteli ve hatta geçersiz yazılım yüklemek, belaya davetiyedir. Tek seferde çok fazla şey eklemek, nihai olarak neyin önemli bir değişiklik olduğunu belirlemeyi zorlaştırabilir. Kovboy kodlamasına benzer şekilde, canlı bir siteye yeni kod ürünleri yüklemek risklidir. Önce özel bir yerel veya hazırlık sitesinde iyi test edin.
- Karmaşık Önbelleğe Alma. Ana makinenizin sunabileceği, tüm önbelleğe alma ve performans optimizasyonu eklentileriyle iyi çalışmayabilecek çeşitli sunucu tarafı önbelleğe alma türleri vardır. Yeni önbelleğe alma yöntemleri veya ayarları uygularken, canlı bir sitede değişiklikleri uygulamadan önce yerel ve hazırlama ortamlarında dikkatlice test edin.
- Her Şeyi Aynı Anda Güncellemek. Birçok temayı ve eklentiyi aynı anda toplu olarak güncelleyebilirsiniz. Normalde bu çalışır, ancak sunucunuz zaman aşımına uğrarsa bakım modunda takılıp kalabilirsiniz. Ayrıca, yeni güncellenen kod yeni hatalara, çakışmalara veya uyumluluk sorunlarına neden olabilir. Bu olursa ve siteniz çökerse, sorunun kaynağını belirlemek daha zor olacaktır. Aynı anda birden çok temayı, eklentiyi ve uzantıyı güncellediyseniz, herhangi bir sayıda öğe olabilir. Güncellenen kod, genel kullanıma açık ana sitenizde kullanıma sunulmadan önce yerel olarak ve canlı hazırlama sitelerinde test edilebilir.
WSOD'suz Bir Hayat İçin İpuçları
WSOD, herhangi bir WordPress sitesinde olabilir, ancak alarma neden olmamalıdır. Bu kılavuzdaki ipuçlarını takip etmek, sorunu tanımlamanıza ve sitenizin ziyaretçileri fark etmeden hızlı bir şekilde çözmenize yardımcı olabilir.
Bir WordPress sitesiyle ilgili sorunlar, uygun bakım ve bakımın önemini vurgular. WSOD'lere tepki vermekten daha iyi, ziyaretçilerinizi asla hata mesajlarına ve boş ekranlara maruz bırakmayacak şekilde WordPress üzerinde çalışmayı öğrenebilirsiniz.
Değişikliklerinizi dikkatli ve kasıtlı olarak yapın. Potansiyel WSOD'lerinizle yerel bir test veya hazırlama ortamında ilgilenin. Bunlar, günümüzde çoğu yönetilen WordPress ana bilgisayarı için standart araçlar ve özelliklerdir. Bu temel, en iyi uygulamaları takip ederseniz, WordPress Beyaz Ölüm Ekranı hakkında endişelenmenize gerek kalmayacak.
WordPress'i Korumak ve Korumak için En İyi WordPress Güvenlik Eklentisi
WordPress şu anda tüm web sitelerinin %40'ından fazlasına güç veriyor, bu nedenle kötü niyetli bilgisayar korsanları için kolay bir hedef haline geldi. iThemes Security Pro eklentisi, WordPress web sitenizi güvenli hale getirmeyi ve korumayı kolaylaştırmak için WordPress güvenliğinin varsayımlarını ortadan kaldırır. Bu, WordPress sitenizi sizin için sürekli izleyen ve koruyan tam zamanlı bir güvenlik uzmanına sahip olmak gibidir.
Dan Knauss, StellarWP'nin Teknik İçerik Genel Sorumlusudur. 1990'ların sonlarından beri açık kaynakta ve 2004'ten beri WordPress ile çalışan bir yazar, öğretmen ve serbest çalışan.