“Bu Sitede Kritik Bir Hata Oluştu” WordPress Hatası: Nedenleri ve Çözümü

“Bu sitede kritik bir hata oluştu” uyarısı ne demek ve ilk ne yapmalısınız?

“Bu sitede kritik bir hata oluştu”, WordPress’in PHP tarafında durdurucu bir hata yakaladığını ve sayfayı güvenli biçimde göstermediğini söyleyen genel uyarıdır. Çoğu zaman bir eklenti, tema ya da yarım kalan güncelleme sorumludur. Önce yönetici e-postanıza bakın, sonra hata günlüğünden nedeni bulun.

Panik yapmadan sırayla ilerleyin. Siteniz silinmedi; WordPress yalnızca sorunlu kodu çalıştırmayı reddediyor. Aşağıdaki sıra, ekibimizin sahada en az riskle sonuç verdiğini gördüğü sıradır.

1. Önce dosya ve veritabanı yedeği alın, çünkü her müdahale yeni bir risk taşır.
2. Ardından, yönetici e-posta kutunuzda WordPress’ten gelen kurtarma modu mesajını arayın.
3. Daha sonra, mesaj yoksa hata günlüğünü açıp hatayı veren dosyanın adını okuyun.
4. Ayrıca, dosya adı bir eklentiyi gösteriyorsa o eklentinin klasör adını değiştirin.
5. Üstelik tema gösteriyorsa temayı varsayılan bir temaya döndürün.
6. Son olarak, sorun sürerse PHP sürümünü, bellek sınırını ve yarım kalan güncellemeyi kontrol edin.

Bu yazıda her adımı ayrı ayrı anlatıyoruz. Not: Bu rehber genel bilgidir; sonuç sitenizin yapısına göre değişir ve kurtarma garantisi vermez.

“Bu sitede kritik bir hata oluştu” uyarısı neden çıkar?

WordPress, PHP kodu çalışırken “fatal error” denen ölümcül bir hata görünce işlemi durdurur. Eskiden bu durum boş beyaz ekran olarak görünürdü. Sürüm 5.2 ile birlikte WordPress, ziyaretçiye genel bir uyarı gösteriyor ve yöneticiye e-posta gönderiyor.

Uyarının Türkçe metni sürüme ve çeviriye göre değişebilir. Bu yüzden ekranınızda benzeri bir ifade görüyorsanız aynı sorunla karşı karşıyasınız. Altta yatan nedenler ise sınırlı sayıdadır.

• Yeni kurduğunuz ya da güncellediğiniz bir eklentide kod hatası olabilir.
• Yani, tema, eklentiyle çakışabilir veya yeni PHP sürümüyle uyumsuz olabilir.
• Sunucudaki PHP sürümü, eklentinin istediği sürümden eski ya da çok yeni olabilir.
• Ardından, betik, ayrılan bellek sınırını aştığı için kesilmiş olabilir.
• Güncelleme yarıda kaldığı için dosyalar birbiriyle uyumsuz kalmış olabilir.
• Daha sonra, dosya aktarımı bozulduğu için eksik ya da hasarlı bir dosya yüklenmiş olabilir.

Dolayısıyla “neden” sorusunun cevabı her zaman günlükte yazar. Tahmin yürütmek yerine önce kaydı okumanızı öneririz.

Bu sitede kritik bir hata oluştu uyarısında müdahale etmeden önce neden yedek almalısınız?

Çünkü bu hatayı çözmek için dosya adı değiştirir, ayar dosyasını düzenler ya da eklenti kapatırsınız. Her adım geri alınabilir görünse de bir yanlış tuş ayarları bozabilir. Yedek, yanlış adımda size geri dönüş yolu sağlar.

Site açılmıyor olsa bile yedek almak mümkündür. Hosting panelinizin dosya yöneticisinden ya da FTP ile site klasörünü indirebilirsiniz. Veritabanı için panelin yedekleme aracını kullanın.

• Site klasörünün tamamını, özellikle wp-content dizinini bilgisayarınıza indirin.
• Ayrıca, veritabanını panelden dışa aktarın ve dosyayı ayrı bir yerde saklayın.
• Barındırma firmanızın otomatik yedeği varsa son yedeğin tarihini not edin.
• Üstelik yedeği aldıktan sonra dosyanın açıldığını ve boş olmadığını kontrol edin.

