WordPress Eklenti Çakışması: Hızlı Teşhis ve Geri Alma

Bir eklenti ya da tema güncellemesinden hemen sonra beyaz ekran, 500 hatası, yönetim paneline erişememe veya bozulan bir ödeme formu görüyorsanız sorun yeni kod ile mevcut tema, başka bir eklenti, PHP sürümü ya da sunucu yapılandırması arasındaki uyumsuzluktan kaynaklanabilir. Bu belirtiler, tek başına hangi bileşenin hatalı olduğunu göstermez.

WordPress eklenti çakışması teşhisinde amaç bütün sistemi rastgele değiştirmek değil, son değişikliği izole ederek sorunu tekrarlanabilir hâle getirmektir. Önce belirtiyi sınıflandıracak, ardından log ve Recovery Mode bilgilerini kullanacak, en son dar kapsamlı bir geri alma uygulayacaksınız.

Sorunun gerçekten eklenti çakışması olduğunu belirleyin

İlk adım, belirtinin güncelleme zamanıyla ilişkisini doğrulamaktır. Güncellemeden önce çalışan bir özellik hemen sonrasında bozulduysa ilgili eklenti güçlü bir adaydır; ancak bu kesin kanıt değildir. Aynı anda PHP sürümü, tema, sunucu yapılandırması veya önbellek katmanı da değişmiş olabilir.

Belirtiyi ve son değişikliği kaydedin

Teşhise başlamadan önce aşağıdaki bilgileri kısa bir not hâline getirin:

• Hata tüm ziyaretçilerde mi, yalnızca yönetici hesabında mı görülüyor?
• Site tamamen mi açılmıyor, yoksa belirli bir sayfa veya işlem mi bozuluyor?
• Son değişiklikte hangi eklenti, tema veya PHP sürümü güncellendi?
• Hata sürekli mi, yoksa form gönderimi, ödeme adımı veya medya yükleme sonrasında mı oluşuyor?
• Tarayıcıda görülen HTTP durum kodu 500, 503 veya 404 mü?

Yönetim paneli açılıyor, ancak yalnızca belirli bir işlev bozuluyorsa teşhise o işlevi sağlayan eklentiden başlamak daha verimlidir. Tüm site beyaz ekran veriyorsa PHP fatal error, tema hatası veya kritik bir eklentinin yüklenememesi olasılığı artar.

Yedek ve geri dönüş yolunu hazırlayın

Dosya silmeden, veritabanı kaydı değiştirmeden veya sürüm düşürmeden önce çalışan bir yedek alın. Dosya ve veritabanının birlikte korunması için WordPress yedekleme stratejileri yaklaşımını inceleyebilirsiniz.

Geri dönüş planı, yalnızca eski sürümü yüklemekten ibaret değildir. Hangi dosyaların değişeceğini, veritabanına dokunulup dokunulmayacağını ve eski hâle hangi yöntemle döneceğinizi belirleyin. WooCommerce gibi veri yazan sitelerde bir yedeği geri yüklemek, yedeğin alınmasından sonra oluşan sipariş veya müşteri verilerini de geriye alabilir. Bu nedenle mümkünse yalnızca sorunlu bileşeni geri alın; tam yedek dönüşünü veri kaybı riskini değerlendirerek uygulayın.

WordPress Recovery Mode ile ilk teşhisi yapın

WordPress Recovery Mode, WordPress 5.2 ve sonraki sürümlerde kritik bir PHP hatası oluştuğunda sorun çıkaran eklenti veya temayı geçici olarak duraklatıp yöneticinin panele girmesine yardımcı olan yerleşik bir özelliktir. Hatalı bileşeni kalıcı olarak düzeltmez; yönetim erişimini geri kazanmanız için bir teşhis yolu sağlar.

Kurtarma e-postasını kontrol edin

WordPress hatayı yakalayabildiğinde site yöneticisinin e-posta adresine kurtarma bağlantısı gönderebilir. Bağlantıyı açtığınızda normal oturumdan ayrı bir kurtarma oturumu oluşturulur. Panelde genellikle hangi eklenti veya temanın etkilendiği, hata mesajının hangi dosyada ve satırda oluştuğu gösterilir.

E-postadaki dosya yolu tek başına yeterli kanıt değildir. Bir eklenti dosyası, başka bir eklentinin çağrısıyla çalışırken de hata verebilir. Hata zamanını, bileşen adını ve çağrı izini kaydedin; ardından sorunun oluştuğu işlevi kontrollü biçimde yeniden deneyin.

