Mağazamda bir sorun var: nereden başlamalı
Mağazanız dünkü gibi davranmıyor ve nedenini henüz bilmiyorsunuz. Bu bölüm, teknik nedene göre değil ekranda gördüğünüze göre sıralanmış otuz arızayı bir araya getirir: belirtiden yola çıkarsınız, sayfa sizi olası kaynağa götürür.
Bu bölüm kimin için
Buradasınız çünkü bir şeyler ters gidiyor ve varsa bile hata mesajı size hiçbir şey anlatmıyor. Sipariş adımları tamamlanmıyor, yönetim paneli açılmıyor, bir sayfa boş kalıyor ya da site bir saniyede yanıt verirken şimdi on saniyede yanıt veriyor. Bu noktada soru hangi hizmet sağlayıcıyı seçeceğiniz değil, arızanın nereden geldiğidir.
Bu sayfalar, henüz bir teşhisi olmayan biri için yazıldı. Görülebilenden yola çıkarlar — bir ekran, bir davranış, barındırma firmasından gelen bir uyarı e-postası — ve en sıktan en nadire doğru olası nedenlere geri giderler. Hiçbiri kod okuyabildiğinizi varsaymaz.
Bölüm nasıl düzenlendi
Otuz sayfa dört aileye ayrılır. Görüntüleme arızaları: boş sayfa, kayıp görseller, düzenlemeden sonra bozulan tema, mobil yerleşimin bozulması. İşlevsel arızalar: ödeme alınamaması, sipariş akışının tıkanması, e-postaların ulaşmaması, içe ve dışa aktarmaların başarısız olması, duran senkronizasyon. Altyapı arızaları: 500 hatası, 504 hatası, veritabanı bağlantısının reddedilmesi, artık hiçbir yere işaret etmeyen alan adı, süresi dolmuş sertifika. Ve yönetim durumları: bakımsız bırakılmış site, ulaşılamayan önceki sağlayıcı, bir güncellemenin veya barındırma değişikliğinin hemen ardından çıkan arıza.
Belirtiniz aşağıdaki listede varsa doğrudan o sayfaya gidin. Birkaçı arasında kararsızsanız, site arızasını barındırma arızasından ayıran sayfayla başlayın: teşhisin ilk çatalı odur ve yanlış tarafta uzun süre aramanızı önler.
Görüntüleme mi sunucu mu: zaman kazandıran ayrım
Görüntüleme arızasında sunucu hâlâ yanıt verir: bir sayfa geri döner, yalnızca boş, yanlış ya da bozuk biçimlendirilmiştir. Sunucu arızasında ise yanıtın kendisi oluşmaz: tarayıcı 500, 502 veya 504 alır ya da zaman aşımına kadar bekler. İlk durumda neden neredeyse her zaman temada, bir modülde, önbellekte veya bir dosya yolundadır. İkincisinde ise PHP, veritabanı ya da barındırma yapılandırması tarafındadır.
Her iki durumda da refleks aynıdır: hiçbir şeye dokunmadan önce hata günlüğünü açmak. PrestaShop'ta işe yarar bilgi var/logs/ dizininde ve barındırma firmasının günlüğündedir; WordPress'te WP_DEBUG_LOG sabiti wp-content/debug.log dosyasına yazar. Oradaki tek bir satır çoğu zaman sorunlu dosyanın adını verir. Onu okumadan siteyi değiştirmek, cevabı taşıyan izi silmek anlamına gelir.
Başlangıçta en işe yarar dört sayfa
-
Site mi barındırma mı: arıza nereden geliyor
Yapılacak ilk ayrım. Sizi koda ya da sunucuya yönlendirir ve yanlış tarafta saatler harcamanızı önler.
-
500 hatası ya da boş sayfa
En yaygın ve en az konuşan mesaj ile onun sessiz türevi. Gerçekte neyi kapsadıkları ve arkalarındaki PHP hatasının nasıl görünür kılınacağı.
-
Sitem hiç yanıt vermiyor
Tarayıcı boşuna dönüyor ve siteyi hiç göstermiyor. Barındırma arızasını uygulama arızasından ayıran dört kontrol.
-
PrestaShop hata günlüklerini okumak
Tek bir tema dosyasını açmadan önce günlükleri bulup yorumlamanın adım adım yöntemi.
Sıkça sorulan sorular
Belirtimi adlandıramıyorum, nereden başlamalıyım?
Bu sayfaları takip etmek için FTP veya SSH erişimi gerekir mi?
Bu sayfalar hem PrestaShop hem WooCommerce için geçerli mi?
Mağazam şu anda kapalı, yine de önce okumam şart mı?
Site kendiliğinden yeniden çalışmaya başladı, yine de araştırmalı mıyım?
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.