Yedekleme düzeninizi baştan kurmak isterseniz web sitesi yedekleme stratejisi yazımıza bakabilirsiniz. Ayrıca veritabanı tarafı için veritabanı yedekleme ve geri yükleme rehberimiz var.

Yönetici e-postasındaki kurtarma modu bağlantısı nasıl kullanılır?

WordPress, ölümcül hatayı yakalayınca site yöneticisinin e-posta adresine bir mesaj yollar. Mesajda hatanın hangi eklenti ya da temadan geldiği yazar ve gizli bir kurtarma modu bağlantısı bulunur. Bağlantıyı açıp yönetici hesabınızla giriş yaparsınız.

WordPress geliştirici ekibinin açıklamasına göre kurtarma modu çerez tabanlıdır. Yani aynı tarayıcıda siz oturum açtıktan sonra da çalışır. Panelde hangi eklenti ya da temanın duraklatıldığını gösteren bir bildirim görürsünüz.

1. Hata e-postasını açın ve bağlantıya tıklayın.
2. Yani, yönetici kullanıcı adı ve parolanızla giriş yapın.
3. Ardından, duraklatılan eklenti ya da temayı bildirimde görün.
4. Daha sonra, sorunlu eklentiyi güncelleyin, kaldırın ya da geliştiricisine hatayı bildirin.
5. Son olarak, işiniz bitince kurtarma modundan çıkın ve siteyi ziyaretçi gözüyle test edin.

Bağlantıyı yalnızca kendi e-postanıza gelen mesajda kullanın. Başkasından gelen, aciliyet vurgulayan ve sizi başka bir adrese yönlendiren mesajlar kimlik avı olabilir. Moddan çıktığınızda duraklatılan bileşenler yeniden devreye girer; sorun düzelmediyse hata geri döner.

Kurtarma modunda neler yapabilir, neler yapamazsınız?

Kurtarma modu bir onarım aracı değil, geçici bir güvenli giriştir. Yani WordPress, hatalı bileşeni duraklatır ve size panele girme imkânı verir. Ancak kodu sizin yerinize düzeltmez; bu nedenle son kararı siz verirsiniz.

Resmî duyuruya göre bu modda sorunlu eklentiyi tamamen devre dışı bırakabilir, sorunu çözebilecek beceriniz varsa kendiniz düzeltebilir ya da eklenti geliştiricisine hatayı bildirebilirsiniz. Üstelik moddan çıkış tek bir düğmeyle yapılır. Çıkınca çerez silinir ve tüm bileşenler yeniden çalışır.

• Duraklatılan bileşeni görüp adını not edebilirsiniz.
• Ayrıca, eklentiyi kalıcı olarak kapatıp siteyi hızla ayağa kaldırabilirsiniz.
• Hatayı geliştiriciye iletmek için günlükteki satırı kopyalayabilirsiniz.
• Üstelik moddan çıkınca hata yeniden başlayabileceği için çözüm uygulamadan çıkmayın.

Bu bilgi için WordPress resmi belgelerindeki yaygın hatalar sayfasına bakabilirsiniz. Dolayısıyla modu bir kurtarma garantisi değil, nedeni bulmanızı kolaylaştıran bir yardımcı olarak görün.

Kurtarma modu e-postası gelmezse ne yaparsınız?

Önce spam klasörüne, ardından site ayarlarında kayıtlı yönetici e-posta adresine bakın. Eski bir adres tanımlıysa mesaj oraya gitmiş olabilir. Sunucunuz e-posta göndermiyorsa mesaj hiç çıkmayabilir.

Bu durumda e-postaya güvenmeyip doğrudan günlük ve dosya yöntemine geçin. Hatayı dosya düzeyinde bulmak çoğu zaman daha güvenilirdir. Üstelik e-posta sorununu da çözüm sonrasında ayrı olarak ele alabilirsiniz.

• Spam ve gereksiz klasörlerini kontrol edin.
• Yani, ayarlardaki yönetici e-posta adresinin güncel olup olmadığına bakın.
• Hosting firmanızdan sunucunun e-posta gönderip göndermediğini sorun.
• Ardından, hata günlüğünden nedeni okuyup dosya yöntemine geçin.

Siteniz giden e-postaları sürekli kaybediyorsa WordPress e-posta gönderme rehberimizdeki SMTP kurulumu bu tür uyarıların size ulaşmasını sağlar.