Kurtarma bağlantısı çalışmıyorsa süresi dolmuş, e-posta gecikmiş veya site kritik bir seviyede yanıt vermiyor olabilir. Aynı bağlantıyı tekrar tekrar kullanmak yerine sunucu erişiminizi ve logları kontrol edin.

Recovery Mode sonrasında ne yapın?

1. Panelde belirtilen eklentiyi geçici olarak devre dışı bırakın.
2. Hatanın görüldüğü sayfayı normal bir tarayıcı oturumunda kontrol edin.
3. Site düzelirse eklentiyi hemen yeniden etkinleştirmeyin; sürüm, tema ve PHP uyumluluğunu inceleyin.
4. Hata devam ederse temayı veya belirtilen diğer bileşeni ayrı bir aday olarak test edin.

Recovery Mode içinde yapılan devre dışı bırakma, ziyaretçiler için etkili olsa da kök nedeni ortadan kaldırmaz. Ödeme, üyelik, önbellek ve güvenlik eklentilerinde devre dışı bırakılan özelliğin başka bir bileşen tarafından bekleniyor olabileceğini ayrıca kontrol edin.

Panel açılmıyorsa eklentileri dosya sistemi üzerinden ayırın

Yönetim paneli hiç açılmıyorsa cPanel Dosya Yöneticisi, SFTP veya SSH ile WordPress kurulumunun wp-content dizinine erişin. İşleme başlamadan önce doğru site dizininde olduğunuzu doğrulayın. Aynı sunucuda birden fazla WordPress kurulumu varsa yanlış klasörde yapılan değişiklik başka bir siteyi etkileyebilir.

Tüm eklentileri geçici olarak devre dışı bırakma

Standart eklentiler wp-content/plugins altında bulunur. Bu klasörü örneğin plugins.disabled olarak yeniden adlandırdığınızda WordPress eklentileri yükleyemez ve çoğunu devre dışı kabul eder. Bu yöntem, erişimi geri kazanmak için geniş kapsamlı bir teşhistir; doğrudan kök nedeni kanıtlamaz.

Site açılırsa sorun büyük olasılıkla eklenti katmanındadır. Şimdi klasörü yeniden plugins olarak adlandırın ve eklentileri panelden tek tek etkinleştirin. Her etkinleştirmeden sonra aynı hatayı veren sayfayı kontrol edin. Birden fazla eklenti aynı işlemi etkiliyorsa iki eklentinin birlikte çalışmasından kaynaklanan bir çakışmayı değerlendirin.

Bu işlem yalnızca standart eklentileri kapsamayabilir. wp-content/mu-plugins içindeki must-use eklentiler, panelde normal eklenti listesinde görünmeden otomatik yüklenir. Tüm standart eklentiler kapalıyken hata sürüyorsa must-use eklentileri, temayı, PHP sürümünü ve sunucu loglarını ayrı değişkenler olarak inceleyin. Bu klasörde değişiklik yapmadan önce yedek alın ve geri dönüş için mevcut klasör adını not edin.

Aday eklentiyi dar kapsamda test etme

Tüm eklentiler kapatıldığında site düzelirse hepsini aynı anda geri açmayın. En son güncellenen eklentiden başlayarak bir eklentiyi etkinleştirin ve hatalı işlevi test edin. Sorun yeniden oluştuğunda son etkinleştirdiğiniz eklenti güçlü bir adaydır; çağrı izi ve logla doğrulama yapın.

Çok sayıda eklenti varsa ikili gruplama kullanabilirsiniz. Eklentilerin bir bölümünü etkinleştirip hatayı test edin. Sorun oluşursa adayları bu bölüm içinde azaltın; oluşmazsa diğer bölümü deneyin. Böylece her bileşeni sırayla etkinleştirmek yerine sorunlu küme daraltılır.

debug.log ile gerçek hata kaydını okuyun

Ekrandaki kritik hata veya sunucu hatası mesajı çoğu zaman kök nedeni açıklamaz. WordPress debug.log kaydı, PHP’nin hangi dosyada ve satırda hata verdiğini görmenizi sağlar. Kayıt, özellikle panel açılmadığında Recovery Mode bilgisini tamamlar.

Geçici ve kontrollü hata ayıklama