Hata günlüğü için WP_DEBUG ve WP_DEBUG_LOG nasıl açılır?

WP_DEBUG, WordPress’in hata ayıklama modunu açan sabittir. WP_DEBUG_LOG ise hataları wp-content klasöründeki debug.log dosyasına yazar. Resmî WordPress geliştirici belgesine göre WP_DEBUG_LOG çalışması için WP_DEBUG’ın da açık olması gerekir.

Bu ayarlar wp-config.php dosyasındadır. Dosyayı düzenlemeden önce kopyasını alın. Ayrıca WP_DEBUG_DISPLAY sabitini kapalı tutarsanız hatalar ziyaretçilere görünmez, yalnızca günlüğe yazılır. Bu, canlı sitede daha güvenli bir yoldur.

• wp-config.php dosyasını hosting panelinizin dosya yöneticisinde açın.
• Daha sonra, wP_DEBUG ve WP_DEBUG_LOG sabitlerini açık, WP_DEBUG_DISPLAY sabitini kapalı olarak ayarlayın.
• Siteyi bir kez yenileyerek hatayı yeniden üretin.
• Ayrıca, wp-content klasöründe oluşan debug.log dosyasını indirip son satırlara bakın.

Resmî belge bu modu canlı sitelerde kalıcı kullanmamanızı önerir. Bu nedenle işiniz bitince ayarları eski haline getirin ve günlük dosyasını silin; çünkü içinde yol bilgileri bulunabilir. Ayrıntı için WordPress hata ayıklama belgesine bakın.

Günlükteki hata satırını nasıl okursunuz?

Günlükte en önemli bölüm, “Fatal error” ifadesinden sonra gelen dosya yoludur. Yolun içinde plugins geçiyorsa sorun bir eklentidedir; themes geçiyorsa temadadır. Eklenti klasörünün adı çoğu zaman eklentinin adını verir.

Satır numarası geliştiriciye lazımdır, sizin için dosya adı yeterlidir. Örneğin yol, bir eklenti klasörünü gösteriyorsa yalnızca o eklentiyi devre dışı bırakmanız çoğu zaman siteyi geri getirir.

• Yolda plugins varsa eklenti klasörünün adını not edin.
• Üstelik yolda themes varsa aktif temanızın klasörünü not edin.
• “Allowed memory size exhausted” benzeri bir ifade varsa bellek sınırına gidin.
• Yani, “Unsupported” ya da “requires PHP” benzeri bir ifade varsa PHP sürümünü kontrol edin.
• Aynı satır sürekli tekrar ediyorsa en eski kaydı değil en yeni kaydı okuyun.

Günlük dosyası size tek bir cümle de verse yeterlidir. Dosya adını yazıp o eklentinin geliştiricisine ya da destek forumuna sorabilirsiniz. Hata mesajını paylaşırken sunucu yolunuzu ve parolalarınızı gizleyin.

Hosting panelinden sunucu hata günlüğünü nasıl bulursunuz?

WordPress günlüğüne ek olarak sunucunun kendi hata kaydı da vardır. Birçok hosting panelinde bu kayıt “hata günlükleri” gibi bir bölümde görünür. Panelin adı ve menüsü firmaya göre değiştiği için kesin bir buton adı vermiyoruz.

Bu kayıt özellikle WordPress hiç yüklenemediğinde işe yarar. Çünkü bazı hatalar WordPress günlüğüne ulaşamadan önce sunucu düzeyinde oluşur. Ayrıca kayıt, hatanın ne zaman başladığını da gösterir.

• Panelde hata günlüğü ya da log bölümünü arayın.
• Ardından, hatanın başladığı saate yakın satırlara odaklanın.
• Satırdaki dosya yolunu ve “fatal” içeren ifadeyi not edin.
• Daha sonra, bulamazsanız hosting firmanızdan site için son kayıtları isteyin.

Kayıtlarda çok sayıda satır görmeniz normaldir. Önemli olan hata başlangıcından sonraki ilk ölümcül kayıttır. Daha uzun kayıt incelemeleri için log analizi aracını kullanabilirsiniz.

Eklentiyi klasör adını değiştirerek nasıl devre dışı bırakırsınız?

Yönetim paneline giremiyorsanız eklentiyi dosya düzeyinde kapatabilirsiniz. wp-content içindeki plugins klasöründe sorunlu eklentinin klasörünü bulun ve adının sonuna bir ek yazın. WordPress eklentiyi bulamayınca otomatik olarak devre dışı bırakır.

Bu yöntem eklentinin ayarlarını silmez, yalnızca çalışmasını engeller. Dolayısıyla sorunu bulduktan sonra klasörü eski adına çevirip güncelleyebilirsiniz. Yine de önce yedek aldığınızdan emin olun.

1. Hosting panelinden ya da FTP ile wp-content içindeki plugins klasörünü açın.
2. Ayrıca, günlükte adı geçen eklenti klasörünü bulun.
3. Üstelik klasörün adının sonuna “_kapali” gibi bir ek ekleyin.
4. Yani, siteyi ve yönetim panelini yenileyerek açılıp açılmadığına bakın.
5. Son olarak, açıldıysa eklentinin güncel olup olmadığını panelden kontrol edin.

Site açıldıysa suçlu eklenti bulunmuş demektir. Eklentiyi güncelleyin, alternatifine geçin ya da geliştiriciye hatayı bildirin. Eklentiyi silmeden önce ayarlarını not etmenizi öneririz.

Tüm eklentileri tek seferde nasıl kapatırsınız?

Hata hangi eklentiden geliyor bilmiyorsanız tüm eklentileri birlikte kapatabilirsiniz. WordPress belgeleri bunun için plugins klasörünü geçici olarak başka bir adla (örneğin plugins.hold) değiştirmeyi anlatır. Panele girince eklentilerin eksik olduğu uyarısını görürsünüz.

Giriş yaptıktan sonra klasörü eski adına çevirin. Eklentiler kapalı kalır, onları tek tek açarak suçluyu bulursunuz. Resmî belge bu yöntemin eklenti ayarlarını koruduğunu söyler.

• Klasörü yeniden adlandırdıktan sonra site açılıyorsa sorun eklentilerden biridir.
• Ardından, klasörü eski adına çevirin ve eklentileri yönetim panelinden birer birer açın.
• Her açışta siteyi yenileyin ve hata geri geldiyse son açtığınız eklentiyi kapalı bırakın.
• Daha sonra, site hâlâ açılmıyorsa tema, PHP sürümü ya da bellek sınırını araştırın.

Ayrıntılı adımlar için WordPress sorun giderme SSS sayfasına bakabilirsiniz. Veritabanı üzerinden kapatma yöntemi de vardır, ancak yanlış satırı değiştirmek riskli olduğu için bunu yalnızca bilen biriyle yapmanızı öneririz.

Temayı varsayılan temaya nasıl döndürürsünüz?

Günlükteki dosya yolu themes klasörünü gösteriyorsa sorun aktif temadadır. Panele girebiliyorsanız görünüm bölümünden WordPress’in varsayılan temalarından birini etkinleştirin. Giremiyorsanız wp-content içindeki themes klasöründe aktif temanın klasör adını değiştirin.

WordPress, aktif tema bulunamazsa mevcut varsayılan temalardan birine otomatik olarak döner. Bunun için sunucuda en az bir varsayılan temanın kurulu olması gerekir. Dolayısıyla klasör adını değiştirmeden önce themes klasöründe varsayılan bir temanın durduğunu doğrulayın.

• Panele girebiliyorsanız varsayılan temayı etkinleştirin ve siteyi test edin.
• Ayrıca, giremiyorsanız aktif tema klasörünün adını değiştirin.
• Site açıldıysa özel tema ya da alt tema dosyalarınızı geliştiricinizle gözden geçirin.
• Üstelik tema özelleştirmelerinizi kaybetmemek için önceden yedek aldığınızdan emin olun.

Ayrıca özel kodlanmış bir temanız varsa eski bir fonksiyonun yeni PHP sürümünde çalışmaması en sık görülen nedenlerden biridir. Bu durumda tema geliştiricisinin kodu güncellemesi gerekir.

PHP sürümü uyumsuzluğu bu hatayı nasıl tetikler?

Her eklenti ve tema belli PHP sürümleri için yazılır. Sunucudaki sürüm eklentinin beklediğinden eski ya da çok yeniyse kod çalışmaz ve WordPress ölümcül hata verir. Bu durum genellikle hosting firmasının sürümü değiştirmesinden ya da siz değiştirmenizden sonra ortaya çıkar.