Üretim sitesinde hatayı ziyaretçilere göstermek yerine loga yazdırın. wp-config.php dosyasında, That's all, stop editing! satırından önce aşağıdaki ayarları kullanabilirsiniz. Dosyayı düzenlemeden önce bir kopyasını alın ve işlemi yalnızca yetkili yönetici erişimiyle yapın:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Bu ayarlar WordPress hata kayıtlarını genellikle wp-content/debug.log dosyasına yazar. Dosya oluşmuyorsa dosya izinlerini, PHP hata logunu ve hosting yapılandırmasını kontrol edin. Bazı sunucularda PHP hataları ayrıca web sunucusu veya PHP-FPM loguna yazılır.

Kaydı etkinleştirdikten sonra hatayı bir kez kontrollü biçimde yeniden üretin. Ardından logun son bölümünü zaman damgasıyla birlikte inceleyin. Aynı hatayı gereksiz yere tekrarlamak logu büyütebilir ve gerçek kaydı ayırmayı zorlaştırabilir.

Log satırını nasıl yorumlayın?

Fatal error, çalışmanın durduğunu gösterir. Call to undefined function veya Class not found gibi ifadeler eksik yükleme, uyumsuz sürüm ya da başka bir eklentinin beklenen sınıfı sağlamamasıyla ilişkili olabilir. Allowed memory size exhausted ise tek başına çakışmayı kanıtlamaz; bellek tüketimi, büyük sorgu veya hatalı döngü de aynı belirtiyi oluşturabilir.

Logdaki eklenti klasör adı faydalı bir ipucudur, fakat hatanın kesin kaynağı olmayabilir. Çağrı izinde hangi bileşenin hangi fonksiyonu çağırdığına bakın. PHP sürümünüz değiştiyse eski kodun yeni PHP davranışıyla uyumsuz olması da mümkündür. PHP sürümü ve eklenti uyumu konusunu kontrol etmek, sürüm değişikliğinden önce daha güvenli bir değerlendirme yapmanızı sağlar.

Teşhis tamamlanınca WP_DEBUG ve WP_DEBUG_LOG ayarlarını üretim ortamının ihtiyacına göre kapatın veya güvenli log yönetimi uygulayın. debug.log dosyasını herkese açık bir URL üzerinden erişilebilir bırakmayın; hata kayıtları dosya yolları, e-posta adresleri veya sorgu ayrıntıları içerebilir.

Tema, PHP ve önbellek kaynaklı belirtileri ayırın

Eklentileri tamamen kapattığınız hâlde hata sürüyorsa aktif temayı varsayılan bir WordPress temasıyla test etmek yararlı olabilir. Bu değişiklik canlı tasarımı etkileyebileceği için mümkünse staging ortamında yapılmalı, canlı sitede uygulanacaksa bakım penceresi ve geri dönüş adımı hazırlanmalıdır.

Staging kopyası, canlı siteden ayrılmış test ortamıdır. Güncelleme kombinasyonlarını ziyaretçilere etkisi olmadan denemek için staging ortamı kurma yaklaşımını kullanabilirsiniz. Staging canlı verilerden oluşturulduysa kişisel verilerin ve sipariş bilgilerinin erişimini sınırlayın; test ortamını herkese açık bırakmayın.

PHP sürümünü rastgele düşürmek veya yükseltmek yerine mevcut sürümü, eklentinin desteklediği sürümleri ve logdaki hatayı karşılaştırın. Sürüm değişikliği veri yapısını veya başka uygulamaları etkileyebilir. Değişiklik yapılacaksa yedek alın, tek bir değişkeni değiştirin ve aynı işlemi yeniden test edin.

Önbellek, eski JavaScript veya CSS dosyalarını sunarak güncelleme sonrası işlev bozulmuş izlenimi yaratabilir. PHP fatal error veya yönetim paneline girişteki sunucu hatası ise genellikle yalnızca önbellek temizlenerek düzelmez. Önce log ve erişim durumunu inceleyin; hata kaynağının önbellek katmanı olduğuna dair belirti varsa ilgili önbelleği temizleyin.

Geri alma kararını güvenli biçimde uygulayın

Çakışan bileşen belirlendiğinde en dar geri alma yöntemini seçin. Eklentiyi geçici olarak devre dışı bırakmak, tüm site yedeğini geri yüklemekten daha az veri riski taşır. Özellik kritikse üretici tarafından sağlanan önceki sürüme dönme seçeneğini veya paketini kullanın; rastgele bir kaynaktan eklenti dosyası indirmeyin.