Çözüm iki yönlüdür. Eklentiyi güncelleyebilirseniz uyumlu sürüme geçer. Güncelleme yoksa PHP sürümünü bir önceki çalışan sürüme geri alırsınız. Sürüm bilgisini panelinizden öğrenebilirsiniz.

• Hatanın başladığı tarihte PHP sürümünün değişip değişmediğini hosting panelinden kontrol edin.
• Yani, eklentinin ve temanın desteklediği PHP sürümünü geliştiricinin açıklamasında okuyun.
• Geçici çözüm olarak sürümü bir önceki çalışan sürüme geri alın.
• Ardından, kalıcı çözüm için eklenti ve temayı güncel sürümlere taşıyın.

Sürüm değiştirme adımları paneldeki araca göre değişir. Ayrıntısı için cPanel PHP sürümü değiştirme rehberimize bakın. Eski sürümde kalmak güvenlik riski taşıdığı için geri almayı yalnızca geçici bir adım olarak görün.

Bellek sınırı (memory limit) dolduğunda ne yaparsınız?

Bellek sınırı, bir PHP betiğinin kullanabileceği en yüksek RAM miktarıdır. Betik bu sınırı aşarsa kesilir ve günlükte “allowed memory size” benzeri bir ifade görürsünüz. Büyük görsel işleyen, yedek alan ya da içe aktarım yapan eklentilerde bu sık yaşanır.

WordPress’te bu sınır WP_MEMORY_LIMIT sabitiyle belirlenir, ancak hosting firmanızın koyduğu üst sınırı aşamaz. Dolayısıyla sabiti büyütmek her zaman işe yaramaz. Firmanın paketinizdeki limiti yükseltmesi gerekebilir.

• Günlükte bellek ifadesini gördüyseniz önce o işlemi yapan eklentiyi bulun.
• Daha sonra, hosting panelinde PHP bellek sınırı ayarı varsa makul bir artış yapın.
• Rakamı kendiniz uydurmayın; paketinizin izin verdiği değeri hosting firmasından öğrenin.
• Ayrıca, sınırı artırınca sorun çözülüyorsa neden bu kadar bellek harcandığını araştırın.

Kaynak sınırlarının nasıl çalıştığını hosting kaynak limitleri yazımızda anlattık. Sürekli bellek sorunu yaşıyorsanız paket yükseltmek eklentileri azaltmaktan daha kalıcı olabilir.

Hata yalnızca ön yüzde mi, yoksa yönetim panelinde de mi çıkıyor?

Bu ayrım size nedeni daraltmada yardımcı olur. Hata yalnızca ziyaretçi tarafında çıkıyorsa tema ya da ön yüzde çalışan bir eklenti şüphelidir. Yönetim panelinde de çıkıyorsa çekirdek, ortak bir eklenti ya da PHP düzeyinde bir sorun olasılığı artar.

Örneğin yalnızca belirli bir sayfada hata varsa o sayfada çalışan kısa kod ya da blok eklentisi şüphelidir. Öte yandan tüm sitede aynı anda çıkıyorsa genelde güncelleme, sürüm değişimi ya da bellek sorunu vardır. Dolayısıyla “nerede çıkıyor” sorusunu not almak değerlidir.

Bu ayrım kesin sonuç vermez; ancak denemeleri sıraya koyar. Böylece rastgele eklenti kapatmak yerine sistemli ilerlersiniz.

Yarım kalan güncelleme siteyi nasıl bozar?

Güncelleme sırasında WordPress, site klasörüne bir bakım dosyası koyar ve işlem bitince siler. Bağlantı kopar ya da süre dolarsa güncelleme yarıda kalır. Bu durumda bazı dosyalar yeni, bazıları eski sürümde kalır ve kod birbiriyle çakışır.

Belirti iki farklı biçimde görünür. Ya ziyaretçiler “kısa süreliğine bakımda” benzeri bir mesaj görür ya da ölümcül hata alırsınız. WordPress belgeleri birinci durumda site kök klasöründeki .maintenance dosyasını silmeyi önerir.

1. Hosting panelinden site kök klasörünü açın, yani wp-admin klasörünü içeren yeri.
2. Üstelik gizli dosyaları göstererek .maintenance dosyasını bulun.
3. Yani, dosyayı silin ve siteyi yenileyin.
4. Ardından, güncelleme tamamlanmadıysa yönetim panelinden yeniden başlatın.
5. Son olarak, ölümcül hata sürerse yarım kalan eklentiyi ya da çekirdeği yedekten geri yükleyin.

Yarım güncelleme eklentiyi bozduysa eklentiyi silip yeniden kurmak çoğu zaman yeterli olur. Çekirdek dosyalar bozulduysa temiz bir WordPress kopyasından yalnızca çekirdek klasörlerini yenilemek gerekir; bunu yedek almadan yapmayın.

Önbellek ve CDN bu uyarıyı etkiler mi?

Önbellek hatayı yaratmaz, ancak görünümünü uzatabilir. Düzelttiğiniz hâlde tarayıcınızda ya da önbellek eklentinizde eski hata sayfası saklanıyor olabilir. Bu durumda çözüm uygulanmış olsa bile hâlâ uyarıyı görürsünüz.

Bu nedenle düzeltmeden sonra önbelleği temizlemek gerekir. Ayrıca farklı bir cihazdan ya da gizli pencereden siteyi açmak, sorunun gerçekten bitip bitmediğini anlamanın hızlı yoludur. Bir CDN kullanıyorsanız onun önbelleğini de yenileyin.

• Tarayıcıda gizli pencere açıp siteyi yeniden deneyin.
• Daha sonra, önbellek eklentisinin önbelleğini panelden temizleyin.
• CDN kullanıyorsanız oradaki önbelleği de yenileyin.
• Ayrıca, siteyi başka bir ağdan ya da telefon verisiyle test edin.

Dışarıdan hızlı bir kontrol için site altyapı tespiti aracıyla sitenizin hangi altyapıyı kullandığına bakabilirsiniz. Böylece hatanın sizde mi yoksa herkeste mi göründüğünü ayırt edersiniz.

Hangi belirti hangi nedene işaret eder?

Aşağıdaki tablo, günlükte ya da ekranda gördüğünüz belirtiyi olası nedene ve ilk adıma bağlar. Bu tablo saha tecrübesine dayalı bir özettir; sitenizin gerçek nedenini yalnızca günlük gösterir.

Tabloyu bir kontrol listesi gibi kullanın. Ancak birden fazla neden aynı anda olabilir; bu nedenle bir adımı uyguladıktan sonra siteyi test edip sonuca göre ilerleyin.

Bu uyarı 500 hatasından, veritabanı hatasından ve hack şüphesinden nasıl ayrılır?

“Bu sitede kritik bir hata oluştu” WordPress’in kendi ürettiği, tasarlanmış bir uyarıdır. HTTP 500 ise sunucunun verdiği genel başarısızlık kodudur ve sayfa çoğu zaman sade bir sunucu mesajıyla gelir. İkisinin kökü benzer olsa da çözüm yolları farklıdır.

• Sunucunun kendi 500 sayfasını görüyorsanız 500 Internal Server Error rehberimize bakın.
• Üstelik “Veritabanı bağlantısı kurulurken hata oluştu” görüyorsanız veritabanı bağlantısı hatası çözümüne geçin.
• Tanımadığınız sayfalar, yönlendirmeler ya da bilmediğiniz yönetici hesapları varsa WordPress sitem hacklendi rehberini izleyin.

Bu üç durumu karıştırmak zaman kaybettirir. Dolayısıyla ekrandaki mesaja bakıp doğru rehbere gidin. Emin değilseniz sitenizin açık olup olmadığını site çöktü mü aracıyla dışarıdan da kontrol edebilirsiniz.

Mağaza ya da üyelik siteniz varsa neye ayrıca dikkat etmelisiniz?

Sipariş ya da üyelik alan sitelerde kesinti doğrudan gelir ve güven kaybı demektir. Bu yüzden müdahaleden önce son siparişlerin kaydedildiğinden emin olun. Ayrıca ödeme ve e-posta eklentilerini kapatmadan önce ne işe yaradıklarını düşünün.

Örneğin bir ödeme eklentisini kapatırsanız müşteri ödeme yapamaz, ama sayfa açılır. Üstelik bazı eklentiler kapatıldığında sipariş durumları güncellenmeyebilir. Dolayısıyla hata geçici olarak sürerken mağazayı bakım sayfasına almak, yarım çalışan bir mağazadan daha güvenlidir.