Geri alma işleminden önce sorunlu dosyaların mevcut sürümünü saklayın, ilgili yedekleme noktasını not edin ve veritabanına dokunulup dokunulmayacağını belirleyin. WooCommerce sitelerinde işlem sürerken tam yedek dönüşü yapmadan önce sipariş ve müşteri verilerinin korunması için bir geri dönüş planı oluşturun.

Geri alma sonrasında şu kontrolleri yapın:

1. Hata veren sayfayı ve hatayı tetikleyen işlemi yeniden çalıştırın.
2. Yönetim paneli, giriş, form, ödeme ve e-posta gibi ilgili akışları kontrol edin.
3. Sunucu ve WordPress loglarında yeni bir fatal error oluşmadığını doğrulayın.

Geri alma sorunu çözüyor ancak güncelleme gerekli bir güvenlik veya uyumluluk düzeltmesi içeriyorsa, güncellemeyi kalıcı olarak bırakmadan nedenini araştırın. Sürüm notlarını, tema gereksinimlerini, PHP sürümünü ve diğer eklentilerle bilinen etkileşimleri kontrol edin. Güncellemeyi tekrar denemeden önce staging üzerinde canlıya yakın sürümlerle test edin.

Sık Sorulan Sorular

Eklentiyi silmek çakışmayı kesin olarak çözer mi?

Hayır. Eklentinin veritabanında bıraktığı ayarlar, tema kodu veya başka bir eklentiyle oluşan uyumsuzluk devam edebilir. Silme işleminden önce eklentinin kendi kaldırma davranışını, ayarlarının korunup korunmayacağını ve geri dönüş seçeneğini kontrol edin.

Recovery Mode e-postası gelmiyorsa ne yapmalıyım?

Spam klasörünü ve WordPress yönetici e-posta adresini kontrol edin. Siteye dosya erişiminiz varsa ilgili eklentiyi geçici olarak yeniden adlandırın; ardından hosting panelindeki PHP ve web sunucusu loglarını inceleyin. Bu durumda Recovery Mode yerine dosya sistemi teşhisi kullanmanız gerekebilir.

debug.log dosyasını ne kadar süre açık bırakmalıyım?

Yalnızca kontrollü teşhis süresince açık bırakın. Kaydı inceledikten sonra üretim ayarlarını gözden geçirin, dosyanın erişim izinlerini kontrol edin ve disk kullanımını izleyin. Logda kişisel veya operasyonel veri bulunuyorsa dosyayı yetkisiz kişilere açmayın.

Çakışma yalnızca yönetici hesabında görülüyorsa bu ne anlama gelir?

Yöneticiye özel bir eklenti, rol yetkisi veya yönetim paneli JavaScript hatası söz konusu olabilir. Ziyaretçi ve farklı yetkideki test kullanıcılarıyla ayrı ayrı kontrol yapın. Tarayıcı konsolundaki JavaScript hatalarını PHP loglarından bağımsız değerlendirin; iki hata türü aynı bileşenden kaynaklanabilse de aynı teşhis yöntemiyle doğrulanmaz.

Uygulanabilir kontrol listesi

• Belirtinin başladığı zamanı ve son güncellenen bileşeni not edin.
• Dosya veya veritabanı değişikliğinden önce geri dönüşü olan bir yedek hazırlayın.
• Recovery Mode e-postasını ve sunucu loglarını kontrol edin.
• Panel açılmıyorsa wp-content/plugins klasörünü silmeden geçici olarak yeniden adlandırın.
• Eklentileri tek tek veya küçük gruplar hâlinde etkinleştirerek hatayı yeniden üretin.
• Gerekirse debug.log kaydını ekrana hata bastırmadan kullanın.
• Tema, PHP sürümü, must-use eklentiler ve önbelleği ayrı değişkenler olarak test edin.
• Çakışan bileşeni yalnızca kontrollü biçimde geri alın ve ilgili işlevleri doğrulayın.

İlk sonraki adımı sitenizin erişim durumuna göre seçin: panel açılıyorsa eklentileri kontrollü biçimde ayırın; panel açılmıyorsa dosya erişimini ve Recovery Mode alternatifini hazırlayın. Sorunu staging ortamında yeniden üretebiliyorsanız kalıcı güncelleme kararını canlı siteye taşımadan önce orada doğrulayın.