• Müdahaleden önce veritabanı yedeği alın, çünkü siparişler orada tutulur.
• Yani, ödeme ve kargo eklentilerini mümkünse en son kapatın.
• Çözümden sonra deneme siparişi ve ödeme akışını test edin.
• Ardından, müşteriye gerekirse kısa bir bilgilendirme yapın.

Bu bir örnek senaryodur; her mağazanın yapısı farklıdır. E-ticaret altyapınızı sağlam kurmak istiyorsanız e-ticaret danışmanlığı sayfamıza göz atabilirsiniz.

Sorun çözüldükten sonra neleri kapatmalı ve kontrol etmelisiniz?

Site geri geldiğinde işiniz bitmiş sayılmaz. Hata ayıklama modunu kapatmak, geçici adları eski haline getirmek ve gerçek ziyaretçi akışını test etmek gerekir. Aksi halde bir sonraki sorun daha zor fark edilir.

1. WP_DEBUG ve WP_DEBUG_LOG ayarlarını kapatın ve debug.log dosyasını silin.
2. Daha sonra, geçici olarak değiştirdiğiniz klasör adlarını kalıcı biçimde düzenleyin.
3. Ayrıca, ana sayfa, bir yazı, iletişim formu ve varsa ödeme adımını test edin.
4. Üstelik kurtarma modundan çıktığınızdan emin olun.
5. Yani, yeni bir yedek alıp çalışan hâli kayıt altına alın.
6. Son olarak, bir hafta boyunca sitenizi arada kontrol edin.

Aynı hatanın tekrar etmesi mümkündür; özellikle sorunlu eklentiyi yeniden açtıysanız. Bu nedenle ilk gün sonra değişiklik yapmadan gözlemleyin. Sunucu günlüklerinizi incelemek isterseniz log analizi aracımız size yardımcı olur.

Bu hatayı bir daha yaşamamak için ne yaparsınız?

Bu hata genellikle denetimsiz güncellemelerden doğar. Önleme planı basittir: değişiklikleri önce deneme ortamında test edin, düzenli yedek alın ve gereksiz eklentileri kaldırın. Her eklenti bir bakım yükü ve olası bir hata kaynağıdır.

• Güncellemeden önce tam yedek alın ve güncellemeyi trafiğin az olduğu saatte yapın.
• Ardından, büyük güncellemeleri önce kopya bir deneme sitesinde deneyin.
• Aktif geliştirilmeyen ya da uzun süredir güncellenmeyen eklentileri çıkarın.
• Daha sonra, pHP sürümünü değiştirmeden önce eklenti uyumluluğunu kontrol edin.
• Yönetici e-posta adresinizin güncel ve ulaşılabilir olduğundan emin olun.

Ayrıca bir eklentiyi eklemeden önce gerçekten gerekli olup olmadığını sorun. Bazen küçük bir ihtiyaç için ağır bir eklenti kurmak yerine hazır bir çözüm daha az risk taşır. Genel tercih için WordPress mi özel kodlama mı yazımıza göz atabilirsiniz.

Bu sitede kritik bir hata oluştu uyarısında ne zaman uzman desteği almalısınız?

Günlüğü okuyamıyorsanız, dosya düzenlemekten çekiniyorsanız ya da site gelir getiriyorsa uzman desteği almak mantıklıdır. Ekibimiz bu tür sorunlarda önce yedek alır, günlüğü okur ve en küçük müdahaleyle ilerler. Sonucu sitenin yapısı belirler; kesin çözüm sözü vermeyiz.

Destek ararken dikkatli olun. Para karşılığı “siteyi kesin açarım” diyen tanımadık kişilere yönetim bilgilerinizi vermeyin. Parolalarınızı paylaşmak yerine geçici ve sınırlı yetkili bir kullanıcı tanımlayın; iş bitince kullanıcıyı silin.

• Hosting firmanızın destek ekibi sunucu tarafını (PHP sürümü, bellek) kontrol edebilir.
• Ayrıca, eklenti geliştiricisi kendi eklentisindeki hatayı en iyi çözer.
• Site sürekli bozuluyorsa bakım ve güncelleme düzenini web tasarım ve bakım hizmetimizle birlikte ele alabiliriz.

Bu yazı genel bilgi içindir ve tüm siteler için aynı sonucu garanti etmez. Önemli verileriniz varsa işlem yapmadan önce yedek almayı unutmayın.