WordPress Hata Similasyonu :)

WordPress Hata çözümleri nelerdir , wordpres neden hata verir , WordPress Hata çözümlerinde güvenilir taktikler, WordPress Hata çözümünde debug önemi nedir…

400 Hatalı İstek Nedir ve WordPress’te Neden Can Sıkar?

WordPress tarafında görülen en sinir bozucu hatalardan biri 400 Hatalı İstek mesajıdır. Çünkü bu hata, çoğu zaman net bir ipucu vermez: Sayfa açılmaz, yönetim paneli bazen kilitlenir, bazen yalnızca belirli bir sayfa patlar. 400 Hatalı İstek temelde tarayıcının sunucuya gönderdiği isteğin sunucu tarafından “geçersiz” kabul edilmesi demektir. Yani sunucu isteği alır, ama içeriğini doğru okuyamaz ya da güvenlik/kurallar nedeniyle reddeder.

İşin kötü tarafı şu: 400 Hatalı İstek kimi zaman tarayıcı tarafında minicik bir şey yüzünden çıkar, kimi zaman da sunucu tarafında sınırlar, güvenlik modülleri veya yanlış yapılandırma yüzünden. Bu yüzden yaklaşım geleneksel olmalı: önce en basit ihtimaller, sonra WordPress katmanı, en son sunucu ayarları.

WordPress Hata 400 Hatalı İstek Belirtileri

400 Hatalı İstek genelde “Bad Request” ya da doğrudan “400” olarak görünür. Bazen sadece belirli bir tarayıcıda çıkar, bazen tüm ziyaretçiler aynı hatayı görür. Yönetici girişi sonrası sayfanın yenilenip tekrar giriş ekranına atması da bazı senaryolarda 400 Hatalı İstek ile birlikte görülebilir. Özellikle çerez bozulması ve güvenlik duvarı tetiklenmesi bu tabloyu yaratır.

Hızlı Kontroller: En Çok Çözen Klasik Hamleler

Önce eski usul ama iş gören kontrollerle başlayın. 400 Hatalı İstek çoğu zaman tarayıcı önbelleği ve çerezlerden çıkar. Tarayıcıda sitenize ait çerezleri temizleyin, sonra önbelleği temizleyin ve sayfayı yeniden yükleyin. Ardından aynı sayfayı gizli pencerede deneyin. Burada amaç, 400 Hatalı İstek kaynağının tarayıcıda mı yoksa sunucuda mı olduğunu hızlıca ayırmaktır.

İkinci klasik kontrol URL tarafıdır. Adreste Türkçe karakterler, hatalı yüzde kodlamaları, kopyala-yapıştır sırasında bozulmuş parametreler varsa 400 Hatalı İstek tetiklenebilir. Özellikle reklam kampanyası linkleri, UTM parametreleri veya uzun sorgu dizgileri (query string) bu hatayı doğurabilir. Adresi sadeleştirip tekrar deneyin.

WordPress Katmanı: Eklenti, Tema ve .htaccess Çatışmaları

Tarayıcı tarafı temizse sıradaki şüpheli WordPress katmanıdır. 400 Hatalı İstek bazen güvenlik eklentilerinin agresif kurallarıyla, bazen cache eklentilerinin bozuk çıktılarıyla ortaya çıkar. FTP veya dosya yöneticisi ile wp-content/plugins klasörünü geçici olarak farklı bir isimle değiştirip eklentileri devre dışı bırakın. Site açılıyorsa 400 Hatalı İstek bir eklenti kuralından kaynaklanıyordur. Bu yöntemde amaç “tek hamlede teşhis” yapmaktır, modern süslemelere gerek yok.

Benzer şekilde temayı da test edin. Tema dosyalarında hatalı yönlendirme, bozuk header çıktısı veya istek başlıklarını şişiren bir script varsa 400 Hatalı İstek oluşabilir. Varsayılan bir temaya geçmek, sorunun tema mı eklenti mi olduğunu netleştirir.

.htaccess bozulması da klasik bir kaynaktır. WordPress kök dizinindeki .htaccess dosyasını yedekleyip geçici olarak kaldırın, ardından WordPress paneline girip kalıcı bağlantıları bir kez kaydedin (bu işlem yeni .htaccess üretir). Eğer panel yoksa, en azından temel WordPress kurallarını temiz şekilde geri koymak işe yarar. Aşağıdaki örnek, çoğu standart kurulum için başlangıç seviyesinde temiz bir iskelet sunar:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Çerez ve Başlık Şişmesi: 400 Hatalı İstek’in Gizli Faili

400 Hatalı İstek çok sık şu yüzden çıkar: Cookie başlığı aşırı büyümüştür. Özellikle çok sayıda eklenti, izleme aracı, A/B sistemi, reklam pikseli bir araya gelince tarayıcının gönderdiği cookie bloğu şişer. Sunucu da “bu başlık fazla büyük” diyerek 400 Hatalı İstek döndürebilir. Bu durumda çözüm sadece çerez temizlemek değil, çerez üreten bileşenleri azaltmak ve gereksiz izleme katmanlarını budamaktır. Geleneksel yaklaşım burada da işe yarar: ne kadar az parça, o kadar az arıza.

Sunucu Tarafı: Güvenlik Modülleri ve Limitler

Eğer 400 Hatalı İstek herkeste oluyorsa ve WordPress katmanında net bir tetikleyici bulamadıysanız, sıra sunucu ayarlarına gelir. Bazı sunucularda ModSecurity gibi kurallar belirli istekleri “şüpheli” görür ve 400 Hatalı İstek döndürür. Özellikle yönetim panelinde form gönderimleri, uzun POST istekleri, bazı parametre adları bu kurallara takılır.

Ayrıca Apache veya Nginx tarafında istek satırı ve başlık limitleri düşükse, uzun URL veya büyük header yüzünden 400 Hatalı İstek görülebilir. Bu ayarlar genelde .htaccess ile değil, sunucu yapılandırmasında yapılır. Örnek olması için tipik parametreleri aşağıya bırakıyorum; nerede uygulanacağı hosting yapınıza bağlıdır:

# Apache (VirtualHost / server config)
LimitRequestLine 8190
LimitRequestFieldSize 16380

# Nginx (server block / http context)
large_client_header_buffers 4 16k

Log Kayıtları: Tahminle Değil Kanıtla İlerleyin

400 Hatalı İstek gibi inatçı hatalarda, asıl netlik logdan gelir. Sunucu error log, access log ve varsa güvenlik duvarı loglarını kontrol edin. Eğer bir WAF kuralı tetikleniyorsa logda genellikle ilgili kural ID’si veya blok nedeni görünür. WordPress içinde de hata ayıklamayı açıp en azından kritik bir uyarı var mı bakabilirsiniz. Aşağıdaki ayarlar wp-config.php içine eklenebilir:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Kalıcı Çözüm: 400 Hatalı İstek Tekrar Yaşanmasın

400 Hatalı İstek ile bir kez uğraştıktan sonra aynı yere tekrar düşmemek gerekir. Birincisi, eklenti sayısını şişirmeyin; özellikle güvenlik, cache, optimizasyon ve izleme araçlarında “üst üste yığma” hastalığı 400 Hatalı İstek dahil birçok sorunu davet eder. İkincisi, çerez üreten sistemleri azaltın; gereksiz pazarlama scriptleri cookie başlığını büyütür. Üçüncüsü, staging ortamında değişiklik test edin; canlıda deneme-yanılma eski usulde bile risklidir. Son olarak, hosting tarafında limitlerinizi ve güvenlik katmanınızı tanıyın. Çünkü çoğu 400 Hatalı İstek, WordPress’ten çok çevresindeki katmanların kavgasıdır.

400 Hatalı İstek hatasını çözmek için önce tarayıcı ve URL, sonra WordPress eklenti/tema/.htaccess, en son sunucu güvenliği ve limitler. Bu sırayla giderseniz hem hızlı teşhis edersiniz hem de işi uzatmadan kapatırsınız.

403 Yasak Nedir ve WordPress’te Neden Bir Duvara Toslarsınız?

403 Yasak hatası, WordPress tarafında “giriş kapıda kaldı” hissi veren klasik bir problemdir. Tarayıcı sunucuya ulaşır, sunucu isteği anlar, ama bilinçli şekilde erişimi reddeder. Yani mesele bağlantı kopması değildir; mesele izin ve kural meselesidir. Bu yüzden 403 Yasak, çoğu zaman yanlış dosya izinleri, hatalı güvenlik kuralı, .htaccess kaynaklı engel, güvenlik duvarı (WAF) tetiklenmesi veya CDN tarafındaki bir blok nedeniyle ortaya çıkar.

Şunu net söyleyeyim: 403 Yasak bir rastlantı değildir. Sunucu “seni içeri almıyorum” diyordur. Bu da bize pratik bir yol haritası verir. Önce en sık rastlanan izin ve kural hatalarını temizleriz, sonra WordPress katmanında eklenti ve tema kaynaklı engelleri ayıklarız, en son CDN ve güvenlik duvarı tarafına ineriz. Eski usul bu sırayla giderseniz hem hızlı teşhis edersiniz hem de rastgele kurcalayıp siteyi daha kötü hale getirmezsiniz.

403 Yasak Belirtileri ve Tipik Senaryolar

403 Yasak bazen tüm siteyi kilitler, bazen sadece wp-admin ekranını, bazen de sadece belirli bir klasörü ya da görselleri. Örneğin medya dosyaları 403 Yasak verip içerik açılıyor olabilir. Bu durumda sorun genellikle uploads klasörü izinleri veya hotlink koruması gibi bir kuraldır. Bir diğer tipik senaryo da şu: Yönetici paneline girersiniz, sayfa ya açılmaz ya da aniden 403 Yasak döner. Bu tablo, çoğu zaman güvenlik eklentisi kuralı, IP bloklaması veya .htaccess içinde istemeden kalan bir deny kuralından çıkar.

Burada amaç şudur: 403 Yasak her yerde mi, sadece panelde mi, sadece belli dosyalarda mı? Bu ayrım, sizi doğrudan doğru yere götürür. Çünkü 403 Yasak “tek tip” değildir; kaynağına göre çözümü değişir.

İlk Temizlik: Tarayıcı Değil, Sunucu “İzin” Diyor

400 serisinde bazen tarayıcı tarafı belirleyicidir ama 403 Yasak çoğu zaman sunucu tarafında kurallara dayanır. Yine de çok basit bir kontrol yapın: siteye mobil internetten veya farklı bir ağdan girin. Eğer sadece sizin ağınızdan 403 Yasak çıkıyorsa, IP bazlı bir engel var demektir. Bu engel bazen host tarafında, bazen güvenlik eklentisinde, bazen de CDN tarafında olur.

Bu noktada panik yok. 403 Yasak genellikle geri alınabilir bir bloktur. Önemli olan, rastgele dosya silmek yerine kanıtla ilerlemek ve hangi katmanın engellediğini bulmaktır.

En Yaygın Kök Neden: Yanlış Dosya ve Klasör İzinleri

WordPress dosya izinleri konusu sıkıcıdır ama geleneğin sebebi var: Doğru izin, hem güvenliktir hem stabilitedir. İzinler fazla sıkıysa 403 Yasak çıkar. Fazla gevşekse site güvenlik riski alır. Standart kurulumlarda klasörler için 755, dosyalar için 644 çoğu zaman doğru başlangıç noktasıdır. Eğer yakın zamanda FTP ile dosya attıysanız, taşıma yaptıysanız veya sunucu kullanıcı/grup sahipliği karıştıysa 403 Yasak görmeniz şaşırtıcı olmaz.

SSH erişiminiz varsa izinleri toparlamak için tipik yaklaşım aşağıdaki gibidir. Bu komutlar her ortamda birebir aynı olmayabilir ama mantık aynıdır: klasörleri 755, dosyaları 644 yapmak.

find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

Bazı durumlarda mesele sadece izin değil, sahipliktir. Dosyalar yanlış kullanıcıya aitse sunucu erişimi yine reddedebilir ve 403 Yasak döndürebilir. Bu durumda host yapınıza uygun user:group ile sahipliği düzeltmek gerekir. Bu işlem hosta göre değişir; emin değilseniz rastgele denemek yerine host desteğine sorarsınız, çünkü yanlış chown komutu işi daha da karıştırabilir.

.htaccess Kaynaklı 403 Yasak: Tek Satırla Siteyi Kilitleyen Klasik Hata

403 Yasak denince .htaccess ilk şüphelilerden biridir. Çünkü bir gün güvenlik için eklenen bir satır, ertesi gün siteyi içeriden kilitleyebilir. Özellikle “deny from all” gibi kurallar, yanlış yerdeyse tüm siteyi kapatır. Bazen de belirli IP’leri engellemek isterken yanlışlıkla kendinizi engellersiniz. Bu yüzden .htaccess dosyasını yedekleyip geçici olarak devre dışı bırakmak, teşhis için çok temiz bir yöntemdir.

Örnek olarak, aşağıdaki gibi bir kural yanlış yerdeyse 403 Yasak kaçınılmaz olur. Bu kuralı körü körüne eklemeyin; burada amaç, neyin 403 Yasak ürettiğini anlamanız.

# Tehlikeli örnek: Yanlış yerdeyse her şeyi kilitler
Order allow,deny
Deny from all

Eğer 403 Yasak sadece wp-admin tarafında çıkıyorsa, wp-admin içine yanlışlıkla atılmış bir .htaccess dosyası da olabilir. Aynı şekilde uploads klasöründe bir deny kuralı varsa görseller 403 Yasak verir. Bu yüzden 403 Yasak nerede görünüyor sorusu yine kritik.

Güvenlik Eklentileri ve WAF Kuralları: İyi Niyetli Engel

WordPress güvenlik eklentileri bazen fazla hevesli davranır. Yönetim panelinde bir ayarı değiştirirsiniz, bir form gönderirsiniz, bir URL parametresi kullanırsınız ve hop 403 Yasak. Burada klasik yaklaşım şudur: Eklentileri devre dışı bırakıp test etmek. FTP ile wp-content/plugins klasörünü geçici olarak yeniden adlandırmak, tek hamlede tüm eklentileri devre dışı bırakır. Eğer 403 Yasak bir anda kayboluyorsa, suçlu eklentidir.

Benzer şekilde sunucu tarafında ModSecurity benzeri kurallar da bazı POST isteklerini “riskli” görüp 403 Yasak döndürebilir. Bu durum özellikle sayfa oluşturucu eklentiler, uzun içerik postları veya belirli karakter dizileri içeren isteklerde ortaya çıkar. Loglara bakmadan kesin konuşmak doğru olmaz ama 403 Yasak inatçıysa, error log ve güvenlik logları burada altın değerindedir.

CDN ve Hotlink Koruması: Görseller 403 Yasak Veriyorsa Şaşırmayın

Eğer 403 Yasak sadece görsellerde oluyorsa ve sayfa metni yükleniyorsa, çoğu zaman problem hotlink koruması veya CDN kuralıdır. Bazı site sahipleri başka siteler görsellerini çalmasın diye hotlink kapatır, sonra bir gün tema veya alan adı yapısı değişince kendi sitesi de görselleri çekemez hale gelir ve 403 Yasak başlar. CDN kullanıyorsanız, örnek olarak :contentReference[oaicite:0]{index=0} tarafında güvenlik seviyesi, firewall kuralı veya bir sayfa kuralı görsel isteklerini engelliyor olabilir.

Bu bölümde prensip yine aynı: 403 Yasak nerede çıkıyor? Sadece /wp-content/uploads/ altında mı, yoksa tüm sitede mi? Eğer sadece görsellerdeyse, CDN ve hotlink kuralları ilk bakılacak yerdir.

Log Kayıtlarıyla Son Nokta: 403 Yasak Nedenini Netleştirin

403 Yasak bazen “dosya izni” bazen “kural bloğu” olduğundan, loglar kesin teşhis sağlar. Access log içinde 403 Yasak dönen URL’leri izleyin. Error log içinde “permission denied” benzeri ifadeler arayın. Güvenlik loglarında kural tetiklenmesi görürseniz, hangi parametrenin takıldığını yakalarsınız. Bu, rastgele çözüm değil, doğrudan hedefe atış demektir.

Kalıcı Çözüm Mantığı: 403 Yasak Tekrar Etmesin

403 Yasak hatasını bir kere temizlemek yetmez; tekrar etmemesi için düzen şarttır. Dosya izinlerini standarda oturtun, .htaccess değişikliklerini gelişi güzel değil kontrollü yapın, güvenlik eklentilerinde bloklama kurallarını abartmayın, CDN ve hotlink ayarlarını her alan adı ve yapı değişikliğinden sonra kontrol edin. WordPress yönetimi biraz disiplin işidir; bu disiplin olmazsa 403 Yasak gibi hatalar fırsat buldukça geri gelir.

Toparlayayım: 403 Yasak gördüğünüzde “site bozuldu” diye değil, “hangi katman izin vermiyor” diye düşünün. İzinler, .htaccess, eklentiler, CDN ve loglar. Bu sırayı takip ederseniz 403 Yasak sizi uğraştırmaz, siz onu terbiye edersiniz.

404 Bulunamadı Nedir ve WordPress’te Neden Sürekli Karşınıza Çıkar?

404 Bulunamadı hatası, WordPress dünyasında en yaygın görülen problemlerden biridir ve çoğu zaman sessizce sitenin itibarını kemirir. Çünkü site genel olarak çalışıyordur, yönetim paneli açıktır, içerikler vardır; ama kullanıcı bir bağlantıya tıkladığında karşısına 404 Bulunamadı çıkar. Bu durum, özellikle arama motorlarından gelen ziyaretçilerde güven kaybı yaratır. İnsan “burada bir şeyler eksik” diye düşünür. Dahası, sitenizde kırık linkler birikirse, arama motorları da bunu hoş karşılamaz.

404 Bulunamadı temelde şunu söyler: Sunucuya bir URL soruldu ama o URL’ye ait bir içerik bulunamadı. Bu bazen gerçekten silinmiş bir sayfadır, bazen yanlış yazılmış bir URL’dir, bazen de WordPress kalıcı bağlantı yapısı bozulduğu için sistem doğru sayfayı bulamaz. İşin püf noktası şudur: 404 Bulunamadı hatası “tek bir neden” değildir; doğru çözüm, kaynağı doğru teşhis etmekten geçer.

404 Bulunamadı Hatasının En Klasik Nedenleri

404 Bulunamadı çoğu zaman içerik taşınması, URL değişimi veya kategori/etiket yapısının elden geçmesi sonrası patlar. Bir sayfayı farklı bir bağlantıya taşırsınız ama eski linkleri yönlendirmezsiniz; sonuç 404 Bulunamadı. Ya da bir eklenti kaldırırsınız, onun ürettiği özel URL’ler kaybolur; yine 404 Bulunamadı. Tema değişiminden sonra eski menülerde hâlâ eski bağlantılar kalır; kullanıcı tıklar, yine 404 Bulunamadı.

Bir diğer yaygın sebep kalıcı bağlantıların (permalink) bozulmasıdır. WordPress bazen taşıma sonrası, sunucu ayarı değişikliği sonrası veya .htaccess dosyası kurcalandıktan sonra yönlendirme kurallarını doğru okuyamaz. Bu durumda var olan içerikler bile 404 Bulunamadı verebilir. Yani içerik duruyor ama WordPress onu doğru eşleyemiyordur.

İlk Teşhis: 404 Bulunamadı Her Yerde mi, Sadece Bazı Sayfalarda mı?

Önce temel ayrımı yapın. Eğer sadece birkaç URL’de 404 Bulunamadı çıkıyorsa, sorun genellikle bozuk link veya silinen içeriktir. Eğer sitenin büyük kısmı 404 Bulunamadı veriyorsa, bu daha çok kalıcı bağlantı yapısı veya yönlendirme kurallarıyla ilgili bir problemdir. Bu ayrım, gereksiz yere saatlerce oyalamayı engeller. Çünkü birkaç link bozuksa çözüm bağlantıları düzeltmektir; tüm site bozuksa çözüm altyapıyı düzeltmektir.

Kalıcı Bağlantıları Yenileme: Basit Ama Çok Etkili

WordPress’te 404 Bulunamadı için en çok işe yarayan klasik yöntemlerden biri kalıcı bağlantıları yeniden kaydetmektir. Yönetim panelinde kalıcı bağlantılar sayfasına girip herhangi bir değişiklik yapmadan kaydetmek bile bazen tüm 404 Bulunamadı problemini bitirir. Bunun sebebi, WordPress’in rewrite kurallarını yeniden üretmesidir. Eğer bu işlemden sonra 404 Bulunamadı kayboluyorsa, problem içerikte değil, yönlendirme altyapısındaymış demektir.

Panel erişiminiz yoksa veya sorun paneli de etkiliyorsa, .htaccess dosyasını kontrol etmek gerekir. WordPress kök dizininde .htaccess yoksa ya da bozuksa, 404 Bulunamadı kaçınılmaz hale gelebilir. Aşağıdaki örnek, çoğu standart WordPress kurulumunda temel yönlendirme iskeletidir:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bu dosyayı ekledikten sonra hâlâ 404 Bulunamadı görüyorsanız, sunucuda mod_rewrite kapalı olabilir veya Nginx kullanıyorsanız zaten .htaccess çalışmıyordur. Bu noktada sunucu katmanına inmek gerekir.

Nginx Kullananlar İçin 404 Bulunamadı: try_files Kuralı

Nginx’te WordPress için yönlendirme mantığı farklıdır. .htaccess yerine site yapılandırmasında bir kural gerekir. Nginx tarafında eksik veya hatalı bir try_files satırı, içerikler durduğu halde 404 Bulunamadı üretir. Aşağıdaki örnek tipik bir WordPress kuralıdır:

location / {
  try_files $uri $uri/ /index.php?$args;
}

Buradaki mantık basittir: Dosya veya klasör gerçekten varsa onu aç, yoksa index.php’ye düşür. Bu kural eksikse, WordPress’in “isteği içeriğe eşleme” mekanizması devreye giremez ve 404 Bulunamadı artar.

Silinen İçerik ve Taşınan Sayfalar: 404 Bulunamadı Yerine 301 Yönlendirme

404 Bulunamadı hatasının en doğru “kalıcı” çözümü, taşınan veya silinen içerikler için doğru yönlendirmeyi kurmaktır. Eski linkler yıllarca internette kalır; insanlar kaydeder, başka siteler link verir, arama motoru indeksler. Siz o sayfayı farklı bir URL’ye taşıdıysanız, kullanıcıyı boş duvara çarptırmak yerine yeni adrese yönlendirmek gerekir. Apache tarafında basit bir 301 yönlendirme örneği aşağıdaki gibidir:

Redirect 301 /eski-sayfa/ https://siteadresiniz.com/yeni-sayfa/

Bazen daha esnek bir yapı gerekir. Örneğin bir kategori yapısını komple değiştirdiyseniz, belirli bir desenle yönlendirme yapmak isteyebilirsiniz. Bu da yine rewrite kurallarıyla yönetilebilir. Önemli olan, 404 Bulunamadı’yi “kader” gibi görmemektir; yönlendirme yapmayı bilmek, WordPress yöneten herkesin eski usul temel disiplinidir.

Özel 404 Sayfası: Kullanıcıyı Kaybetmeyin

Her 404 Bulunamadı hatasını sıfıra indirmek gerçekçi değildir. Bazen kullanıcı yanlış yazar, bazen tarayıcı eski bir link taşır, bazen botlar saçma URL’ler dener. Bu yüzden özel 404 sayfası, işin “zararı azaltma” tarafıdır. İyi bir 404 sayfası; kullanıcıya ne olduğunu söyler, arama kutusu sunar, ana sayfaya dönüş yolu verir ve ziyaretçiyi sitede tutar. Ama burada ince bir çizgi var: 404 Bulunamadı sayfasını süsleyip komiklik yapacağım derken, asıl hedefi kaçırmayın. Amaç kullanıcıyı tekrar doğru içeriğe taşımaktır.

404 Bulunamadı Takibi: Sorunu Saklamayın, Avlayın

404 Bulunamadı hatasını gerçekten bitirmek istiyorsanız, düzenli takip şarttır. Kırık linkler genelde “bir kere olur biter” diye düşünülür ama içerik büyüdükçe yeniden çıkar. Siteye yeni yazılar eklenir, bazı sayfalar kaldırılır, menüler güncellenir; 404 Bulunamadı tekrar birikir. Bu yüzden loglar ve arama konsolu raporları üzerinden 404 Bulunamadı URL’lerini yakalayıp ya düzeltmek ya yönlendirmek gerekir. Eski usul bakımın kıymeti burada çıkar: düzenli kontrol, düzenli temizlik, düzenli yönlendirme.

Son Dokunuş: 404 Bulunamadı Sorununu Kökten Bitiren Zihniyet

404 Bulunamadı ile mücadelede en büyük hata, sadece “hata çıkınca” müdahale etmektir. Doğru yaklaşım, değişiklik yaparken sonucu düşünmektir. URL değiştiriyorsanız yönlendirme planı yaparsınız. Tema değiştiriyorsanız menüleri kontrol edersiniz. Taşıma yapıyorsanız kalıcı bağlantıları test edersiniz. Bu disiplin oturduğunda 404 Bulunamadı sitenizde istisna olur, alışkanlık değil.

405 Yöntemi İzin Verilmiyor Nedir ve WordPress’te Neden Ortaya Çıkar?

405 Yöntemi İzin Verilmiyor hatası, WordPress tarafında can sıkan ama “izini nerede kapattım” diye doğru yerden bakılırsa hızlı çözülebilen bir durumdur. Mantığı nettir: Tarayıcı ya da bir bot sunucuya bir istek gönderir, sunucu bu isteği alır, hedef URL’yi tanır ama kullanılan HTTP yöntemini kabul etmez. Yani sorun “sayfa yok” değildir, sorun “bu sayfaya böyle gelinmez” meselesidir. Bu yüzden 405 Yöntemi İzin Verilmiyor çoğu zaman yanlış yapılandırılmış bir kuraldan, güvenlik katmanından, cache/CDN ayarından veya WordPress içindeki bir eklentinin yöntem kısıtlamasından çıkar.

Bu yazıda işi geleneksel usulde ele alacağız: önce en basit teşhis, sonra WordPress katmanı, en son sunucu katmanı. Çünkü bu hata bir WordPress Hata gibi görünse de, çoğu zaman WordPress’in çevresindeki kuralların kavgasıdır. Bir başka deyişle, WordPress Hata deyip geçmeyin; 405’te “yöntem” kelimesi sizi doğrudan doğru yere götürür.

405 Yöntemi İzin Verilmiyor ile 403 Yasak Arasındaki İnce Fark

403 Yasak genelde “erişim yok” der. 405 Yöntemi İzin Verilmiyor ise “erişim var ama yanlış yöntemle geldin” der. Örneğin bir endpoint yalnızca GET kabul ederken siz POST gönderirseniz 405 görürsünüz. Ya da bir form/REST isteği normalde POST ile gitmeliyken araya giren bir yönlendirme bunu GET’e çevirir, sistem de “ben bunu kabul etmiyorum” diyerek 405 döndürür. Bu ayrım, sorunu yarım saatte mi çözeceğinizi yoksa yarım gün mü oyalanacağınızı belirler.

WordPress’te 405 En Çok Hangi Durumlarda Görülür?

405 Yöntemi İzin Verilmiyor çoğu zaman üç yerde patlar. Birincisi wp-admin içinde bazı işlemler sırasında, özellikle güvenlik eklentilerinin agresif ayarları devreye girdiğinde. İkincisi REST API kullanan temalar ve eklentilerde; sayfa oluşturucular, sipariş sistemleri, üyelik eklentileri gibi bileşenler arka planda sürekli istek atar. Üçüncüsü de cache/CDN katmanında; bazen bir kural “PUT, DELETE, PATCH gibi yöntemleri kapatayım” diye eklenir, sonra meşru bir istek de o kuralın altına girer ve 405 başlar.

Bu noktada net konuşayım: 405 Yöntemi İzin Verilmiyor hatası çıktığında “WordPress bozuldu” diye panik yapmak gereksiz. Bu tip bir WordPress Hata genelde yanlış bir kuralın ürünüdür ve doğru sırayla teşhis edilirse temizlenir.

Hızlı Teşhis: Hata Herkeste mi, Sadece Sizde mi?

Önce basit bir ayrım yapın. Farklı bir cihazdan, farklı bir ağdan deneyin. Eğer sadece sizde 405 Yöntemi İzin Verilmiyor çıkıyorsa, çoğu zaman tarayıcı uzantıları, bozuk cache veya ara katmanda bir proxy etkisi devrededir. Eğer herkeste çıkıyorsa, problem sunucu kuralı, CDN veya WordPress katmanındaki global bir ayardır. Bu ayrım, gereksiz yere kod kurcalamayı engeller.

Bir de şunu yapın: Sorun sadece belirli bir sayfada mı, yoksa belli bir işlemde mi çıkıyor? Örneğin giriş, kayıt, ödeme, form gönderme gibi bir aksiyonda 405 görüyorsanız, o aksiyonun hangi yöntemle çalıştığını hedefleyerek ilerlemek gerekir. Sayfayı yenilemek, tarayıcı önbelleğini temizlemek gibi klasik hamleler bazen işe yarar, ama 405’te asıl mesele “yöntemin nerede değiştiği”dir.

WordPress Katmanı: Eklenti ve Tema Çakışmalarını Ayıklama

405 Yöntemi İzin Verilmiyor, güvenlik eklentilerinin veya bazı performans eklentilerinin “istek filtreleme” davranışları yüzünden tetiklenebilir. Özellikle REST API’yi kısıtlayan, XML-RPC’yi sert şekilde kapatan ya da belirli endpoint’lere kural koyan eklentiler bu hatayı üretebilir. Burada eski usul yöntem en hızlısıdır: eklentileri geçici olarak devre dışı bırakıp test etmek. FTP üzerinden wp-content/plugins klasörünü geçici olarak yeniden adlandırmak, tek hamlede tüm eklentileri kapatır. 405 kayboluyorsa, sorun WordPress çekirdeği değil; bir eklentinin kuralıdır.

Tema tarafı da masum değildir. Bazı temalar admin-ajax.php veya REST isteklerini farklı yollarla çağırır. Bir yönlendirme eklentisiyle birleşince istek yöntemi bozulabilir. Temayı varsayılan bir temaya çekip test etmek, temanın payını hızlıca ortaya çıkarır.

Sunucu Katmanı: Apache ve Nginx’te Yöntem Kısıtlamaları

405 Yöntemi İzin Verilmiyor hatasının en “temiz” kaynaklarından biri sunucu yapılandırmasıdır. Birileri güvenlik için HTTP yöntemlerini sınırlamış olabilir. Normalde kötü bir fikir değildir; ama yanlış yerde uygulanırsa WordPress’in meşru isteklerini de boğar. Apache tarafında bazen .htaccess içine eklenen kural, istenmeyen yöntemleri engellerken istemeden POST’u da engeller ve sonuç 405 olur. Örnek bir kural aşağıdaki gibi görünür. Bunu olduğu gibi yapıştırma niyetiyle değil, neyin 405 üretebileceğini anlamanız için veriyorum:

<LimitExcept GET POST HEAD>
  Require all denied
</LimitExcept>

Nginx tarafında da benzer bir yaklaşım vardır. Bazı yapılandırmalar “GET ve HEAD dışını reddet” gibi sert kurallarla gelir. WordPress sitenizde form gönderimleri, ödeme işlemleri veya REST istekleri varsa bu kural 405 Yöntemi İzin Verilmiyor üretir. Basit bir örnek:

if ($request_method !~ ^(GET|POST|HEAD)$ ) {
  return 405;
}

Burada kritik olan şudur: WordPress’in hangi işlemi hangi yöntemi kullanıyor? Sitenizde sadece içerik okunan bir yapı yoksa, POST’u yanlışlıkla kesmek işleri yakar. Bu yüzden “güvenlik” adına konan kuralları körlemesine bırakmak yerine, site işleyişine göre ayarlamak gerekir.

Log Kayıtları: 405’in Gerçek Sebebini Nokta Atışı Bulma

405 Yöntemi İzin Verilmiyor gibi hatalarda loglar çok şey söyler. Access log’da 405 dönen URL’yi görürsünüz, aynı anda hangi yöntemle (GET mi POST mu) geldiğini de yakalarsınız. Error log ya da güvenlik log’larında “blocked method” benzeri bir not varsa, hatanın kaynağı netleşir. Bu yaklaşım “tahminle değil kanıtla” ilerlemenin en pratik yoludur.

WordPress tarafında debug log da yardımcı olur. Aşağıdaki ayarlar wp-config.php içinde kullanılabilir ve özellikle eklenti kaynaklı bir davranış varsa ipucu bırakabilir:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Kalıcı Çözüm Mantığı: 405 Tekrar Etmesin

405 Yöntemi İzin Verilmiyor hatasını temizledikten sonra iş bitmez. Kalıcı çözüm, kuralı doğru yere taşımaktır. Eğer CDN veya güvenlik duvarı kullanıyorsanız, kuralların REST ve admin işlemlerine engel olmadığından emin olun. Eğer sunucu tarafında yöntem kısıtı varsa, WordPress’in ihtiyaç duyduğu yöntemleri kapsayacak şekilde düzenleyin. Eklenti tarafında ise “REST kapat, XML-RPC kapat, her şeyi kilitle” yaklaşımı çoğu sitede ters teper. Güvenlik, siteyi çalışmaz hale getirmek değildir; kontrollü, mantıklı sınır koymaktır.

413 İstek Varlığı Çok Büyük Nedir ve WordPress’te Neden Bir Anda Duvara Çarparsınız?

413 İstek Varlığı Çok Büyük hatası, özellikle dosya yükleme işlerinde insanı çıldırtan bir hatadır. Çünkü siz gayet normal bir görsel, yedek, tema paketi ya da eklenti zip dosyası yüklediğinizi sanırsınız; sunucu ise net bir şekilde “Bu istek bana fazla büyük, kabul etmiyorum” der. Bu durum çoğu zaman WordPress’in kendi sınırından değil, sunucunun, ters proxy’nin veya CDN katmanının koyduğu limitlerden kaynaklanır. Yani bu hata bir WordPress Hata gibi görünse de, sahnenin arkasında sunucu kuralları konuşuyordur.

Bu noktada klasik yaklaşım şarttır: önce hatanın nerede üretildiğini bulacağız, sonra doğru katmanda limiti artıracağız. Aksi halde wp-config.php ile oynarsınız, eklenti değiştirirsiniz, tema değiştirirsiniz; ama 413 yine aynı yerde çıkar. Çünkü 413 İstek Varlığı Çok Büyük hatasında “yük” çoğu zaman WordPress’e ulaşmadan kesilir. Bu yüzden WordPress Hata deyip sadece WordPress içinde aramak, sizi gereksiz yere oyalayan bir alışkanlıktır.

413 İstek Varlığı Çok Büyük Hangi Durumlarda Görülür?

En sık senaryo şudur: Medya Kütüphanesine büyük bir görsel veya video yüklersiniz, 413 çıkar. İkinci senaryo: WordPress panelinden tema veya eklenti yüklemeye çalışırsınız, yine 413 çıkar. Üçüncü senaryo: Bir yedek eklentisiyle büyük bir yedek dosyası geri yüklemek istersiniz, 413 çıkar. Bu üç tabloda ortak nokta aynıdır: sunucu, gelen isteğin gövdesini (request body) belirli bir boyutun üstünde kabul etmiyordur.

Bazen bu hata tarayıcıda direkt 413 olarak görünür, bazen hosting firması farklı bir sayfa basar, bazen de sadece yükleme ekranda dönüp sonra hata verir. Ama özü değişmez: sınır aşıldı. Bu yüzden teşhis de nettir: aynı dosyayı daha küçük bir boyutla denediğinizde yükleme oluyorsa, sorun dosya boyutu limitidir.

Bu Hata WordPress’ten Mi Geliyor, Sunucudan Mı?

İşi hızlandıran soru budur. WordPress tarafında PHP limitleri düşükse genellikle “upload_max_filesize” veya “post_max_size” sınırına takılırsınız ve bazen WordPress daha açıklayıcı bir hata verir. Ama 413 İstek Varlığı Çok Büyük çoğunlukla Nginx, Apache, CDN veya güvenlik duvarı gibi bir ara katmandan gelir. Yani istek WordPress’e ulaşmadan kesilir. Bu nedenle log kontrolü çok değerlidir: Nginx error log veya Apache error log içinde “client intended to send too large body” benzeri bir kayıt görürseniz, mesele nettir. Bu, WordPress Hata değilmiş gibi görünen ama WordPress’i doğrudan kilitleyen türdendir.

Pratik bir kontrol daha var: Aynı yüklemeyi farklı bir yöntemle deneyin. Örneğin medya yüklemesini WordPress panelinden yapınca 413 çıkıyor ama FTP ile dosyayı uploads klasörüne atınca sorun olmuyorsa, bu doğrudan HTTP istek boyutu limiti demektir. FTP ile atmak geçici bir çözümdür; asıl çözüm limiti doğru yerden büyütmektir.

PHP Limitleri: upload_max_filesize ve post_max_size

WordPress’in yükleme işlemleri PHP üzerinden çalışır. PHP tarafında upload_max_filesize küçükse büyük dosya zaten yüklenemez. post_max_size küçükse form üzerinden gönderilen veri (dosya dahil) kesilir. Bu ikisi genelde birlikte artırılır. Ayrıca bazı işlemlerde max_execution_time da önemlidir; dosya büyükse yükleme ve işleme süresi uzar.

Bu ayarlar hosting yapınıza göre php.ini içinde, .user.ini içinde, panel üzerinden veya .htaccess üzerinden yönetilebilir. Aşağıdaki örnekler temel mantığı gösterir:

; php.ini veya .user.ini örneği
upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
memory_limit = 256M

Apache + PHP modülü kullanan bazı kurulumlarda .htaccess ile de tanımlama yapılabilir. Her sunucuda çalışacağı garanti değildir ama örnek şudur:

# .htaccess örneği (her ortamda geçerli olmayabilir)
php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value memory_limit 256M

Burada kritik kural şudur: post_max_size değeri upload_max_filesize değerinden küçük olmamalıdır. Aksi halde yine 413 benzeri davranışlar yaşarsınız. Ayrıca yalnızca bu değerleri artırıp bırakmak da yetmez; dosya gerçekten çok büyükse sunucu katmanı ayrıca engelliyor olabilir.

Nginx ve Proxy Katmanı: client_max_body_size

Nginx kullanan sistemlerde 413 İstek Varlığı Çok Büyük hatasının en klasik sebebi client_max_body_size değerinin düşük olmasıdır. Bu limit düşükse, PHP ayarlarını artırmanız hiçbir işe yaramaz; çünkü istek Nginx tarafından daha baştan reddedilir. Çözüm Nginx yapılandırmasında ilgili blokta bu limiti artırmaktır:

# Nginx server veya location bloğunda
client_max_body_size 256m;

Bir ters proxy kullanıyorsanız (örneğin Nginx önde, Apache arkada veya başka bir load balancer), limit yalnızca bir yerde değil iki yerde de olabilir. Öndeki katman küçükse arka katmanın büyük olması sizi kurtarmaz. Bu yüzden 413 hatasında katmanları tek tek düşünmek gerekir: CDN, proxy, web sunucusu, PHP. Her biri kendi sınırını koyabilir.

Apache Tarafı: LimitRequestBody ve Benzeri Kısıtlar

Apache üzerinde de istek gövdesi sınırlanabilir. Bazı güvenlik yapılandırmaları veya yanlış bir kural yüzünden LimitRequestBody ile küçük bir değer tanımlandıysa, büyük yüklemelerde 413 görebilirsiniz. Bu tür ayarlar genelde vhost veya sunucu konfigürasyonunda olur. Örnek bir ifade aşağıdaki gibidir:

# Apache (genellikle VirtualHost içinde)
LimitRequestBody 0

Burada 0 çoğu senaryoda sınırsız anlamına gelir; ama gerçek hayatta sınırsız bırakmak her zaman doğru değildir. Doğrusu, sitenizin ihtiyacına göre mantıklı bir üst limit belirlemektir. Güvenlik ile işlevsellik arasında denge kurulmazsa bu tip problemler geri gelir.

Kalıcı Çözüm: Dosya Yükleme İşini Sağlamlaştırma

413 İstek Varlığı Çok Büyük hatasını kalıcı olarak bitirmek için yalnızca bir rakamı büyütmek yetmez. Birincisi, ihtiyacınız olan gerçek yükleme boyutunu belirleyin. İkincisi, limitleri aynı seviyeye getirip katmanlar arası çelişki bırakmayın. Üçüncüsü, çok büyük medya dosyaları için doğru yöntem kullanın; gereksiz yere 1-2 GB dosyayı panelden yüklemeye çalışmak, sırf sorun çıkarmak için davetiye çıkarmaktır. Büyük dosyalarda daha doğru yaklaşım, sunucuya doğrudan yükleme ve WordPress’e sadece tanıtma yöntemidir. Dördüncüsü, cache ve güvenlik eklentilerinin upload isteklerine müdahale edip etmediğini kontrol edin. Çünkü bazen iyi niyetli bir güvenlik kuralı, upload isteğini “şüpheli” görüp kesebilir.

Son söz: 413 İstek Varlığı Çok Büyük hatasında sorumluyu doğru seçin. Bu bir WordPress Hata gibi görünür ama çoğu zaman WordPress suçlu değildir. Suçlu, limit koyan katmandır. Katmanı bulur, limiti doğru yerden artırır, işi bitirirsiniz.

429 Çok Fazla İstek Nedir ve WordPress’te Neden Bir Anda Kilitlenme Hissi Verir?

429 Çok Fazla İstek hatası, özellikle trafik artışlarında veya saldırı benzeri yoğun istek durumlarında ortaya çıkan bir “koruma refleksi” hatasıdır. Sunucu, CDN ya da güvenlik katmanı, kısa süre içinde aynı kaynaktan (bazen aynı IP, bazen aynı kullanıcı oturumu, bazen aynı endpoint) çok fazla istek geldiğini görür ve sistemi korumak için isteği reddeder. Sonuç olarak tarayıcıda 429 mesajını görürsünüz. Bu, çoğu zaman gerçek bir WordPress Hata değildir; WordPress’in üstüne giydirilmiş koruma katmanlarının limitidir. Ama kullanıcı açısından sonuç değişmez: site açılmaz, yönetim paneli zorlanır, formlar çalışmaz, API çağrıları patlar.

Şunu açık söyleyeyim: 429 hata veren bir sitede “bir şeyler çok iyi gidiyor” demek saflık olur. Ya gerçekten anormal trafik alıyorsunuz, ya bir bot sürüsü siteye abanıyor, ya da limitleriniz gereğinden fazla kısıtlı. Bu yüzden 429 Çok Fazla İstek, doğru teşhis edilirse hızlı biter; yanlış yerden kurcalanırsa günlerce sürer. Bu yazıda işi eski usul, sağlam bir sırayla ele alacağım.

429 Çok Fazla İstek Hangi Senaryolarda Görülür?

En tipik senaryo giriş sayfasıdır. wp-login.php veya /wp-admin, botlar tarafından sürekli denenir ve güvenlik sistemi “rate limit” devreye sokar. İkinci senaryo, ağır sayfa oluşturucuların veya temaların arka planda çok sık istek atmasıdır. Admin-ajax.php veya REST çağrıları çok yoğun yapılır ve bir eşik aşılınca 429 başlar. Üçüncü senaryo ise yanlış yapılandırılmış önbellek/optimizasyon eklentileridir; sayfa her yenilendiğinde gereksiz istek yağdırır, sistem bunu “anormal” görür. Bu noktada 429, bir WordPress Hata gibi görünse de aslında “çok istek atıyorsun, dur” diyen bir fren mekanizmasıdır.

Bir de şu var: Bazı hosting ortamlarında 429 sadece saldırı değil, kaynak yetersizliği belirtisi gibi de davranabilir. Trafik normaldir ama sunucu limitleri o kadar dardır ki birkaç eşzamanlı istek bile sistemi boğar ve 429’a dönüşür. Bu durumda suçu WordPress’e atmak kolaydır ama yanlış olur. Burada güçlü fikrim nettir: Stabil bir WordPress kurulumu, doğru limit ve doğru cache ile 429’u istisna haline getirir. Sürekli 429 görüyorsanız sorun yönetim disiplininizdedir.

İlk Teşhis: 429 Herkeste mi, Sadece Sizde mi?

Önce basit ayrımı yapın. 429 sadece sizde çıkıyorsa, IP’niz rate limit yemiş olabilir. Hemen farklı bir ağdan deneyin. Eğer farklı ağda açılıyorsa, sorun site genelinde değil, sizin kaynak IP’nize uygulanan bir kuraldır. Bu durumda güvenlik eklentinizde veya güvenlik duvarınızda blok kaydı ararsınız. Eğer 429 herkeste çıkıyorsa, global bir limit devrededir ve daha derine inmek gerekir.

İkinci ayrım da “nerede çıkıyor” sorusudur. Sadece wp-login.php mi 429 veriyor, yoksa ana sayfa da mı? Sadece admin-ajax.php çağrıları mı patlıyor, yoksa tüm site mi kilit? Bu ayrım çok değerlidir, çünkü çözüm hedefe göre değişir. Giriş sayfası 429 ise saldırı veya brute-force öncelikli düşünülür. Tüm site 429 ise limit, cache, CDN veya sunucu kaynak yönetimi öncelikli düşünülür.

WordPress Katmanı: Eklenti Çakışması ve Aşırı İstek Üreten Bileşenler

429’un WordPress tarafındaki en sık kaynağı, aşırı istek üreten eklentiler ve temalardır. Özellikle güvenlik eklentileri, giriş denemelerine karşı çok sert limit koyduysa kendi kendinizi bile kilitleyebilirsiniz. Performans eklentileri ise yanlış ayarda sürekli temizleme/önbellek yenileme yapıp istekleri artırabilir. Bu yüzden klasik yöntem burada da geçerlidir: eklentileri toplu kapatıp test etmek. FTP ile wp-content/plugins klasörünü geçici olarak yeniden adlandırmak, tek hamlede eklentileri keser. 429 kayboluyorsa, sorun WordPress çekirdeği değil, bir eklentinin davranışıdır. Bu, WordPress Hata değil; eklenti yönetim hatasıdır.

Tema tarafı da önemlidir. Bazı temalar sayfa açılır açılmaz arka planda çok sayıda çağrı yapar. Özellikle canlı arama, anlık bildirim, sayaç, animasyon kütüphaneleri gibi parçalar gereksiz istek üretir. Geleneksel yaklaşım şudur: önce gereksizi budarsınız. WordPress tarafında “az eklenti, az sorun” kuralı boşa söylenmedi.

Sunucu ve Güvenlik Katmanı: Rate Limit Kuralları

429 hatası çoğu zaman sunucu veya CDN üzerinde rate limiting ile doğrudan bağlantılıdır. Örneğin önde bir WAF/CDN varsa, belirli URL’lere saniyede belirli istekten fazla gelince 429 döndürebilir. Bu katmanda en çok kullanılan platformlardan biri :contentReference[oaicite:0]{index=0} gibi CDN sistemleridir; buradaki firewall ve rate limit kuralları 429 üretebilir. Bu nedenle panel tarafında “hangi kural tetiklenmiş” sorusunun cevabını ararsınız. Log yoksa kör dövüş olur.

Nginx tarafında da rate limit yaygındır. Aşağıdaki örnek, belirli bir endpoint’e saniyede belirli sayıda istek üstünü sınırlayan tipik bir mantığı gösterir. Bunu körlemesine uygulamak yerine, mantığını anlayın: amaç botu frenlemek, gerçek kullanıcıyı boğmak değil.

# Nginx örnek rate limit mantığı
limit_req_zone $binary_remote_addr zone=loginlimit:10m rate=5r/s;

server {
  location = /wp-login.php {
    limit_req zone=loginlimit burst=10 nodelay;
    try_files $uri $uri/ /index.php?$args;
  }
}

Apache tarafında ise mod_evasive benzeri mekanizmalar veya hosting’in kendi koruma katmanı devrede olabilir. Bazı panellerde bu kurallar görünmez; sadece sonuç 429 olarak size yansır. Bu durumda, host desteğiyle konuşmak bazen en kısa yoldur. “429 nerede üretiliyor” sorusunun cevabını netleştirmeden WordPress içinde debelenmek verimsizdir.

Giriş Sayfası 429 Veriyorsa: Kök Nedeni Temizleme

wp-login.php üzerinde 429 çok görüyorsanız iki şey düşünürsünüz: ya bot denemeleri vardır ya da siz/ekibiniz çok sık yanlış şifre denemiştir. Güvenlik eklentisi limit koyduysa bir süre sonra sizi de kilitler. Burada pratik yaklaşım şudur: önce gerçek trafik mi bot mu ayrıştırılır. Eğer loglarda aynı IP’ler sürekli vuruyorsa bot ihtimali yükselir. Bu noktada giriş URL’sini değiştirmek, basit bir CAPTCHA eklemek ve brute-force korumasını mantıklı seviyeye çekmek işe yarar. Ama aşırıya kaçmayın; güvenlik uğruna yönetimi felç etmek akıl işi değildir.

Kalıcı Çözüm: 429’u İstisna Yapmak İçin Doğru Düzen

429 Çok Fazla İstek hatasını kalıcı olarak azaltmak için disiplin gerekir. Önce gereksiz istek üreten eklenti/tema parçalarını budayın. Ardından cache katmanını doğru kurun; doğru cache, aynı sayfayı her seferinde baştan üretmeyi azaltır ve istek yükünü düşürür. Sonra rate limit kurallarını hedefli yapın; tüm siteyi sıkmak yerine, giriş sayfası gibi hassas noktaları koruyun. Son olarak da log takibini rutin hale getirin. 429 bir kez çıktıysa tekrar çıkar; siz düzenli kontrol etmezseniz bu hata alışkanlık olur.

Özetle, 429 Çok Fazla İstek bir WordPress Hata gibi görünse de çoğu zaman yönetim ve limit ayarı meselesidir. Doğru katmanda doğru ayarı yaparsanız, bu hata sizi uğraştırmaz. Aksi halde, en iyi tema da en iyi hosting de sizi kurtaramaz.

500 Dahili Sunucu Hatası Nedir ve WordPress’te Neden En Sinir Bozanlardan biridir?

500 Dahili Sunucu Hatası, adı üstünde “sunucu tarafında bir şey koptu” demektir. Kullanıcı siteye gelir, tarayıcı isteği gönderir; ama sunucu bu isteği işleyip düzgün bir yanıt üretemez. Sonuç: beyaz sayfa, hata ekranı veya sadece “500” yazan soğuk bir mesaj. Bu durum çoğu zaman tek bir nedene bağlı değildir; tam tersine, farklı katmanlarda biriken küçük hatalar 500 Dahili Sunucu Hatası olarak patlar. O yüzden bu yazıda işi şansa bırakmadan, eski usul sağlam bir sırayla çözeceğiz.

Şunu net söyleyeyim: 500 Dahili Sunucu Hatası bir WordPress Hata gibi görünür, ama çoğu zaman WordPress’in çevresindeki yapılandırmanın, izinlerin, eklentilerin veya PHP limitlerinin kavgasıdır. Bu yüzden “panelden bir şeyler kurcalayayım” yaklaşımıyla rastgele gitmek genelde süreyi uzatır. Doğru yaklaşım, kanıtla ilerlemektir. Çünkü 500, “ne olduğunu söylemeyen” bir hatadır; siz loglara bakmadan gerçeği tam yakalayamazsınız.

500 Dahili Sunucu Hatası Ne Zaman Ortaya Çıkar?

Bu hatayı en çok şu anlarda görürsünüz: yeni eklenti/tema kurulumu sonrası, güncelleme sonrası, sunucu taşıma sonrası, .htaccess üzerinde oynama sonrası, PHP sürümü değiştirme sonrası veya disk doluluğu gibi sunucu kaynak problemlerinde. Bazen tek bir sayfada 500 görürsünüz, bazen tüm site gider. Tek sayfadaysa genelde ilgili sayfa bir fonksiyon, bir endpoint veya bir şablon hatasıyla tetikleniyordur. Tüm sitedeyse sorun daha çok sunucu kuralı, bozuk .htaccess, PHP çökmesi veya ciddi bir izin sorunu tarafındadır.

Bu noktada 500 Dahili Sunucu Hatası ile karşılaştığınızda, “bu kesin WordPress bozuldu” demek aceleciliktir. Bu bir WordPress Hata gibi dursa da çoğu zaman asıl suçlu, WordPress’e nefes aldırmayan katmandır.

İlk Hamle: Önbellek Temizleme Değil, Teşhis

Tarayıcı önbelleğini temizlemek bazen işe yarar, evet. Ama 500’de asıl amaç “hata üretildi mi, üretilmediyse niye üretilmedi” sorusunu cevaplamaktır. İlk pratik test şudur: Siteyi farklı bir ağdan ve farklı bir cihazdan açın. Eğer herkeste aynı 500 varsa, bu kullanıcı tarafı değil sunucu tarafıdır. Ardından mümkünse yönetim paneline girip giremediğinizi kontrol edin. Panel de 500 veriyorsa, sorun daha temel bir katmandadır.

Hata Günlükleri: 500’ün Dilini Çeviren Tek Şey

500 Dahili Sunucu Hatası çözümünde en değerli kaynak error log’lardır. Çünkü 500’ün arkasında genellikle “fatal error”, “permission denied”, “out of memory”, “syntax error” gibi net bir satır yatar. Hosting panelinizde “error log” bölümü varsa oradan bakın. SSH erişiminiz varsa web sunucusu ve PHP loglarını kontrol edin. WordPress tarafında da debug log açmak, özellikle eklenti/tema kaynaklı bir çöküşü yakalamanızı sağlar.

WordPress debug ayarlarını wp-config.php içine eklemek için aşağıdaki satırlar kullanılır:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Bu ayarlarla WordPress hatayı ekrana basmak yerine log dosyasına yazar. Bu yaklaşım daha temizdir; çünkü canlı sitede ziyaretçiye hata göstermek profesyonel değildir. 500 gibi bir WordPress Hata durumunda “gösteriş” değil “delil” istersiniz.

.htaccess Bozulması: 500’ün Klasik Sebebi

Apache kullanan sistemlerde .htaccess dosyası bozulduğunda 500 Dahili Sunucu Hatası çok sık görülür. En pratik teşhis yöntemi, .htaccess dosyasını yedekleyip geçici olarak devre dışı bırakmaktır. Site açılıyorsa problem .htaccess içindeki bir kuraldadır. Sonra temiz bir WordPress yönlendirme iskeletiyle dosyayı yeniden oluşturursunuz.

Standart WordPress yönlendirme iskeleti genelde şu şekildedir:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Nginx kullanıyorsanız .htaccess zaten çalışmaz; o zaman 500’ün sebebi farklıdır. Bu ayrımı bilmek şarttır. Çünkü yanlış dosyaya odaklanmak, vakit kaybıdır.

Eklenti ve Tema Çakışmaları: “Bir Güncelleme Yaptım, Site Gitti” Senaryosu

500 Dahili Sunucu Hatası, kötü yazılmış bir eklenti veya tema güncellemesi sonrası çok sık patlar. Özellikle PHP sürümü yükseltildiğinde eski kodlar fatal error üretir. Panel açılamıyorsa en temiz yöntem, FTP ile wp-content/plugins klasörünü geçici olarak yeniden adlandırıp eklentileri toplu kapatmaktır. Site açılırsa, suçlu bir eklentidir. Sonra eklentileri tek tek geri açarak hangisi 500 üretiyor bulursunuz. Aynı mantık tema için de geçerlidir; temayı varsayılan temaya çekmek, temanın payını netleştirir.

PHP Bellek ve Limit Sorunları: “Allowed memory size exhausted”

500 Dahili Sunucu Hatasının en yaygın kök nedenlerinden biri bellek sınırıdır. Özellikle ağır sayfa oluşturucular, büyük sorgular veya yoğun eklenti seti, PHP belleğini tüketir ve site çöker. Çözüm çoğu zaman PHP memory_limit’i artırmaktır. WordPress tarafında wp-config.php içine şu satır eklenebilir:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

Ancak şunu unutmayın: Eğer hosting tarafı belleği kısıtlı tutuyorsa, WordPress içinden artırmanız yetmeyebilir. Bu durumda php.ini veya panel ayarları gerekir. Yani 500 gibi bir WordPress Hata çözümünde “tek düğme” yoktur; katmanlar vardır.

İzinler ve Sahiplik: 500 Bazen Aslında “Permission Denied”dir

Yanlış dosya izinleri ve sahiplik problemleri de 500 Dahili Sunucu Hatası üretebilir. Özellikle uploads, cache klasörleri ve bazı eklentilerin yazma ihtiyacı olan dizinlerde izinler yanlışsa sunucu hataya düşebilir. Klasörler genelde 755, dosyalar 644 olur; ama asıl kritik nokta dosya sahipliğinin doğru kullanıcıda olmasıdır. Sahiplik bozulduysa bazı işlemler kilitlenir ve 500 görürsünüz. Emin olmadığınız sahiplik düzeltme işlemlerinde rastgele işlem yapmak yerine hosting desteğiyle netleştirmek daha akıllıcadır.

Kalıcı Çözüm Mantığı: 500’ü Tamamen Bitirmek İçin Disiplin

500 Dahili Sunucu Hatası yaşandıktan sonra asıl hedef, aynı yere tekrar düşmemektir. Bunun yolu basittir ama ciddiyet ister: Güncellemeleri canlıda değil test ortamında deneyin, eklenti sayısını şişirmeyin, PHP sürümü değişikliklerini kontrol listesiyle yapın, log takibini rutin hale getirin ve yedek almadan “büyük değişiklik” yapmayın. WordPress yönetimi biraz gelenek işidir; düzeni bozarsanız sistem cezasını keser.

Özetle, 500 Dahili Sunucu Hatası bir WordPress Hata gibi görünür; ama siz doğru sırayla log, .htaccess, eklenti/tema, bellek-limit ve izin katmanlarını kontrol ederseniz bu hata kalıcı olarak susturulur. Rastgele kurcalarsanız, 500 sizi susturur.

501 Uygulanmadı Nedir ve WordPress’te Neden “Bu İşi Yapamam” Duvarına Çarparsınız?

501 Uygulanmadı hatası, adından da anlaşılacağı gibi sunucunun bir isteği yerine getirmek için gereken işlevi desteklemediğini söyler. Yani sunucu isteği alır, okur, hatta hangi URL’ye geldiğinizi anlar; ama “bu isteği tamamlayacak kabiliyet bende yok” diyerek geri çevirir. Bu yüzden 501 Uygulanmadı, çoğu zaman bir WordPress Hata gibi görünse de doğrudan WordPress’ten çıkmaz. Asıl kaynak genellikle web sunucusu (Apache/Nginx), bir ters proxy, CDN, güvenlik katmanı veya sunucu tarafındaki bir modül/yapılandırma problemidir.

Burada en çok yapılan hata şudur: 500 gördüğümüzde “sunucu çöktü” deriz, 501 gördüğümüzde de “site bozuldu” diye paniğe kapılırız. Hayır. 501 Uygulanmadı, çoğu zaman “yanlış yöntemle geldin” ya da “ben bu yöntemi tanımıyorum” gibi çok net bir sebepten doğar. Bu yüzden bu yazıda işi geleneksel usulle, katman katman ele alacağız. Çünkü 501 gibi bir WordPress Hata olayında rastgele eklenti kapatmak bazen işe yarar, bazen de tamamen zaman kaybıdır.

501 Uygulanmadı ile 405 ve 500 Arasındaki Fark

Bu ayrım işi hızlandırır. 405 Yöntemi İzin Verilmiyor genelde “yöntem var ama burada yasak” der. 500 Dahili Sunucu Hatası “bir yerde patladım, sebebi loglarda” der. 501 Uygulanmadı ise çoğu zaman “bu isteği karşılayacak özelliğim yok” der. Mesela istemci, sunucunun tanımadığı bir HTTP metoduyla geliyordur; ya da proxy, upstream’e beklenmeyen bir biçimde davranıyordur. Sonuç aynı: kullanıcı karşı tarafta bir WordPress Hata görüyor, ama aslında konu WordPress’in dış katmanlarında dönüyor.

501 Uygulanmadı Hangi Durumlarda Görülür?

En yaygın senaryo, ters proxy/CDN arkasında çalışan sitelerde ortaya çıkar. Bir katman, belirli HTTP yöntemlerini veya belirli header’ları düzgün iletmiyordur. İkinci senaryo, sunucu yazılımı veya modüllerinin eksik olmasıdır. Örneğin bir uygulama belirli bir özelliği (WebDAV, belirli bir reverse proxy davranışı, özel bir method) bekler; sunucu bunu tanımaz ve 501 döndürür. Üçüncü senaryo da güvenlik katmanıdır: bazı WAF kuralları hatalı şekilde 501 üretebilir veya 501’e benzeyen bir sayfayla yanıt verebilir.

WordPress tarafında daha nadir olsa da şu da olur: Bir eklenti REST API üzerinden beklenmeyen yöntemlerle istek üretir, veya bir entegrasyon sunucu tarafında desteklenmeyen bir isteğe dönüşür. Bu durumda 501 Uygulanmadı “WordPress kaynaklı gibi” görünür, ama kök sebep yine çoğu zaman web sunucusu konfigürasyonudur.

Hızlı Teşhis: 501 Gerçekten Sunucudan mı Geliyor?

En pratik teşhis, yanıt başlıklarını görmektir. Çünkü 501 Uygulanmadı yanıtı hangi katmandan çıkıyorsa, genelde “Server” veya benzeri başlıklarda bir iz bırakır. Tarayıcıdan değil, komut satırından kontrol etmek daha net sonuç verir. Aşağıdaki komut, yanıt kodunu ve başlıkları hızlıca görmenizi sağlar:

curl -I https://siteadresiniz.com/

Eğer 501 sadece belirli bir endpoint’te çıkıyorsa (örneğin bir API yolu, admin-ajax.php veya özel bir URL), aynı kontrolü o URL üzerinde yapın. Bu basit kontrol, hatanın WordPress mi yoksa öndeki katman mı kaynaklı olduğunu anlamada çok iş görür.

CDN/Proxy Kaynaklı 501: En Sık Kaçırılan Nokta

Önde bir CDN veya ters proxy varsa, 501 Uygulanmadı çoğu zaman yanlış bir kural yüzünden oluşur. Örneğin proxy, upstream’e iletmesi gereken istek yöntemini dönüştürür, bazı header’ları keser veya belirli bir davranışı “desteklemiyorum” diye geri çevirir. Bu tip durumlarda iki şey yapılır: birincisi, CDN/proxy üzerinde “bloklanan yöntemler” veya “kural setleri” kontrol edilir. İkincisi, siteyi geçici olarak CDN’siz test etmektir. CDN devre dışı kalınca 501 kayboluyorsa, sorun WordPress’te değil, öndeki katmandadır. Bu noktada “WordPress’i sıfırlayayım” gibi hamleler tamamen gereksizdir.

Sunucu Tarafı: Desteklenmeyen HTTP Yöntemleri ve Modül Eksikleri

501 Uygulanmadı hatasının çekirdeğinde sıklıkla “yöntem tanınmıyor” durumu vardır. Normal bir WordPress sitesinde çoğunlukla GET/POST/HEAD dolaşır. Ama bazı entegrasyonlar PUT, PATCH, DELETE gibi yöntemleri de kullanabilir. Sunucu veya güvenlik katmanı bu yöntemleri tanımıyorsa 501 üretebilir. Burada kaba kuvvetle “her şeyi aç” yaklaşımı da yanlıştır. Doğru yaklaşım, hangi yolun hangi yönteme ihtiyaç duyduğunu belirlemek ve sadece gerekli olanı sağlıklı şekilde desteklemektir.

Nginx tarafında yanlış bir kural, bazı yöntemlerde 501/405 üretecek davranışa sebep olabilir. Apache tarafında da modüller eksikse veya belirli özellikler devre dışıysa benzer sonuçlar çıkar. Bu noktada loglara bakmadan kesin konuşmak doğru olmaz; ama 501’in mantığı nettir: sunucu tarafında bir “destek boşluğu” vardır.

WordPress Katmanı: Eklenti ve Entegrasyon Testi

501 doğrudan WordPress’ten çıkmasa da WordPress’in tetiklediği istek biçimi sorunu doğuruyor olabilir. Özellikle API tabanlı eklentiler, ödeme entegrasyonları, dış servis bağlantıları, webhooks ve sayfa oluşturucular bu tür istekleri üretir. Pratik test şudur: eklentileri geçici olarak kapatıp 501’in devam edip etmediğine bakın. Eğer 501 kayboluyorsa, sorun WordPress çekirdeği değil; bir eklentinin ürettiği isteğin sunucu tarafından desteklenmemesidir.

Bir de şu sert gerçeği kabul edin: Bazı eklentiler “her ortamda çalışır” diye yazılmaz. Hosting altyapınız belirli özellikleri kapatmışsa, o eklenti 501 Uygulanmadı ile duvara çarpar. Bu durumda çözüm ya sunucu tarafında gerekli özelliği açmaktır ya da eklenti/entegrasyon seçimini değiştirmektir.

Log Kayıtları: 501’in Net Sebebini Söyleyen Tek Yer

501 Uygulanmadı hatasını kesin çözen şey, logdaki satırdır. Nginx error log, Apache error log, proxy logları ve varsa WAF logları kontrol edilmelidir. Çünkü orada genellikle “unsupported method”, “not implemented”, “upstream sent invalid response” gibi direkt ipucu veren ifadeler olur. Bu noktada “tahminle” ilerlemek yerine “logla” ilerlemek şarttır. Geleneksel disiplin burada kazandırır: log okumayan, 501’i tam bitiremez.

Kalıcı Çözüm: 501 Uygulanmadı Tekrar Etmesin

Kalıcı çözüm, 501’in kaynağını doğru katmanda düzeltmektir. Eğer sorun CDN/proxy kuralıysa, kuralı netleştirirsiniz. Eğer sorun sunucu tarafında desteklenmeyen yöntem veya modül eksikliyse, gerekli özelliği açarsınız veya istek davranışını değiştirecek şekilde entegrasyonu düzenlersiniz. Eğer sorun bir eklentinin ürettiği “uygunsuz” istek biçimiyse, eklenti ayarını düzeltirsiniz ya da daha uyumlu bir alternatif seçersiniz. Bu süreçte şunu unutmayın: 501 Uygulanmadı bir WordPress Hata gibi görünür; ama çözüm çoğu zaman WordPress’in dışında biter.

501 gördüğünüzde “site çöktü” değil, “hangi katman hangi isteği desteklemiyor” diye düşünün. Doğru soru, doğru çözümü getirir.

502 Hatalı Ağ Geçidi Nedir ve WordPress’te Neden Bir Anda “Aracı Bozuldu” Hissi Verir?

502 Hatalı Ağ Geçidi hatası, WordPress sitelerinde özellikle CDN, ters proxy veya yük dengeleyici kullanılan yapılarda sık görülen bir problemdir. Mantığı basittir: Önde duran bir sunucu (proxy/ağ geçidi), arkadaki asıl sunucudan geçerli bir yanıt alamaz ve kullanıcıya 502 döndürür. Yani tarayıcı ile WordPress’in çalıştığı sunucu arasına bir “aracı” girmiştir; işte o aracı, upstream’den saçma/boş/bozuk bir yanıt aldığı için “ben bunu iletemem” der.

Bu hata çoğu zaman bir WordPress Hata gibi algılanır, çünkü kullanıcı WordPress sitesine giremez. Fakat 502’nin ruhu WordPress’ten çok altyapıdadır. Yine de WordPress tarafındaki ağır sorgular, çöken PHP-FPM süreçleri, bellek sorunları veya ölümcül hatalar bu zincirin arkasında olabilir. Bu yüzden 502 Hatalı Ağ Geçidi çözümünde disiplin şarttır: önce proxy/CDN katmanı, sonra sunucu durumu, sonra WordPress katmanı. Bu sırayı bozarsanız gereksiz yere oyalandınız demektir.

502 Hatalı Ağ Geçidi Hangi Durumlarda Görülür?

En klasik senaryo: Site bazen açılır bazen açılmaz. Bir yenilersiniz gelir, bir yenilersiniz 502. Bu dalgalanma genelde arka sunucunun zaman zaman yanıt verememesinden kaynaklanır. İkinci senaryo: Trafik artınca 502 başlar. Bu durumda arka sunucu kaynakları yetmiyordur ya da PHP-FPM havuzu tıkanıyordur. Üçüncü senaryo: CDN veya güvenlik duvarı ayarı değişir, 502 bir anda patlar. Bu durumda “aracı” katman upstream’e düzgün bağlanamıyordur. Dördüncü senaryo: Sunucu taşıma veya DNS değişimi sonrası 502 görülür. Bu da yanlış IP, yanlış port, yanlış SSL veya yanlış origin ayarı gibi konuları işaret eder.

Burada güçlü fikir şudur: 502’nin çoğu zaman “tek bir faili” yoktur ama her zaman “tek bir boğazı” vardır. O boğaz ya proxy ile upstream arasındaki bağlantıdır ya da upstream’in kendisidir. O yüzden rastgele eklenti kapatmak yerine, zinciri ölçerek ilerlemek gerekir. Aksi halde 502 gibi bir WordPress Hata sizi döndürür durur.

İlk Kontrol: CDN/Proxy Var mı, Yok mu?

Önce sitenizin önünde CDN veya proxy olup olmadığını netleştirin. Örneğin :contentReference[oaicite:0]{index=0} benzeri bir katman kullanıyorsanız 502 bazen doğrudan oradan gelir. En pratik teşhis, CDN’yi geçici olarak devre dışı bırakıp (ya da “development mode” benzeri bir modla) origin sunucuya doğrudan test etmektir. CDN kapalıyken 502 kayboluyorsa problem WordPress’te değil, CDN/origin iletişimindedir.

Bir diğer pratik kontrol: Aynı siteyi doğrudan sunucu IP’siyle veya hosts dosyası üzerinden origin’e yönlendirerek test etmektir. Bu test, “aracı mı bozuyor, upstream mi çöküyor” sorusunu netleştirir.

Sunucu Durumu: Upstream Gerçekten Ayakta mı?

502 Hatalı Ağ Geçidi genelde upstream sunucunun yanıt veremediğini söyler. Bu da çoğu zaman şu kök nedenlere iner: PHP-FPM çökmüştür, web sunucusu (Nginx/Apache) kilitlenmiştir, CPU/RAM tavan yapmıştır, disk dolmuştur veya arka uç servisleri (örneğin veritabanı) yanıt vermiyordur. Bu yüzden sunucuda kaynak kullanımını kontrol etmek gerekir. “Site çalışmıyor” dediğinizde ilk bakacağınız şey CPU, RAM, disk ve süreç durumudur. Gelenek böyledir; çünkü sunucu nefes alamıyorsa WordPress’in konuşacak hali kalmaz.

PHP-FPM kullanılan sistemlerde, FPM havuzu dolduğunda veya süreçler öldüğünde proxy upstream’den yanıt alamaz ve 502 döndürür. Bu durum özellikle ağır sorgularda ve yoğun trafikte ortaya çıkar. Çözüm bazen FPM ayarlarını iyileştirmek, bazen eklentileri optimize etmek, bazen de kaynak artırmaktır.

DNS ve SSL Uyuşmazlıkları: 502’nin Sinsi Sebepleri

502 sadece “sunucu çöktü” demek değildir. Bazen CDN/origin arasında SSL yanlış ayarlanmıştır; örneğin CDN HTTPS ile bağlanmak ister, origin HTTP bekler veya tersi. Bazen origin sertifikası geçersizdir, proxy handshake yapamaz ve 502/525 benzeri hatalar döner. Bazen de DNS yanlış IP’ye gider, proxy yanlış origin’e bağlanır. Bu yüzden DNS değişimi veya SSL değişimi yaptıktan sonra 502 görüyorsanız, doğrudan bu iki alanı kontrol edin.

WordPress Katmanı: Ağır İşler Upstream’i Boğuyorsa

502’nin kökü altyapı olsa bile, tetikleyicisi WordPress olabilir. Örneğin bir eklenti her sayfada ağır bir sorgu çalıştırıyordur, PHP süresi uzuyordur, proxy zaman aşımına düşer ve 502 döner. Bu durumda 502 bir WordPress Hata gibi görünür ama aslında “WordPress işi uzattı, upstream yanıt yetiştiremedi” meselesidir.

Pratik teşhis yöntemi şudur: Siteyi geçici olarak en basit moda çekmek. Eklentileri toplu kapatmak (FTP ile plugins klasörünü yeniden adlandırmak) ve varsayılan temayla test etmek. 502 kayboluyorsa tetikleyici WordPress tarafındadır. Sonra eklentileri tek tek açıp hangisinin sistemi boğduğunu bulursunuz. Bu, eski usul ama en güvenilir yöntemdir.

Timeout Ayarları: Proxy Bekliyor, Upstream Yetişemiyor

502 bazen gerçekte 504’e benzeyen bir davranışla ortaya çıkar: proxy bekler ama upstream cevap veremez. Proxy timeout değerleri düşükse, normalde biraz daha bekleyince dönecek bir işlem bile 502/504 ile biter. Nginx’te proxy_read_timeout, fastcgi_read_timeout gibi değerler bu noktada önemlidir. Bunları yükseltmek bir çözüm olabilir, ama asıl hedef WordPress’in neden bu kadar yavaşladığını bulmaktır. Yoksa sadece bekleme süresini uzatmış olursunuz; sorun büyüyünce yine patlar.

Log Kayıtları: 502’yi Kökten Bitiren Kanıt

502 Hatalı Ağ Geçidi çözümünde loglar hayati önemdedir. Proxy loglarında “upstream prematurely closed connection”, “connect() failed”, “no live upstreams” gibi mesajlar görürsünüz. PHP-FPM loglarında süreç ölmesi veya bellek tükenmesi çıkar. WordPress debug log bazen fatal error’ü yakalar. Siz bu satırları görmeden 502’ye kesin teşhis koyamazsınız. Bu yüzden 502 gibi bir WordPress Hata durumunda “tahmin” değil “log” ile yürüyün.

Kalıcı Çözüm: 502 Hatalı Ağ Geçidi Tekrar Etmesin

Kalıcı çözüm, boğazı genişletmektir. Eğer sorun CDN/origin iletişimindeyse doğru SSL ve origin ayarları yapılır. Eğer upstream kaynak yetersizliğiyse kaynak artırılır veya optimizasyon yapılır. Eğer WordPress tarafı upstream’i boğuyorsa tetikleyici eklenti/tema bulunur ve düzeltilir. Eğer timeout düşüklüğü sorunsa değerler site gerçekliğine göre ayarlanır. Ama en önemlisi şudur: 502’yi “arada bir olur” diye kabullenmeyin. Bu hata, altyapınızın veya yönetim disiplininizin size gönderdiği bir uyarıdır.

502 Hatalı Ağ Geçidi bir WordPress Hata gibi görünür; fakat çoğu zaman proxy ile upstream arasındaki zincirin kopmasıdır. Zinciri doğru yerden onarırsanız, hata biter.

503 Hizmet Kullanılamıyor Nedir ve WordPress’te Neden “Site Var Ama Yok” Gibi Davranır?

503 Hizmet Kullanılamıyor hatası, WordPress sitelerinde en sinir bozucu “ara durum” hatalarından biridir. Çünkü sunucu çoğu zaman tamamen çökmez; sadece o anki isteği karşılayacak durumda değildir ve bilinçli şekilde “şu an hizmet veremiyorum” der. Yani 503, “ben çalışıyorum ama şu an meşgulüm / bakımdayım / kaynaklarım tükendi” mesajıdır. Bu yüzden 503 Hizmet Kullanılamıyor, birçok kişinin sandığı gibi yalnızca bir WordPress Hata değildir; çoğu zaman bakım modu, trafik patlaması, sunucu kaynak tükenmesi veya agresif güvenlik/limit ayarlarının sonucudur.

Bu hataya geleneksel bakış şarttır: 503 çıktığında önce bakım modu var mı kontrol edilir, sonra sunucunun kaynakları incelenir, ardından WordPress katmanına inilir. Çünkü 503 genellikle “sebebi söyleyen” bir hatadır; siz doğru yerden bakarsanız kısa sürede netleştirirsiniz. Rastgele eklenti kapatıp durmak ise bazen işe yarar, bazen sadece vakit kaybettirir.

503 Hizmet Kullanılamıyor Hangi Durumlarda Görülür?

En klasik senaryo planlı bakım ve güncellemedir. WordPress güncelleme sırasında bakım moduna geçer ve ziyaretçilere 503 benzeri bir mesaj gösterebilir. İkinci senaryo, trafik artışıdır: site normalde kaldırdığı yükün üstüne çıkınca web sunucusu veya PHP katmanı istekleri geri çevirir ve 503 başlar. Üçüncü senaryo da sunucu kaynaklarının tükenmesidir: CPU %100, RAM dolu, disk dolu, süreçler tıkanmış. Bu durumda sunucu “kısmi ayakta” durur ama iş yapamaz, 503 verir. Dördüncü senaryo, güvenlik duvarı veya WAF’ın “koruma modu”dur; sistem şüpheli yoğunluğu görünce 503/429 benzeri yanıtlarla trafiği kesebilir.

Burada güçlü fikir şu: 503 görüyorsanız ya site bakımdadır ya da site boğuluyordur. İkisi de yönetilebilir durumdur. 503’ü kader gibi görmek, zayıf yönetimdir. Bu tip bir WordPress Hata algısı, sizi yanlış teşhise iter.

İlk Kontrol: Bakım Modu Takılı Kaldı mı?

WordPress güncelleme yaparken kök dizine .maintenance adında bir dosya oluşturur. Normalde güncelleme bitince bu dosya silinir. Ama tarayıcı kapanır, bağlantı kopar, toplu güncelleme yarıda kalırsa site bakım modunda takılı kalabilir ve 503 Hizmet Kullanılamıyor gibi davranabilir. Bu durumda çözüm basittir: FTP veya dosya yöneticisi ile WordPress kök dizinine girip .maintenance dosyasını silersiniz.

Bu kontrol, 503’te yapılacak en “eski usul ama en etkili” hamlelerden biridir. Çünkü saniyeler içinde teşhis edersiniz. Eğer .maintenance yoksa, o zaman asıl sebep bakım modu değildir ve sunucu katmanına inersiniz.

Sunucu Kaynakları: 503’ün En Büyük Yakıtı

503 Hizmet Kullanılamıyor hatasının en yaygın kök nedeni, sunucunun kaynaklarının yetmemesidir. CPU tavan yapmışsa, PHP süreçleri yetişemiyorsa, veritabanı kilitlenmişse veya disk dolmuşsa, sunucu gelen istekleri işlemek yerine geri çevirmeye başlar. Bu, özellikle paylaşımlı hostinglerde daha sık görülür. Çünkü limitler dardır ve küçük bir trafik artışı bile 503 üretir.

Pratik kontrol şudur: Hosting panelinden CPU/RAM kullanımına bakın. Disk doluluğunu kontrol edin. PHP-FPM kullanıyorsanız süreç havuzunun dolup dolmadığına bakın. Bu noktada “WordPress’i kurcalayayım” demek doğru değildir; önce altyapının nefes alıp almadığını bilmeniz gerekir. 503’te gelenek budur: önce sunucu, sonra uygulama.

CDN ve Cache Katmanı: Yanlış Ayar 503 Üretebilir

Önde bir CDN veya ters proxy varsa, yanlış bir kural veya origin erişim problemi 503 üretebilir. Bazen CDN, origin’i geçici olarak “ulaşılamaz” görür ve ziyaretçiye 503 döner. Bazen de cache ayarı yanlış yapılandırılmıştır ve belirli istekler sürekli origin’e vurur, origin tıkanır ve 503 başlar. Bu noktada, CDN’yi geçici devre dışı bırakıp doğrudan origin test etmek yine sağlam bir teşhistir. Eğer CDN kapalıyken 503 kayboluyorsa, sorun WordPress’te değil, öndeki katmandadır.

WordPress Katmanı: Eklenti/Temanın Sunucuyu Boğması

503’ün kökü altyapı olsa bile tetikleyici WordPress olabilir. Özellikle ağır sorgu üreten eklentiler, kötü optimize edilmiş temalar, sürekli çalışan cron işleri ve aşırı admin-ajax istekleri sunucuyu boğar. Sonuçta sunucu bir noktadan sonra 503 vermeye başlar. Bu yüzden WordPress tarafında da klasik bir teşhis yaparsınız: eklentileri toplu kapatıp test edersiniz. FTP ile wp-content/plugins klasörünü geçici olarak yeniden adlandırmak, eklentileri tek hamlede devre dışı bırakır. 503 kayboluyorsa, tetikleyici bir eklentidir.

Benzer şekilde temayı varsayılan temaya almak da temanın etkisini gösterir. Bu, kaba ama etkili bir yöntemdir. Çünkü 503 gibi bir WordPress Hata algısı yaratan problemler, çoğu zaman “fazla yük” problemleridir.

WordPress Cron ve Arka Plan İşleri: Gizli Trafik Üreticisi

WordPress cron sistemi, her ziyaretçi geldiğinde tetiklenebilen bir yapıdır. Trafik yüksekse cron işleriniz de yüksek frekansta çalışır ve bu sunucuya ek yük bindirir. Özellikle yoğun e-posta gönderimleri, yedekleme işlemleri, tarama işlemleri veya otomatik optimizasyonlar cron üzerinden koşuyorsa 503 tetiklenebilir. Bu yüzden cron işlerini kontrol etmek, gerekiyorsa gerçek sistem cron’una taşımak veya aralıklarını düzene sokmak gerekir. Eski usul bakımın değeri burada çıkar: arka plan işleri kontrolsüz bırakılmaz.

Log Kayıtları: 503’te “Neden” Genelde Yazılıdır

503 Hizmet Kullanılamıyor hatasında loglar çoğu zaman açık konuşur. Nginx/Apache loglarında “upstream busy”, “service unavailable”, “resource temporarily unavailable” benzeri mesajlar görebilirsiniz. PHP logları bellek tükenmesini veya fatal error’ü gösterebilir. Veritabanı logları kilitlenme ve yavaş sorgu işaretlerini verir. Bu kayıtlar olmadan 503’e kalıcı çözüm koymak zordur.

Kalıcı Çözüm: 503 Hizmet Kullanılamıyor Tekrar Etmesin

Kalıcı çözüm, iki şeyi dengede tutmaktır: kaynak ve yük. Kaynaklarınız (CPU/RAM/disk/süreç havuzu) sitenin gerçek ihtiyacına uygun olmalı. Yük üreten unsurlar (ağır eklentiler, kontrolsüz cron, yanlış cache) kontrol altında olmalı. Bakım modunun takılı kalmaması için güncellemeler disiplinle yapılmalı, mümkünse test ortamında denenmeli ve işlem yarıda bırakılmamalı. 503 bir WordPress Hata gibi görünür ama çoğu zaman yönetim disiplini eksikliğinin faturasıdır.

503 gördüğünüzde önce .maintenance kontrolü, sonra kaynak kontrolü, sonra WordPress tetikleyicileri. Bu sırayla giderseniz 503 sizi yormaz.

504 Ağ Geçidi Zaman Aşımı Nedir ve WordPress’te Neden “Cevap Gelmedi” Diye Patlar?

504 Ağ Geçidi Zaman Aşımı hatası, WordPress sitelerinde özellikle bir proxy/CDN arkasındaysanız çok sık can sıkar. Mantığı nettir: Önde duran ağ geçidi (proxy), arkadaki sunucudan belirli bir süre içinde yanıt bekler. Yanıt gelmeyince “ben daha fazla beklemiyorum” der ve 504 döndürür. Yani 504, çoğu zaman “site çöktü” değil, “site çok yavaş kaldı, yetişemedi” demektir. Bu yüzden 504, bir WordPress Hata gibi görünse de özünde süre ve performans problemidir.

Burada geleneksel yaklaşım şart: 504’te önce “bu zaman aşımı nerede oluyor?” sorusunu sorarsınız. CDN mi beklemeyi bırakıyor, Nginx mi, yoksa PHP mi? Sonra “neden geç yanıt veriyor?” sorusuna inersiniz: ağır sorgu mu var, PHP-FPM mi tıkanmış, veritabanı mı kilitlenmiş, dış servis mi bekletiyor? Bu sırayı bozarsanız, rastgele ayar yükseltip durursunuz ama kök neden kalır.

504 Ağ Geçidi Zaman Aşımı Hangi Durumlarda Görülür?

En yaygın senaryo, yönetim panelinde ağır bir işlem sırasında olur. Örneğin büyük bir sayfa kaydedersiniz, toplu işlem yaparsınız, yedek alırsınız, içe aktarım yaparsınız; hop 504. İkinci senaryo, yoğun trafik saatlerinde olur: site normalde idare eder ama yük artınca yanıtlar gecikir ve proxy zaman aşımına düşer. Üçüncü senaryo, dış servislere bağlanan eklentilerde olur: ödeme sistemi, API entegrasyonu, harici doğrulama gibi bir servis yavaşladığında WordPress bekler, proxy bekler, sonra 504 patlar. Dördüncü senaryo, veritabanı problemleridir: yavaş sorgular, kilitlenmeler, aşırı tablo şişmesi gibi durumlar yanıtı geciktirir ve 504 başlar.

Şunu açık söyleyeyim: 504, çoğu zaman “süreyi artır” diye bağıran bir hata gibi görünür ama doğru çözüm her zaman timeout yükseltmek değildir. Timeout’u yükseltmek bazen sadece sorunu geciktirir. Bu yüzden 504 gibi bir WordPress Hata algısı yaratan durumda önce performansın neden düştüğünü bulmak gerekir.

İlk Teşhis: CDN/Proxy Katmanı Var mı?

Önde CDN veya proxy varsa 504’ün kaynağı çoğu zaman orasıdır. Örneğin :contentReference[oaicite:0]{index=0} gibi bir katman, origin’den yanıtı belirli bir süre içinde bekler. Origin geç kalırsa 504 döndürür. Bu yüzden ilk pratik test: CDN’yi geçici devre dışı bırakıp origin’i doğrudan test etmektir. CDN kapalıyken 504 kayboluyorsa, WordPress’in yavaşlığı origin’de var ama kullanıcıya yansıyan hata CDN’nin timeout sınırında patlıyordur. Bu durumda iki yöne bakarsınız: origin’i hızlandırmak ve CDN/origin timeout uyumunu doğru kurmak.

Sunucu Katmanı: PHP-FPM, CPU ve RAM Tıkanıklığı

504 çoğu zaman “upstream yetişemedi” demektir. Upstream burada PHP-FPM olabilir, Apache olabilir, Nginx arkasındaki uygulama olabilir. PHP-FPM havuzu dolduysa, yeni istekler sıraya girer, yanıt gecikir, proxy 504 döndürür. CPU %100’e dayanmışsa her şey yavaşlar, 504 gelir. RAM doluysa swap’e düşer, sistem ağırlaşır, 504 gelir. Disk doluysa veya I/O tıkanıyorsa yine 504 tetiklenir. Yani 504’te geleneksel kontrol listesi nettir: kaynaklara bak, süreçlere bak, darboğazı bul.

Pratik olarak şunu bilin: 502 daha çok “geçersiz yanıt” veya “bağlantı koptu” gibi davranır. 504 ise “bekledim ama gelmedi” davranışıdır. Bu ayrım, doğru logu doğru yerde aramanızı sağlar.

Veritabanı Yavaşlığı: 504’ün Sessiz Faili

WordPress’in kalbi veritabanıdır. Veritabanı yavaşlarsa, PHP sayfayı üretmekte gecikir ve proxy 504’e düşer. Özellikle şişmiş wp_options tablosu (autoload yükü), devasa transients, yavaş sorgu üreten eklentiler, kötü indeksler ve kilitlenmeler 504’e yakıt olur. Bu yüzden 504 yaşayan bir sitede veritabanını “hiç ilgisi yok” diye kenara atmak hatadır.

Burada güçlü fikir şudur: 504’ü kalıcı bitirmek istiyorsanız, yavaş sorguyu bulmadan rahat edemezsiniz. Cache ile bir süre idare edersiniz, ama tetikleyici kaldıkça 504 geri gelir.

Dış Servisler ve API Entegrasyonları: WordPress Bekler, Proxy Beklemez

Birçok WordPress sitesi ödeme, SMS, kargo, doğrulama, haritalar, analitik gibi dış servislerle konuşur. Bu servislerden biri yavaşlarsa WordPress kodu beklemeye geçer. WordPress bekler, PHP bekler, ama proxy’nin sabrı sınırlıdır. Bu yüzden 504 görebilirsiniz. Bu tür durumlarda çözüm, dış servis çağrılarını optimize etmek, zaman aşımı ayarlarını doğru yapmak veya kritik işlemleri arka plana taşımaktır.

WordPress Katmanı: Eklenti/Temanın Ürettiği Ağır İşler

504’ün tetikleyicisi sıklıkla bir eklentidir. Büyük sayfa oluşturucular, ağır güvenlik taramaları, yedekleme eklentileri, içe aktarma araçları, görüntü optimizasyonları… Bunların hepsi yoğun işlem üretir. Bu noktada klasik yöntem yine altın kuraldır: eklentileri toplu kapatıp test etmek. FTP ile wp-content/plugins klasörünü geçici olarak yeniden adlandırın. 504 kayboluyorsa, tetikleyici bir eklentidir. Sonra eklentileri tek tek açarak hangisinin 504’e sebep olduğunu yakalarsınız.

Aynı şekilde temayı varsayılan temaya çekmek de temanın ağır sorgu üretip üretmediğini gösterir. 504 gibi bir WordPress Hata algısında, tetikleyiciyi bulmak şarttır.

Timeout Ayarları: Sadece Son Dokunuş Olarak Kullanılır

Proxy timeout değerlerini artırmak bazen gerekli olur. Özellikle büyük içe aktarmalar veya nadir ama meşru uzun işlemler için. Nginx’te fastcgi_read_timeout, proxy_read_timeout gibi ayarlar bu noktada devreye girer. Ancak burada sert konuşacağım: Timeout artırmak, yavaşlığı çözmez; sadece hatanın oluşmasını geciktirir. Bu yüzden önce yavaşlığın sebebi bulunur, sonra gerekiyorsa timeout uyumu yapılır.

Log Kayıtları: 504’ün Nerede Zaman Aşımına Düştüğünü Gösteren Kanıt

504 çözümünde loglar hayat kurtarır. Nginx loglarında “upstream timed out” ifadesi, doğrudan sorunun nerede olduğunu söyler. PHP-FPM logları süreçlerin takıldığını gösterebilir. Veritabanı logları yavaş sorguları işaret eder. WordPress debug log bazen bir fonksiyonun takıldığı yeri yakalar. Bu kanıt olmadan 504’ü kalıcı çözmek zorlaşır.

Kalıcı Çözüm: 504 Ağ Geçidi Zaman Aşımı Tekrar Etmesin

Kalıcı çözüm, beklemeyi azaltmaktır. Cache katmanı doğru kurulur, ağır eklentiler budanır, veritabanı optimize edilir, PHP-FPM havuzu site yüküne göre ayarlanır, dış servis çağrıları akıllıca yönetilir. Sonra en son aşamada proxy/CDN timeout değerleri site gerçekliğine göre uyumlanır. 504 bir WordPress Hata gibi görünür; ama gerçekte “performans hesabı” keser. Siz performansı düzeltirseniz, 504 susar.

504 gördüğünüzde önce “kim bekledi, kim yetişemedi” sorusunu cevaplayın. Doğru katmanı bulur, darboğazı açarsanız iş biter.

WordPress Bellek Sınırı Hatası Nedir ve Neden Bir Anda Her Şeyi Kilitler?

WordPress Bellek Sınırı Hatası, WordPress tarafında en yaygın görülen “site bir anda ağırlaştı, sonra da patladı” türü sorunların başında gelir. Genelde ekranınızda “Allowed memory size of X bytes exhausted” benzeri bir mesaj görürsünüz. Bazen bu mesaj doğrudan görünmez; onun yerine 500 hatası, beyaz ekran veya panelde yarım yüklenen sayfalar çıkabilir. Ama kök sebep çoğu zaman aynıdır: PHP’ye tanımlanan bellek limiti, WordPress’in o an yapmak istediği işi karşılamaya yetmemiştir.

Bu konuyu hafife almayın. Çünkü bu tip WordPress Hata durumları “benim sitem küçük” dediğiniz anda bile çıkabilir. Bir eklenti güncellemesi, bir tema bileşeni, bir görsel işleme süreci, bir yedekleme işlemi veya bir içe aktarma işi tek hamlede belleği şişirir. Sonuç: site ya çöker ya da kritik bölümler çalışmaz. Klasik disiplin burada da geçerlidir: önce teşhis, sonra doğru katmanda doğru artırma, en son da gereksiz yükü budama.

Belirti ve Teşhis: Bu Sorunun Gerçekten Bellek Olduğunu Nasıl Anlarsınız?

WordPress Bellek Sınırı Hatası bazen çok net konuşur; ekranda fatal error satırı görürsünüz. Bazen de sessizdir: yönetim paneli açılır ama bir sayfaya girince beyaz ekran olur, medya yükleme yarıda kalır, sayfa oluşturucu kaydetmez, ürün ekleme sırasında hata verir. Özellikle yoğun eklenti seti olan sitelerde bu WordPress Hata “arada bir olur” diye görünür; ama aslında siz yük bindirdikçe tekrarlar.

En sağlam teşhis yöntemi loglardır. Hosting panelinizde PHP error log varsa oraya bakın. WordPress debug log açmak da işe yarar. WordPress’in işi “gizleyip geçmesi” yerine loga yazmasını istersiniz. Canlı sitede hatayı ziyaretçiye göstermek profesyonel değildir; logdan ilerlemek daha temizdir.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Bu ayarlardan sonra wp-content klasörü içinde debug.log oluşur. Eğer bellek hatası varsa orada açık açık görünür. Böylece “bu bir bellek mi yoksa başka bir şey mi” tartışması biter. Bu kadar net.

Neden Çıkar: WordPress Neyi Yaparken Belleği Şişirir?

WordPress Bellek Sınırı Hatası genellikle şu işleri yaparken patlar:

1) Sayfa oluşturucular ve ağır temalar: Görsel editörler, bloklar, dev tasarım kütüphaneleri belleği hızlı tüketir.

2) Resim işleme: Büyük boyutlu görselleri yeniden boyutlandırma, optimize etme, farklı boyutlar üretme bellek kullanır.

3) Yedekleme ve içe aktarma: Veritabanı + dosya toplu işlemleri bellek ve süre tüketir.

4) E-ticaret yoğunluğu: Çok sayıda ürün, varyasyon, filtre, ağır sorgu; hepsi belleği şişirebilir.

5) Kötü yazılmış eklentiler: Gereksiz yere devasa veri çekip hafızaya basan eklentiler bu WordPress Hata durumunun “asıl suçlusu” olur.

Bu noktada güçlü fikrim şu: Bellek artırmak çözüm olabilir ama her zaman “doğru çözüm” değildir. Eğer bir eklenti beceriksizse, siz belleği artırdıkça o eklenti daha da şişer. Sonra “256M yetmedi 512M yapalım” döngüsüne girersiniz. Bu, kök nedeni düzeltmek değil, sorunu büyütmektir.

Çözüm 1: wp-config.php Üzerinden WordPress Belleğini Artırma

En pratik başlangıç hamlesi, WordPress’e tanımlanan bellek limitini yükseltmektir. wp-config.php dosyanıza aşağıdaki satırları ekleyebilirsiniz. Bu, özellikle yönetim paneli için gerekli olan limiti yukarı çeker.

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

Burada önemli bir ayrıntı var: Bu satırlar bazen tek başına yetmez. Çünkü hosting tarafı PHP memory_limit değerini sabit bir üst sınırla kilitlemiş olabilir. Yani WordPress “256M istiyorum” der, hosting “ben sana 128M veririm” der. O zaman bu WordPress Hata devam eder. Bu yüzden ikinci çözüm katmanına geçmeniz gerekir.

Çözüm 2: PHP memory_limit Değerini Doğru Katmanda Artırma

PHP bellek limiti genellikle php.ini veya .user.ini gibi dosyalardan yönetilir. Bazı hosting panellerinde “PHP Settings” kısmında bir dropdown ile ayarlanır. Ama mantık aynı: memory_limit’i artırırsınız. Örnek bir php.ini/.user.ini satırı aşağıdaki gibidir:

memory_limit = 256M

Apache + mod_php kullanan bazı yapılarda .htaccess üzerinden de ayar denenebilir. Her hosting bunu kabul etmez, ama örnek olarak mantığı gösteriyorum:

php_value memory_limit 256M

Eğer bu satırı eklediğiniz anda 500 hatası çıkıyorsa, hosting’iniz .htaccess üzerinden php_value kullanımına izin vermiyor demektir. O durumda o satırı geri alırsınız ve panel veya php.ini/.user.ini üzerinden ilerlersiniz. Bu, çok sık görülen klasik bir tuzaktır.

Çözüm 3: Belleği Artırdınız, Peki Neden Yetmedi?

Burada çoğu kişi hata yapar. Belleği artırınca site açıldı diye “tamamdır” sanırlar. Ama birkaç gün sonra aynı WordPress Hata geri gelir. Neden? Çünkü tetikleyici hâlâ yerinde duruyordur. Bu yüzden mutlaka şunları yapın:

– Hangi sayfada/işlemde patlıyor? Aynı işlemi tekrar edip logdan hangi eklenti/tema dosyasının tetiklediğini yakalayın.

– Son güncellenen eklentileri kontrol edin. Bu hata çoğu zaman bir güncelleme sonrası belirir.

– Eklentileri geçici olarak devre dışı bırakıp test edin. FTP ile plugins klasörünü geçici isim değiştirerek toplu kapatma, teşhiste en hızlı yoldur.

– Büyük görselleri kontrol edin. Aşırı büyük görseller işleme sırasında bellek tüketimini patlatır.

– Gereksiz özellikleri budayın. Özellikle “her şey bir arada” paket eklentiler belleği şişirmeye yatkındır.

Kalıcı Çözüm Mantığı: Sadece Bellek Artırmak Yetmez

Kalıcı çözüm, iki ayağı birlikte yürütmektir: doğru limit + doğru yük. Evet, WordPress’in çalışması için yeterli memory_limit gerekir. Ama aynı zamanda WordPress’in gereksiz yere şişmesini engellemek gerekir. Bu da düzenli bakım, ölçülü eklenti kullanımı ve log takibi ile olur. Eski usul yönetim dediğim tam da budur: sistemin nereye kadar dayanacağını bilmek, sınırı doğru koymak ve yük yapan parçaları terbiye etmek.

WordPress Bellek Sınırı Hatası bir WordPress Hata gibi görünür ama aslında “kaynak planlaması” ve “eklenti disiplini” sınavıdır. Doğru ayarla düzeltirsiniz, doğru bakım ile tekrar etmesini engellersiniz.

Yüklenen Dosya, php.ini’deki upload_max_filesize Yönergesini Aşıyor Nedir?

Bu hata, WordPress’e bir dosya yüklemeye çalıştığınızda PHP’nin “bu dosya benim izin verdiğim maksimum boyutu geçti” diyerek yüklemeyi daha baştan reddetmesidir. Genelde mesaj çok nettir: “Uploaded file exceeds the upload_max_filesize directive in php.ini” veya Türkçe karşılığına benzer bir ifade görürsünüz. Bu sorun, çoğu zaman bir WordPress Hata gibi algılansa da esasen PHP limitidir. WordPress, sizin dosyanızı almak ister; ama PHP katmanı “bu boyut bende yasak” der ve kapıyı kapatır.

Burada geleneksel yaklaşım basittir: Önce mevcut limitleri görürsünüz, sonra ihtiyacınıza göre doğru katmanda yükseltirsiniz, en son da yükleyeceğiniz dosyanın gerçekten o kadar büyük olup olması gerektiğini sorgularsınız. Çünkü her şeyi şişirmek uzun vadede güvenlik ve performans açısından pahalıya patlar. Bu tip bir WordPress Hata durumunda pratik olmak gerekir.

Bu Hata WordPress’te Nerede Görülür?

En sık Medya Kütüphanesine dosya yüklerken görürsünüz. Tema/eklenti yüklerken de görülür. Ayrıca bazı yedekleme eklentilerinde büyük yedek dosyasını geri yüklerken de aynı limit duvarına çarparsınız. WordPress yönetim panelinde çoğu zaman “Maksimum yükleme dosya boyutu” gibi bir bilgi satırı olur. Bu değer size ilk ipucunu verir. Eğer yüklemek istediğiniz dosya bu değerden büyükse, hata sürpriz değildir.

Bu arada şunu bilin: upload_max_filesize tek başına yetmez. post_max_size değeri de önemlidir. Çünkü dosya yükleme, aslında bir POST isteği ile gönderilir. post_max_size daha küçükse, upload_max_filesize’ı büyütseniz bile hâlâ sorun yaşarsınız. Bu yüzden bu WordPress Hata türünde iki limiti birlikte düşünmek zorundasınız.

Çözüm 1: php.ini veya .user.ini Üzerinden Limit Artırma

En doğru ve temiz yöntem, PHP ayarını doğru yerden düzenlemektir. Hosting türüne göre php.ini veya .user.ini dosyası kullanılır. Aşağıdaki örnek, temel bir ayar setidir:

upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Burada dikkat: post_max_size genellikle upload_max_filesize değerinden küçük olmamalıdır. Aksi halde yine aynı hata veya farklı yükleme problemleri görürsünüz. Ayrıca dosya büyükse yükleme süresi uzayabileceği için max_execution_time ve max_input_time değerleri de bazen şart olur.

Çözüm 2: Hosting Panelinden PHP Ayarlarını Düzenleme

Pek çok hosting panelinde PHP ayarları bir arayüzden yönetilir. Burada upload_max_filesize ve post_max_size değerlerini yükseltirsiniz. Bu yöntem, teknik risk açısından genelde daha güvenlidir. Çünkü yanlış dosyaya yanlış satır yazıp siteyi bozma ihtimaliniz düşer. Özellikle paylaşımlı hostinglerde panel yöntemi en pratik çözümdür.

Şunu açık söyleyeyim: Eğer paneliniz varsa ve bu ayarlar erişilebilirse, “kodla uğraşayım” diye ısrar etmeye gerek yok. Geleneksel yönetim, en az riskli yöntemle işi çözmeyi sever. Bu tip WordPress Hata durumlarında risk almak gereksizdir.

Çözüm 3: .htaccess ile Deneme (Her Sunucuda Çalışmaz)

Apache + mod_php kullanılan bazı ortamlarda .htaccess içine PHP değerleri eklenebilir. Ancak modern hostinglerin önemli bir kısmında bu yöntem kapalıdır. Yine de mantığı göstermek için örnek:

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 memory_limit 256M

Eğer bu satırları ekleyince 500 hatası alırsanız, hostinginiz .htaccess üzerinden php_value kullanımına izin vermiyor demektir. O zaman bu satırları derhal geri alırsınız. Bu, sık yapılan bir hatadır: “limit artırayım” derken siteyi tamamen kapatırlar. Bu yüzden .htaccess yöntemi her zaman “dikkatli deneme” kategorisindedir.

Çözüm 4: Nginx Ortamlarında Doğru Yerden Ayar Yapma

Nginx’te .htaccess yoktur. Bu yüzden php.ini/.user.ini veya panel üzerinden gidersiniz. Bazı Nginx kurulumlarında ayrıca Nginx tarafında istek gövdesi limiti vardır. Eğer o limit düşükse 413 benzeri davranışlar da görebilirsiniz. Yani yalnızca upload_max_filesize artırmak yetmeyebilir. Bu tür durumlarda katmanları birlikte düşünmek şarttır.

Dosya Boyutunu Düşürmek: Bazen En Akıllı Çözüm

Her zaman limit artırmak doğru değildir. Örneğin 20 MB’lık bir görseli yüklemeye çalışıyorsanız, asıl sorun o görselin hazırlanma biçimidir. Web için doğru çözüm, görseli optimize etmek, uygun format kullanmak ve boyutu düşürmektir. Aynı şekilde devasa bir yedek dosyasını panelden yüklemek yerine daha uygun bir yöntem (sunucuya direkt yükleme, parça parça aktarma) tercih edilebilir. Bu, eski usul “işi doğru yapma” mantığıdır. Bu WordPress Hata durumunda da geçerlidir: sistemi şişirmek yerine yükü akıllı yönetmek çoğu zaman daha iyidir.

Kalıcı Çözüm Mantığı: Limitleri İhtiyaca Göre Ayarlayın

Kalıcı çözüm şudur: Sitenizin gerçek ihtiyacı neyse ona göre upload_max_filesize ve post_max_size değerlerini belirleyin. “Ne olur ne olmaz 2GB yapalım” yaklaşımı iyi bir yönetim değildir. Çünkü gereksiz yüksek limitler, kötü niyetli kullanım riskini ve kaynak tüketimini artırır. Bu yüzden ölçülü olun. Yükleme ihtiyacınız düzenliyse makul bir değer seçin, nadiren büyük dosya gerekiyorsa o işi farklı yöntemle yapın.

“Yüklenen dosya, upload_max_filesize’ı aşıyor” hatası bir WordPress Hata gibi görünür; ama özünde PHP limitidir. Doğru katmanda limitleri düzenler, gerekiyorsa dosyayı optimize eder, işi temiz bitirirsiniz.

Ölümcül Hata: Maksimum Yürütme Süresi Aşıldı Nedir?

“Ölümcül Hata: Maksimum Yürütme Süresi Aşıldı” uyarısı, WordPress’in (daha doğrusu PHP’nin) bir işlemi bitirmek için kendisine tanınan süreyi aştığını söyler. PHP tarafında her script için bir zaman sınırı vardır. İşlem bu süre içinde tamamlanamazsa PHP “burada duruyorum” diyerek süreci keser ve ekrana fatal error basabilir. Bazı durumlarda kullanıcı sadece beyaz ekran görür, bazen de 500 hatası çıkar. Ama kök sebep nettir: işlem uzadı, süre yetmedi. Bu tip bir WordPress Hata özellikle içe aktarma, yedekleme, büyük görsel işleme, ağır sayfa kaydı ve yoğun sorgu üreten eklentilerde sık görülür.

Burada pratik bir gerçek var: Süreyi artırmak çoğu zaman işi “geçici” çözer. Kalıcı çözüm ise işlemi hızlandırmak veya o işlemi arka plana taşımaktır. Eski usul sağlam yönetim, “sınırı yükseltip geçmek” yerine “neden bu kadar uzun sürdü” sorusunu sorar. Çünkü aynı WordPress Hata tekrar tekrar geliyorsa, sorun süre değil, yükün kontrolsüzlüğüdür.

Bu Hata WordPress’te Ne Zaman Karşınıza Çıkar?

En sık görülen senaryolar şunlardır:

– Büyük bir eklenti/tema güncellemesi sırasında.

– Medya Kütüphanesine büyük görsel/video yüklerken veya görsel boyutları üretilirken.

– WooCommerce gibi sistemlerde toplu ürün işlemlerinde.

– Site taşıma, yedek alma veya yedek geri yükleme işlemlerinde.

– İçe aktarma (XML/CSV) işlemlerinde.

– Ağır sayfa oluşturucularda kaydetme sırasında.

Bu işlemlerden biri sırasında “maksimum yürütme süresi aşıldı” hatası çıkıyorsa, iki şeyden biri oluyordur: ya limitiniz düşük, ya işlem gereksiz yere ağır. Bu yüzden çözümü de iki katmanda ele alacağız.

Çözüm 1: max_execution_time Değerini Artırma

Başlangıç hamlesi olarak max_execution_time değerini yükseltmek çoğu zaman işi açar. Bu değer php.ini veya .user.ini içinden ayarlanabilir. Örnek:

max_execution_time = 300
max_input_time = 300

Buradaki 300 saniye örnektir. Bazı hostinglerde 30 saniye gibi düşük değerler olur. Büyük işlemler için 120-300 saniye aralığı sık kullanılır. Ancak unutmayın: Bu değerleri artırmak, siteyi “hızlandırmaz”; sadece daha uzun süre beklemesine izin verir. Bu yüzden bu WordPress Hata durumunda mutlaka performans tarafına da bakılmalıdır.

Çözüm 2: wp-config.php veya .htaccess Üzerinden Artırma (Ortamınıza Bağlı)

Bazı ortamlarda wp-config.php içine veya .htaccess içine değer ekleme yapılabilir. Ancak hosting’e göre değişir. Yine de mantığı görmek için örnek veriyorum. .htaccess ile deneme:

php_value max_execution_time 300
php_value max_input_time 300

Eğer bu satırlar 500 hatası doğurursa, hostinginiz .htaccess üzerinden php_value kullanımına izin vermiyor demektir; hemen geri alırsınız. Bu, klasik bir tuzaktır: “süre artırayım” derken siteyi tamamen düşürürsünüz.

Çözüm 3: İşlemi Hafifletme (Asıl Kalıcı Çözüm)

Burada sert konuşacağım: Süreyi sonsuza kadar artırarak iyi yönetici olunmaz. Çünkü sorun çoğu zaman “işlem gereksiz ağır” olduğu için çıkar. Bu yüzden aşağıdaki adımlar, kalıcı çözümün bel kemiğidir:

– Büyük içe aktarmaları parçalara bölün. Tek seferde dev XML/CSV basmak, bu WordPress Hata için davetiyedir.

– Yedeklemeyi yoğun trafikte değil, sakin saatlerde alın. Aynı anda hem ziyaretçi trafiği hem yedekleme, sunucuyu boğar.

– Görselleri yüklemeden önce optimize edin. 12-15 MB görseli WordPress’e “işle” diye yollamak, süreyi uzatır.

– Ağır eklentileri kontrol edin. Bazı eklentiler her işlemde gereksiz tarama yapar, log tutar, dış servise bağlanır.

– Veritabanı yavaşsa önce onu düzeltin. Yavaş sorgu = uzun işlem = zaman aşımı.

Bu adımlar yapıldığında, çoğu zaman max_execution_time artırmaya bile gerek kalmaz. Çünkü işlem zaten hızlanır.

Çözüm 4: Sunucu Kaynaklarını ve PHP-FPM Havuzunu Kontrol Etme

Uzun süren işlemler bazen sadece uygulama değil kaynak problemidir. CPU tavan, RAM doluysa her şey yavaşlar. PHP-FPM havuzu dolduysa istekler sıraya girer ve süre aşımı daha hızlı gelir. Bu yüzden hosting panelinden kaynak kullanımını kontrol edin. Paylaşımlı hostinglerde limitler darsa, aynı işi daha güçlü bir planda yapmak zorunda kalabilirsiniz. Bu bir gerçek. “Ben artırdım olmuyor” dediğinizde, çoğu zaman sorun kaynak sınırıdır.

Log Kayıtları: Hangi Dosya Takıldı, Hangi İşlem Uzadı?

Bu hatada loglar size hangi dosyanın ve hangi satırın takıldığını gösterebilir. Böylece “hangi eklenti” veya “hangi işlem” sorusuna net cevap bulursunuz. WordPress debug log açmak bu açıdan faydalıdır. Ayrıca hosting’in PHP error log’u da çoğu zaman doğrudan hatayı yazar. Bu kanıt olmadan siz sadece tahmin yürütmüş olursunuz.

Kalıcı Çözüm Mantığı: Süreyi Artır, Ama Disiplini Kaybetme

max_execution_time artırmak, acil durumda siteyi ayağa kaldırır. Ama kalıcı çözüm, işlemi hafifletmek ve sistemi optimize etmektir. Bu WordPress Hata tekrar ediyorsa, bir yerde kontrolsüz büyüme vardır: eklenti sayısı, görsel boyutları, içe aktarma alışkanlığı, veritabanı şişmesi veya kaynak darlığı. Geleneksel, sağlam yönetim bu işi “neden” üzerinden çözer.

Son söz: “Maksimum yürütme süresi aşıldı” hatası size şunu söylüyor: ya daha iyi optimize ol, ya da daha iyi kaynak planla. İkisini de yaparsanız bu hata sizi uğraştırmaz.

Yükleme: Dosya Diske Yazma Başarısız Oldu Hatası Nedir?

“Yükleme: Dosya Diske Yazma Başarısız Oldu” hatası, WordPress’in yüklenen dosyayı sunucuda kalıcı olarak kaydedemediğini söyler. Kullanıcı açısından çok basit görünür: bir görsel yüklemek ister, yükleme yarıda kalır ve hata çıkar. Ama arka planda birkaç kritik sebep vardır: yanlış dosya izinleri, yanlış klasör sahipliği, dolu disk, geçici (tmp) dizin problemleri veya hosting tarafında güvenlik kısıtlamaları. Yani bu olay çoğu zaman “WordPress bozuldu” değil, “sunucu yazma izni yok” meselesidir. Yine de sonuç itibarıyla bu bir WordPress Hata olarak karşınıza çıkar.

Bu hatada da eski usul kural geçerlidir: önce en basit kontrol (disk dolu mu?), sonra izin/sahiplik, en son da PHP geçici dizin ve güvenlik katmanı. Rastgele eklenti kapatmak bazen işe yarar ama genellikle kök sebep dosya sistemi tarafındadır.

Bu Hata Ne Zaman Görülür?

Genellikle Medya Kütüphanesine görsel yüklerken görülür. Bazen tema/eklenti yüklemesinde de benzer davranış olur. Ayrıca bir resim optimize eklentisi (yüklerken dönüştürme/sıkıştırma yapan) kullanıyorsanız, işlem sırasında temp dosyalar üretildiği için hata daha sık tetiklenebilir. Özellikle paylaşımlı hostinglerde, tmp dizini dolarsa veya yazma izni kısıtlanırsa bu WordPress Hata aniden ortaya çıkar.

İlk Kontrol: Disk Alanı Dolmuş Olabilir

Bu hatanın en kaba ama en gerçek sebebi disk doluluğudur. Disk doluysa WordPress hiçbir yere yazamaz. Sadece medya değil, cache dosyaları bile yazılamaz. Sonuç da çeşitli hatalarla gelir. Hosting panelinizden disk kullanımını kontrol edin. Eğer disk doluysa, önce yer açın: eski yedekleri silin, gereksiz logları temizleyin, cache klasörlerini kontrol edin. Disk doluyken “izinleri düzeltmeye” çalışmak boş iştir.

Disk doluluğu düzeldikten sonra yükleme tekrar denenir. Eğer sorun devam ediyorsa, ikinci katmana geçersiniz: izinler ve sahiplik.

Çözüm 1: uploads Klasörünün İzinlerini Kontrol Etme (755 Kuralı)

WordPress medya dosyalarını genellikle wp-content/uploads içine yazar. Bu klasörün yazılabilir olması gerekir. Klasör izinleri genelde 755, dosya izinleri 644 olur. Eğer uploads veya wp-content yazılamıyorsa, “Dosya Diske Yazma Başarısız Oldu” hatası kaçınılmazdır.

FTP/SFTP ile kontrol ettiğinizde wp-content ve uploads için izinlerin mantıklı olduğundan emin olun. Klasörler için genel standart:

klasörler: 755
dosyalar: 644

Ama burada kritik bir gerçek var: İzinler doğru görünse bile sahiplik yanlışsa yine yazamaz. Yani sadece “chmod” yetmez; bazen “chown” gerekir. Paylaşımlı hostinglerde chown erişimi sizde olmayabilir; o zaman hosting desteğiyle çözülür.

Çözüm 2: Klasör Sahipliği Sorunu (İzin Var Gibi, Ama Yazmıyor)

Sahiplik problemi en sinir bozucu olanıdır. Dışarıdan bakarsınız 755, dersiniz “tamam”. Ama WordPress hâlâ yazamaz. Çünkü dosyaların sahibi web sunucusunun çalıştığı kullanıcı değildir. Bu durum sıkça şu senaryoda olur: site taşıma, manuel dosya yükleme, yedekten geri yükleme, farklı kullanıcıyla dosya kopyalama. Sonuç: WordPress yazamaz, bu WordPress Hata çıkar.

Bu noktada pratik hareket: hosting panelinde “File Manager” üzerinden bir dosya oluşturmayı deneyin (örneğin uploads içine boş bir txt). Eğer panel yazabiliyor ama WordPress yazamıyorsa, web sunucusu kullanıcısının yetkisi yok demektir. Bu durumda sahiplik düzeltilmelidir. Paylaşımlı hostingte en hızlı yol hosting desteğidir.

Çözüm 3: Geçici (tmp) Dizin Problemi ve WP_TEMP_DIR Tanımı

WordPress dosya yüklerken önce geçici bir dizine yazar, sonra uploads’a taşır. Sunucunuzdaki tmp dizini doluysa, erişim yoksa veya PHP yanlış tmp dizinini kullanıyorsa yükleme yine patlar. Bu durumda wp-config.php içine geçici dizin tanımı eklemek çözüm olabilir. Örnek:

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Sonra wp-content içinde temp adında bir klasör oluşturup yazılabilir yaptığınızdan emin olursunuz. Bu yaklaşım özellikle hosting’in varsayılan tmp dizininde problem varsa işe yarar. Bu, klasik bir “sisteme alternatif yol açma” hamlesidir. Bu tip WordPress Hata durumlarında çok pratiktir.

Çözüm 4: Güvenlik Katmanı veya ModSecurity Engeli

Bazı hostinglerde ModSecurity gibi katmanlar yükleme isteklerini şüpheli görüp kesebilir. Özellikle dosya isimleri, uzantılar veya bazı içerikler tetikleyici olabilir. Bu durumda WordPress “diske yazamadım” gibi genelleme yapar, ama gerçekte istek daha baştan engellenmiştir. Eğer izinler doğru, disk boş, tmp düzgün ama sorun devam ediyorsa, güvenlik logları ve hosting tarafı kuralları kontrol edilmelidir.

Burada akıllı yöntem şudur: farklı bir dosya adıyla deneyin (Türkçe karakter, boşluk, özel karakter olmadan). Farklı bir küçük görselle deneyin. Eğer bazı dosyalar olur bazıları olmazsa, güvenlik veya filtre ihtimali yükselir.

Çözüm 5: Cache ve Optimizasyon Eklentileriyle Çakışma

Normalde bu hata dosya sistemi kaynaklıdır ama bazı optimizasyon eklentileri yükleme anında görsel dönüştürür, yeniden boyutlandırır, WebP üretir. Bu işlemler temp dosyalar üretir ve daha fazla yazma ister. Eğer sunucu yazma yetkisi sınırdaysa hata tetiklenebilir. Bu yüzden sorunu teşhis ederken görsel optimizasyon eklentilerini geçici kapatmak mantıklıdır. Çünkü bazı WordPress Hata durumlarında tetikleyici “ek işlem”dir.

Kalıcı Çözüm Mantığı: Yazma Yetkisi, Alan ve Düzen

Kalıcı çözüm şudur: uploads ve ilgili klasörler doğru izin/sahiplikte olacak, disk alanı düzenli kontrol edilecek, tmp dizini sağlam çalışacak, güvenlik kuralları gereksiz agresif olmayacak. Bu işin “geleneksel” tarafı bakımdır: ayda bir disk kontrolü, logların şişmesini engelleme, yedeklerin birikmesini temizleme, taşıma sonrası sahiplikleri doğrulama. Bu disiplin olmazsa bu WordPress Hata bir gün yine gelir.

“Dosya diske yazma başarısız” hatası WordPress’in değil, çoğu zaman sunucunun “yazamazsın” demesidir. Doğru yerden kontrol eder, yazma yolunu açarsanız iş biter.

Güvenli Bağlantı Hatası Nedir ve WordPress Neden WordPress.org’a Uzanamaz?

“Güvenli Bağlantı Hatası” WordPress tarafında genelde çekirdek güncellemesi, eklenti/tema kurulumu veya güncellemesi sırasında ortaya çıkar. WordPress bu işlemler için çoğu zaman WordPress.org ile güvenli bir bağlantı kurmak zorundadır. Bağlantı kurulamazsa, panelde uyarı görürsünüz ve bazı güncellemeler takılır. Bu olay bir WordPress Hata gibi görünür; ama çoğu zaman gerçek sebep sunucu ağ ayarları, güvenlik duvarı kısıtları, DNS sorunları, TLS/SSL kütüphaneleri veya hosting tarafındaki geçici engellerdir. Yani WordPress “ben erişemedim” der, siz de “neden erişemedi”yi altyapıda ararsınız.

Bu hatada “eski usul” yaklaşımın değeri büyüktür: önce bağlantı var mı, DNS doğru mu, SSL/TLS düzgün mü, firewall engelliyor mu, sonra WordPress tarafında hangi istek başarısız oluyor. Rastgele eklenti kapatarak bunu çözemezsiniz. Bu tip WordPress Hata durumlarında iş, ağ ve güvenlik tarafında biter.

Bu Hata Hangi Durumlarda Görülür?

En sık görülen durumlar şunlardır:

– WordPress çekirdeği güncellerken

– Eklenti/tema indirip kurarken

– Otomatik güncellemeler çalışırken

– Hosting taşıma sonrası veya DNS değişimi sonrası

– Sunucuda güvenlik duvarı kuralı güncellendiğinde

– Sunucu, WordPress.org’a giden çıkış trafiğinde problem yaşadığında

Bu tablo size şunu söyler: WordPress çalışıyor olabilir, site açılıyor olabilir; ama WordPress’in dış dünyaya (özellikle WordPress.org’a) güvenli şekilde çıkışı kırılmıştır. İşte bu yüzden bu hata, sessiz ama kritik bir WordPress Hata olarak değerlendirilmelidir.

İlk Kontrol: Sorun Sizde mi, WordPress.org Tarafında mı?

Bazen sorun sizde değildir; WordPress.org tarafında geçici bir problem olabilir. Bu nadirdir ama olur. Bu yüzden ilk pratik hareket: bir süre sonra tekrar deneyin ve farklı bir ağdan WordPress.org’a erişim var mı kontrol edin. Ancak çoğu vakada sorun sunucu tarafındadır. Çünkü tarayıcınızdan WordPress.org açılıyor olsa bile, sunucunun kendisi erişemiyor olabilir. Önemli olan sunucunun çıkış bağlantısıdır.

DNS Sorunları: Sunucu Adres Çözümleyemiyorsa Bağlantı Kurulmaz

Sunucu WordPress.org alan adını IP’ye çeviremiyorsa, güvenli bağlantı kurulamaz. Bu, DNS ayarlarındaki bozukluk, yanlış resolv.conf, hatalı nameserver veya geçici DNS kesintisi nedeniyle olur. Burada pratik test mantığı şudur: sunucu tarafında alan adını çözmeyi deneyin. SSH erişiminiz varsa bu tip testler çok hızlı teşhis sağlar. Örnek komut mantığı:

nslookup wordpress.org

Bu çözümleme başarısızsa sorun WordPress değil DNS’tir. DNS düzelmeden bu WordPress Hata bitmez.

SSL/TLS Problemleri: Sertifika ve Protokol Uyumsuzlukları

Güvenli bağlantı hatasının bir diğer klasik sebebi, sunucuda SSL/TLS desteğinin eksik veya uyumsuz olmasıdır. Örneğin eski bir OpenSSL sürümü, güncel TLS şartlarını karşılamayabilir. Ya da sunucunun CA sertifika paketi (cert bundle) bozulmuş olabilir. WordPress dışarıya HTTPS ile çıkarken sertifikayı doğrulayamazsa bağlantıyı kuramaz. Bu durumda WordPress “güvenli bağlantı hatası” verir.

Burada önemli bir ayrıntı var: Bazı hostinglerde bu durum PHP’nin cURL uzantısının veya OpenSSL’in yanlış derlenmesinden de kaynaklanır. Yani uygulama katmanında bir “kütüphane” problemi olabilir. Bu yüzden “WordPress’i sıfırlayayım” gibi hamleler bu WordPress Hata için yanlış hedefe ateştir.

Firewall ve Güvenlik Duvarı Engelleri: Çıkış Trafiği Kısıtlanmış Olabilir

Paylaşımlı veya kurumsal bazı sunucularda, güvenlik gereği dışarı çıkış (outbound) kısıtlanır. WordPress.org’a giden istekler engellenirse, güncellemeler doğal olarak çalışmaz. Ayrıca bazı güvenlik sistemleri belirli IP aralıklarını yanlışlıkla bloklayabilir. Bu durumda WordPress “ben bağlanamadım” der. Eğer sizin tarafınızda her şey normal görünüyorsa ama güncelleme/kurulum işlemleri hep patlıyorsa, firewall ihtimali yükselir.

Bu noktada en pratik yaklaşım, hosting sağlayıcısından “sunucum WordPress.org’a çıkabiliyor mu?” sorusuna net cevap almaktır. Çünkü çoğu kullanıcı panelden bunu göremez. Bu tip WordPress Hata durumlarında host desteği çoğu zaman en kısa yoldur.

Proxy ve Kurumsal Ağ Ayarları: WordPress’in Çıkışı Yanlış Yönleniyor Olabilir

Bazı sunucular proxy üzerinden internete çıkar. Proxy ayarı yanlışsa veya kimlik doğrulama gerekiyorsa, WordPress dışarı bağlantı kuramaz. Ayrıca WordPress’in kullandığı HTTP API’nin proxy ayarları farklı davranabilir. Bu durumda bağlantı hatası “rastgele” gibi görünür. Bu nedenle sunucuda proxy yapılandırması varsa, sistem genelinde doğru çalıştığından emin olmanız gerekir.

WordPress Tarafı: Site Sağlığı, HTTP API ve WP Cron Kontrolü

WordPress’in yönetim panelinde “Site Sağlığı” bölümü (Site Health) bazı bağlantı sorunlarını işaret edebilir. Ayrıca WP Cron çalışmıyorsa otomatik güncellemeler de sapıtabilir. Yine de bu hatanın temel sebebi çoğu zaman ağdır. WordPress tarafında yapılacaklar genelde “sorunu görünür kılmak” ve log toplamak içindir. Örneğin debug log açıp hatanın detayını yakalamak işe yarar.

Geçici Çözüm: Manuel Güncelleme ve Yükleme

Bu WordPress Hata çözülene kadar siteyi güncel tutmanız gerekebilir. O zaman en güvenli geçici yöntem, eklenti/tema dosyalarını manuel yüklemek ve WordPress çekirdeğini manuel güncellemektir. Ama bunu alışkanlık haline getirmeyin. Çünkü sorun çözülmezse ileride güvenlik açıklarına davetiye çıkarırsınız. Güncellemelerin otomatik/kolay akması, WordPress yönetiminin temel geleneğidir.

Kalıcı Çözüm Mantığı: Bağlantıyı Sunucu Tarafında Sağlamlaştırın

Kalıcı çözüm şudur: DNS çözümlemesi düzgün olacak, SSL/TLS kütüphaneleri güncel ve uyumlu olacak, CA sertifikaları sağlam olacak, firewall WordPress.org isteklerini engellemeyecek, proxy varsa doğru ayarlanacak. Bunlar sağlandığında WordPress güncellemeleri sorunsuz çalışır ve bu WordPress Hata ortadan kalkar.

“Güvenli Bağlantı Hatası” çoğu zaman WordPress’in değil, sunucunun dış dünyaya güvenli çıkışının problemidir. Doğru katmanı düzeltirseniz, WordPress kendiliğinden toparlar.

Cloudflare Hatası 521 Nedir

WordPress Siteniz Neden “Origin Yanıt Vermiyor” Diye Bağırır?

Cloudflare Hatası 521, doğrudan :contentReference[oaicite:0]{index=0} ile ilgili bir hatadır. Cloudflare bir CDN ve güvenlik katmanı olarak sitenizin önünde durur; ziyaretçi önce Cloudflare’a gelir, Cloudflare da arka taraftaki asıl sunucuya (origin) bağlanıp içeriği alır. 521 hatası şu anlama gelir: Cloudflare, origin sunucuya bağlanmaya çalıştı ama sunucu bağlantıyı reddetti veya yanıt vermedi. Yani WordPress’e ulaşamadı. Bu yüzden bu durum bir WordPress Hata gibi görünse de çoğu zaman WordPress’ten önceki katmanlarda biter: sunucu kapalı, firewall engelliyor, portlar yanlış, IP engeli var, SSL uyumsuzluğu var, veya web sunucusu cevap veremeyecek durumda.

Bu hatada en büyük tuzak şudur: “Cloudflare bozuldu” diye düşünmek. Cloudflare çoğu zaman sadece haberci. Asıl mesele origin’in ya çalışmaması ya da Cloudflare’ın IP’lerini içeri almamasıdır. Geleneksel yaklaşım burada da şart: önce origin ayakta mı, sonra firewall/izinler, en son Cloudflare ayarları.

521 Hatası Ne Zaman Görülür?

En sık görülen senaryolar şunlardır:

– Sunucu geçici olarak down olmuştur veya kaynakları tükenmiştir.

– Firewall Cloudflare IP aralıklarını engelliyordur.

– Hosting tarafında güvenlik sistemi Cloudflare’ı saldırı sanıp bloklamıştır.

– Origin web sunucusu (Nginx/Apache) çökmüştür veya servis durmuştur.

– Port 80/443 erişimi kısıtlanmıştır.

– Sunucu IP’si değişmiştir ama Cloudflare DNS hâlâ eski IP’ye gidiyordur.

Bu senaryoların çoğunda WordPress’in suçu yoktur. Ama kullanıcı yine de “site açılmıyor” diye sizi arar. İşte bu yüzden Cloudflare 521, operasyonel olarak ciddi bir WordPress Hata gibi ele alınmalıdır.

İlk Teşhis: Cloudflare’ı Bypass Edince Site Açılıyor mu?

En hızlı teşhis şu: Cloudflare’ı devre dışı bırakıp (DNS kaydını “DNS only” yapmak veya geçici olarak Cloudflare proxy’yi kapatmak gibi) origin sunucuya doğrudan bağlanmayı deneyin. Eğer Cloudflare kapalıyken site açılıyorsa, sorun WordPress’in kendisi değil; Cloudflare ile origin arasındaki iletişimdir. Eğer Cloudflare kapalıyken de açılmıyorsa, origin zaten problemli demektir.

Bu teşhis, boş yere WordPress içinde debelenmenizi engeller. Çünkü 521’in kalbi “origin’e erişim”dir. Bu da çoğunlukla sunucu/firewall işidir.

Origin Sunucunun Ayakta Olduğunu Kanıtlama

Origin sunucu gerçekten çalışıyor mu? Web sunucusu (Nginx/Apache) ayakta mı? PHP-FPM çökmüş mü? Disk dolu mu? CPU/RAM tavan mı? Bu kontroller 521 çözümünün bel kemiğidir. Hosting panelinizde servis durumları varsa kontrol edin. SSH erişiminiz varsa web sunucusu servislerini kontrol edin. Çünkü Cloudflare 521 genelde “ben bağlanamadım” derken, origin tarafında “servis yok” veya “servis var ama reddediyor” gerçeği yatar.

Bu noktada güçlü fikir şudur: Cloudflare 521’i çözmek istiyorsanız, önce origin’i sağlamlaştıracaksınız. Origin sallanıyorsa Cloudflare’ın yapacağı bir şey yok.

Firewall ve IP Engeli: Cloudflare IP’leri Beyaz Listeye Alınmadıysa

521 hatasının en yaygın sebebi, origin tarafında firewall’ın Cloudflare’ı engellemesidir. Özellikle güvenlik eklentileri, sunucu güvenlik duvarları, WAF kuralları veya brute-force korumaları bazen Cloudflare’dan gelen trafiği yanlışlıkla “şüpheli” görür. Sonuç: bağlantı reddedilir, Cloudflare 521 verir.

Çözüm mantığı basittir: Cloudflare’ın IP aralıkları origin firewall’da izinli olmalıdır. Bu işlem hosting veya sunucu yönetimi gerektirir. Eğer buna erişiminiz yoksa, hosting desteğiyle yapılır. Yanlış yere odaklanmayın; bu WordPress Hata görüntüsünün sebebi çoğu zaman firewall’dır.

Port ve Servis Kontrolü: 80/443 Açık mı?

Cloudflare origin’e genelde 80 (HTTP) ve 443 (HTTPS) üzerinden bağlanır. Eğer sunucuda bu portlar kapalıysa veya sadece belirli IP’lere açıksa, Cloudflare bağlanamaz ve 521 çıkar. Bazı sistemlerde 443 açık ama 80 kapalıdır; bazı Cloudflare ayarları buna göre uyum ister. Ayrıca hosting, belli güvenlik politikalarıyla portları kısıtlamış olabilir. Bu durumda çözüm, port erişimini düzgün hale getirmektir.

DNS ve IP Değişimi: Cloudflare Yanlış IP’ye Gidiyor Olabilir

Sunucu taşıması yaptıysanız veya IP değiştiyse, Cloudflare DNS kayıtları hâlâ eski IP’ye gidiyor olabilir. Bu durumda Cloudflare origin’e bağlanamaz, çünkü yanlış yere bağlanıyordur. Özellikle A kaydı veya AAAA (IPv6) kaydı yanlışsa 521 tetiklenebilir. Burada pratik kontrol: Cloudflare panelinde DNS kayıtlarını gözden geçirin. Origin IP’niz doğru mu? IPv6 kullanmıyorsanız AAAA kaydı var mı? Bu tip detaylar 521’de sık “sessiz fail” olur.

SSL Modu Uyumsuzluğu: Full, Flexible ve Gerçeklik

Cloudflare SSL modları doğru ayarlanmazsa, origin ile bağlantı kurma şekli bozulabilir. Örneğin origin’de SSL yokken “Full” gibi modlar yanlış olur. Ya da origin sertifikası geçersizken “Full (Strict)” seçilirse Cloudflare bağlantıyı kuramaz. Bu durumda bazen 525/526 gibi hatalar da görülür ama bazı durumlarda 521’e yakın davranışlar çıkar. Bu yüzden Cloudflare SSL modunu origin’in gerçek durumuna göre ayarlamak şarttır.

WordPress Tarafı: Neden Yine de İlgili Olabilir?

Cloudflare 521 çoğunlukla WordPress’ten bağımsızdır; ama dolaylı tetikleyici WordPress olabilir. Örneğin ağır bir eklenti yüzünden PHP-FPM çöküyordur, web sunucusu yanıt veremez hale geliyordur; Cloudflare da “origin yok” diyerek 521 döndürür. Yani WordPress, origin’i boğarak hatayı tetikleyebilir. Bu nedenle origin kaynakları tükendiyse eklenti/tema yükünü de kontrol etmek gerekir. Bu yönüyle 521, dolaylı bir WordPress Hata tetiklenmesi olabilir.

Kalıcı Çözüm Mantığı: Cloudflare ile Origin Arasını Sağlamlaştırın

Kalıcı çözüm şudur: Origin sunucu istikrarlı çalışacak, 80/443 açık olacak, firewall Cloudflare IP’lerini engellemeyecek, DNS kayıtları doğru IP’yi gösterecek, SSL modu origin ile uyumlu olacak. Bunlar düzeldikten sonra Cloudflare 521 susar. Bu hatayı “arada olur” diye kabullenmeyin; çünkü her 521, kullanıcıya “site yok” demektir. Bu da marka güvenilirliğine doğrudan zarar verir.Cloudflare Hatası 521 bir WordPress Hata gibi görünür; ama çözümün büyük kısmı sunucu ve güvenlik katmanındadır. Origin sağlam değilse, Cloudflare sadece haber verir.

Üzgünüz, bu dosya türüne güvenlik nedenleriyle izin verilmiyor Hatası Nedir?

Bu uyarı, WordPress’in güvenlik refleksidir. Siz Medya Kütüphanesine bir dosya yüklemek istersiniz; WordPress dosyanin uzantısına ve dosyanın tipine (MIME) bakar, sonra da “bu dosya tehlikeli olabilir” diyerek yüklemeyi daha baştan keser. Ekrana da gayet net bir mesaj basar: “Üzgünüz, bu dosya türüne güvenlik nedenleriyle izin verilmiyor.” Birçok kişi bunu anında bir WordPress Hata sanıyor, ama çoğu vakada sistemin doğru yaptığı bir iş var: sitenize çalıştırılabilir içerik, zararlı kod veya güvenlik açığı doğurabilecek dosyaların girmesini engellemek. Hele ki siteyi birden fazla kişi kullanıyorsa, bu kural sizi kötü sürprizlerden korur; çünkü bir kişinin “ne olur ne olmaz” diye yüklediği tek bir dosya, bütün siteyi riskli hale getirebilir.

Bu hata genelde üç temel sebepten çıkar. Birincisi, gerçekten WordPress’in varsayılan olarak engellediği bir tür yüklemeye çalışıyorsunuzdur. Örneğin SVG dosyaları çok istenir ama WordPress çoğu kurulumda SVG’yi temkinli yaklaşım nedeniyle engeller; çünkü SVG metin tabanlıdır ve kötü niyetle düzenlenirse istenmeyen davranışlara kapı açabilir. İkincisi, dosya aslında masumdur ama sunucunuz dosyanın tipini yanlış algılıyordur; uzantı doğru olsa bile MIME yanlış raporlanır, WordPress de “ben buna güvenemem” der. Üçüncüsü ise WordPress’in önünde veya yanında çalışan güvenlik katmanlarıdır: güvenlik eklentileri, WAF kuralları, hosting tarafındaki korumalar veya ModSecurity benzeri sistemler bazı dosyaları otomatik reddeder. Sonuç değişmez: siz bunu bir WordPress Hata gibi görürsünüz, ama gerçekte bir “yükleme politikası” engeline takılmışsınızdır.

Çözüm tarafında iki yaklaşım vardır. Birinci yaklaşım doğru olandır: sadece ihtiyacınız olan dosya türünü kontrollü biçimde izinli hale getirmek. Bu, geleneksel ve düzgün yönetim biçimidir; sistemi gevşetmez, sadece gerekli kapıyı açar. Mesela sadece SVG veya WebP yüklemeniz gerekiyorsa, tüm yüklemeleri serbest bırakmak yerine yalnızca bu türlere izin verirsiniz. Bunun en yaygın yolu, temanızın functions.php dosyasına MIME izinleri eklemektir. Aşağıdaki kod örneği, yalnızca SVG ve WebP gibi belirli türleri izinli hale getirir. Bu yöntemi uyguladıktan sonra dosyayı tekrar yüklemeyi denersiniz; çözüm buysa iş biter, güvenlik de gereksiz yere zayıflamaz.

add_filter('upload_mimes', 'dw_allow_custom_mimes');
function dw_allow_custom_mimes($mimes) {
    $mimes['svg']  = 'image/svg+xml';
    $mimes['webp'] = 'image/webp';
    return $mimes;
}

Burada kritik bir ayrıntı var: WordPress sadece uzantıya bakmaz, dosyanın gerçekten o tipte olup olmadığını da doğrulamaya çalışır. Bu yüzden bazı sunucularda, özellikle SVG gibi dosyalarda MIME algısı tutarsızsa, izin ekleseniz bile yükleme yine reddedilebilir. Böyle bir durumda pratik hareket şudur: dosyayı yeniden kaydedin, dosya adını sadeleştirin, özel karakterlerden ve gereksiz boşluklardan kaçının, mümkünse dosyayı farklı bir araçla yeniden üretin. Bu basit adımlar, “dosya tipi uyumsuz” gibi görünen pek çok sorunu çözer. Çünkü bazı hatalar teknik görünür ama kökü dosyanın kendisindedir.

İkinci yaklaşım ise daha serttir ve ben bunu ancak kısa süreli, kontrollü senaryolarda anlamlı bulurum: filtrelenmemiş yüklemeleri açmak. Bu yöntem, WordPress’in güvenlik frenini gevşetir. Evet, bazı projelerde acil bir iş için gerekebilir; ama kalıcı hale getirmek doğru değildir. Çünkü bugün bir dosya yüklersiniz, yarın aynı kapıdan başka biri farklı bir şey sokar. Yine de mecbur kalırsanız, wp-config.php dosyasına aşağıdaki satırı eklemek bu davranışı değiştirebilir. İşiniz bitince bunu mutlaka geri alın; aksi halde bu WordPress Hata görünmez olur, ama risk büyür.

define('ALLOW_UNFILTERED_UPLOADS', true);

Eğer bu düzenlemelerden sonra bile sorun devam ediyorsa, artık mesele WordPress katmanından çıkmış olabilir. Güvenlik eklentiniz veya hosting güvenlik sistemi dosyayı daha yükleme aşamasında kesiyor olabilir. Bu durumda en akıllı hareket, geçici olarak yalnızca yükleme işlemi sırasında güvenlik kuralını daraltmak ya da ilgili eklentide “upload restrictions” benzeri bir ayar varsa onu düzenlemektir. Benim tavrım net: “her şeyi kapatayım” değil, “sadece gerekeni düzeltip tekrar açayım.” Çünkü bir siteyi yıllarca sorunsuz taşıyan şey, küçük ama disiplinli ayarlardır. WordPress yönetimi böyle yapılır; günü kurtarırken yarını yakmazsınız.

Sonuç olarak bu mesaj, çoğu zaman WordPress’in sizi korumak için yaptığı bir müdahaledir. İhtiyacınız olan dosya türünü kontrollü biçimde izinli hale getirir, dosya tipini doğru üretir ve güvenlik katmanlarını akıllıca yönetirseniz bu uyarı dağılır gider. Üstelik sitenin güvenliği bozulmadan. İşte kaliteli yönetim dediğim budur.

Üzgünüz, bu sayfaya erişmenize izin verilmiyor Hatası Nedir?

“Üzgünüz, bu sayfaya erişmenize izin verilmiyor” uyarısı WordPress’in size net şekilde “bu alana girme yetkin yok” demesidir. Kullanıcı tarafında bu durum çoğu zaman bir WordPress Hata gibi algılanır; çünkü yönetim panelinde bir menüye tıklarsınız ve bir anda duvara toslarsınız. Oysa WordPress, erişimi rol ve yetkilerle (capabilities) yönetir: Yönetici (Administrator) olmanız gerekirken rolünüz düşmüş olabilir, rolünüz doğru görünse bile veritabanındaki yetki kaydı bozulmuş olabilir, bir güvenlik eklentisi sizi yanlışlıkla engelliyor olabilir ya da site taşıma/güncelleme sonrası bazı izinler karışmış olabilir. Bu yüzden “Üzgünüz, bu sayfaya erişmenize izin verilmiyor” hatasını tek bir sebebe bağlayıp rastgele kurcalamak zaman kaybettirir; doğru yöntem, erişim zincirini sırasıyla kontrol etmektir.

En sık görülen senaryo şudur: Kullanıcı hesabınızın rolü değişmiştir ve WordPress artık sizi “admin” görmüyordur. Bu bazen yanlışlıkla olur, bazen bir eklenti rol-yetki düzeniyle oynar, bazen de taşıma sırasında usermeta kayıtları çakışır. Sonuç değişmez: kritik sayfalara girmek istediğinizde “Üzgünüz, bu sayfaya erişmenize izin verilmiyor” mesajı tekrar tekrar çıkar. İkinci yaygın sebep güvenlik eklentileridir. Özellikle yönetim paneli sayfalarını kısıtlayan, IP kuralı koyan, bruteforce korumasını agresif çalıştıran veya belirli menüleri sadece belirli rollere açan eklentiler bu mesajı üretebilir. Üçüncü senaryo veritabanı tarafıdır: wp_usermeta tablosundaki wp_capabilities veya wp_user_level alanları bozulur ya da önek (table prefix) yanlış olduğundan WordPress rolleri yanlış tablodan okur.

Dördüncü senaryo ise daha sinsi olur: sizde yetki vardır ama WordPress’in o sayfada yapmak istediği bir işlem (örneğin dosyaya yazma) izin/sahiplik yüzünden gerçekleşmez, sistem de bunu bazen “Üzgünüz, bu sayfaya erişmenize izin verilmiyor” gibi genel bir uyarıyla yansıtır. Yani bu WordPress Hata görünümü, aslında rol-yetki kadar dosya düzeniyle de tetiklenebilir.

Teşhis için en sağlam ve hızlı yöntem, eklenti kaynaklı bir engel olup olmadığını önce elemek ve ardından rol kaydını doğrulamaktır. Panelin bir kısmına erişebiliyorsanız Kullanıcılar bölümünden hesabınızın rolünü kontrol edin; “Yönetici” değilse zaten mesele bitmiştir. Panelin hiçbir yerine giremiyorsanız, eklenti engeli ihtimali çok yükselir: FTP/SFTP ile wp-content/plugins klasörünün adını geçici olarak değiştirerek tüm eklentileri devre dışı bırakın ve tekrar deneyin. Eğer mesaj kaybolursa, sorun WordPress çekirdeğinde değil; bir eklentinin kuralındadır. Bu klasik yöntem eski usul gibi görünür ama en hızlı sonuç veren yöntemdir: bir hamlede gerçeği görürsünüz. Sonra eklentileri tek tek geri açıp hangisinin “Üzgünüz, bu sayfaya erişmenize izin verilmiyor” sorununu ürettiğini yakalarsınız. Bu yaklaşım, deneme-yanılmayı kontrollü hale getirir ve WordPress Hata aramasını netleştirir.

Eğer eklentiler kapalıyken bile sorun sürüyorsa, artık rol/yetki kaydına bakmak gerekir. Bu noktada phpMyAdmin üzerinden kullanıcı yetkisini düzeltmek mümkündür; fakat burada kural tek: önce yedek, sonra işlem. Çünkü yanlış bir veritabanı hamlesi, sorunu büyütür. Aşağıdaki örnek, ilgili kullanıcının yetkisini tekrar “administrator” seviyesine çekmek için kullanılan mantığı gösterir. Burada amaç, WordPress’in hesabı tekrar doğru rol ile tanıması ve “Üzgünüz, bu sayfaya erişmenize izin verilmiyor” mesajını üretmeyi bırakmasıdır. Bu düzeltme yapıldıktan sonra önbellek varsa temizlenir, çıkış yapılıp tekrar giriş denenir ve problem tekrarlıyorsa tabloların öneki (wp_) ile gerçek önek eşleşiyor mu kontrol edilir. Çünkü önek yanlışsa, WordPress rolü yanlış anahtardan okuyabilir ve yine aynı WordPress Hata görüntüsü ortaya çıkar.

-- phpMyAdmin icin ornek mantik (tablo onegi sizde wp_ olmayabilir)
-- 1) Kullanici ID'sini bulun (wp_users tablosundan)
-- 2) wp_usermeta tablosunda ilgili kayitlari duzeltin

-- administrator rolunu geri verme (ornek: user_id = 1)
UPDATE wp_usermeta
SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 1 AND meta_key = 'wp_capabilities';

UPDATE wp_usermeta
SET meta_value = '10'
WHERE user_id = 1 AND meta_key = 'wp_user_level';

Kalici cozum mantigi su: Rolleri ve yetkileri tertipli tutacaksiniz, guvenlik eklentilerini “her seyi kilitle” mantigiyla degil, olculu ve kontrollu kullanacaksiniz, tasima/guncelleme sonrasi wp_usermeta rol kayitlarini ve tablo onegini dogrulayacaksiniz, gerekiyorsa dosya izin ve sahipligini standartta tutacaksiniz. Boyle yaparsaniz “Uzgunuz, bu sayfaya erismenize izin verilmiyor” mesaji bir daha sizi oyalamaz. En kotu senaryoda bile, bu kontrol zinciriyle sorunu nerede oldugunu dakikalar icinde tespit edersiniz. Bu da iyi yonetimin alametidir: panik degil, sistemli hareket. Ve evet, bu WordPress Hata goruntusu ortadan kalktiginda, yonetim paneliniz eski duzenine geri doner.

Kurulum Başarısız: Dizin Oluşturulamadı Hatası Nedir?

“Kurulum Başarısız: Dizin Oluşturulamadı” hatası, WordPress’in eklenti veya tema kurarken (ya da güncellerken) sunucuda gerekli klasörü oluşturamaması demektir. Yani WordPress dosyaları indirmek ister, sonra wp-content altında uygun yere yerleştirmek için bir klasör açmaya çalışır; fakat sunucu “yazamazsın” diye kapıyı kapatır. Kullanıcı bunu bir WordPress Hata olarak görür; çünkü panelde tek tıkla kurulması gereken şey bir anda takılır. Gerçekteyse olay çoğu zaman WordPress’in kendisinde değil, dosya sistemi izinleri, klasör sahipliği, disk alanı, güvenlik kısıtları veya WordPress’in dosya yazma yöntemi (Filesystem API) tarafındadır. Bu yüzden bu hatayı çözmenin yolu “eklentiyi tekrar yükle” gibi yüzeysel denemeler değil, sunucunun yazma yetkisini doğru şekilde düzeltmektir.

Bu hata genelde üç ana sebepten çıkar. Birinci sebep klasik olanıdır: wp-content, wp-content/plugins veya wp-content/themes dizinlerinde yazma izni yoktur. İkinci sebep daha sinsi olanıdır: izinler kağıt üzerinde doğru görünür ama klasör sahipliği (owner) yanlıştır; web sunucusu kullanıcısı o dizine yazamaz ve WordPress “dizin oluşturulamadı” diye patlar. Üçüncü sebep ise kaynak ve güvenlik tarafıdır: disk doludur, inode sayısı dolmuştur, tmp dizini sorunludur, ya da ModSecurity/WAF gibi katmanlar dosya yazmayı engelliyordur. Yani bu WordPress Hata tek bir ayarla çözülebileceği gibi, bazen “hangi katman yazmayı reddediyor” sorusunu netleştirmeyi de gerektirir.

En doğru başlangıç, WordPress’in yazmak istediği yerin gerçekten yazılabilir olup olmadığını kontrol etmektir. Eğer FTP/SFTP ile sunucuya giriyorsanız, wp-content dizininin içine manuel olarak “test” adında boş bir klasör açmayı deneyin. Açabiliyorsanız en azından kullanıcı düzeyinde yazma var demektir; ama WordPress’in çalıştığı kullanıcı yine farklı olabilir. Açamıyorsanız sorun nettir: izin veya sahiplik. Bu noktada genel standartlar çoğu projede klasörler için 755, dosyalar için 644’tür; fakat asıl mesele “kim yazıyor” sorusudur. Paylaşımlı hostinglerde bu genelde sorunsuzdur; VPS/dedicated ortamlarda ise site taşıma veya yanlış FTP kullanımı sonrası sahiplik karıştığında bu WordPress Hata çok sık görülür. Klasör izinlerini örnek olarak şöyle düşünün; burada sayıların kendisinden çok mantığı önemlidir: WordPress’in yazacağı dizinler yazılabilir olmalı, ama dünyaya açık da olmamalıdır.

klasörler: 755
dosyalar: 644

Bazen izinleri yükseltmek “çözmüş gibi” yapar ama doğru yaklaşım bu değildir. 777 gibi geniş izinler kısa vadede kapıyı açar; fakat güvenlik açısından gereksiz risk üretir. Sağlam yönetim, önce sahipliği düzeltir, sonra standart izinlerle işi bitirir. Eğer sahiplik düzeltmeye erişiminiz yoksa (chown yetkisi yoksa), hosting desteği burada en kısa yoldur. Çünkü WordPress’in dosya yazma işlemi, web sunucusunun çalıştığı kullanıcıyla yapılır; sizin FTP kullanıcınızın yazabiliyor olması tek başına garanti değildir. Bu ayrım, “ben klasör açabiliyorum ama WordPress kuramıyor” diye çıldırtan vakaların ana sebebidir.

WordPress’in dosya sistemiyle konuşma biçimi de bu hatayı etkiler. Bazı ortamlarda WordPress, FTP kimliği ister; bazı ortamlarda “direct” yöntemle doğrudan yazar. Eğer sunucunuz direct yazımı destekliyor ama WordPress FTP moduna düşüyorsa, kurulumlar hata üretebilir. Bu tür durumlarda wp-config.php içine dosya sistemi yöntemini netleştirmek işe yarayabilir. Bu bir sihir değildir; sadece WordPress’e “dosyayı nasıl yazacağını” daha belirgin söylersiniz. Aşağıdaki tanım, uygun ortamlarda bu WordPress Hata sorununu kesebilir (uygun değilse etkisiz kalır; zarar vermez ama mucize de beklemeyin).

define('FS_METHOD', 'direct');

Bir diğer sık tetikleyici, sunucunun geçici dizinidir. WordPress eklenti/tema indirirken önce geçici alana yazar, sonra hedef dizine taşır. Geçici dizin doluysa, yazma izni yoksa veya PHP yanlış tmp dizinini kullanıyorsa, WordPress yine “dizin oluşturulamadı” diye yüzeye vurabilir. Bu durumda WordPress’e kontrollü bir temp dizini göstermek pratik bir çözümdür. Önce wp-content altında temp klasörü açılır, sonra wp-config.php içine aşağıdaki gibi bir satır eklenir. Böylece WordPress’in arada kullandığı yol daha stabil hale gelir.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Şimdi gelelim en kaba ama en gerçek sebebe: disk doluluğu. Disk doluysa WordPress klasör oluşturamaz; nokta. Bazen disk dolu değildir ama inode doludur (çok fazla küçük dosya birikmiştir); sonuç yine aynıdır. Özellikle yedekleme eklentileri, cache eklentileri ve log birikimi disk/inode tüketir. Bu yüzden “dizin oluşturulamadı” görür görmez, “temayı yeniden indir” demeden önce depolama tarafını kontrol etmek gerekir. Bu, eski usul bir disiplin gibi durur ama web işi hâlâ aynı temel üzerinde döner: dosya yazamıyorsan kuramazsın.

Son olarak güvenlik katmanları: ModSecurity kuralları, WAF ayarları veya bazı agresif güvenlik eklentileri, wp-content altına belirli dosya türlerinin yazılmasını şüpheli görüp engelleyebilir. Bu durumda hata mesajı WordPress’ten gelir ama engel daha yukarıdadır. Böyle bir şüphede, aynı eklentiyi manuel kurmak (zip’i bilgisayarda açıp klasörü doğrudan wp-content/plugins içine yüklemek) iyi bir testtir. Manuel yükleme sorunsuz çalışıyor ama panelden kurulum sürekli “dizin oluşturulamadı” diyorsa, büyük olasılıkla WordPress’in otomatik kurulum akışında bir güvenlik/izin düğümü vardır. Bu test, teşhisi netleştirir ve gereksiz debelenmeyi bitirir.

“Kurulum Başarısız: Dizin Oluşturulamadı” hatası, WordPress’in değil sunucunun “yazamazsın” demesidir. Doğru çözüm sırası şudur: yazma izni ve sahipliği düzelt, disk/inode durumunu kontrol et, WordPress’in dosya yazma yöntemini ve temp dizinini stabilize et, gerekiyorsa güvenlik katmanlarını ölçülü hale getir. Bu adımları düzgün yaparsanız bu WordPress Hata bir daha kolay kolay geri gelmez; çünkü temeli düzeltmiş olursunuz, üstünü boyamamış olursunuz.

Yanlış Dosya İzinleri Hatası Nedir?

Yanlış dosya izinleri konusu, WordPress yönetiminde “küçük ayrıntı” sanılıp en çok siteyi kilitleyen konulardan biridir. Çünkü WordPress’in yaptığı işin önemli kısmı dosya okuma-yazma üzerinedir: eklenti kurar, tema günceller, görsel yükler, önbellek dosyası üretir, bazen geçici dosya oluşturur. Siz bu işlemleri panelden tek tıkla yaparsınız ama arka planda sunucu dosya sistemine “yaz” komutu gider. Eğer izinler yanlışsa WordPress ya hata verir ya da bazı işlemleri yarım bırakır. Kullanıcı bunu çoğu zaman bir WordPress Hata olarak görür; örneğin eklenti yükleyemez, görsel yükleyemez, güncelleme çalıştırmaz, hatta bazen yönetim paneli garip davranır. Oysa asıl sebep basittir: WordPress’in dokunması gereken klasör veya dosya yazılabilir değildir ya da tam tersi, gereğinden fazla açıktır ve güvenlik riskine dönüşmüştür.

Bu işte en kritik nokta şudur: “İzin” sadece rakam değildir; izin + sahiplik birlikte çalışır. Birçok kişi FTP’den bakıp 755/644 görüyor diye rahatlıyor, sonra “neden olmuyor” diye çıldırıyor. Çünkü dosyaların sahibi web sunucusunun çalıştığı kullanıcı değilse, kağıt üstünde doğru görünen izinler pratikte işe yaramaz. Özellikle site taşıma yaptıysanız, yedekten dosya açtıysanız, farklı kullanıcıyla dosya kopyaladıysanız veya farklı panel/FTP kullanıcıları arasında gidip geldiyseniz sahiplik karışması çok yaygındır. Sonuçta WordPress wp-content içine yazmak ister ama yazamaz. Bu durumda ortaya çıkan şey, görünüşte bir WordPress Hata; gerçekte ise dosya sistemi düzeni bozukluğudur. Benim tavrım net: WordPress’i suçlamayın; dosya düzenini düzeltin. Çünkü WordPress düzgün çalışmak için “standardı” sever, standart bozulunca da işlerin yarısı sürünür.

Peki doğru standart nedir? Genel ve güvenli yaklaşım şudur: klasörler 755, dosyalar 644. Bu, web sunucusuna okuma izni verir, gerekli yerlerde sahibine yazma alanı bırakır ve “herkese yazma” gibi tehlikeli bir kapı açmaz. 777 gibi izinler, kısa vadede “çalıştı” hissi verir ama uzun vadede güvenliği baltalar; üstelik bazı güvenlik katmanları 777 gördüğünde daha da agresif davranır ve işiniz iyice uzar. Yani yanlış izinler iki uçta da problem üretir: çok kısıtlı olursa WordPress yazamaz, çok açık olursa güvenlik riski doğar. Bu yüzden yanlış dosya izinleri konusu, tam anlamıyla “denge” işidir. Bu denge bozulunca da siz ne yaparsanız yapın bir WordPress Hata zinciri başlar: yükleme hataları, güncelleme hataları, “dizin oluşturulamadı”, “dosya diske yazılamadı” gibi mesajlar peş peşe gelir.

Pratik teşhis için iki yöntem vardır. Birincisi, panel/FTP ile wp-content içine manuel bir klasör açmayı denemek: açamıyorsanız yazma izni yoktur, konu nettir. İkincisi, SSH erişiminiz varsa izin ve sahipliği gerçekten görmek ve düzeltmektir. Aşağıdaki komutlar, durum tespiti için klasik ve temiz bir başlangıçtır; “neye kimin izni var” sorusuna laf değil, kanıt verir.

# Klasör ve dosya sahiplik/izinlerini görmek
ls -la
ls -la wp-content
ls -la wp-content/uploads

Eğer düzeltme yapma yetkiniz varsa, wp-content altında (ve genellikle tüm WordPress kökünde) klasörleri 755, dosyaları 644’e çekmek yaygın ve güvenli bir düzeltmedir. Bu işlem, “rakamları standarda çevirme” kısmıdır. Sahiplik doğruysa çoğu zaman yeter. Aşağıdaki örnek komutlar, klasör ve dosyaları ayrıştırarak düzeltir; tek kalemde 777 yapıp geçmek gibi kaba işlerden çok daha temizdir.

# Klasörleri 755 yap
find wp-content -type d -exec chmod 755 {} \;

# Dosyaları 644 yap
find wp-content -type f -exec chmod 644 {} \;

İşin asıl kırılma noktası sahipliktir. Eğer web sunucusu kullanıcısı dosyaların sahibi değilse, WordPress yine yazamaz. VPS/dedicated ortamlarda bu sık görülür. Bu durumda sahipliği web sunucusunun kullandığı kullanıcıya göre düzeltmek gerekir (örneğin bazı sistemlerde www-data, bazılarında nginx, bazılarında apache). Aşağıdaki örnek “mantığı” gösterir; sizdeki kullanıcı farklı olabilir ama prensip aynıdır: WordPress’in yazacağı alanların sahibi, WordPress’in gerçekten çalışan kullanıcısı olmalıdır.

# Ornek: web sunucusu www-data calisiyorsa
chown -R www-data:www-data wp-content

Burada ince ama önemli bir nokta daha var: her şeyi wp-content ile sınırlı sanmayın. Bazı güncellemelerde wp-admin ve wp-includes tarafında da yazma gerekebilir (özellikle çekirdek güncellemeleri). Ayrıca bazı eklentiler kendi klasörlerine yazmak ister, cache klasörleri oluşturur, log tutar. Bu yüzden yalnızca “uploads düzelsin yeter” yaklaşımı bazen yetmez; WordPress’in çalışma mantığına uygun bir dosya düzeni kurmak gerekir. Böyle yaptığınızda hem performans hem güvenlik toparlanır. Aksi halde bugün düzeltip yarın yine aynı WordPress Hata ile uğraşırsınız, çünkü kök sebep olan sahiplik/izin dağınıklığı duruyordur.

Yanlış dosya izinleri meselesi, WordPress yönetiminin temel disiplinidir. Bu işte nazik olmaya gerek yok; ya standardı uygulayıp işi kökten düzeltirsiniz ya da her hafta bir başka dosya yazma problemiyle boğuşursunuz. Standart izin (755/644) + doğru sahiplik + gereksiz 777’den kaçınma… Bunlar oturdu mu WordPress sakinleşir. Oturmadı mı, en sağlam eklenti bile sizi kurtaramaz.

ERR_SSL_PROTOCOL_ERROR Hatası Nedir?

ERR_SSL_PROTOCOL_ERROR, tarayıcının siteyle güvenli (HTTPS) bağlantı kurarken SSL/TLS el sıkışmasını tamamlayamadığını gösteren sert bir uyarıdır. Kullanıcı tarafında “site açılmıyor” diye görünür; teknik tarafta ise “sunucu ile tarayıcı aynı dili konuşamadı” demektir. Bu sorun, çoğu kişinin sandığı gibi tek başına basit bir WordPress Hata değildir; genellikle sertifika, protokol sürümü, yanlış yönlendirme, araya giren CDN/WAF veya sunucu yapılandırması gibi altyapı meselelerinin WordPress katmanında patlamasıdır. Yani WordPress düzgün çalışsa bile HTTPS katmanı bozuksa ziyaretçiye kapı kapanır. Bu yüzden ERR_SSL_PROTOCOL_ERROR çıktığında “eklenti kapatayım” refleksiyle sağa sola saldırmak vakit kaybıdır; önce bağlantıyı sağlayan zinciri düzeltmek gerekir.

Bu hata en sık şu dönemlerde görülür: yeni SSL sertifikası takıldıktan sonra, hosting değişiminden sonra, alan adı taşındıktan sonra, CDN devreye alındıktan sonra, zorunlu HTTPS yönlendirmesi eklendikten sonra veya sunucuda TLS ayarlarıyla oynandıktan sonra. Özellikle “www / non-www” ve “http / https” karışınca, bir tarafta sertifika var diğer tarafta yoksa ya da sertifika doğru alan adını kapsamıyorsa ERR_SSL_PROTOCOL_ERROR sıklıkla çıkar. Üstelik bazen sadece belirli tarayıcılarda görünür; mesela :contentReference[oaicite:0]{index=0} daha katı davranıp bağlantıyı tamamen kesebilir, bazı tarayıcılar daha toleranslı gibi görünür. Bu da insanı yanıltır. Buradaki temel gerçek şudur: SSL/TLS konusu tolerans kaldırmaz; doğru kurulum yoksa herkes sonunda duvara çarpar. İşte bu yüzden bu hatayı “geçici bir WordPress Hata diye hafife almak yanlış bir yönetim refleksidir.

Teşhis için en sağlam yöntem, önce sertifikanın gerçekten doğru kurulu olup olmadığını kanıtlamaktır. Sertifika zinciri eksik mi, sertifika süresi geçmiş mi, sertifika yanlış alan adına mı basılmış, sunucu TLS 1.2/1.3 gibi güncel protokolleri sunuyor mu, SNI doğru mu, bunlar netleşmeden WordPress tarafına inmenin anlamı yoktur. Eğer SSH erişiminiz varsa, en eski ama en güvenilir testlerden biri openssl ile doğrudan sunucuya bağlanıp sertifikayı ve el sıkışmayı kontrol etmektir. Bu komut çıktısı, “sorun WordPress’te değil, sunucu SSL katmanında” gerçeğini çoğu zaman tartışmasız ortaya koyar.

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com

Sunucu tarafı sağlam görünüyorsa, ikinci aşama WordPress tarafındaki URL ve yönlendirme düzenidir. WordPress Adresi (URL) ve Site Adresi (URL) yanlışsa (örneğin biri http, diğeri https), tarayıcı bazen saçma bir döngüye girer; bazı durumlarda bu döngü “redirect” hatası gibi görünür, bazı durumlarda ise SSL protokol hatasına kadar sürüklenir. Bu nedenle WordPress’in “home” ve “siteurl” değerlerini tutarlı hale getirmek gerekir. Panelden düzeltemiyorsanız, wp-config.php üzerinden sabitlemek en pratik ve kontrollü yoldur. Aşağıdaki gibi sabitleme, özellikle panel erişimi yokken bu WordPress Hata görüntüsünü kesmekte çok işe yarar; çünkü WordPress’in kafası karışmayı bırakır.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Bu noktada yönlendirmeyi de doğru kurmak gerekir. Yanlış yazılmış bir .htaccess kuralı, HTTPS’e geçireceğim derken protokol müzakeresini bozar veya istekleri farklı host adına zıplatır. Apache kullanıyorsanız aşağıdaki gibi sade ve klasik bir yönlendirme kuralı çoğu projede güvenle iş görür. Burada amaç “tek kanonik yol” oluşturmaktır: ya her şey https://www ile açılır ya da her şey https:// ile açılır; ikisi birden olmaz. Kararsızlık, ERR_SSL_PROTOCOL_ERROR gibi sert hatalara zemin hazırlar ve sonra siz bunu bir WordPress Hata diye panelde ararsınız, oysa kök sebep yönlendirme disiplinidir.

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Bir diğer kritik nokta, “sertifika var ama zincir eksik” meselesidir. Bazı hostinglerde sertifika yüklenir ama ara sertifikalar (intermediate chain) eksik bırakılır. Bazı tarayıcılar bunu tolere eder gibi görünür; bazıları ise bağlantıyı dümdüz keser. Bu yüzden sertifika kurulumu “tak-çalıştır” sanılmamalıdır. Geleneksel düzgün yönetim, sertifikayı taktıktan sonra doğrulama testlerini yapar, zincirin tam olduğunu teyit eder, sonra WordPress URL’lerini düzeltir. Bu sırayı ters yaparsanız, yani önce WordPress’i https yapıp sonra sertifikayı düzeltmeye kalkarsanız, siteye erişimi zora sokarsınız. Bu da gereksiz yere büyüyen bir WordPress Hata zinciri doğurur.

İstemci tarafı ihtimali de tamamen yok değildir. Kullanıcının cihaz saati yanlışsa, tarayıcı sertifika doğrulamasını “zaman tutmuyor” diye reddedebilir. Bazı antivirüs yazılımları HTTPS trafiğine araya girip kendi sertifikasını sokar; bu da protokol hatası üretir. Tarayıcı uzantıları veya bozuk önbellek/çerez de nadiren bu tip SSL hatalarını tetikleyebilir. Ama şunu açık söyleyeyim: Siz site sahibisiniz; sizin işiniz “kullanıcının bilgisayarını tamir etmek” değil, sunucunun doğru SSL/TLS sunduğunu garanti etmektir. Sunucu tarafı sağlam olunca kullanıcı tarafı sorunları zaten azınlıkta kalır.

Kalıcı çözüm mantığı nettir: SSL sertifikası doğru alan adını kapsayacak, zincir eksiksiz olacak, sunucu TLS 1.2/1.3 gibi modern protokolleri destekleyecek, WordPress URL’leri tutarlı şekilde HTTPS olacak ve yönlendirme kuralları tek bir kanonik yapıya oturacak. Bunlar oturdu mu ERR_SSL_PROTOCOL_ERROR ortadan kalkar. Oturmadı mı, siz WordPress’te eklenti kapatsanız da tema değiştirseniz de bu WordPress Hata gibi görünen problem geri gelir; çünkü temel katman bozuk kalmıştır. Düzgün yönetim, temeli düzeltir; üstünü boyamaz.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH Hatası Nedir?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH, tarayıcı ile sunucunun TLS/SSL konusunda “anlaşamadığı” durumlarda çıkan ağır bir bağlantı hatasıdır. Kullanıcı siteye girmek ister, tarayıcı güvenli bağlantıyı kurmaya çalışır; fakat sunucu ya çok eski bir TLS sürümü sunuyordur ya da tarayıcının kabul etmediği şifreleme takımlarını (cipher suites) dayatıyordur. Sonuç olarak tarayıcı “bu bağlantı güvenli kurulamaz” der ve sayfayı açmayı reddeder. Bu durum, çoğu zaman WordPress’in içinden kaynaklanmamasına rağmen, site sahibi açısından kritik bir WordPress Hata gibi yaşanır; çünkü ziyaretçi gözünde “site çökmüş” görünür. Asıl gerçek şudur: WordPress içeride tıkır tıkır çalışsa bile, TLS katmanı bozuksa kimse içeri giremez. Bu yüzden bu hatayı “panelden bir ayar yaparım” diye küçümsemek yanlış olur; mesele temelde sunucu güvenlik standardıdır.

Bu hatanın bugünlerde daha sık görülmesinin sebebi tarayıcıların eski güvenlik standartlarını terk etmesidir. Özellikle modern tarayıcılar TLS 1.0 ve TLS 1.1 gibi eski sürümleri fiilen “ölü” kabul eder; ayrıca zayıf şifreleme setlerini de engeller. Sunucu tarafı hâlâ eski protokolleri kullanıyorsa, tarayıcı bağlantıyı daha baştan keser ve ERR_SSL_VERSION_OR_CIPHER_MISMATCH gösterir. Bu nedenle hatayı gören kullanıcılar genellikle “bende mi sorun var?” diye düşünür; ama çoğu vakada sorun kullanıcıda değil, sunucunun sunduğu TLS profilindedir. Yani bu WordPress Hata görüntüsü, WordPress’ten çok daha önce, HTTPS kapısında gerçekleşir.

Eğer yakın zamanda hosting taşıdıysanız, CDN/WAF açtıysanız, yeni sertifika yüklediyseniz veya sunucu yazılımı güncellemesi yaptıysanız bu hatanın tetiklenmesi çok olasıdır. Bir de şu klasik senaryo vardır: SSL sertifikası var sanırsınız ama yanlış şekilde bağlanıyordur; örneğin sunucu belirli bir alan adı için doğru sertifikayı sunamıyor (SNI meselesi) ya da ara sertifikalar eksik olduğu için tarayıcı uyumsuzluk çıkarır. O zaman da aynı hata ortaya düşebilir.

Teşhis tarafında en sağlam yaklaşım, “WordPress’te ne bozuldu?” diye içeriden başlamak değil, dışarıdan kanıt toplamaktır. Eğer sunucuya erişiminiz varsa, TLS el sıkışmasının hangi sürümde tıkandığını test etmek çok değerlidir. Bu test, tartışmayı bitirir: sorun protokol mü, şifreleme mi, sertifika zinciri mi? Örneğin aşağıdaki komut, doğrudan 443 portundan TLS görüşmesini gösterir; tarayıcının neden itiraz ettiğini çoğu zaman net anlatır. Bu adımı atlamayın; çünkü kanıtsız ilerlerseniz günlerce “eklenti mi tema mı” diye boşuna uğraşırsınız ve WordPress Hata diye yanlış hedefe ateş edersiniz.

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com

Bu hatanın en temel çözümü, sunucunun TLS yapılandırmasını modernleştirmektir. Burada net konuşayım: 2026 yılında hâlâ TLS 1.0/1.1 ile ayakta durmaya çalışan site, ziyaretçi kaybetmeye mahkûmdur. Nginx/Apache tarafında TLS 1.2 ve TLS 1.3 açık olmalı, zayıf cipher’lar kapalı olmalı, sertifika zinciri eksiksiz olmalı ve mümkünse HTTP/2 düzgün çalışmalıdır. Bu ayarlar hosting panelinden yönetiliyorsa işiniz kolaydır; değilse sunucu konfigürasyonuna girilir. Aşağıda “mantık” olarak Nginx için tipik bir örnek veriyorum. Bu bir kopyala-yapıştır sihri değil; ama size neyin hedeflenmesi gerektiğini gösterir: modern protokoller, modern şifreleme, tutarlı HTTPS.

# Nginx mantik ornegi (ortaminiza gore degisir)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

WordPress tarafında ise yapılacaklar, bu sorunu “tetikleyen” yanlış yönlendirmeleri ve tutarsız URL’leri temizlemektir. Çünkü bazı kurulumlarda HTTP/HTTPS arasında kararsızlık olur; biri https’e iter, diğeri http’a döndürür, kullanıcı arada kalır ve tarayıcı farklı davranışlar sergileyebilir. Bu yüzden WordPress’in adreslerini netleştirmek, özellikle panel erişimi yokken, en pratik güvenlik adımlarındandır. Aşağıdaki tanımlar, WordPress’in kendini hangi URL’den ilan edeceğini sabitler ve gereksiz zıplamaları azaltır. Bu, doğrudan çözüm olmasa bile teşhisi sadeleştirir ve WordPress Hata gibi görünen tabloyu toparlamaya yardımcı olur.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Son olarak, bazı durumlarda sorun sunucunun kendisinden çok araya giren sistemler yüzünden olur. CDN, WAF veya proxy katmanı TLS’i farklı bir profile zorlayabilir; özellikle “eski mod” ayarları açıksa tarayıcılar bunu affetmez. Bu yüzden araya bir katman koyduysanız, o katmanın TLS ayarlarının da modern olması gerekir. Özetle bu hatada yapılacak iş, WordPress’in içinde “ayar aramak” değil, HTTPS kapısındaki standardı düzeltmektir. Bu kapı sağlam olunca içerideki WordPress zaten nefes alır ve bu WordPress Hata görüntüsü ortadan kaybolur.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH Hatası Nedir?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH, tarayıcı ile sunucunun HTTPS üzerinden anlaşamaması demektir. Bu hata çıktığında WordPress içeride kusursuz çalışıyor bile olabilir ama ziyaretçi siteye giremez; çünkü kapıda TLS/SSL el sıkışması başarısız olmuştur. Kullanıcı tarafında bu durum çok net görünür: sayfa açılmaz, tarayıcı güvenli bağlantıyı reddeder. Site sahibi açısından bu, doğrudan bir WordPress Hata gibi yaşanır; çünkü “site gitti” hissi verir.

Fakat asıl sebep çoğu zaman WordPress eklentisi, tema veya içerik değildir. Sebep genellikle sunucunun çok eski TLS sürümü kullanması, tarayıcının artık kabul etmediği şifreleme takımlarını (cipher) sunması, yanlış yapılandırılmış SSL ayarları veya araya giren CDN/WAF katmanının protokolü bozmasıdır. Bu yüzden bu hatayı “panelden bir ayar yaparım” diye küçümsemek, gereksiz yere zaman kaybettirir ve yanlış yere odaklanmanı sağlar. Buradaki doğru yaklaşım eski usuldür: önce altyapı zincirini doğrularsın, sonra WordPress’e inersin.

Bu hatanın son yıllarda daha sık görünmesinin sebebi tarayıcıların güvenlik standartlarını sertleştirmesidir. Modern tarayıcılar TLS 1.0 ve TLS 1.1 gibi sürümleri artık fiilen terk etti; zayıf şifrelemeyi de affetmiyor. Sunucu tarafı hâlâ eski protokollere yaslanıyorsa, tarayıcı “ben buna girmem” der ve ERR_SSL_VERSION_OR_CIPHER_MISMATCH verir. Bu noktada kullanıcı “bende mi sorun var” diye sorar; sen de çoğu zaman bunu WordPress Hata zannedersin. Ama genellikle sorun kullanıcıda değil, sunucunun sunduğu TLS profilindedir. İşte bu yüzden burada ilk hedef WordPress değil, sunucunun HTTPS konuşma biçimidir.

Teşhis kısmında kanıt toplamak şart. Sunucuya erişimin varsa en sağlam yöntemlerden biri openssl ile el sıkışmayı görmektir. Bu test, “tarayıcı neden reddediyor” sorusuna somut cevap verir. Böylece “WordPress Hata mı, yoksa TLS katmanı mı” tartışması biter. Aşağıdaki komut, sertifika zinciri ve protokol detaylarını gösterir; çıktıdaki protokol sürümü ve handshake aşaması genelde ipucu verir. Bu testi yapmadan körlemesine eklenti kapatmak, temayı değiştirmek gibi hamleler çoğu zaman boştur.

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com

Çözümün ana omurgası şudur: sunucuda TLS 1.2 ve TLS 1.3 açık olacak, zayıf cipher’lar kapalı olacak, sertifika zinciri eksiksiz olacak ve mümkünse güncel bir web sunucusu sürümü çalışacak. Nginx veya Apache tarafında bu ayarlar hosting panelinden yönetilebiliyorsa iş kolaydır; yönetilemiyorsa sunucu yapılandırmasına girilir. Aşağıdaki örnek Nginx mantığını gösterir: modern protokoller açık, gereksiz “zorla eski cipher” yaklaşımı kapalı. Bu ayarı “kopyala yapıştır mucizesi” sanma; ama hedefin ne olması gerektiğini net anlatır. Böyle yaptığında bu WordPress Hata görüntüsü büyük oranda ortadan kalkar çünkü tarayıcı artık sunucuyla ortak bir güvenli dil bulur.

# Nginx icin mantik ornegi (ortaminiza gore farkli olabilir)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

WordPress tarafında yapılacaklar ise çoğunlukla tutarlılık sağlamaktır. Özellikle site URL’leri bir yerde http, başka yerde https kalmışsa; “www” ile “www’suz” adresler karışmışsa; bir de üstüne CDN veya proxy eklenmişse tarayıcı farklı uçlara çekilebilir. Bu doğrudan ERR_SSL_VERSION_OR_CIPHER_MISMATCH üretmez gibi görünse de, yanlış yönlendirme ve yanlış host kombinasyonu HTTPS katmanını tetikleyebilir ve sen bunu yine WordPress Hata diye yaşarsın. Panelden düzeltemiyorsan wp-config.php üzerinden WordPress’in kendini ilan ettiği adresi sabitlemek en pratik hamlelerden biridir. Aşağıdaki tanım, gereksiz zıplamaları azaltır ve teşhisi sadeleştirir.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Araya giren CDN/WAF katmanı da unutulmamalı. Bazı sistemler “eski uyumluluk” modlarıyla TLS’i zayıflatır ya da yanlış sertifika sunar. Bu durumda WordPress Hata zannedersin ama sorun CDN ayarındadır. Bu yüzden CDN kullanıyorsan TLS ayarlarını “modern” seviyeye çekmek, eski protokolleri kapatmak ve sertifika sunumunun doğru olduğundan emin olmak gerekir. Bir de pratik bir kural: SSL işinde “yarım doğru” diye bir şey yoktur; zincirde tek bir yanlış varsa tarayıcı kapıyı kapatır. Bakım notlarını ve uyguladığın değişiklikleri tek bir yerde toplamak da işini hızlandırır; örneğin https://datweb.com.tr/ altında kendi kontrol notlarını düzenli tutarsan aynı WordPress Hata döngüsüne tekrar düşmezsin.

Özetle, ERR_SSL_VERSION_OR_CIPHER_MISMATCH bir WordPress Hata gibi görünse bile çözümün ağırlığı sunucu TLS yapılandırmasındadır. TLS’i modernleştir, sertifika zincirini düzelt, URL tutarlılığını sağla, aradaki katmanları doğru ayarla. Bunlar tamamlandığında tarayıcılar siteyi tekrar açar ve sorun kendiliğinden kapanır. Bu işte yumuşatmaya gerek yok: HTTPS kapısı sağlam değilse içeride ne yaptığın önemsizdir.

Karışık İçerik Uyarıları Nedir?

Karışık içerik uyarıları, siten HTTPS üzerinden açılırken sayfanın içindeki bazı kaynakların hâlâ HTTP üzerinden çağrılmasıdır. Tarayıcı bunu güvenlik açısından problem görür; çünkü “sayfa güvenli ama içindeki bazı parçalar güvensiz kanaldan geliyor” anlamına gelir. Kullanıcı tarafında bazen kilit simgesi kırılır, “tamamen güvenli değil” uyarısı çıkar, bazı tarayıcılar HTTP kaynakları tamamen engeller ve sayfada görseller, fontlar, JS dosyaları yüklenmez. Site sahibi açısından bu durum çok net bir WordPress Hata gibi yaşanır: “siteyi HTTPS yaptım ama tasarım bozuldu”, “slider kayboldu”, “butonlar çalışmıyor”, “admin paneli garip” gibi şikâyetler gelir. Buradaki gerçek şu: Bu çoğu zaman WordPress’in bozulması değil, URL tutarsızlığıdır. HTTPS’e geçiş yarım bırakılmıştır; veritabanında, temada, eklenti ayarlarında veya dış kaynak linklerinde hâlâ http:// ile başlayan çağrılar kalmıştır.

Bu uyarı en sık SSL sertifikası takıldıktan sonra veya siteyi HTTP’den HTTPS’e yönlendirdikten sonra ortaya çıkar. Çünkü siteyi sadece yönlendirmek yetmez; içeriklerin içindeki linkler, görsel yolları, script çağrıları ve CSS içindeki font linkleri de HTTPS olmalıdır. WordPress Hata gibi görünen şey, çoğu zaman veritabanında gömülü kalan eski bağlantılardan kaynaklanır. Örneğin yazıların içinde geçmişten kalma http:// ile eklenmiş görseller olabilir. Veya tema ayarlarında logo URL’si http:// olarak kaydedilmiştir. Ya da bir eklenti CDN linkini HTTP veriyordur. Tarayıcı “karışık içerik” dediğinde aslında size şunu söylüyor: “Sen siteyi güvenli yaptığını sanıyorsun ama sayfanın bazı parçaları hâlâ eski yoldan geliyor.” Bu konu özellikle e-ticaret ve form sayfalarında önemlidir; çünkü kullanıcı güveni ve dönüşüm doğrudan etkilenir.

Teşhis için en pratik yöntem, tarayıcının geliştirici konsolunu açıp hangi kaynakların HTTP’den geldiğini görmektir. Orada genellikle net bir liste çıkar: hangi dosya, hangi URL, hangi satır. Bu liste yoksa körlemesine ilerlersiniz ve sürekli aynı WordPress Hata hissine girersiniz. Çünkü siz “bunu düzelttim” sanırsınız ama bir başka sayfada başka bir HTTP kaynak kalmıştır. Ayrıca sadece görsellere bakmayın; çoğu zaman asıl problem JS ve CSS dosyalarıdır. Tarayıcı bunları engelleyince sayfa davranışı bozulur. Örnek olarak bir sayfa oluşturucu düzgün yüklenmez, menü açılmaz, slider dönmez. Bu yüzden karışık içerik uyarıları, “estetik bir uyarı” değil, işlevsel bir arızaya dönüşebilir.

Çözümün birinci ayağı WordPress URL ayarlarını doğru yapmaktır. WordPress Adresi ve Site Adresi https:// ile başlamalıdır. Eğer panelden yapabiliyorsanız Ayarlar > Genel’den düzeltirsiniz. Panel erişimi yoksa wp-config.php üzerinden sabitlemek de mümkündür. Bu sabitleme, WordPress’in kendi ürettiği linkleri doğru üretmesini sağlar ve karışık içerik kaynaklarının bir kısmını otomatik keser. Aşağıdaki tanım, özellikle “site açılıyor ama bazı yerler http’ye dönüyor” tarzı WordPress Hata görünen durumlarda çok işe yarar.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Çözümün ikinci ayağı veritabanındaki eski http:// linkleri temizlemektir. Burada en sık yapılan hata şudur: phpMyAdmin ile “bul-değiştir” yaparken rastgele her şeyi değiştirip serileştirilmiş (serialized) verileri bozmak. Bu, düzeltmek isterken yeni bir WordPress Hata üretmenin en kısa yoludur. Doğru yöntem, serileştirme dostu araç kullanmak veya WP-CLI ile güvenli arama-değiştirme yapmaktır. Eğer WP-CLI erişimin varsa, en temiz yaklaşım aşağıdaki gibi search-replace komutudur. Bu komut, veritabanında http://alanadiniz.com geçen yerleri https://alanadiniz.com ile değiştirir ve serileştirilmiş alanlarda bozulma riskini düşürür.

wp search-replace 'http://alanadiniz.com' 'https://alanadiniz.com' --all-tables

Üçüncü ayak tema ve eklenti ayarlarıdır. Bazı temalar logo veya arka plan görselini tam URL ile kaydeder. Bazı eklentiler harici script çağırır ve bunu HTTP ile yapar. Ayrıca CSS dosyalarının içinde font URL’leri olabilir; örneğin Google Fonts çağrısı HTTP ise tarayıcı bunu karışık içerik sayar. Çözüm basittir: ilgili ayar ekranına girip URL’yi HTTPS yaparsınız veya protokol bağımsız (//) kullanırsınız. Ama burada da bir kural var: mümkünse her şeyi açıkça HTTPS yapın. “//” bazen kurtarır ama her ortamda aynı davranışı garanti etmez. Geleneksel sağlam yönetim, net olanı seçer: HTTPS.

Dördüncü ayak CDN/WAF ve önbellek katmanıdır. Bazı sitelerde siz düzeltmeyi yaparsınız ama cache hâlâ eski HTML’i servis eder. Bu yüzden tarayıcı hâlâ karışık içerik görür ve siz “niye düzelmedi” diye tekrar tekrar WordPress Hata yaşıyormuş gibi hissedersiniz. Bu noktada hem site cache’ini hem CDN cache’ini temizlemek şarttır. Aksi halde yaptığınız doğru değişiklik kullanıcıya ulaşmaz. Ayrıca bazı CDN ayarlarında “Always Use HTTPS” gibi bir seçenek vardır; bu açılır ama origin’den gelen HTML’de HTTP linkleri kalırsa yine karışık içerik çıkar. Yani CDN tek başına mucize değildir; içerik de temiz olmalıdır.

Özetle karışık içerik uyarıları, HTTPS geçişinin yarım kalmış halidir. URL’leri tutarlı hale getir, veritabanındaki eski linkleri serileştirme bozmadan değiştir, tema/eklenti ayarlarını kontrol et, cache katmanlarını temizle. Bunlar yapıldığında tarayıcı kilidi tekrar “tam güvenli” hale gelir, sayfa bozulmaları biter ve WordPress Hata gibi görünen şikâyetler de kesilir. Bu işte kestirme yok: güvenli site istiyorsan içerik de güvenli kanaldan gelecek.

25. SSL Bağlantısı Başarısız Oldu Hatası Nedir?

“SSL Bağlantısı Başarısız Oldu” ifadesi, tarayıcının sunucu ile güvenli bağlantıyı kuramadığını anlatan genel bir hatadır. Bu hata bazen tarayıcı ekranında net bir uyarı olarak çıkar, bazen de arka planda istekler başarısız olur ve site “yarım” çalışıyor gibi görünür. Site sahibi için bu durum genellikle bir WordPress Hata gibi algılanır; çünkü kullanıcılar “site açılmıyor” diye döner, formlar gitmez, ödeme sayfası boş kalır, hatta yönetim paneli bile düzgün yüklenmez. Fakat bu problemin önemli bir kısmı WordPress’in içinden değil, HTTPS zincirinin kendisinden çıkar: sertifika yanlış, sertifika zinciri eksik, alan adı uyuşmuyor, sunucu TLS’i yanlış sunuyor, araya giren CDN/WAF protokolü bozuyor veya istemci tarafında saat/antivirüs gibi bir etken devreye giriyordur.

Bu yüzden “SSL Bağlantısı Başarısız Oldu” gördüğünde yapılacak ilk iş, WordPress’te eklenti kapatmak değil; SSL/TLS doğrulamasını kanıtlamak ve hatanın hangi katmanda olduğunu netleştirmektir.Bu hata en çok şu zamanlarda patlar: yeni SSL sertifikası kurulduktan sonra, hosting/IP değişiminden sonra, HTTPS yönlendirmesi eklendikten sonra, CDN devreye alındıktan sonra veya sertifika yenileme (renewal) yapıldıktan sonra. Ayrıca “www” ile “www’suz” alan adları karışınca da sık çıkar.

Çünkü sertifika bir alan adını kapsıyor, siz kullanıcıyı diğerine yönlendiriyorsunuz ve tarayıcı “sertifika uyuşmuyor” diye bağlantıyı kesiyor. Bu noktada yine WordPress Hata gibi görünür ama kök sebep sertifika kapsaması ve yönlendirme disiplinidir. Bir de şu klasik hata var: sertifikayı kurarsınız ama ara sertifikaları (intermediate chain) eksik bırakırsınız. Bazı tarayıcılar bunu tolere eder gibi görünür; bazıları ise “ben buna güvenemem” deyip kapıyı kapatır. Bu yüzden SSL işi “takıldı, tamam” değildir; doğrulama yapılmadan güvenilmez.

Teşhiste en sağlam yöntemlerden biri, sunucunun gerçekten hangi sertifikayı ve hangi zinciri sunduğunu görmek ve TLS el sıkışmasını izlemektir. Sunucuya SSH erişimin varsa openssl s_client testi burada altın değerindedir. Bu test, sertifika zincirini, sunulan protokolü ve handshake akışını gösterir. Böylece “WordPress Hata mı, yoksa SSL katmanı mı” sorusu netleşir. Ayrıca bazen sorun sadece belirli bir SNI/host adına karşı çıkar; o yüzden -servername parametresi önemlidir. Aşağıdaki komutla ilk kanıtı alırsın.

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com

Çözümün birinci adımı, sertifikanın doğru alan adını kapsadığından emin olmaktır. Sertifika “alanadiniz.com” için geçerliyse ama kullanıcı “www.alanadiniz.com” üzerinden geliyorsa, sertifikada SAN (Subject Alternative Name) olarak www yoksa tarayıcı hata verir. Çözüm ya iki alan adını da kapsayan sertifika almak ya da yönlendirmeyi sertifikanın kapsadığı kanonik alan adına doğru kurmaktır. Burada kararsızlık en büyük düşmandır. Bir gün www, ertesi gün www’suz, bir yerde http, bir yerde https… Bu karışıklık hem “SSL Bağlantısı Başarısız Oldu” hatasını doğurur hem de kullanıcıya sürekli WordPress Hata varmış gibi hissettirir. O yüzden tek bir kanonik yapı seçilir ve her şey oraya bağlanır.

İkinci adım, sertifika zincirinin eksiksiz sunulmasıdır. Sertifika sadece “leaf” dosyasıyla bitmez; çoğu otoritede ara sertifikalar gerekir. Hosting panelinde genellikle “certificate + private key + CA bundle” şeklinde üç parça vardır. CA bundle eksikse veya yanlışsa tarayıcı güven ilişkisini kuramaz. Bu durumda bazı cihazlarda site açılırken bazı cihazlarda açılmaz; bu da insanı çıldırtır. Burada pratik yaklaşım şudur: Zinciri düzeltmeden WordPress’e inmeye çalışma.

Çünkü asıl kapı orada kilitlidir.Üçüncü adım, TLS sürümleri ve cipher setleridir. Sunucu hâlâ eski TLS 1.0/1.1’i kullanıyorsa veya zayıf cipher’lar açıksa modern tarayıcılar bağlantıyı reddedebilir. Bu durum özellikle “SSL Bağlantısı Başarısız Oldu” şeklinde yüzeye vurur. Çözüm, sunucuda TLS 1.2 ve TLS 1.3’ü etkin tutmak ve zayıf şifrelemeleri kapatmaktır. Nginx/Apache ayarları ortama göre değişir ama hedef bellidir: modern protokoller. Aşağıdaki örnek, Nginx mantığını gösterir. Bu, her sunucuda birebir aynı olmaz; ama çözüm yönünü net anlatır.

# Nginx icin mantik ornegi (ortaminiza gore farkli olabilir)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Dördüncü adım, WordPress’in URL tutarlılığıdır. WordPress Home/SiteURL değerleri https olmalı, “http’ye geri döndürme” yapan eski ayarlar temizlenmelidir. Panelden düzeltemiyorsan wp-config.php üzerinden sabitlemek, hem teşhisi sadeleştirir hem de WordPress’in ürettiği linklerin doğru olmasını sağlar. Bu adım bazen doğrudan çözüm olmaz; ama SSL ile ilgili WordPress Hata benzeri yan etkileri azaltır ve yönlendirme karmaşasını keser.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

İstemci tarafı ihtimali de tamamen yok değildir: cihazın saati yanlışsa sertifika “geçersiz” görünür; bazı antivirüsler HTTPS trafiğine araya girip kendi sertifikasını sokar ve tarayıcı bunu reddeder; kurumsal ağlarda proxy SSL kırma yapar. Fakat site sahibi olarak senin görevin, sunucunun doğru SSL sunduğunu garanti etmektir. Sunucu tarafı doğruysa, kullanıcı tarafı sorunları zaten azınlık olur. O yüzden bu hatayı gördüğünde önce sunucuyu sağlamlaştır, sonra kullanıcıya “tarayıcıyı güncelle, saati düzelt” gibi önerileri en son konu

“SSL Bağlantısı Başarısız Oldu” hatası WordPress Hata gibi görünse de çözümün ağırlığı sertifika, zincir, TLS sürümü ve yönlendirme disiplinidir. Sertifika doğru alan adlarını kapsayacak, zincir eksiksiz olacak, TLS modern olacak, WordPress URL’leri tutarlı olacak ve araya giren CDN/WAF ayarları düzgün çalışacak. Bunlar tamamlandığında site tekrar açılır ve bu problem ortadan kalkar. SSL işinde yarım doğru yoktur; kapı sağlam değilse içeride ne yaptığın kimseyi ilgilendirmez.

WordPress HTTP Hatası (Medya Kütüphanesine Resim Yükleme) Nedir?

WordPress Medya Kütüphanesine bir görsel yüklerken “HTTP Hatası” görüyorsan, bu genellikle WordPress’in yükleme isteğini başlatıp bir noktada yarıda kalması demektir. Mesajın sinir bozucu tarafı şudur: “HTTP Hatası” çok genel bir ifadedir, yani sana tek cümlede kesin sebebi söylemez.

Bu yüzden kullanıcı gözüyle bu durum direkt WordPress Hata gibi yaşanır; çünkü sen bir resim atmak istersin, WordPress “olmadı” der ve konu kapanır.

Fakat altyapıda bir sürü ihtimal vardır: dosya boyutu sınırı, PHP tarafındaki zaman aşımı, bellek limiti, geçici klasör problemleri, dosya adı ve karakter sorunları, izin/sahiplik sorunları, görüntü işleme kütüphanesi (GD/Imagick) problemleri, CDN/WAF engelleri veya oturum (session) düşmesi.

Bu yüzden burada doğru yaklaşım, rastgele denemek değil; sorunu katman katman daraltmaktır. Bu yaklaşımı uygularsan, aynı WordPress Hata görüntüsünü tekrar tekrar yaşamak yerine, tek seferde kök sebebi bulursun.

İlk etapta en pratik test şudur: aynı dosyayı farklı bir isimle ve daha küçük boyutla dene. Çünkü çok sık karşılaşılan bir tetikleyici, dosya adındaki karakterlerdir. Uzun dosya adı, noktalama, Türkçe karakter, boşluk ve bazı semboller bazı sunucu kurallarına takılabilir. Bu durumda WordPress “HTTP Hatası” der ama aslında istek daha baştan engellenmiştir. İkinci pratik test dosya boyutudur. Bazı hostinglerde upload_max_filesize ve post_max_size sınırları düşük tutulur; görsel büyükse yükleme başlar gibi görünür ama yarıda kesilir. Üçüncü pratik test tarayıcı tarafıdır: sayfayı yenile, gizli sekmede dene, eklentileri geçici kapat. Çünkü bazen medya yükleyici tarafında JavaScript çakışması olur; yükleme isteği düzgün tamamlanmadan kesilir ve sen bunu WordPress Hata sanırsın. Bu üç test, “anlık” sorun mu yoksa kalıcı altyapı mı sorusunu hızla netleştirir.

Kalıcı teşhis için asıl önemli adım, WordPress’in log üretmesini sağlamaktır. Çünkü “HTTP Hatası” tek başına yeterli kanıt değildir. WordPress debug log açıldığında, yükleme sırasında bellek mi bitti, time limit mi doldu, geçici dizin mi bulunamadı, bunlar daha net görünür. Bunu kontrollü biçimde wp-config.php dosyası üzerinden açabilirsin. Burada amaç debug’ı sonsuza kadar açık tutmak değil; sorunu yakalayıp kapatmaktır. Aşağıdaki ayarlar, hatayı kayıt altına almak için tipik ve güvenli bir başlangıçtır.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Bu ayarları ekledikten sonra tekrar görsel yüklemesini denersin. Ardından wp-content/debug.log içinde bir ipucu oluşur. Eğer logda “Allowed memory size exhausted” gibi bir şey görürsen, bu WordPress Hata görüntüsünün arkasında bellek limiti olduğunu anlarsın. Eğer “Maximum execution time exceeded” görürsen süre limitine çarpmışsındır. Bu iki senaryo, özellikle görsel çok büyükse veya WordPress yüklerken farklı boyutlar üretmeye çalışıyorsa sık olur. Bu durumda çözüm “daha fazla limit” ve “daha verimli görsel” birleşimidir. Sadece limiti şişirmek kısa vadede işe yarar, ama kalıcı çözüm görseli yüklemeden önce optimize etmektir. Yine de acil durumda bellek limitini wp-config.php ile yükseltmek gerekebilir. Aşağıdaki satır, birçok kurulumda hızlı sonuç verir.

define('WP_MEMORY_LIMIT', '256M');

Bir başka kritik sebep, sunucudaki geçici klasördür. WordPress dosyayı önce geçici alana yazar, sonra uploads dizinine taşır. Eğer PHP’nin temp dizini problemliyse veya yazma izni yoksa, yükleme yarıda kalır ve WordPress “HTTP Hatası” gibi genel bir mesaj verir. Bu da yine tipik bir WordPress Hata gibi görünür. Böyle bir durumda WordPress’e kendi temp dizinini göstermek çok pratik bir çözümdür. wp-content altında temp klasörü oluşturup yazılabilir yaptığında, aşağıdaki tanımla WordPress’in geçici yolu daha stabil hale gelir.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Görsel işleme kütüphanesi de sık tetikleyicidir. WordPress yükleme sonrası küçük boyutlar üretirken GD veya Imagick kullanır. Bu kütüphane sunucuda eksikse, bozuksa veya limitler yüzünden işlem yarıda kalıyorsa, yükleme tarafında tuhaf hatalar çıkar. Bu durumda bazı görseller yüklenir, bazıları yüklenmez; sen de bunu “rastgele WordPress Hata” sanırsın. Aslında sistem tutarlıdır: bazı dosyalar daha ağır işleme ister, bazıları istemez. Çözüm, hosting tarafında bu kütüphaneleri düzgün kurmak veya görselleri yüklemeden önce boyutlandırmaktır. Ayrıca güvenlik katmanları da devreye girebilir. WAF, ModSecurity veya CDN bazı dosyaları ya da istekleri şüpheli görüp kesebilir; WordPress’e kalan sadece “HTTP Hatası” demek olur. Burada teşhis, aynı görseli farklı bir ağdan denemek ve loglarda engel izini aramaktır.

Özetle, Medya Kütüphanesinde görülen WordPress HTTP Hatası çoğu zaman tek bir düğmeyle çözülmez; ama sistemli gidersen çözümü basittir. Dosya adını sadeleştir, görseli optimize et, debug log ile kanıt topla, bellek ve süre limitlerini makul seviyeye çek, temp dizinini stabil hale getir, ardından sunucu tarafında görüntü işleme ve güvenlik katmanını kontrol et. Bu adımlar doğru uygulandığında, aynı WordPress Hata görüntüsünü tekrar tekrar düzeltmek zorunda kalmazsın; çünkü sorunu kökten kapatmış olursun.

Medya Ekle Düğmesi Çalışmıyor Sorunu Nedir?

Klasik Editör kullanırken “Medya Ekle” düğmesine tıklayıp hiçbir şey olmuyorsa, bu genelde editörün arayüzünü açan JavaScript tarafının takılması demektir. Kullanıcı açısından bu durum net bir WordPress Hata gibi görünür: görsel ekleyemezsin, dosya seçemezsin, içerik üretimi durur. Oysa çoğu vakada sorun WordPress’in çekirdeğinden ziyade, yönetim paneline eklenen bir eklenti betiğinin (script) çakışması, tarayıcı önbelleği, minify/optimizasyon ayarları veya sunucu tarafında birleşik dosya (concatenate) yükleme mantığının bozulmasıdır. Bu hata “bir kere oldu geçer” gibi davranmaz; kök sebep duruyorsa tekrar eder, hatta editörde başka tuhaflıkları da tetikler.

Bu tip WordPress Hata vakalarında ilk doğru hareket, rastgele kurcalamak değil, sorunu ikiye bölmektir: tarayıcı tarafı mı, WordPress yönetim paneli tarafı mı? Tarayıcı tarafında en hızlı test gizli sekmede denemek ve tüm eklentileri (özellikle reklam engelleyici, script engelleyici, güvenlik uzantıları) kapatıp yeniden tıklamaktır. Çünkü medya modal penceresi (dosya seçici) açılmadan önce bazı script çağrıları yapılır; tarayıcı eklentisi bunları engellerse düğmeye basarsın ama tepki alamazsın. Bu testi geçmeden, “WordPress bozuldu” diye paniğe kapılmak gereksizdir.

Tarayıcı tarafı temizse ikinci adım, eklenti çakışmasını hızlıca elemek olmalıdır. En klasik ve en sağlam yöntem şudur: eklentileri topluca devre dışı bırak, sonra düğmeyi tekrar dene. Panelden yapamıyorsan FTP/SFTP ile wp-content/plugins klasörünün adını geçici değiştirmen yeterlidir. Düğme çalışmaya başlarsa mesele WordPress Hata değil, bir eklentinin yönetim panelinde medya bileşenini bozmasıdır. Sonra klasör adını geri alır, eklentileri tek tek açarak hangisinin sorunu çıkardığını yakalarsın. Bu disiplinli yöntem, saatlerce boşuna uğraşmayı keser.

Bu sorunun çok sık görülen bir nedeni de yönetim panelindeki script birleştirme ve sıkıştırma sürecidir. Bazı sunucularda veya bazı kurulumlarda WordPress yönetim paneli script’leri birleştirirken problem yaşar; sonuçta medya penceresini açacak kod düzgün yüklenmez. Bu durumda çözüm, WordPress’e yönetim panelinde script birleştirmeyi kapatmasını söylemektir. Bu bir “kalıcı performans ayarı” değil, teşhis ve stabilizasyon adımıdır. wp-config.php dosyana aşağıdaki satırı ekleyip tekrar denediğinde düğme çalışmaya başlarsa, sorunun nerede olduğunu netleştirirsin.

define('CONCATENATE_SCRIPTS', false);

Bazen bununla da bitmez; çünkü sorun birleşmeden değil, sıkıştırılmış dosyaların debug edilmeden servis edilmesinden kaynaklanır. Yönetim panelinde script’leri daha “ham” halde yüklemek için SCRIPT_DEBUG açmak, hem sorunu azaltır hem de tarayıcı konsolunda daha net hata görmeni sağlar. Bu, WordPress Hata vakalarında teşhisi inanılmaz hızlandırır. Şunu unutma: bu ayarı sürekli açık tutmak şart değildir; sorunu bulduktan sonra kapatabilirsin.

define('SCRIPT_DEBUG', true);

Şimdi işin pratik tarafı: bu sorunu doğuran şeyin çoğu zaman “optimizasyon eklentileri” olması tesadüf değildir. Admin panelinde JS/CSS küçülten, birleştiren, geciktiren (defer/delay) eklentiler bazen ön yüzde iyi iş çıkarır ama yönetim panelinde medya penceresini bozar. Bu yüzden performans eklentilerinde “admin panelinde optimizasyonu kapat” veya “wp-admin hariç tut” gibi bir ayar varsa onu kullanmak gerekir. Aksi halde sen sürekli WordPress Hata temizliyor gibi hissedersin, çünkü her gün bir yerde panel fonksiyonu patlar.

Bir başka sinsi sebep, tema veya sayfa oluşturucu eklentilerin admin tarafına gereksiz script basmasıdır. Normalde tema ön yüz içindir; ama bazı temalar admin’e de script yükler. Bu script, medya çerçevesiyle çakışırsa düğme kör olur. Bu noktada tarayıcı geliştirici konsolunda (Console) “Uncaught TypeError” gibi hatalar görürsün. Konsol hata veriyorsa bu, “benim sistemim kapris yaptı” değil, gerçek bir çakışma olduğunun kanıtıdır. Kanıtı gördükten sonra çözüm kolaylaşır: sorunlu eklentiyi/temayı güncelle, gerekiyorsa geçici olarak varsayılan temaya dön, sonra tekrar test et.

Bu WordPress Hata durumunda en çok atlanan ama çok etkili bir kontrol daha var: WordPress sürümü, Klasik Editör eklentisi ve ilgili bileşenlerin güncelliği. Yönetim paneli JS tarafında eski bir sürüm ile yeni bir bileşen bir araya gelince, özellikle medya modal penceresi gibi parçalar ilk patlayan yer olur. Güncelleme derken “her şeyi rastgele güncelle” demiyorum; önce yedek, sonra kontrollü güncelleme. Geleneksel düzen budur. Çünkü güncelleme hem çözüm olabilir hem de yanlış yapılırsa yeni sorun çıkarabilir.

Bozuk Medya Dosyaları Sorunu Nedir?

Medya Kütüphanesine giriyorsun ve görsellerin ya hiç görünmüyor ya da yer tutucu (kırık resim) ikonları çıkıyor. Bu durum kullanıcı gözünde doğrudan WordPress Hata gibi algılanır; çünkü “resimlerim gitti” paniği yaşatır. Gerçekte ise çoğu vakada resimler kaybolmamıştır, sadece tarayıcı o dosyaya ulaşamıyordur. Yani sorun genellikle dosyanın fiziksel olarak silinmesinden değil, dosya yolunun bozulmasından, izinlerin yanlış olmasından, sunucunun dosyayı servis edememesinden veya CDN/önbellek katmanının yanlış adresi göstermesinden çıkar. Bazı durumlarda güvenlik eklentisi veya hotlink koruması da görselleri engeller. Bu yüzden “bozuk medya” gördüğünde hemen veritabanını kurcalamak yerine, önce erişim zincirini kontrol etmek daha akıllıcadır. Çünkü bu WordPress Hata hissi çoğu zaman tek bir ayarla kesilir.

İlk adım çok basit ama çok etkilidir: görselin URL’sine tıkla ve yeni sekmede açmayı dene. Yeni sekmede açılmıyorsa, sorun WordPress editöründe değil; dosya sunucuda erişilemiyor demektir. Eğer yeni sekmede açılıyor ama kütüphanede kırık görünüyorsa, o zaman önbellek veya yönetim paneli tarafında bir görüntüleme sorunu ihtimali yükselir. Yeni sekmede açılmıyorsa, ikinci adım FTP/SFTP ile wp-content/uploads klasörüne bakmaktır. Dosya gerçekten orada mı? Alt klasör yapısı (yıl/ay) duruyor mu? Eğer dosyalar yoksa, burada artık WordPress Hata değil veri kaybı veya taşıma hatası konuşulur. Dosyalar oradaysa, o zaman mesele çoğunlukla izin/sahiplik veya sunucu servisidir.

Bozuk medya dosyalarının en yaygın sebeplerinden biri yanlış dosya izinleridir. uploads klasörü okunabilir değilse tarayıcı görseli çekemez. Bir diğer yaygın sebep, taşıma sırasında uploads klasörünün eksik taşınması veya yanlış yere taşınmasıdır. Üçüncü sebep CDN’dir: CDN eski URL’leri cache’lemiştir, origin’de dosya yolu değişmiştir, CDN hâlâ kırık yolu dağıtıyordur. Dördüncü sebep güvenlik katmanlarıdır: bazı WAF kuralları belirli uzantıları, belirli istekleri veya referer’ı engeller. Bu durumda görsel URL’si açılmaya çalışıldığında 403/404 döner ve sen bunu WordPress Hata sanırsın. Bu nedenle teşhiste en iyi kanıt, görsel URL’sinin hangi HTTP durum kodu döndürdüğünü görmektir: 404 ise dosya/yol sorunu, 403 ise izin/engelleme, 500 ise sunucu servis sorunu ihtimali yükselir.

İzin tarafında genel standart şudur: uploads klasörü ve alt klasörleri genelde 755, dosyalar 644 olmalıdır. Ancak tekrar söyleyeyim, sadece rakamlar değil sahiplik de önemlidir. VPS/dedicated ortamlarda site taşıma sonrası sahiplik karışırsa, izinler doğru görünse bile web sunucusu dosyayı servis edemez veya WordPress dosyaya doğru erişemez. Bu WordPress Hata gibi görünür ama kök sebep dosya sistemi düzenidir. Eğer erişimin varsa uploads için izinleri standartta toparlamak çoğu zaman hızlı çözüm verir. Aşağıdaki komutlar, sadece wp-content/uploads içinde klasör ve dosya izinlerini düzene sokmak için örnek bir yaklaşımdır.

# uploads icinde klasorleri 755, dosyalari 644 yap
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

İzinleri düzelttin ama hâlâ kırık görünüyorsa, sıradaki büyük şüpheli URL yoludur. Özellikle “Ayarlar > Ortam” altında yükleme diziniyle oynandıysa, ya da eski bir eklenti medya yolunu değiştirdiyse, WordPress veritabanında kayıtlı URL ile gerçek dosya yolu uyuşmayabilir. Bazı taşımalar sonrası “http -> https” geçişi de bozuk medya görüntüsü yaratır; çünkü içerikte gömülü kalan http linkleri yüzünden tarayıcı karışık içerik veya engelleme yaşayabilir. Bu da yine WordPress Hata gibi görünür. Bu tip durumda WP-CLI ile güvenli search-replace yapmak, özellikle alan adı değiştiyse çok işe yarar. Burada serileştirilmiş verileri bozmayacak yöntem tercih edilmelidir.

wp search-replace 'http://alanadiniz.com' 'https://alanadiniz.com' --all-tables

CDN kullanıyorsan, bozuk medya dosyalarında çoğu zaman asıl suçlu cache’tir. Dosya origin’de var olsa bile CDN hâlâ eski hatalı kopyayı servis eder. Bu yüzden CDN temizliği şarttır. Aynı şekilde WordPress’te cache eklentisi varsa onun da temizlenmesi gerekir. Aksi halde sen “düzeldi” sanırsın, kullanıcı “bende hâlâ kırık” der ve bu WordPress Hata döngüsü uzar. Ayrıca bazı CDN ayarlarında “hotlink protection” veya “referer kontrolü” vardır; yanlış yapılandırılırsa kendi sitenden gelen istekleri bile engelleyebilir. Bu durumda görsel URL’si açıldığında 403 döner. 403 görüyorsan, önce güvenlik/koruma katmanına bakmak gerekir.

Bozuk medya bazen de resim boyutları üretiminden kaynaklanır. WordPress görsel yükleyince farklı boyutlar üretir; tema belirli bir boyutu ister ama o boyut yoksa, bazı sayfalarda görsel kırık görünebilir. Bu durumda dosya var ama istenen alt boyut yoktur. Çözüm genellikle thumbnail yeniden üretmektir. Bunu eklentiyle yapmak mümkündür, ancak önce disk alanını ve kaynakları kontrol etmek gerekir; çünkü binlerce görselde yeniden üretim sunucuyu yorabilir. Yani yine klasik düzen: önce kontrol, sonra işlem. Aksi halde bir WordPress Hata düzeltirken performans tarafında yeni bir sorun çıkarırsın.

Bozuk medya dosyaları, genellikle “dosyalar silindi” değil “dosyaya ulaşılamıyor” problemidir. URL’yi tek sekmede test et, uploads klasöründe dosyayı doğrula, izin/sahipliği düzelt, alan adı değişimi varsa güvenli search-replace yap, CDN ve cache’i temizle, gerekirse görsel boyutlarını yeniden üret. Bu adımlar doğru uygulanınca bozuk medya görüntüsü ortadan kalkar ve WordPress Hata gibi görünen panik de kapanır. Sabit bir düzen kurduğunda bu sorun tekrar tekrar gelmez; çünkü temel zinciri sağlamlaştırmış olursun.

Resminizin kırpılmasında bir hata oluştu Sorunu Nedir?

WordPress Medya Kütüphanesinde bir görseli kırpmaya, döndürmeye veya yeniden boyutlandırmaya çalıştığında “Resminizin kırpılmasında bir hata oluştu” mesajını görüyorsan, bu genellikle WordPress’in görsel işleme motorunun işi tamamlayamadığını gösterir. Kullanıcı tarafında bu durum net bir WordPress Hata gibi hissedilir; çünkü basit bir kırpma işlemi bile yapılamıyordur. Fakat çoğu vakada sorun görselin kendisinden değil, sunucudaki PHP yapılandırmasından, kullanılan görüntü işleme kütüphanesinden (GD veya Imagick), bellek ve süre limitlerinden veya dosya izinlerinden kaynaklanır. WordPress görseli işlerken geçici dosyalar oluşturur, farklı boyutlar üretir ve sonra bunları uploads içine yazar. Zincirin herhangi bir halkası aksarsa WordPress işlemi yarıda keser ve bu genel mesajı verir. Bu nedenle doğru yaklaşım, “WordPress bozuldu” diye düşünmek yerine, görsel işleme zincirinin hangi adımda tıkandığını bulmaktır.

Bu sorunun en klasik nedeni, sunucuda Imagick/GD tarafının eksik veya sorunlu olmasıdır. Bazı hostinglerde GD kurulu olur ama sınırlıdır; bazı dosya türlerinde (özellikle büyük boyutlu PNG veya yüksek çözünürlüklü JPEG) zorlanır. Imagick varsa ama yanlış sürümse veya politika dosyası (policy.xml) belirli işlemleri kısıtlıyorsa kırpma başarısız olabilir. Bu noktada WordPress Hata gibi görünen şey, aslında sistemin “görseli işleyemiyorum” demesidir. İkinci klasik neden bellek limitidir. Büyük görseller kırpılırken RAM tüketimi artar; PHP bellek limiti düşükse işlem patlar. Üçüncü neden zaman aşımıdır. Sunucu maksimum yürütme süresini düşük tutuyorsa WordPress görseli işleyemeden zaman dolabilir. Dördüncü neden dosya izinleri ve sahipliktir. WordPress kırptıktan sonra yeni dosyayı uploads içine yazamazsa yine hata verir. Yani bu WordPress Hata görüntüsü; kütüphane, kaynak ve dosya sistemi üçgeninde ortaya çıkar.

İlk pratik test, daha küçük bir görsel üzerinde aynı işlemi denemektir. Küçük görsel kırpılıyor ama büyük görsel kırpılmıyorsa, bu genellikle bellek veya süre limitine işaret eder. Ayrıca görsel türü de önemlidir: aynı boyutta JPEG kırpılırken PNG kırpılmıyorsa, kütüphane/işleme farkı devreye giriyor olabilir. Bu testlerle “genel mi, boyuta/forma bağlı mı” sorusunu netleştirirsin. WordPress Hata teşhisinde bu ayrım altın değerindedir; çünkü çözümü doğrudan yönlendirir.

Teşhis tarafında bir diğer sağlam adım, WordPress debug log açmaktır. Çünkü bu hata mesajı tek başına yetersizdir; log çoğu zaman gerçek sebebi yakalar: bellek tükendi, dosyaya yazılamadı, kütüphane fonksiyonu başarısız oldu gibi. wp-config.php içine aşağıdaki debug ayarlarını geçici olarak ekleyebilirsin. Buradaki amaç ekranda hata göstermek değil; dosyaya kaydetmek ve kanıt toplamaktır. Bu yöntem, “WordPress Hata gibi görünüyor ama nereden” sorusuna net cevap verir.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Logda bellek veya süre ile ilgili bir kayıt görürsen, çözüm kaynak limitlerini makul seviyeye çekmektir. WordPress tarafında WP_MEMORY_LIMIT tanımı çoğu kurulumda yardımcı olur. Ancak şunu açık söyleyeyim: sadece limit artırmak, görsel optimizasyonu yapmadan binlerce yüksek çözünürlüklü dosyayla devam edersen yine başa dönersin. Yani kalıcı çözüm iki ayaklıdır: bir yandan limitleri makul tutarsın, diğer yandan görselleri yüklemeden önce optimize edersin. Yine de acil durumda aşağıdaki satır, WordPress Hata görüntüsünü kesebilir.

define('WP_MEMORY_LIMIT', '256M');

PHP tarafında maksimum yürütme süresi düşükse kırpma işlemi yarıda kalabilir. Hosting panelinden veya php.ini üzerinden max_execution_time artırmak gerekebilir. Panel erişimin yoksa hosting desteği bu işi hızla çözer. Çünkü burada WordPress Hata değil, sunucu politikası konuşuyoruz. Aynı şekilde upload/tmp dizini de önemlidir: WordPress görseli işlerken geçici alan kullanır, orada yazma sorunu varsa kırpma patlar. Bu durumda WordPress’e stabil bir temp dizini göstermek çoğu zaman pratik bir çözümdür. wp-content altında temp klasörü oluşturup yazılabilir yaptığında aşağıdaki satır işe yarar.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Kütüphane tarafına gelirsek: Imagick ve GD hangi durumda kullanılıyor sorusu önemlidir. Bazı sistemlerde Imagick kurulu görünür ama kısıtlıdır; bazı güvenlik politikaları büyük görselleri veya belirli işlemleri yasaklar. Bu durumda WordPress kırpma denediğinde “işleyemiyorum” der. Eğer hosting panelinde Imagick/GD durumunu görebiliyorsan kontrol et; göremiyorsan bir PHP info sayfası veya WP sağlık ekranı bazı ipuçları verebilir. Bu noktada rastgele eklenti kurup denemek yerine, sunucu tarafını netleştirmek daha geleneksel ve daha doğru yoldur. Çünkü altyapı sağlam değilse WordPress’e ne eklersen ekle aynı WordPress Hata tekrar eder.

Dosya izinleri de göz ardı edilmemeli. WordPress kırpılmış yeni dosyayı uploads içine kaydeder. uploads yazılabilir değilse, işlem başarılı olsa bile sonuç dosyası oluşmaz ve WordPress hata verir. Bu yüzden wp-content/uploads izin ve sahipliğinin düzgün olduğundan emin olmak gerekir. İzinlerin genel standardı klasörlerde 755, dosyalarda 644’tür; ama asıl mesele sahipliktir. Sahiplik karışıksa WordPress Hata zinciri burada da kendini gösterir.

“Resminizin kırpılmasında bir hata oluştu” sorunu, çoğu zaman WordPress’in değil sunucudaki görsel işleme altyapısının problemidir. Küçük/büyük görsel testini yap, debug log ile kanıt topla, bellek ve süre limitlerini makul seviyeye çek, temp dizinini stabil hale getir, Imagick/GD durumunu doğrula, uploads izin/sahipliğini düzelt. Bunları yaptığında bu WordPress Hata görüntüsü genellikle tamamen ortadan kalkar ve medya düzenleme araçları tekrar normal çalışır.

Yanlış Facebook Küçük Resmi Sorunu Nedir?

Bir yazını veya sayfanı Facebook’ta paylaştığında beklediğin kapak görseli yerine alakasız bir görsel çıkıyorsa, mesele çoğu zaman “Facebook kafasına göre seçti” değildir; senin sayfan, Facebook’a doğru sinyali veremiyordur. Bu durum site sahibi açısından bariz bir WordPress Hata gibi hissedilir çünkü paylaşımın görüntüsü bozulur, tıklanma oranı düşer, marka görüntüsü sarsılır. Fakat buradaki kök sebep genellikle Open Graph (OG) etiketlerinin hatalı olması, birden fazla görselin aynı anda “ben kapak görseliyim” diye aday olması, önbellek ve cache katmanlarının eski meta veriyi tutması veya sayfanın kaynak kodunda OG etiketlerinin yanlış sırada/yanlış şekilde basılmasıdır.

WordPress tarafında bunu çoğu zaman SEO eklentileri, sosyal paylaşım eklentileri veya tema tarafından eklenen meta etiketler yönetir. Bu yüzden yanlış Facebook küçük resmi gördüğünde “WordPress bozuldu” diye panik yapmak yerine, meta etiket zincirini temizleyerek işi kökten çözmek gerekir.

Bu sorunun en sık senaryosu şudur: Aynı sayfada birden fazla OG:image etiketi vardır veya OG:image, featured image yerine başka bir görseli işaret ediyordur. Örneğin tema header’da bir logo yükler ve bu logo OG etikete sızar. Ya da sayfa oluşturucu eklenti, bir hero görseli kullanır ve bunu otomatik “ilk görsel” diye öne çıkarır. Facebook, sayfayı taradığında birden fazla aday görür ve bazen yanlış olanı seçer. Bu noktada “Facebook neden bunu seçti” diye sinirlenirsin; ama sistemin mantığı basittir: Sen net bir kural koymamışsan, o da tahmin yürütür. Bu tahmin hatalı olunca da sen bunu WordPress Hata sanarsın. Oysa çözüm, sayfanın meta etiketlerini tek bir kaynaktan, tek bir kural setiyle üretmektir.

İlk iş, sayfanın kaynak kodunda OG etiketlerini kontrol etmektir. Tarayıcıda sayfayı açıp “Kaynağı Görüntüle” dediğinde head bölümünde og:image, og:title, og:description var mı, kaç tane var, hangi URL’yi gösteriyor görürsün. Burada iki tehlike vardır: Birincisi, aynı etiketten birden fazla olması. İkincisi, og:image’in http ile gelmesi veya yanlış domaine gitmesi. Özellikle siteyi http’den https’e taşıdıysan ve veritabanında eski URL’ler kaldıysa, OG etiketi hâlâ http linki basabilir. Bu da hem karışık içerik hem de paylaşım görseli hatası doğurabilir ve yine WordPress Hata gibi görünür. Bu yüzden OG etiketini tekil ve doğru URL ile vermek şarttır.

Bu sorunu kalıcı çözmenin en sağlam yolu, tek bir SEO eklentisi üzerinden sosyal paylaşım ayarlarını yönetmektir. Birden fazla eklenti aynı anda OG basıyorsa (mesela hem SEO eklentisi hem sosyal paylaşım eklentisi), çakışma çıkar. Çakışma çıktığında Facebook yanlış küçük resmi seçer, sen de her seferinde “yine WordPress Hata” diye uğraşırsın. Burada disiplinli yaklaşım şudur: OG etiketlerini yalnızca bir yer üretsin. Diğer eklentilerde OG üretimini kapat. Tema OG basıyorsa temada kapat veya çocuk temada müdahale et. Çünkü aynı işi iki kişi yaparsa, kural karışır.

Facebook tarafında bir başka can sıkıcı gerçek daha var: Facebook sayfanı bir kere taradı mı, meta bilgiyi cache’ler. Sen WordPress’te her şeyi düzeltmiş olsan bile Facebook hâlâ eski küçük resmi gösterebilir. Bu da “ben düzelttim niye hâlâ yanlış” diye tekrar tekrar WordPress Hata yaşatır. Çözüm burada Facebook’un yeniden taramasını tetiklemektir. Bunun için Facebook’un paylaşım hata ayıklama aracında (debugger) ilgili URL’yi yeniden “Scrape Again” ettirmek gerekir. Aksi halde doğru meta etiket bile anında yansımaz. Bu, teknik bir gerçek; kabullenip süreç yönetmek lazım.

İşin WordPress tarafında pratik bir önlem de, paylaşıma özel görseli bilinçli seçmektir. Featured image boşsa veya çok küçükse, Facebook farklı bir görsel seçmeye meyleder. Ayrıca Facebook’un önerdiği görsel boyutları vardır; görselin en-boy oranı ve çözünürlüğü çok düşükse Facebook bunu kırpabilir veya hiç seçmeyebilir. Bu durumda da “yanlış küçük resim” görürsün. Yani sadece etiket değil, görselin kalitesi ve oranı da önemlidir. Burada pratik kural şudur: her paylaşılacak içerikte bir featured image olacak, yeterli çözünürlükte olacak ve mümkünse paylaşım için uygun oranı koruyacak. Bu standardı oturttuğunda WordPress Hata gibi görünen paylaşım sorunları büyük ölçüde biter.

Teknik müdahale gerektiğinde, tema veya özel kod OG etiketlerini yanlış basıyorsa, doğrudan müdahale edebilirsin. Örneğin bazı temalar “ilk görseli otomatik og:image yap” gibi eski bir mantık taşır. Bu mantığı kapatmadan, üstüne SEO eklentisi OG basınca iki OG:image oluşur. Bu durumda ya temanın OG çıktısı kapatılır ya da diğer eklentinin OG çıktısı kapatılır. Hangi yolu seçeceğin, sitedeki kontrolün sende olup olmamasına bağlıdır. Benim tavrım nettir: kontrol tek elde olmalı. Paylaşım metalarını temanın insafına bırakmak yerine, SEO eklentisi gibi merkezi bir yerden yönetmek daha düzenli ve geleneksel yöntemdir.

Yanlış Facebook küçük resmi sorunu, WordPress Hata gibi görünse de çoğu zaman meta etiket disiplininin bozuk olmasından çıkar: birden fazla OG:image, yanlış URL, http/https karışıklığı, Facebook cache’i ve tema/eklenti çakışması. Kaynak kodda OG’leri tekilleştir, OG basan eklentileri tek kaynağa indir, featured image standardı oturt, gerekirse Facebook’ta yeniden tarama yaptır. Bunları yaptığında paylaşım görselleri stabil hale gelir ve “her paylaşımda tekrar düzeltme” eziyeti biter.

Veritabanı Bağlantısı Kurulurken Hata Sorunu Nedir?

“Veritabanı bağlantısı kurulurken hata oluştu” mesajı, WordPress’in sitenin içeriğini çekmek için gerekli olan veritabanına bağlanamadığını söyler. Bu mesaj çıktığında çoğu kişi bunu doğrudan WordPress Hata diye görür, çünkü site bir anda açılmaz hale gelir ve bazen yönetim paneline de giremezsin. Fakat gerçekte WordPress’in yaptığı şey çok basittir: wp-config.php içindeki veritabanı bilgileriyle MySQL/MariaDB sunucusuna bağlanmayı dener, bağlanamazsa da bu uyarıyı verir. Yani sorun çoğu zaman “WordPress bozuldu” değil, WordPress’in bağlanacağı hedefin ya yanlış olması ya da geçici/kalıcı olarak erişilemez olmasıdır.

Bu sorunun en sık sebepleri birkaç başlıkta toplanır. Birincisi yanlış veritabanı kimlik bilgileri: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST hatalıysa WordPress bağlanamaz. İkincisi hosting tarafında veritabanı servisinin çökmesi veya aşırı yüklenmesidir; veritabanı sunucusu cevap vermezse WordPress de doğal olarak bağlanamaz. Üçüncüsü site taşımalarında çok görülür: yeni sunucuda veritabanı adı veya kullanıcı adı değişmiştir ama wp-config.php güncellenmemiştir. Dördüncüsü DB_HOST değeridir; bazı hostinglerde “localhost” değil özel bir host adı kullanılır. Beşinci sebep daha sinsi olanıdır: veritabanı kullanıcı yetkileri kısıtlanmıştır, kullanıcı bağlanır ama tabloya erişemez ve WordPress bunu bağlantı hatası gibi yansıtabilir. Sonuçta yine WordPress Hata hissi oluşur, ama kök sebep WordPress değil altyapı zinciridir.

İlk ve en pratik kontrol, wp-config.php içindeki değerleri doğrulamaktır.

Özellikle taşıma yaptıysan, DB_NAME ve DB_USER genelde değişir; DB_PASSWORD de çoğu zaman farklıdır. Bu noktada “ben biliyorum” diye varsayma; hosting panelinde veritabanı bölümünden gerçek değerleri kontrol et. Ayrıca DB_HOST kısmına dikkat et: bazı yerlerde localhost doğruyken, bazı yerlerde 127.0.0.1, bazı yerlerde ise “mysql.siteadi.com” gibi bir adres gerekir. Bu tek satır yanlışsa WordPress Hata gibi görünen şey anında patlar. Aşağıdaki bölüm, wp-config.php içinde kontrol edeceğin alanların tipik halidir.

define('DB_NAME', 'veritabani_adi');
define('DB_USER', 'veritabani_kullanicisi');
define('DB_PASSWORD', 'veritabani_sifresi');
define('DB_HOST', 'localhost');

İkinci kontrol, veritabanı servisinin gerçekten ayakta olup olmadığıdır. Hosting panelinde “MySQL çalışıyor” gibi bir durum ekranı olabilir. VPS kullanıyorsan servis durmuştur, yeniden başlatmak gerekir. Paylaşımlı hostingde ise bazen kısa süreli kesinti yaşanır; 2-3 dakika sonra kendiliğinden toparlar. Burada önemli olan, sorunun süresidir: bir anda oldu ve kısa sürüyorsa geçici olabilir; sürekli oluyorsa kalıcı bir yapılandırma veya kaynak problemidir. Bu ayrımı yapmadan “WordPress Hata” diye sürekli dosya kurcalamak, sadece stresi büyütür.

Üçüncü adım, doğrudan veritabanına bağlanabildiğini test etmektir. Eğer SSH erişimin varsa mysql istemcisiyle bağlanmayı denersin. SSH yoksa phpMyAdmin üzerinden giriş yapıp yapamadığını kontrol edersin. Bağlanamıyorsan, WordPress’in bağlanamaması çok normaldir; önce veritabanı erişimini düzeltmen gerekir. Bağlanabiliyorsan ama WordPress yine hata veriyorsa, wp-config.php değerleriyle senin bağlandığın değerler arasında uyuşmazlık var demektir ya da DB_HOST farklıdır. Bu tip somut testler, WordPress Hata gibi görünen problemi “tahmin oyunu” olmaktan çıkarır.

Bazen asıl sorun veritabanının bozulması değil, veritabanı sunucusunun kaynak yetersizliğidir. Çok trafik, kötü yazılmış sorgular, ağır eklentiler, devasa autoload kayıtları gibi etkenler MySQL’i kilitleyebilir. MySQL kilitlenince WordPress “bağlantı yok” sanır. Bu senaryoda çözüm, sadece wp-config.php düzeltmek değildir; veritabanı performansını iyileştirmek, gereksiz eklentileri azaltmak, cache katmanını düzgün kurmak ve gerekirse hosting planını yükseltmektir. Kulağa sert geliyor ama gerçek bu: kaynak yetmiyorsa, WordPress Hata diye görünen şey bitmez; çünkü sistem boğuluyordur.

Bir diğer klasik sebep, site taşınırken tablo önekinin karışmasıdır. WordPress tabloları genelde wp_ ile başlar ama sende farklı bir önek olabilir. wp-config.php içindeki $table_prefix yanlışsa, WordPress bağlandıktan sonra tabloları bulamaz ve farklı tür hatalar verir; bazen bu da bağlantı problemi gibi algılanır. Bu yüzden wp-config.php içinde öneki de kontrol etmek gerekir. Taşıma sonrası “veritabanı var ama WordPress görmüyor” şikâyeti çok tipiktir ve yine WordPress Hata gibi yaşanır.

$table_prefix = 'wp_';

Çözüm adımlarını özetleyeyim: önce wp-config.php içindeki DB_NAME/DB_USER/DB_PASSWORD/DB_HOST değerlerini hosting panelindeki gerçek bilgilerle birebir doğrula. Sonra phpMyAdmin veya SSH ile aynı bilgilerle veritabanına bağlanabildiğini kanıtla. Veritabanı servisi çalışmıyorsa servis tarafını düzelt veya hosting destekle konuş. Taşıma yaptıysan DB_HOST ve $table_prefix hatasını özellikle ara. Ardından, sorun tekrar ediyorsa kaynak ve performans tarafına geç: MySQL’in kilitlendiği senaryolarda çözüm altyapı iyileştirmesidir. Bu adımlarla ilerlersen, “veritabanı bağlantısı kurulurken hata” mesajı bir WordPress Hata döngüsü olmaktan çıkar, net ve ölçülebilir bir problem haline gelir ve kalıcı şekilde kapanır.

WordPress Veritabanı Bozuk Sorunu Nedir?

WordPress veritabanı bozuk (corrupt) denildiğinde, veritabanındaki bazı tabloların veya indekslerin hatalı hale gelmesi ve WordPress’in bu yüzden doğru veriyi okuyamaması anlaşılır. Kullanıcı açısından bu durum çoğu zaman WordPress Hata diye görünür; çünkü bazen site hiç açılmaz, bazen yönetim paneline girersin ama tuhaf hatalar görürsün, bazen de “veritabanı bağlantısı” gibi daha genel mesajlar çıkar.

Oysa bozulma, “bağlanamıyorum”dan farklı bir durumdur: bağlantı kurulabilir ama veriler tutarlı olmadığı için sorgular hata verir. Bu da WordPress’in normal çalışmasını engeller.

Veritabanı bozulmasının yaygın sebepleri oldukça nettir. En başta ani kapanmalar gelir: sunucu resetlenir, disk sorunu yaşanır, MySQL servisi aniden durur, güncelleme sırasında sistem yarıda kalır. İkinci sebep disk/inode problemleri ve dosya sistemi hatalarıdır; veritabanı dosyaları yazılırken hata oluşursa tablolar zarar görebilir. Üçüncü sebep yoğun trafik veya kötü yazılmış sorgularla veritabanının kilitlenmesi ve yarım kalan işlemlerdir.

Dördüncü sebep ise kötü niyetli müdahale ya da zayıf güvenliktir; saldırganlar bazen tabloya zarar verecek işlemler yapabilir. Beşinci sebep, bazı eklentilerin yanlış SQL işlemleriyle tabloyu şişirmesi veya yapıyı bozmasıdır. Sen bunların hepsini “WordPress Hata çıktı” diye tek sepete atarsan yanlış teşhis yaparsın; doğru olan, bozulmayı kanıtlayıp kontrollü şekilde onarmaktır.

Bu sorunda en güvenli yaklaşım eski usuldür: önce yedek, sonra işlem. Çünkü veritabanında yapacağın her işlem geri dönüşsüz olabilir. Yedek yoksa onarım denemesi bile risk taşır. Bu yüzden ilk adım, hosting panelinden veya phpMyAdmin’den veritabanı yedeğini almaktır. Yedek alındıktan sonra ikinci adım, WordPress’in kendi “veritabanı onarma” mekanizmasını devreye almaktır. WordPress çekirdeğinde bunun için özel bir mod vardır. wp-config.php dosyana aşağıdaki satırı eklediğinde, WordPress onarım ekranını açar ve bazı tabloları onarmayı dener.

define('WP_ALLOW_REPAIR', true);

Bu satırı ekledikten sonra tarayıcıdan şu yolu açarsın: /wp-admin/maint/repair.php. Burada iki seçenek olur: sadece onar veya onar ve optimize et. Bu noktada pratik tavsiye: önce sadece onar ile başla. İş başarılı olursa site normale dönebilir. Ardından optimize seçeneğiyle tablo düzeni toparlanır.

Bu araç, birçok vakada WordPress Hata gibi görünen bozulma problemini hızlıca keser. Fakat şunu da açık söylemek gerekir: Bu araç her şeyi kurtarmaz. Eğer disk hatası varsa veya tablolar ağır hasarlıysa, onarım da başarısız olabilir.

Onarım bittiğinde kritik bir adım var: WP_ALLOW_REPAIR satırını mutlaka kaldırmak. Çünkü bu mod açık kalırsa, giriş gerektirmeyen bir onarım sayfası erişime açık kalabilir. Bu güvenlik açısından gereksiz bir risktir. Yani iş biter bitmez wp-config.php içinden bu satırı silersin. Bu küçük disiplin detayı, “bir WordPress Hata çözdüm derken güvenlik açığı açma” riskini ortadan kaldırır.

Onarım işe yaramadıysa veya sorun kısa süre sonra tekrar ediyorsa, burada artık “kök sebep” tarafına bakmak gerekir. Veritabanı kendi kendine durduk yere bozulmaz; altta genellikle bir disk sorunu, kaynak yetersizliği, ani kapanma, agresif eklenti, çöp gibi büyüyen autoload kayıtları veya kötü yapılandırılmış cron işleri vardır. Örneğin sürekli çalışan ağır cron görevleri, veritabanını zorlar ve kilitlenmelere yol açabilir. Bazı cache eklentileri veya istatistik eklentileri kontrolsüz log biriktirir, tabloyu şişirir. Bu şişme, bir gün “bozuk” olarak geri döner ve sen yine WordPress Hata diye uğraşırsın. Kalıcı çözüm için bu tip eklentileri disipline etmek, gereksiz tabloları temizlemek ve veritabanı kaynaklarını artırmak gerekir.

Bir diğer sık senaryo, yedekten geri dönme gerekliliğidir. Eğer elinde sağlam bir yedek varsa, bozuk tabloyu onarmaya çalışmak yerine yedeği geri yüklemek çoğu zaman daha temizdir. Çünkü onarım bazen veri kaybıyla sonuçlanabilir: bozuk satırları atar, indeksleri yeniden kurarken bazı kayıtları dışarıda bırakabilir. Bu yüzden iş kritikse ve güvenilir bir yedek varsa, en geleneksel ve en risksiz yöntem yedekten geri dönmektir. Bu yaklaşım, WordPress Hata döngüsünü hızlı keser, sonra bozulmanın nedenini ayrı ayrı incelersin.

Veritabanı bozulması yaşadığında dikkat etmen gereken bir nokta daha var: site açılıyor gibi görünse bile arka planda hatalar üretebilir. Bu yüzden debug log açıp bir süre izlemek faydalıdır. Hata tekrar ediyorsa, loglar genellikle “table is marked as crashed” gibi ipuçları verir. Bu ipucu, sorunun gerçekten bozulma olduğunu kanıtlar ve seni doğru yola sokar. Çünkü bazen insanlar performans sorununu bozulma sanır, bazen bozulmayı performans sanır; ikisinin çözümü farklıdır.

WordPress veritabanı bozuk sorunu, WordPress Hata gibi görünse de çoğunlukla altyapı ve veritabanı bütünlüğü problemidir. Önce yedek al, WP_ALLOW_REPAIR ile onarmayı dene, iş bitince satırı kaldır, devam ederse kök sebebi ara (disk, kaynak, eklenti, cron, tablo şişmesi) ve mümkünse sağlam yedekten geri dönmeyi değerlendir. Bu disiplinle ilerlersen, veritabanı bozulması “sürekli geri gelen bela” olmaktan çıkar ve yönetilebilir bir arıza haline gelir.

WordPress Veritabanı Bozuk Sorunu Nedir?

WordPress veritabanı bozuk (corrupt) denildiğinde, veritabanındaki bazı tabloların veya indekslerin hatalı hale gelmesi ve WordPress’in bu yüzden doğru veriyi okuyamaması anlaşılır. Kullanıcı açısından bu durum çoğu zaman WordPress Hata diye görünür; çünkü bazen site hiç açılmaz, bazen yönetim paneline girersin ama tuhaf hatalar görürsün, bazen de “veritabanı bağlantısı” gibi daha genel mesajlar çıkar.

Oysa bozulma, “bağlanamıyorum”dan farklı bir durumdur: bağlantı kurulabilir ama veriler tutarlı olmadığı için sorgular hata verir. Bu da WordPress’in normal çalışmasını engeller.

Veritabanı bozulmasının yaygın sebepleri oldukça nettir. En başta ani kapanmalar gelir: sunucu resetlenir, disk sorunu yaşanır, MySQL servisi aniden durur, güncelleme sırasında sistem yarıda kalır. İkinci sebep disk/inode problemleri ve dosya sistemi hatalarıdır; veritabanı dosyaları yazılırken hata oluşursa tablolar zarar görebilir. Üçüncü sebep yoğun trafik veya kötü yazılmış sorgularla veritabanının kilitlenmesi ve yarım kalan işlemlerdir.

Dördüncü sebep ise kötü niyetli müdahale ya da zayıf güvenliktir; saldırganlar bazen tabloya zarar verecek işlemler yapabilir. Beşinci sebep, bazı eklentilerin yanlış SQL işlemleriyle tabloyu şişirmesi veya yapıyı bozmasıdır. Sen bunların hepsini “WordPress Hata çıktı” diye tek sepete atarsan yanlış teşhis yaparsın; doğru olan, bozulmayı kanıtlayıp kontrollü şekilde onarmaktır.

Bu sorunda en güvenli yaklaşım eski usuldür: önce yedek, sonra işlem. Çünkü veritabanında yapacağın her işlem geri dönüşsüz olabilir. Yedek yoksa onarım denemesi bile risk taşır. Bu yüzden ilk adım, hosting panelinden veya phpMyAdmin’den veritabanı yedeğini almaktır. Yedek alındıktan sonra ikinci adım, WordPress’in kendi “veritabanı onarma” mekanizmasını devreye almaktır. WordPress çekirdeğinde bunun için özel bir mod vardır. wp-config.php dosyana aşağıdaki satırı eklediğinde, WordPress onarım ekranını açar ve bazı tabloları onarmayı dener.

define('WP_ALLOW_REPAIR', true);

Bu satırı ekledikten sonra tarayıcıdan şu yolu açarsın: /wp-admin/maint/repair.php. Burada iki seçenek olur: sadece onar veya onar ve optimize et. Bu noktada pratik tavsiye: önce sadece onar ile başla. İş başarılı olursa site normale dönebilir. Ardından optimize seçeneğiyle tablo düzeni toparlanır.

Bu araç, birçok vakada WordPress Hata gibi görünen bozulma problemini hızlıca keser. Fakat şunu da açık söylemek gerekir: Bu araç her şeyi kurtarmaz. Eğer disk hatası varsa veya tablolar ağır hasarlıysa, onarım da başarısız olabilir.

Onarım bittiğinde kritik bir adım var: WP_ALLOW_REPAIR satırını mutlaka kaldırmak. Çünkü bu mod açık kalırsa, giriş gerektirmeyen bir onarım sayfası erişime açık kalabilir. Bu güvenlik açısından gereksiz bir risktir. Yani iş biter bitmez wp-config.php içinden bu satırı silersin. Bu küçük disiplin detayı, “bir WordPress Hata çözdüm derken güvenlik açığı açma” riskini ortadan kaldırır.

Onarım işe yaramadıysa veya sorun kısa süre sonra tekrar ediyorsa, burada artık “kök sebep” tarafına bakmak gerekir. Veritabanı kendi kendine durduk yere bozulmaz; altta genellikle bir disk sorunu, kaynak yetersizliği, ani kapanma, agresif eklenti, çöp gibi büyüyen autoload kayıtları veya kötü yapılandırılmış cron işleri vardır. Örneğin sürekli çalışan ağır cron görevleri, veritabanını zorlar ve kilitlenmelere yol açabilir. Bazı cache eklentileri veya istatistik eklentileri kontrolsüz log biriktirir, tabloyu şişirir.

Bu şişme, bir gün “bozuk” olarak geri döner ve sen yine WordPress Hata diye uğraşırsın. Kalıcı çözüm için bu tip eklentileri disipline etmek, gereksiz tabloları temizlemek ve veritabanı kaynaklarını artırmak gerekir.

Bir diğer sık senaryo, yedekten geri dönme gerekliliğidir. Eğer elinde sağlam bir yedek varsa, bozuk tabloyu onarmaya çalışmak yerine yedeği geri yüklemek çoğu zaman daha temizdir. Çünkü onarım bazen veri kaybıyla sonuçlanabilir: bozuk satırları atar, indeksleri yeniden kurarken bazı kayıtları dışarıda bırakabilir.

Bu yüzden iş kritikse ve güvenilir bir yedek varsa, en geleneksel ve en risksiz yöntem yedekten geri dönmektir. Bu yaklaşım, WordPress Hata döngüsünü hızlı keser, sonra bozulmanın nedenini ayrı ayrı incelersin.

Veritabanı bozulması yaşadığında dikkat etmen gereken bir nokta daha var: site açılıyor gibi görünse bile arka planda hatalar üretebilir. Bu yüzden debug log açıp bir süre izlemek faydalıdır. Hata tekrar ediyorsa, loglar genellikle “table is marked as crashed” gibi ipuçları verir. Bu ipucu, sorunun gerçekten bozulma olduğunu kanıtlar ve seni doğru yola sokar. Çünkü bazen insanlar performans sorununu bozulma sanır, bazen bozulmayı performans sanır; ikisinin çözümü farklıdır.

WordPress veritabanı bozuk sorunu, WordPress Hata gibi görünse de çoğunlukla altyapı ve veritabanı bütünlüğü problemidir. Önce yedek al, WP_ALLOW_REPAIR ile onarmayı dene, iş bitince satırı kaldır, devam ederse kök sebebi ara (disk, kaynak, eklenti, cron, tablo şişmesi) ve mümkünse sağlam yedekten geri dönmeyi değerlendir. Bu disiplinle ilerlersen, veritabanı bozulması “sürekli geri gelen bela” olmaktan çıkar ve yönetilebilir bir arıza haline gelir.

WordPress’te PHP Hataları Sorunu Nedir?

WordPress yönetim panelinde üstte sarı bir uyarı bandı, ekranda “Warning”, “Notice” veya daha kötüsü “Fatal error” gibi mesajlar görüyorsan, bu PHP tarafında bir şeylerin yolunda gitmediğini gösterir. Kullanıcı bunu doğal olarak WordPress Hata diye algılar; çünkü “WordPress bana hata basıyor” hissi verir. Fakat PHP hataları, WordPress’in kalbiyle doğrudan ilgilidir: tema dosyaları, eklentiler ve çekirdek, PHP ile çalışır.

Bu yüzden hatanın kaynağı çoğu zaman bir eklenti/tema kodu, uyumsuz PHP sürümü, eksik PHP eklentisi veya yanlış yapılandırılmış sunucu ayarıdır. Önemli olan şudur: PHP hataları her zaman sitenin tamamen çökmesi demek değildir. Bazen sadece geliştiriciye bilgi veren uyarılardır, bazen de siteyi tamamen durduran ölümcül (fatal) hatalardır. Bu ayrımı yapmadan, rastgele müdahale edersen bir WordPress Hata düzeltmeye çalışırken daha büyük bir sorun çıkarabilirsin.

En kritik senaryo “Fatal error” türüdür. Bu durumda genellikle belirli bir dosyada, belirli bir satırda hata yazılır ve sayfa çalışmayı durdurur. Bu, en net WordPress Hata tipidir: ya beyaz ekran görürsün ya da yarım bir hata ekranı. Fatal error çoğu zaman bir eklentinin veya temanın PHP sürümünle uyumsuz olmasından çıkar. Örneğin eklenti PHP 8.2 ister, senin sunucun 7.4’tedir veya tam tersi, eklenti eski kalmıştır, yeni PHP sürümünde kırılır. Bir diğer yaygın sebep, kod parçacığı yapıştırmaktır. İnternetten bir snippet alıp functions.php’ye yapıştırırsın, bir noktalı virgül unutulur, site gider. Bu noktada “WordPress Hata” demek kolaydır ama gerçek şu: hata, çalıştırılan PHP kodundadır.

Uyarı (Warning/Notice) tipleri daha sinsi olabilir. Site açılır, panel çalışır ama ekranda uyarılar akar. Bu uyarılar çoğu zaman kullanıcıyı doğrudan engellemez; fakat profesyonel görünümü bozar, özellikle ön yüzde görünüyorsa marka algısını zedeler. Ayrıca bazı durumlarda uyarılar çıktıyı bozduğu için cookie/redirect gibi işlemler de etkilenir ve bu da başka WordPress Hata zincirleri üretir. Yani “çok da önemli değil” deyip geçmek de doğru değildir. Doğru yaklaşım, uyarıyı kaynağında çözmektir: hangi eklenti/tema üretiyorsa onu güncellemek, uyumlu sürüme çekmek veya geliştiriciyle iletişime geçmektir.

Bu konudaki ilk sağlam adım, hataları düzgün loglamaktır. Çünkü ekranda görünen hata bazen buzdağının sadece ucudur. Ayrıca üretim ortamında (canlı sitede) hataları ekrana basmak güvenlik açısından da kötü bir fikirdir; dosya yolu, satır numarası, sistem bilgisi gibi şeyleri açık edersin. Bu yüzden WordPress’te en doğru yöntem, debug log’u açıp hataları dosyaya yazdırmaktır. wp-config.php içine aşağıdaki ayarları eklediğinde, hatalar wp-content/debug.log içine düşer. Bu log, WordPress Hata teşhisinde “kanıt defteri” gibidir.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Log açıldıktan sonra hatayı tetiklersin (hangi sayfada çıkıyorsa o sayfaya gidersin) ve debug.log dosyasını incelersin. Çoğu zaman hata mesajında sorumlu eklenti veya tema dosyası adı yazar. Bu sana doğrudan hedef verir. Eğer eklentinin adı geçiyorsa ilk hızlı çözüm, eklentiyi devre dışı bırakmaktır. Panel açılmıyorsa FTP/SFTP ile wp-content/plugins klasöründe ilgili eklentiyi geçici devre dışı bırakabilirsin. Tema kaynaklıysa varsayılan bir temaya dönmek teşhisi netleştirir. Bu yaklaşım “geleneksel” ama etkilidir: önce sistemi ayağa kaldırırsın, sonra kalıcı düzeltmeye geçersin. Çünkü site kapalıyken mükemmel kod yazmanın kimseye faydası yoktur.

PHP sürümü uyumsuzluğu çok kritik bir başlıktır. WordPress çekirdeği ve eklentiler belirli sürümlerle test edilir. Sunucuda PHP sürümünü rastgele yükseltmek, bir gecede onlarca WordPress Hata üretebilir. Aynı şekilde çok eski PHP sürümünde kalmak da yeni eklentileri kırar. Bu yüzden sürüm yönetimi kontrollü olmalıdır. En temiz yöntem, staging/test ortamında denemek, eklentilerin uyum durumunu kontrol etmek, sonra canlıya almak. Eğer staging yoksa bile en azından yedek alıp kontrollü ilerlemek şarttır. Bu düzeni kurduğunda PHP kaynaklı WordPress Hata sayısı dramatik şekilde düşer.

Bir de “eksik PHP eklentileri” meselesi var. Örneğin Imagick yoksa bazı görsel işlemler patlar; mbstring yoksa bazı karakter işlemleri sıkıntı çıkarır; curl yoksa dış servis çağrıları bozulur. Bu tip eksikler bazen fatal error üretir, bazen sadece uyarı üretir. Çözüm WordPress panelinde aranmaz; hosting seviyesinde PHP modülleri açılır. Burada da pratik kural: WordPress katmanında çözüm ararken sunucu katmanını görmezden gelirsen, WordPress Hata döngüsü bitmez.

Özetle WordPress’te PHP hataları, “WordPress bozuk” değil “WordPress’i çalıştıran kod veya ortam sorunlu” demektir. Önce debug log ile kanıt topla, hatayı üreten eklenti/tema dosyasını yakala, sistemi ayağa kaldırmak için sorunlu bileşeni devre dışı bırak, sonra kalıcı çözüm olarak uyumlu sürüme geç, güncelle, gerekiyorsa geliştiriciye dön. PHP sürümünü ve modülleri de kontrollü yönet. Böyle ilerlersen PHP kaynaklı WordPress Hata’lar bir panik konusu olmaktan çıkar ve rutin bakım disiplinine dönüşür.

Geçici Klasör Eksik Sorunu Nedir?

“Geçici klasör eksik” uyarısı, WordPress’in dosya yüklerken veya güncelleme yaparken kullanması gereken geçici (temp) dizine erişemediğini anlatır. Bu uyarı çıktığında işler genelde zincirleme bozulur: eklenti güncellemesi yarıda kalır, tema yüklenmez, medya yükleme saçmalar, bazen otomatik güncelleme tamamen kilitlenir. Kullanıcı tarafında bu tablo doğal olarak WordPress Hata gibi görünür; çünkü panelde sıradan bir işlem yapmak istersin, sistem “yapamıyorum” der. Ancak bu sorunun kaynağı çoğu zaman WordPress değil, PHP’nin temp dizin ayarı veya sunucuda temp dizinine yazma izninin olmamasıdır. Yani WordPress’in suçu, “ben geçici dosyayı nereye yazacağımı bilmiyorum” demek kadar basittir.

WordPress bir dosyayı doğrudan uploads klasörüne pat diye yazmaz. Birçok işlemde önce geçici bir yere yazar, doğrular, ardından hedef dizine taşır. Bu süreç, özellikle eklenti/tema yüklemelerinde ve medya yüklemelerinde yoğun çalışır. Eğer PHP’nin “upload_tmp_dir” ayarı boşsa, yanlışsa, sunucuda temp dizini doluysa, temp dizini silinmişse veya web sunucusunun o dizine yazma izni yoksa, WordPress bu hatayı üretir. Bu yüzden “geçici klasör eksik” denince, ilk bakacağın yer wp-admin değil, sunucunun dosya sistemi düzenidir. Bu gerçeği görmezden gelirsen aynı WordPress Hata tekrar tekrar karşına çıkar.

İlk pratik kontrol, hosting panelinde PHP ayarlarını kontrol etmektir. Bazı panellerde “Temporary directory” veya “upload_tmp_dir” değeri görünür. Eğer burada bir yol tanımlı değilse veya tanımlı yol yazılamıyorsa, sorunun sebebi nettir. VPS kullanıyorsan bu ayar php.ini üzerinde olabilir. Paylaşımlı hosting kullanıyorsan destek ekibi bu ayarı düzeltir. Bu tip sorunlarda “ben eklenti kapatırım düzelir” yaklaşımı boştur; çünkü WordPress’in geçici dosyaya yazamaması, eklentiden bağımsız bir engeldir.

WordPress tarafında en pratik ve kontrollü çözüm, WordPress’e kendi temp dizinini göstermektir. Yani wp-content altında temp adında bir klasör oluşturur, yazılabilir hale getirir ve wp-config.php üzerinden WordPress’e “geçici dosyaları buraya koy” dersin. Bu yöntem, hem hızlıdır hem de hostingin global temp ayarına bağımlılığı azaltır. Ayrıca sorunu tek noktadan kontrol edersin. Aşağıdaki satır, tam olarak bunu yapar; WordPress’e temp dizin yolunu sabitler.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Bu satırı ekledikten sonra mutlaka wp-content içinde temp klasörü oluşturmalısın. Klasör yoksa WordPress yine yazamaz. FTP/SFTP ile wp-content altına temp klasörünü açıp yazma iznini vermen gerekir. İzin tarafında genelde klasör için 755 yeterlidir; ama sahiplik karışıksa 755 de yetmez. Burada yine klasik gerçek devreye girer: izin + sahiplik birlikte çalışır. Eğer web sunucusu kullanıcısı klasörün sahibi değilse WordPress yazamaz ve sen tekrar WordPress Hata görürsün. Bu yüzden temp klasörünü oluşturduktan sonra yazılabilir olduğunu gerçekten test et: küçük bir dosya yükle, eklenti güncelle, medya yükle. Test yoksa çözüm de yoktur.

Bir diğer sık senaryo, temp dizininin dolmasıdır. WordPress güncellemeler sırasında zip dosyalarını açar, geçici dosyalar üretir. Disk doluysa veya inode doluysa, temp dizinine yazamaz. WordPress bunu bazen “geçici klasör eksik” gibi gösterir; çünkü pratikte geçici alan kullanılamıyordur. Bu nedenle disk kullanımını kontrol etmek şarttır. Özellikle paylaşımlı hostingde inode limiti dolar ve sistem tuhaf hatalar üretir. Sen de bunu WordPress Hata zannedersin. Oysa çözüm, gereksiz dosyaları temizlemek, cache klasörlerini kontrol etmek ve disk alanını genişletmektir.

Bu hatanın güncellemelerle birlikte görülmesi çok tipiktir. Çünkü güncelleme, temp dizinini en agresif kullanan işlemdir. Eğer otomatik güncelleme yarıda kalırsa, bakım modunda takılı kalma gibi başka problemler de tetiklenebilir. Yani tek bir “geçici klasör eksik” hatası, arkasından bir sürü WordPress Hata doğurabilir. Bu yüzden burada yapılacak iş, sadece hatayı geçiştirmek değil; temp dizini meselesini kalıcı şekilde çözmektir. Kalıcı çözüm, ya sunucu PHP temp ayarını düzeltmek ya da WordPress’e özel temp dizini tanımlamaktır. İkisini birden düzgün yaparsan sorun tekrarlamaz.

“Geçici klasör eksik” sorunu, WordPress’in dosya yazma zincirinde geçici durağı kullanamamasıdır. wp-config.php ile WP_TEMP_DIR tanımla, wp-content/temp klasörünü oluştur, yazılabilirliğini kanıtla, disk/inode durumunu kontrol et, gerekiyorsa hosting tarafında upload_tmp_dir ayarını düzelt. Bunları yaptığında bu WordPress Hata görünümü genellikle tamamen biter ve medya yükleme ile güncelleme işlemleri tekrar stabil hale gelir.

WordPress Tema Stil Dosyası Eksik Sorunu Nedir?

“Stil sayfası eksik” uyarısı, WordPress’in temayı geçerli bir tema olarak kabul edebilmesi için gerekli olan style.css dosyasını bulamadığını söyler. Bu uyarı çıktığında temayı kuramazsın veya tema listesinde tema görünür ama etkinleştirilemez. Kullanıcı bunu doğal olarak WordPress Hata diye görür; çünkü tema var gibi durur ama çalışmaz. Buradaki mantık çok net: WordPress bir temayı tanımak için tema klasöründe style.css dosyasını arar ve bu dosyanın içinde tema başlığı bilgilerini okur. Dosya yoksa veya yanlış yerdeyse, WordPress “ben bunu tema olarak tanıyamam” der. Bu yüzden çözüm, “tema bozuk” paniğine kapılmak değil, dosya yapısını doğru yere oturtmaktır.

Bu hatanın en yaygın sebebi, yanlış zip yüklemektir. Bazı tema sağlayıcıları sana “tüm paket” zip’i verir; içinde dokümantasyon, lisans, demo içerikleri, hatta birden fazla tema/eklenti bulunur. Sen bu büyük paketi doğrudan WordPress’e yüklersen, WordPress zip’i açar ama tema klasörü içinde beklediği style.css’i bulamaz; çünkü gerçek tema klasörü bir alt klasörün içindedir. Sonuç: “Stil sayfası eksik.” Bu senaryoda WordPress Hata gibi görünse de aslında sen yanlış dosyayı yüklemişsindir. En pratik çözüm, zip’i bilgisayarında açıp gerçek tema klasörünü bulmaktır. İçinde style.css olan klasör hangisiyse, onu ayrı zip yapıp onu yüklemek gerekir.

İkinci sık sebep, dosya adının veya konumunun yanlış olmasıdır. style.css dosyası “Style.css” gibi büyük harfli veya farklı isimli ise bazı sunucularda sorun çıkar. WordPress bu dosyayı tam adla arar. Ayrıca style.css tema klasörünün kökünde olmalıdır; alt klasörde durursa WordPress görmez. Üçüncü sebep kurulumun yarıda kalmasıdır: yükleme sırasında bağlantı kesilir, disk dolar, izin sorunu olur; klasör oluşur ama dosyalar tam açılmaz. Bu durumda tema klasöründe style.css oluşmamış olabilir. Sen yine WordPress Hata görürsün ama kök sebep eksik dosyadır.

Bu sorunu çözmenin en sağlam yöntemi FTP/SFTP ile temanın gerçekten nereye açıldığını kontrol etmektir. wp-content/themes içine girersin ve ilgili tema klasörünü bulursun. Klasörün içinde style.css var mı, yoksa başka bir klasörün içinde mi? Eğer tema klasörü şöyle bir yapıdaysa: wp-content/themes/tema-paketi/tema-adi/style.css, burada WordPress tema-paketi klasörünü tema sanmış olur ve style.css’i bulamaz. Çözüm basittir: tema-adi klasörünü wp-content/themes içine doğrudan taşırsın. Bu düzeni kurduğunda WordPress Hata kesilir, tema listede normal görünür.

Dosya gerçekten eksikse, bazen tema dosyaları bozuk inmiş veya sağlayıcı hatalı paket göndermiş olabilir. Bu durumda en temiz çözüm, temayı yeniden indirmektir. “Ben style.css yazayım” gibi bir refleks bazen işe yarar gibi görünür ama tavsiye etmem; çünkü style.css sadece bir CSS dosyası değil, tema meta bilgisini taşıyan dosyadır ve tema bütünlüğüyle beraber gelir. Dosyayı elle ekleyip tema çalışıyormuş gibi yapmak, ileride daha büyük WordPress Hata zincirleri üretir. Doğru olan, sağlam paketi yüklemektir.

Bu hatada bir başka kritik konu da izin ve sahipliktir. WordPress tema yüklerken wp-content/themes içine dosyaları yazmalıdır. Eğer yazma iznin yoksa, yükleme yarım kalır ve style.css gelmez. Sen tekrar tekrar yükleme dener, tekrar WordPress Hata görürsün. Bu durumda tema klasörünün ve wp-content/themes dizininin yazılabilir olduğundan emin olmak gerekir. Paylaşımlı hostingde bu genellikle panelden düzelir; VPS’de sahiplik düzeltmek gerekebilir. Bu tarz temel dosya sistemi problemleri çözülmeden, tema kurulumları stabil olmaz.

Pratik bir alternatif, temayı manuel yüklemektir. Eğer WordPress panelinden yükleme sürekli sorun çıkarıyorsa, tema zip’ini bilgisayarda açıp doğru tema klasörünü FTP/SFTP ile wp-content/themes içine atarsın. Sonra WordPress panelinden Görünüm > Temalar bölümünden etkinleştirirsin. Bu yöntem, panel yükleyicisindeki bazı limitleri bypass eder ve WordPress Hata döngüsünü kesebilir. Ama yine de doğru klasörü attığından emin olmalısın; içinde style.css kökte olacak.

Özetle “Tema stil dosyası eksik” sorunu, çoğu zaman WordPress’in değil paket yapısının problemidir. Yanlış zip yükleme, alt klasörde kalan tema, eksik/yanlış isimli style.css veya yarım kurulum en sık sebeplerdir. wp-content/themes içinde doğru klasörü konumlandır, style.css’in kökte ve doğru isimde olduğundan emin ol, gerekirse temayı yeniden indir veya manuel yükle. Bu adımları düzenli uygularsan bu WordPress Hata bir daha seni uğraştırmaz; çünkü sorun tema yapısının disiplinidir.

Pluggable.php Dosya Hataları Sorunu Nedir?

Pluggable.php ile ilgili bir hata gördüğünde çoğu kişi paniğe kapılır; çünkü hata mesajında “pluggable.php” yazması, sanki WordPress çekirdeğinin kritik bir dosyası bozulmuş gibi bir izlenim verir. Bu yüzden kullanıcı bunu doğrudan WordPress Hata diye yaşar. Ancak işin gerçeği çoğu zaman farklıdır: pluggable.php dosyası genellikle “suçlu” değil “haberci”dir. WordPress’te bazı işlevler (örneğin kullanıcı oturumu, kimlik doğrulama, e-posta gönderimi gibi) eklentiler ve temalar tarafından “geçersiz kılınabilir” yapıdadır. WordPress bu esnekliği pluggable fonksiyonlarla sağlar. Eğer bir eklenti veya tema yanlış yerde/yanlış zamanda çıktı üretirse ya da PHP kapanış etiketinden sonra boşluk basarsa, pluggable.php dosyasında görünen bir hata zinciri oluşur. Yani hata mesajı seni pluggable.php’ye işaret eder ama kök sebep çoğu zaman başka bir dosyadadır.

Bu hataların en sık görülen tipi “Cannot redeclare function …” veya “Headers already sent” türüdür. Birincisi genelde aynı fonksiyonun iki kez tanımlanmasından çıkar. Örneğin bir eklenti, WordPress’in pluggable fonksiyonlarını yanlış şekilde yeniden tanımlar; başka bir eklenti de aynı şeyi yapar; sonuçta PHP “bu fonksiyon zaten var” diye patlar. İkincisi ise daha klasik ve daha sinir bozucudur: herhangi bir dosyada, özellikle wp-config.php veya functions.php gibi dosyalarda, PHP’nin kapanış etiketinden sonra boşluk, boş satır veya görünmeyen bir karakter (BOM) kalır. PHP bu boşluğu çıktı olarak kabul eder; çıktı başladıktan sonra WordPress header gönderemez ve pluggable.php üzerinden hata verir. Sen bunu WordPress Hata sanarsın ama sebep bir tane gereksiz boşluktur. Bu yüzden teşhiste hata mesajındaki “satır numarası” kadar, “hangi dosya çıktı üretti” kısmı çok önemlidir.

Bu tür WordPress Hata vakalarında doğru yöntem, hata mesajını kelimesi kelimesine takip etmektir. Hata ekranında genellikle şuna benzer bir ifade olur: “… pluggable.php on line X” ve hemen üstünde veya altında “output started at /path/to/something.php:line Y” gibi bir ipucu verir. Asıl hedef “output started at” kısmıdır. Çünkü boşluğu veya çıktıyı başlatan dosya odur. pluggable.php sadece zincirin kırıldığı yerdir. Eğer bu ipucunu görmezden gelirsen, saatlerce yanlış dosyayla uğraşırsın ve aynı WordPress Hata tekrar eder.

En pratik başlangıç hamlesi, son yaptığın değişikliği geri almaktır. Bu hatalar çoğu zaman bir güncellemeden, yeni bir eklentiden, temaya eklenen bir kod parçacığından veya wp-config.php’ye elle eklenen bir satırdan sonra ortaya çıkar. Geleneksel ve akıllı yönetim şudur: son değişikliği geri al, sistem ayağa kalksın, sonra kontrollü tekrar uygula. Çünkü sistem çalışmıyorken “ince ayar” yapmaya çalışmak, kör dövüşe döner. Panel açılmıyorsa eklentiyi FTP/SFTP ile devre dışı bırakmak burada çok işe yarar. wp-content/plugins içindeki ilgili eklenti klasörünün adını değiştirmen bile çoğu zaman yeterlidir; WordPress o eklentiyi yüklemez ve WordPress Hata kesilebilir.

Boşluk ve BOM meselesi özellikle wp-config.php ve functions.php dosyalarında çok görülür. Bir dosyada kapanış PHP etiketi varsa (?>) ve ondan sonra boşluk varsa problem çıkabilir. WordPress projelerinde genel iyi uygulama şudur: PHP dosyalarının sonunda kapanış etiketi kullanmamak. Böylece istemeden boşluk basma riski kalmaz. Eğer functions.php dosyanda kapanış etiketi varsa ve ondan sonra boşluk/satır varsa, kaldırmak çoğu zaman bu WordPress Hata zincirini bitirir. Aynı şey wp-config.php için de geçerlidir: dosyanın başında <?php’den önce hiçbir karakter olmayacak, sonunda da mümkünse kapanış etiketi olmayacak.

Eğer hata “Cannot redeclare” gibi bir şeyse, burada suçlu çoğu zaman bir eklentidir. Özellikle eski veya agresif şekilde “core override” yapan eklentiler pluggable fonksiyonları yanlış kullanabilir. Bu durumda çözüm genellikle o eklentiyi güncellemek, alternatifini kullanmak veya geliştiriciyle görüşmektir. Çünkü çekirdeğin bu kısmına müdahale eden WordPress bileşenleri düzgün yazılmamışsa, aynı WordPress Hata tekrar eder. Burada yumuşatmaya gerek yok: kötü yazılmış eklentiyle site yönetilmez; değiştirmen gerekir.

Teşhis için debug log da çok faydalıdır. Canlı sitede hatayı ekrana basmak yerine, loglamak daha güvenlidir. wp-config.php’ye aşağıdaki ayarları ekleyip hata detaylarını wp-content/debug.log içine alırsın. Bu, pluggable.php etrafındaki hatalarda “asıl dosya neresi” sorusunu daha net görmeni sağlar. Sorunu çözdükten sonra debug’ı kapatmak da disiplinin parçasıdır.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

pluggable.php hataları, çoğu zaman çekirdeğin bozulması değil; bir eklenti/tema dosyasının yanlış çıktı üretmesi, gereksiz boşluk/BOM bırakması veya fonksiyonları hatalı şekilde yeniden tanımlamasıdır. Hata mesajındaki “output started at” kısmını hedef al, son değişikliği geri al, sorunlu eklentiyi FTP ile devre dışı bırak, wp-config.php ve functions.php içinde kapanış etiketi/boşluk/BOM temizliği yap, gerekirse eklentiyi değiştir. Bu adımlarla ilerlersen, pluggable.php kaynaklı WordPress Hata görüntüsü kalıcı şekilde kapanır ve tekrar tekrar aynı noktaya düşmezsin.

WordPress Dosyaları Bozuk Sorunu Nedir?

WordPress dosyaları bozuk dendiğinde, çekirdek dosyaların veya sitenin çalışması için kritik bazı dosyaların eksik, değişmiş, kısmen yüklenmiş ya da erişilemez hale gelmesi anlaşılır. Kullanıcı açısından bu durum çoğu zaman WordPress Hata gibi yaşanır: site açılmaz, admin paneli yarım gelir, bazı sayfalar 500 verir, garip PHP hataları çıkar veya birdenbire “dosya bulunamadı” şikâyetleri başlar. Buradaki kritik gerçek şudur: WordPress’in dosya yapısı düzenli ve tutarlıdır; sistem stabil çalışıyorsa, dosyalar da tutarlı duruyor demektir. Dosyalar bozulduğunda, WordPress her yerde farklı davranış sergileyebilir. Yani sorun tek bir yerde patlamaz; oradan buradan belirtiler verir. Bu yüzden teşhis “hangi dosya bozuldu” seviyesine inmeden, rastgele eklenti kapatmak veya temayı değiştirmek çoğu zaman oyalamadır.

Dosyaların bozulmasına yol açan sebepler pratikte birkaç başlıkta toplanır. En yaygını başarısız güncellemedir: WordPress çekirdeği güncellenirken bağlantı kesilir, disk dolar, izin sorunu olur ve bazı dosyalar yarım kalır. İkinci sık sebep yanlış FTP yüklemesidir: dosyalar “binary/ascii” karışır, transfer yarıda kesilir, bazı klasörler eksik kalır. Üçüncü sebep barizdir: saldırı veya kötü niyetli müdahale. Zararlı yazılım bazı dosyaları değiştirir, gizli arka kapılar ekler veya sistem dosyalarını bozar. Dördüncü sebep disk ve dosya sistemi problemleridir: bozuk sektör, inode sorunları, anlık IO hataları dosyaların tutarlılığını bozar. Beşinci sebep ise “temizlik” adı altında yanlış dosya silmektir. wp-includes veya wp-admin gibi çekirdek klasörlerinden bir şey silinirse, WordPress Hata zinciri kaçınılmaz olur.

Bu problemin doğru çözümü, önce riski azaltmak, sonra sağlam parçaları yerine koymaktır. En güvenli ve geleneksel yöntem yedekten geri dönmektir. Çünkü yedek, hem çekirdeği hem içeriği hem de yapılandırmayı tutarlı bir noktaya taşır. Eğer elinde yakın tarihli ve güvenilir bir yedek varsa, dosya bozulmasında en kısa yol budur. Yedek yoksa veya geri dönüş istemiyorsan, ikinci sağlam yöntem WordPress çekirdek dosyalarını yeniden yüklemektir. Burada önemli nokta: wp-content klasörüne dokunmadan, sadece çekirdek klasörlerini yenilersin. Çünkü wp-content içinde temalar, eklentiler ve uploads var; orası sitenin “içeriği”dir. Çekirdeği yenileyerek WordPress Hata kaynaklı bozuk dosya riskini azaltırsın, içerik durur.

Çekirdek dosyalarını yenilemenin en temiz yolu WP-CLI’dir. SSH erişimin varsa, WordPress çekirdeğini indirip doğrulamak ve bozuk dosyaları yeniden yazdırmak çok kolaydır. Bu yöntem, dosyaları el ile sürükle bırak yapmaktan daha düzenlidir ve hata payı düşüktür. Aşağıdaki komutlar, çekirdek dosyalarını yeniden indirip üstüne yazar; wp-content’a dokunmaz. Bu sayede WordPress Hata üreten çekirdek bozulmaları hızlıca toparlanabilir.

wp core download --force

WP-CLI yoksa, manuel yöntem devreye girer: WordPress’in aynı sürümünü indirirsin, bilgisayarında açarsın, sonra wp-admin ve wp-includes klasörlerini ve kökteki çekirdek PHP dosyalarını sunucuya yüklersin. Burada kritik disiplin şudur: wp-config.php ve wp-content’a dokunma. Çünkü wp-config.php veritabanı bilgilerini içerir, wp-content ise tüm içeriğini taşır. Bu iki şey değişirse yeni WordPress Hata çıkar. Yani çekirdeği değiştirirken “sadece çekirdek” kuralına sadık kalmak şarttır.

Bozulmanın saldırı kaynaklı olma ihtimali de her zaman düşünülmelidir. Çünkü saldırganın değiştirdiği dosyaları sen çekirdeği yenileyerek kısmen temizleyebilirsin ama asıl arka kapı wp-content içinde bir yere gizlenmiş olabilir. Bu nedenle dosya bozulması yaşadıysan, en azından basit bir kontrol yapmalısın: Son günlerde şüpheli bir kullanıcı eklendi mi, admin parolaları değişmiş mi, wp-content altında alakasız PHP dosyaları var mı, uploads içinde PHP dosyası bulunuyor mu, bilinmeyen cron işleri var mı? Bunlar varsa, konu artık “bozuk dosya” değil “temizleme” konusudur. WordPress Hata çözmek için çekirdeği yenilersin ama saldırı sürüyorsa yine bozulur. Bu yüzden güvenlik katmanını ihmal etmek, sorunu sürekli geri getirir.

Dosya izinleri de bu tabloda önemli yer tutar. Dosyalar bozuk gibi görünüyorsa bazen aslında bozuk değildir; web sunucusu okuma izni olmadığı için “erişilemiyor” görünür. Bu durumda 403, 500 veya karışık hatalar görürsün. Yani WordPress Hata sandığın şey, izin/sahiplik sorunu da olabilir. Özellikle taşıma sonrası sahiplik karışması çok olur. Dosyaların doğru izinlerde olması (genelde klasör 755, dosya 644) temel standarttır ama sahiplik düzeltmeden tek başına yeterli olmayabilir.

WordPress dosyaları bozuk sorunu, çoğu zaman başarısız güncelleme, yarım FTP transferi, disk sorunları veya saldırı nedeniyle ortaya çıkar. En güvenli çözüm yedekten geri dönmektir. Yedek yoksa çekirdeği wp core download –force ile yenilemek veya manuel olarak wp-admin/wp-includes ve çekirdek dosyaları değiştirmek işe yarar; wp-content ve wp-config.php’ye dokunma kuralına sadık kal. Ardından güvenlik olasılığını kontrol et ve izin/sahiplik düzenini doğrula. Bu disiplinle ilerlersen, dosya bozulması kaynaklı WordPress Hata döngüsü kapanır ve site tekrar stabil hale gelir.

Chrome’da Güvenli Değil Uyarısı Sorunu Nedir?

Chrome adres çubuğunda sitenin yanında “Güvenli Değil” yazıyorsa, bu tarayıcının “bu siteyle kurduğum bağlantı şifreli değil veya güvenlik beklentilerini karşılamıyor” demesidir. Kullanıcı bunu gördüğünde güveni düşer, form doldurmaz, ödeme yapmaz, hatta siteyi terk eder. Site sahibi açısından bu durum net bir WordPress Hata gibi hissedilir; çünkü “site çalışıyor ama itibar gidiyor” demektir. Fakat bu uyarı çoğu zaman WordPress’in içindeki bir ayardan değil, HTTPS/SSL katmanının eksik veya yanlış yapılandırılmasından kaynaklanır. Yani çözümün odağı WordPress panelinde değil; sertifika, yönlendirme, içerik ve tarayıcı güvenlik beklentilerindedir.

En temel sebep şudur: Site HTTP üzerinden açılıyordur. Bu durumda tarayıcı bağlantıyı şifrelemez ve “Güvenli Değil” gösterir. Bazen de site HTTPS açılır ama sertifika yanlış kurulduğu için tarayıcı güvenemez; bu durumda daha sert uyarılar çıkar. Bir başka sık sebep, HTTPS açık olsa bile sayfada karışık içerik olmasıdır: yani sayfa HTTPS, ama bazı kaynaklar HTTP’den geliyor. Chrome bu durumda kilidi bozabilir ve kullanıcıya güvenlik sinyali düşebilir. Bu da yine WordPress Hata gibi görünür çünkü “SSL var ama uyarı var” dersin. Ancak tarayıcının mantığı nettir: “tamamı güvenli değilse, ben tam güvenli demem.”

İlk adım, sitenin gerçekten HTTPS üzerinden düzgün çalıştığını kanıtlamaktır. Bu hem sertifikanın geçerli olması hem de doğru alan adını kapsaması demektir. “www” ve “www’suz” alan adı karışıklığı burada çok tipiktir. Sertifika sadece birini kapsıyorsa, diğerine giden kullanıcı uyarı görür. Bu yüzden tek bir kanonik yapı seçilir ve herkes oraya yönlendirilir. Bu disiplin kurulmadıkça, Chrome’daki “Güvenli Değil” uyarısı bir WordPress Hata gibi sürekli geri gelir.

WordPress tarafında, Home ve Site URL değerlerinin HTTPS olması kritik bir temeldir. Eğer WordPress hâlâ http:// link üretiyorsa, tarayıcı karışık içerik veya yönlendirme döngüsü gibi başka sorunlar da çıkarabilir. Panelden yapabiliyorsan Ayarlar > Genel’den iki URL’yi HTTPS’e çekersin. Panel erişimi yoksa wp-config.php üzerinden sabitlemek en pratik ve sağlam yöntemdir. Bu sabitleme, WordPress’in kendi ürettiği bağlantıları düzgünleştirir ve WordPress Hata gibi görünen birçok SSL yan etkisini azaltır.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

İkinci adım, zorunlu HTTPS yönlendirmesidir. Yani http:// ile gelen herkesin otomatik https://’ye gitmesi gerekir. Bu yönlendirme sunucuda (Nginx/Apache) yapılır, bazen de CDN/WAF üzerinde yapılır. Eğer yönlendirme yoksa kullanıcı HTTP’ye düşer ve Chrome “Güvenli Değil” der. Eğer yönlendirme yanlışsa, bu sefer yönlendirme döngüsü çıkar ve başka bir WordPress Hata daha üretirsin. Yani yönlendirme işi de disiplin ister: tek kural, tek hedef.

Üçüncü adım, karışık içerik kontrolüdür. Bu konu sandığından daha sık çıkar. Site HTTPS’ye geçmiştir ama içerikte eski http:// görsel linkleri vardır, tema bir fontu HTTP’den çağırıyordur, bir eklenti harici scripti HTTP’den yüklüyordur. Chrome bu durumda güvenlik sinyalini düşürür. Burada çözüm, sayfanın hangi kaynakları HTTP’den çektiğini tarayıcı konsolundan görmek ve bunları HTTPS’e çevirmektir. Alan adı değişimi veya HTTP→HTTPS geçişi yaptıysan, veritabanında güvenli bir search-replace yapmak da gerekir. Bu işlem serileştirilmiş veriyi bozmadan yapılmalıdır; WP-CLI erişimi varsa bu iş çok temiz olur.

wp search-replace 'http://alanadiniz.com' 'https://alanadiniz.com' --all-tables

Bir başka nokta da sertifika türü ve güncelliğidir. Sertifika süresi dolduysa, ara sertifikalar eksikse veya sunucu TLS yapılandırması zayıfsa Chrome uyarı vermeye başlar. Son yıllarda tarayıcılar eski protokollere daha sert davranıyor. Bu yüzden sunucunun TLS 1.2 ve TLS 1.3 ile düzgün çalışması gerekir. Bu bir WordPress ayarı değildir; hosting katmanıdır. Hosting paneli veya destek ekibiyle çözülür. Bu gerçeği kabul etmeden sadece WordPress içinde dönüp durursan, “Güvenli Değil” uyarısı yine geri gelir ve sen tekrar WordPress Hata diye uğraşırsın.

Son olarak, bazı sayfalarda özel olarak uyarı çıkıyorsa (örneğin giriş, ödeme, form sayfası), o sayfada gömülü HTTP kaynakları olma ihtimali yükselir. Bazen bir form eklentisi reCAPTCHA’yı yanlış çağırır, bazen bir ödeme eklentisi harici scripti HTTP’den ister. Bu tip durumlarda “sitede SSL var ama sadece şu sayfada uyarı var” diye gelinir. Çözüm aynı: sayfa kaynaklarını kontrol et, HTTP çağrıları temizle, cache/CDN temizliği yap, sonra tarayıcıda tekrar test et.

Chrome’daki “Güvenli Değil” uyarısı WordPress Hata gibi görünse de çoğunlukla SSL/HTTPS disiplininin eksik olmasından çıkar. Sertifika geçerli olacak, kanonik alan adı seçilecek, http→https yönlendirmesi sağlam olacak, WordPress URL’leri HTTPS olacak, karışık içerik temizlenecek ve sunucu TLS modern tutulacak. Bu zinciri kurarsan uyarı biter, kullanıcı güveni geri gelir ve “itibar kaybı” gibi en pahalı WordPress Hata etkisini de ortadan kaldırmış olursun.

Bağlantınız Gizli Değil Tarayıcı Hatası Nedir?

Chrome’da “Bağlantınız gizli değil” sayfası çıkıyorsa, tarayıcı sana açıkça şunu söylüyordur: “Bu siteyle kurduğum HTTPS bağlantısına güvenemiyorum.” Kullanıcı tarafında bu, en ağır güvenlik uyarılarından biridir ve çoğu kişi geri döner. Site sahibi açısından da tam bir WordPress Hata gibi görünür; çünkü site açılmıyor, trafik düşüyor, iş duruyor. Fakat bu hata neredeyse her zaman WordPress’in içinden değil, SSL/TLS tarafındaki bir problemden kaynaklanır. Yani çözüm; sertifika, alan adı, sertifika zinciri, sunucu zamanı, TLS ayarları ve bazen de CDN/WAF gibi aracı katmanlar üzerindedir. WordPress panelinde eklenti kapatarak bu ekranı düzeltmeyi beklemek, yanlış yerde arama yapmak olur.

Bu hatanın en sık nedeni, sertifikanın geçersiz olmasıdır. Sertifikanın süresi dolmuş olabilir, yanlış alan adına verilmiş olabilir, wildcard/SAN kapsamı doğru olmayabilir veya sertifika zinciri eksik olabilir. Özellikle zincir (intermediate) eksikliği çok yaygındır: Sertifikayı kurarsın ama ara sertifikaları doğru eklemezsin; bazı tarayıcılar tolere eder, bazıları “hayır” der. İkinci yaygın neden, alan adı uyuşmazlığıdır. Sertifika “alanadiniz.com” için geçerlidir ama kullanıcı “www.alanadiniz.com” ile geliyor olabilir. Sertifika iki alanı da kapsamıyorsa Chrome bu uyarıyı patlatır. Üçüncü neden, sunucunun tarih/saat ayarının bozuk olmasıdır. Sertifika aslında geçerlidir ama sunucu saati yanlış olduğu için tarayıcı “bu sertifika daha geçerli değil / süresi geçmiş” zannedebilir. Dördüncü neden, eski TLS yapılandırması veya zayıf cipher setidir. Beşinci neden de araya giren güvenlik katmanlarıdır: bazı antivirüs/proxy sistemleri HTTPS trafiğini “kırıp” kendi sertifikasını enjekte eder; tarayıcı bunu tanımayınca uyarı çıkar. Sen bunu WordPress Hata sanarsın ama aslında istemci ortamıdır.

Teşhiste doğru yaklaşım, uyarı ekranında görünen hata koduna bakmaktır. Chrome genelde altta bir kod gösterir: NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_AUTHORITY_INVALID gibi. Bu kod, sorunun sınıfını netleştirir. Tarih invalid ise saat/sertifika süresi konuşulur. Common name invalid ise alan adı uyuşmazlığı konuşulur. Authority invalid ise zincir/CA problemi konuşulur. Bu kodu görmezden gelirsen, çözümü şansa bırakırsın ve aynı WordPress Hata döngüsü uzar. Burada iyi yönetim, kodu görüp doğrudan hedefe gitmektir.

Sunucu tarafını kanıtlamak için en sağlam testlerden biri, openssl ile sertifika zincirini ve TLS el sıkışmasını kontrol etmektir. SSH erişimin varsa, aşağıdaki komutla sunucunun gerçekte hangi sertifikayı sunduğunu görürsün. Burada özellikle “Certificate chain” kısmı ve “Verify return code” satırı önemlidir. Zincir eksikse veya doğrulama hatası varsa, WordPress’in içinde ne yaparsan yap bu uyarı bitmez. Çünkü tarayıcı siteye daha girmeden kapıyı kapatır.

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com

Çözüm adımları pratik ve nettir. Sertifika süresi dolduysa yenilemek gerekir. Let’s Encrypt kullanıyorsan otomatik yenileme çalışmıyor olabilir; cron veya panel ayarı bozulmuş olabilir. Alan adı uyuşmazlığı varsa, iki alan adını da kapsayan sertifika alınmalı veya yönlendirmeler sertifikanın kapsadığı kanonik alana bağlanmalıdır. Zincir eksikse, hosting panelinde “CA bundle / intermediate certificate” kısmına doğru zincir eklenmelidir. Sunucu saati yanlışsa NTP ile düzeltilmelidir. TLS eskiyse, sunucu TLS 1.2/1.3’e çekilmelidir. Bunlar doğrudan WordPress Hata değil, hosting yönetim işidir; gerektiğinde hosting desteğine bunu net biçimde iletmek gerekir.

WordPress tarafında yapılacaklar ise daha çok “yan etkileri” temizler. Örneğin site HTTPS’e geçtiyse ama WordPress URL’leri hâlâ HTTP ise, tarayıcıya farklı senaryolarda karışık içerik çıkar. Bu, “Gizli değil” kadar ağır değil ama güven sinyalini bozar. Bu yüzden WordPress’in Home ve SiteURL değerleri HTTPS olmalıdır. Panel erişimi yoksa wp-config.php üzerinden sabitlemek, gereksiz yönlendirme karmaşasını azaltır ve WordPress Hata gibi görünen ikincil sorunların önünü keser.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Bir de şu gerçeği unutma: CDN kullanıyorsan, sertifika CDN’de olabilir ve origin (asıl sunucu) ile CDN arasındaki SSL ayarı yanlış olabilir. Örneğin CDN “Full (Strict)” ister ama origin’de geçersiz sertifika vardır; bu durumda kullanıcıda uyarı olmasa bile sitenin bazı bölümleri patlar. Ya da tam tersi, CDN yanlış yapılandırılmıştır ve kullanıcıya sertifika uyarısı verir. Bu katmanı kontrol etmeden sadece WordPress’e bakarsan, WordPress Hata sandığın şey bir türlü bitmez. Çünkü asıl hata, WordPress’in önünde duran kapıdadır.

“Bağlantınız gizli değil” uyarısı, WordPress Hata gibi görünse de büyük ölçüde SSL/TLS doğrulama problemidir. Hata kodunu gör, sertifika süresini ve alan adı kapsamını doğrula, zinciri eksiksiz kur, sunucu saatini düzelt, TLS’i modern tut, CDN/WAF varsa ayarlarını kontrol et. WordPress tarafında da URL’leri HTTPS’e sabitleyip karışık içerik riskini azalt. Bu adımlar tamamlanınca tarayıcı uyarısı kalkar; çünkü tarayıcı artık siteye güvenebilir hale gelir.

ERR_TOO_MANY_REDIRECTS Sorunu Nedir?

ERR_TOO_MANY_REDIRECTS hatası, tarayıcının bir sayfaya ulaşmak isterken sürekli başka bir adrese yönlendirilmesi ve sonunda “ben bu döngüden çıkamıyorum” diyerek vazgeçmesidir. Kullanıcı bunu genelde “site açılmıyor” diye görür; site sahibi ise bunu tipik bir WordPress Hata diye yaşar çünkü bazen sadece ana sayfa değil, giriş sayfası dahil her yer kilitlenir. Fakat işin özünde bu hata, yanlış yapılandırılmış yönlendirme mantığıdır. Yani bir URL diğerine gidiyor, o da tekrar baştakine dönüyor veya HTTPS/HTTP, www/www’suz, CDN/origin arasında ping-pong yapıyordur. WordPress “yönlendir”, sunucu “yönlendir”, CDN “yönlendir” derken herkes aynı anda direksiyona asılır ve araba duvara girer.

Bu sorunun en klasik sebebi HTTP ile HTTPS’in birbirini döngüye sokmasıdır. Örneğin WordPress ayarlarında site URL’si https’tir ama sunucu tarafında da ayrıca bir yönlendirme kuralı vardır ve bu kural, tersine veya yanlış koşulla çalışır. Ya da CDN HTTPS’i terminate eder ama origin’e HTTP gönderir; WordPress bunu “ben HTTPS istiyorum” diye tekrar HTTPS’e yönlendirir; CDN tekrar origin’e gönderir… döngü oluşur. İkinci klasik sebep www karmaşasıdır: WordPress www’lu, sunucu www’suz zorluyordur veya tam tersi. Üçüncü sebep cache ve çerezlerdir: Tarayıcı eski yönlendirme bilgisini tutar, sen düzeltmiş olsan bile kullanıcıda hata devam eder. Dördüncü sebep eklentilerdir: SSL zorlayan, yönlendirme yöneten veya güvenlik amaçlı URL değiştiren eklentiler yanlış yapılandırılırsa döngü çıkar. Bu yüzden ERR_TOO_MANY_REDIRECTS bir WordPress Hata gibi görünse de çoğu zaman “birden fazla yerde aynı işi yapma” problemidir.

İlk hızlı çözüm, tarayıcı tarafındaki çerez ve cache’i temizlemektir. Çünkü yönlendirme döngüleri bazen cookie tabanlı koşullara bağlıdır; özellikle giriş/oturum sayfalarında bu çok görülür. Kullanıcıya “çerezleri temizle” demek bazen sorunu anında çözer. Ama bu sadece semptomu geçici olarak kesebilir. Kalıcı çözüm için yönlendirmeyi nerede yaptığını netleştirmen gerekir. Yani WordPress mi yönlendiriyor, sunucu mu, yoksa CDN mi? Bunu bilmeden yapılan her hamle, yeni bir WordPress Hata üretme riski taşır.

Teşhiste en pratik yöntem, tek bir kanonik yapı seçmektir: HTTPS mi olacak? Evet. www’lu mu www’suz mu? Birini seç. Sonra yönlendirmeyi sadece tek katmanda uygula. Benim tavrım net: yönlendirme işini mümkünse sunucu veya CDN katmanında tek yerden yönetmek daha temizdir. WordPress’e bir şey bırakacaksan, sadece URL değerlerinin tutarlı olmasıdır. WordPress’in Home ve SiteURL değerleri, seçtiğin kanonik yapıyla birebir aynı olmalıdır. Bunu panelden düzeltebilirsin; panel açılmıyorsa wp-config.php ile sabitlemek en hızlı ve garantili yoldur. Bu adım, ERR_TOO_MANY_REDIRECTS gibi WordPress Hata görüntülerinde çok işe yarar çünkü WordPress’in kendi yönlendirme mantığını sakinleştirir.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Sunucu tarafında .htaccess veya Nginx kurallarıyla hem HTTPS’e hem de www düzenine yönlendirme yapıyorsan, bu kuralların birbirini tetiklemediğinden emin olmalısın. Aynı anda hem “www ekle” hem “https’e zorla” kuralını yanlış sırada veya yanlış koşulla yazarsan, döngü üretirsin. CDN kullanıyorsan da benzer mantık geçerlidir: CDN’de “Always Use HTTPS” açıkken origin’de de bir yönlendirme kuralı varsa, bazı senaryolarda döngüye girersin. Burada kural şu: aynı işi iki yerde yapma. Çünkü çift kontrol, çift hata üretir. Bu, WordPress Hata dünyasında en klasik tuzaktır.

Eklenti tarafı da ihmal edilmemeli. Özellikle SSL zorlayan eklentiler, cache eklentileri, güvenlik eklentileri veya “login URL değiştirici” eklentiler yönlendirme döngüsü çıkarabilir. Bu durumda en hızlı teşhis, eklentileri geçici olarak devre dışı bırakmaktır. Panel açılmıyorsa FTP/SFTP ile wp-content/plugins klasörünün adını geçici değiştirerek tüm eklentileri devreden çıkarabilirsin. Eğer döngü kesilirse, sorun eklenti kaynaklıdır. Sonra eklentileri tek tek açıp hangisinin WordPress Hata ürettiğini yakalarsın. Bu yöntem sıkıcıdır ama en sağlamdır; çünkü kanıt üretir.

Bir de şu pratik detay var: WordPress’in “Giriş sayfası sürekli yenileniyor” gibi sorunları da bazen yönlendirme döngüsünün başka bir yüzüdür. Çünkü cookie set edilemez, domain uyuşmaz, HTTPS zorlaması çakışır ve kullanıcı login olamaz. Yani ERR_TOO_MANY_REDIRECTS sadece ana sayfa hatası değildir; site genelinde zincirleme etki yaratabilir. Bu yüzden kanonik URL disiplinini kurmak ve yönlendirmeyi tek katmana indirmek, uzun vadede çok daha az WordPress Hata yaşatır.

ERR_TOO_MANY_REDIRECTS, yönlendirme döngüsüdür ve genelde HTTP/HTTPS, www/www’suz veya CDN/origin çakışmasından çıkar. Tarayıcı çerezlerini temizlemek kısa vadede yardımcı olabilir ama kalıcı çöz_

ERR_TOO_MANY_REDIRECTS Sorunu Nedir?

ERR_TOO_MANY_REDIRECTS hatası, tarayıcının bir sayfaya ulaşmak isterken sürekli başka bir adrese yönlendirilmesi ve sonunda “ben bu döngüden çıkamıyorum” diyerek vazgeçmesidir. Kullanıcı bunu genelde “site açılmıyor” diye görür; site sahibi ise bunu tipik bir WordPress Hata diye yaşar çünkü bazen sadece ana sayfa değil, giriş sayfası dahil her yer kilitlenir. Fakat işin özünde bu hata, yanlış yapılandırılmış yönlendirme mantığıdır. Yani bir URL diğerine gidiyor, o da tekrar baştakine dönüyor veya HTTPS/HTTP, www/www’suz, CDN/origin arasında ping-pong yapıyordur. WordPress “yönlendir”, sunucu “yönlendir”, CDN “yönlendir” derken herkes aynı anda direksiyona asılır ve araba duvara girer.

Bu sorunun en klasik sebebi HTTP ile HTTPS’in birbirini döngüye sokmasıdır. Örneğin WordPress ayarlarında site URL’si https’tir ama sunucu tarafında da ayrıca bir yönlendirme kuralı vardır ve bu kural, tersine veya yanlış koşulla çalışır. Ya da CDN HTTPS’i terminate eder ama origin’e HTTP gönderir; WordPress bunu “ben HTTPS istiyorum” diye tekrar HTTPS’e yönlendirir; CDN tekrar origin’e gönderir… döngü oluşur. İkinci klasik sebep www karmaşasıdır: WordPress www’lu, sunucu www’suz zorluyordur veya tam tersi. Üçüncü sebep cache ve çerezlerdir: Tarayıcı eski yönlendirme bilgisini tutar, sen düzeltmiş olsan bile kullanıcıda hata devam eder. Dördüncü sebep eklentilerdir: SSL zorlayan, yönlendirme yöneten veya güvenlik amaçlı URL değiştiren eklentiler yanlış yapılandırılırsa döngü çıkar. Bu yüzden ERR_TOO_MANY_REDIRECTS bir WordPress Hata gibi görünse de çoğu zaman “birden fazla yerde aynı işi yapma” problemidir.

İlk hızlı çözüm, tarayıcı tarafındaki çerez ve cache’i temizlemektir. Çünkü yönlendirme döngüleri bazen cookie tabanlı koşullara bağlıdır; özellikle giriş/oturum sayfalarında bu çok görülür. Kullanıcıya “çerezleri temizle” demek bazen sorunu anında çözer. Ama bu sadece semptomu geçici olarak kesebilir. Kalıcı çözüm için yönlendirmeyi nerede yaptığını netleştirmen gerekir. Yani WordPress mi yönlendiriyor, sunucu mu, yoksa CDN mi? Bunu bilmeden yapılan her hamle, yeni bir WordPress Hata üretme riski taşır.

Teşhiste en pratik yöntem, tek bir kanonik yapı seçmektir: HTTPS mi olacak? Evet. www’lu mu www’suz mu? Birini seç. Sonra yönlendirmeyi sadece tek katmanda uygula. Benim tavrım net: yönlendirme işini mümkünse sunucu veya CDN katmanında tek yerden yönetmek daha temizdir. WordPress’e bir şey bırakacaksan, sadece URL değerlerinin tutarlı olmasıdır. WordPress’in Home ve SiteURL değerleri, seçtiğin kanonik yapıyla birebir aynı olmalıdır. Bunu panelden düzeltebilirsin; panel açılmıyorsa wp-config.php ile sabitlemek en hızlı ve garantili yoldur. Bu adım, ERR_TOO_MANY_REDIRECTS gibi WordPress Hata görüntülerinde çok işe yarar çünkü WordPress’in kendi yönlendirme mantığını sakinleştirir.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Sunucu tarafında .htaccess veya Nginx kurallarıyla hem HTTPS’e hem de www düzenine yönlendirme yapıyorsan, bu kuralların birbirini tetiklemediğinden emin olmalısın. Aynı anda hem “www ekle” hem “https’e zorla” kuralını yanlış sırada veya yanlış koşulla yazarsan, döngü üretirsin. CDN kullanıyorsan da benzer mantık geçerlidir: CDN’de “Always Use HTTPS” açıkken origin’de de bir yönlendirme kuralı varsa, bazı senaryolarda döngüye girersin. Burada kural şu: aynı işi iki yerde yapma. Çünkü çift kontrol, çift hata üretir. Bu, WordPress Hata dünyasında en klasik tuzaktır.

Eklenti tarafı da ihmal edilmemeli. Özellikle SSL zorlayan eklentiler, cache eklentileri, güvenlik eklentileri veya “login URL değiştirici” eklentiler yönlendirme döngüsü çıkarabilir. Bu durumda en hızlı teşhis, eklentileri geçici olarak devre dışı bırakmaktır. Panel açılmıyorsa FTP/SFTP ile wp-content/plugins klasörünün adını geçici değiştirerek tüm eklentileri devreden çıkarabilirsin. Eğer döngü kesilirse, sorun eklenti kaynaklıdır. Sonra eklentileri tek tek açıp hangisinin WordPress Hata ürettiğini yakalarsın. Bu yöntem sıkıcıdır ama en sağlamdır; çünkü kanıt üretir.

Bir de şu pratik detay var: WordPress’in “Giriş sayfası sürekli yenileniyor” gibi sorunları da bazen yönlendirme döngüsünün başka bir yüzüdür. Çünkü cookie set edilemez, domain uyuşmaz, HTTPS zorlaması çakışır ve kullanıcı login olamaz. Yani ERR_TOO_MANY_REDIRECTS sadece ana sayfa hatası değildir; site genelinde zincirleme etki yaratabilir. Bu yüzden kanonik URL disiplinini kurmak ve yönlendirmeyi tek katmana indirmek, uzun vadede çok daha az WordPress Hata yaşatır.

ERR_TOO_MANY_REDIRECTS, yönlendirme döngüsüdür ve genelde HTTP/HTTPS, www/www’suz veya CDN/origin çakışmasından çıkar. Tarayıcı çerezlerini temizlemek kısa vadede yardımcı olabilir ama kalıcı çözüm; tek bir kanonik URL seçmek, WordPress URL’lerini onunla eşitlemek, yönlendirmeyi sadece tek katmanda yapmak ve yönlendirme eklentilerini kontrol etmektir. Bu disiplin kurulduğunda bu WordPress Hata tamamen biter ve site stabil hale gelir.

ERR_CONNECTION_REFUSED Sorunu Nedir?

ERR_CONNECTION_REFUSED hatası, tarayıcının sunucuya bağlanmak istediğini ama sunucunun bağlantıyı “reddettiğini” ifade eder. Kullanıcı için bu, “site açılmıyor” demektir. Site sahibi içinse genellikle panik bir WordPress Hata gibi görünür; çünkü WordPress ekranını bile göremezsin. Fakat burada önemli gerçek şudur: Bu hata çoğu zaman WordPress’le bile ilgili değildir. Tarayıcı daha WordPress dosyalarına ulaşmadan, ağ ve sunucu katmanında engellenir. Yani WordPress’i kurcalayarak çözülecek bir şey değildir; önce sunucuya neden bağlanılamadığını netleştirmek gerekir.

Bu hatanın sık sebepleri nettir. Birincisi sunucu kapalıdır veya web sunucusu (Nginx/Apache) çalışmıyordur. İkincisi yanlış port konuşuluyordur: 80/443 kapalıdır veya güvenlik duvarı bu portları engelliyordur. Üçüncüsü IP bazlı engeldir: güvenlik eklentisi, WAF, CDN veya sunucu firewall’u senin IP’ni veya kullanıcıların IP’lerini bloklamıştır. Dördüncüsü DNS yanlış yönleniyordur: alan adı yanlış IP’ye gidiyordur ve o IP’de web servisi yoktur; bu durumda bağlanmaya çalışınca “refused” alırsın. Beşincisi, hosting tarafında geçici bir arıza veya bakım vardır. Yani bu WordPress Hata gibi görünse de çoğu zaman “WordPress’e gelene kadar” yaşanan bir bağlantı problemidir.

İlk pratik kontrol, sorunun herkeste mi yoksa sende mi olduğudur. Aynı siteyi farklı internetten (mobil hotspot gibi) dene veya farklı bir cihazdan aç. Eğer sadece sende oluyorsa, IP engeli, DNS cache veya tarayıcı/proxy/VPN sorunu ihtimali yükselir. Eğer herkeste oluyorsa, sunucu tarafı daha olasıdır. Bu ayrım, gereksiz WordPress Hata arayışını keser ve seni doğru katmana götürür. Ayrıca VPN kullanıyorsan kapatıp denemek de önemlidir; bazı sunucular VPN IP’lerini direkt engeller.

İkinci pratik kontrol DNS’tir. Alan adı doğru IP’ye mi gidiyor? Eğer yeni taşıma yaptıysan, DNS hâlâ eski sunucuya gidiyor olabilir. Bu durumda eski sunucuda servis kapalıysa “connection refused” görürsün. DNS değişimlerinde yerel DNS cache de yanıltıcı olur. Bu yüzden DNS’i farklı bir resolver ile kontrol etmek gerekir. Eğer alan adı yanlış IP’ye gidiyorsa, WordPress tarafında ne yaparsan yap sonuç değişmez; çünkü kullanıcı WordPress’e hiç ulaşamıyordur.

Üçüncü kontrol, sunucu portlarının açık olup olmadığıdır. Eğer SSH erişimin varsa, sunucuda Nginx/Apache çalışıyor mu bakarsın. Paylaşımlı hostingde panelden “service status” görürsün. CDN kullanıyorsan, CDN ile origin arasında bağlantı kopmuş olabilir. Ayrıca firewall kuralı yanlışsa, 443 portu kapalı kalabilir. Bu durumda tarayıcı siteye bağlanamaz ve WordPress Hata diye bir ekran göremezsin; çünkü ortada WordPress’e giden trafik yoktur.

Bazen bu hata güvenlik katmanlarından gelir. Örneğin yanlış yapılandırılmış bir güvenlik eklentisi veya sunucu firewall’u “çok fazla istek” gördüğünde bağlantıyı tamamen reddedebilir. Bu da kullanıcılarda ERR_CONNECTION_REFUSED olarak görünür. CDN/WAF kullanıyorsan, oradaki güvenlik kurallarını kontrol etmek gerekir. IP engeli varsa, whitelist eklemek veya kuralları yumuşatmak gerekir. Bu noktada şunu açık söyleyeyim: aşırı agresif güvenlik ayarı, WordPress Hata diye kullanıcı kaybettirir. Güvenlik gerekli ama ölçüsüz olursa siteyi kendin kilitlersin.

İstemci tarafında da olası sebepler vardır. Kullanıcının virüs koruması, kurumsal proxy, DNS filtreleme veya tarayıcı eklentileri bağlantıyı engelleyebilir. Bu yüzden kullanıcı şikâyet ediyorsa, onlara kısa bir kontrol listesi verirsin: router’ı yeniden başlat, tarayıcı cache’i temizle, VPN/proxy kapat, farklı tarayıcı dene, DNS’i sıfırla. Bu öneriler bazen sorunu çözer. Ancak sen site sahibiysen ve hata çoğunlukla herkeste görünüyorsa, burada vakit kaybetme; hosting tarafına odaklan.

Kalıcı çözüm, sebebe bağlıdır ama rota nettir: Önce DNS’in doğru IP’ye gittiğini doğrula. Sonra sunucuda web servisinin çalıştığını ve 80/443 portlarının açık olduğunu doğrula. Ardından firewall/WAF/CDN engellerini kontrol et. Eğer hosting kaynaklı kesinti varsa, destekle konuşup servis durumunu netleştir. Bu adımları izlersen ERR_CONNECTION_REFUSED gibi WordPress Hata sanılan durumların çoğunu hızlıca kapatırsın. Çünkü sorun WordPress’te değil, WordPress’e giden yolun kapanmasındadır.

ERR_EMPTY_RESPONSE Sorunu Nedir?

ERR_EMPTY_RESPONSE hatası, tarayıcının sunucuya istek gönderdiğini ama sunucudan “hiç yanıt” alamadığını söyler. Yani bağlantı kuruluyor gibi olur, fakat sayfa içeriği dönmez; tarayıcı bekler, sonra vazgeçer. Kullanıcı bunu “site boş dönüyor” diye anlatır; site sahibi ise doğal olarak WordPress Hata diye düşünür. Fakat bu hata, WordPress’in kendi içindeki bir mesaj değildir; tarayıcının ağ katmanında gördüğü bir davranıştır. Bu nedenle çözüm, WordPress’e dalmadan önce ağ, sunucu yanıtı, güvenlik katmanı ve kaynak tüketimi gibi daha geniş resmi kontrol etmeyi gerektirir.

Bu hatanın sık nedenlerinden biri, sunucunun anlık olarak “boğulması”dır. Yüksek trafik, saldırı, ağır sorgular veya yetersiz kaynak yüzünden web sunucusu bağlantıyı alır ama yanıtı tamamlayamaz. Bu durumda tarayıcıya veri akmaz ve ERR_EMPTY_RESPONSE görürsün. İkinci yaygın neden, güvenlik duvarı veya WAF’ın bağlantıyı sessizce kesmesidir. Bazı güvenlik kuralları 403 vermek yerine bağlantıyı kapatır; tarayıcı bunu “boş yanıt” olarak yorumlar. Üçüncü sebep, CDN ile origin arasındaki kopmalardır. CDN istek alır, origin’den düzgün yanıt alamaz, bazı senaryolarda kullanıcıya boş yanıt gibi bir sonuç döner. Dördüncü sebep DNS veya ağ istikrarsızlığıdır; paket kaybı varsa tarayıcı sanki yanıt gelmiyormuş gibi davranır. Beşinci sebep de istemci tarafındaki proxy/VPN veya antivirüs yazılımının bağlantıyı bozmasıdır. Yani bu WordPress Hata gibi görünse de “yalnızca WordPress” bakışıyla çözülmesi zor bir sınıftır.

İlk pratik adım, sorunun tekrarlanabilir olup olmadığını görmek ve kapsamını belirlemektir. Sadece sen mi görüyorsun, yoksa herkes mi? Farklı ağdan (mobil hotspot gibi) dene. Eğer sadece sende çıkıyorsa, tarayıcı uzantıları, VPN/proxy veya antivirüs yazılımı ihtimali yükselir. Herkeste çıkıyorsa, sunucu tarafı ihtimali yükselir. Bu ayrımı yapmadan WordPress Hata diye eklenti söküp takmak, gereksiz risk yaratır.

İkinci adım, basit bir HTTP kontrolüdür. Eğer erişimin varsa, komut satırından curl ile yanıt başlıklarını görmek çok işe yarar. Burada amaç, sunucunun bir HTTP kodu döndürüp döndürmediğini görmek. Eğer hiç kod yoksa, bağlantı kesiliyordur. Eğer 200 dönüyor ama tarayıcı boş görüyorsa, arada başka bir katman olabilir. Bu test, WordPress Hata teşhisinde “sunucu gerçekten cevap veriyor mu” sorusunu netleştirir.

curl -I https://alanadiniz.com

Sunucu tarafında en sık karşılaşılan neden kaynak tüketimidir. WordPress tarafında ağır eklentiler, kötü optimize edilmiş tema, devasa görseller, gereksiz sorgular sunucuyu zorlar. Sunucu zorlanınca bazen 500 verir, bazen 503 verir, bazen de bağlantıyı kapatır ve tarayıcı ERR_EMPTY_RESPONSE görür. Bu yüzden sunucu hata logları ve kaynak kullanımı (CPU/RAM) burada ana delildir. Hosting panelinde “error logs” veya “resource usage” varsa kontrol et. Eğer loglarda time-out, upstream reset, worker limit gibi şeyler görüyorsan mesele WordPress’in bir fonksiyonu değil; sunucunun taşıyamaması demektir. Bu da WordPress Hata gibi görünen ama altyapı kaynaklı bir durumdur.

WAF/CDN tarafını da unutmamak gerekir. Özellikle güvenlik ayarları agresifse, bazı istekleri sessizce düşürür. Örneğin belirli user-agent’ları, belirli query string’leri veya belirli hızda gelen istekleri aniden kesebilir. Bu durumda tarayıcı “boş yanıt” görür. CDN kullanıyorsan CDN loglarına bakmak veya geçici olarak CDN’i bypass edip origin’den test etmek gerekir. Eğer CDN bypass testinde sorun yoksa, WordPress Hata değil CDN kuralı konuşulur. Eğer origin’de de aynıysa, sunucu/WordPress kaynak tüketimi konuşulur.

İstemci tarafında çözüm önerileri, kullanıcı şikâyetlerinde pratik olur: tarayıcı cache temizle, uzantıları kapat, VPN/proxy kapat, DNS’i temizle, router’ı yeniden başlat. Bu öneriler bazen gerçekten sorunu çözer. Ama sen site sahibisin ve sorun herkeste görünüyorsa, burada vakit kaybetme; sunucu ve güvenlik katmanına odaklan. Çünkü “herkeste boş yanıt” bir WordPress Hata gibi görünse de çoğunlukla sunucu yanıt üretme zinciri kopmuştur.

Kalıcı çözüm, sebebe göre ilerler: Sunucu kaynak yetersizse optimizasyon yaparsın (cache, görsel optimizasyonu, gereksiz eklenti azaltma, sorgu iyileştirme) veya planı yükseltirsin. WAF/CDN kuralı problemliyse kuralı düzeltirsin, yanlış blokları kaldırırsın. Ağ/DNS istikrarsızsa DNS sağlayıcısını ve TTL ayarlarını gözden geçirirsin. Bu adımlarla ERR_EMPTY_RESPONSE gibi WordPress Hata sanılan ama aslında “yanıt üretme” problemine dönüşen durumları kontrol altına alırsın.

DNS_PROBE_FINISHED_NXDOMAIN Sorunu Nedir?

DNS_PROBE_FINISHED_NXDOMAIN hatası, tarayıcının alan adını bir IP adresine çeviremediğini söyler. Yani kullanıcı “siteye gitmek istiyorum” der, tarayıcı DNS’e sorar, DNS “bu alan adı yok” (NXDOMAIN) diye yanıt verir. Bu yüzden WordPress ekranına bile gelemezsin; WordPress çalışsa da çalışmasa da fark etmez. Buna rağmen kullanıcılar bunu yine de WordPress Hata gibi anlatır, çünkü onların gözünde “site benim WordPress sitem” ve “açılmıyor”. Burada net konuşmak gerekir: NXDOMAIN bir WordPress hatası değildir, DNS çözümleme hatasıdır. Çözüm alan adı ve DNS kayıtları üzerindedir.

Bu hatanın en sık sebepleri şunlardır: Alan adı yanlış yazılmıştır (en basiti ama çok olur). Domain süresi dolmuştur veya registrar tarafında pasife düşmüştür. DNS sunucuları yanlış ayarlanmıştır (nameserver değişmiş, yanlış nameserver girilmiş). A kaydı veya CNAME kaydı silinmiştir ya da yanlış yapılandırılmıştır. Yeni DNS değişikliği yapıldıysa henüz yayılmamıştır (propagation). Son olarak, kullanıcı tarafında DNS cache bozulmuş veya kullandığı DNS sunucusu problemli olabilir. Görüldüğü gibi bu, WordPress Hata diye çözülmez; WordPress’e dokunmak sadece vakit kaybıdır.

İlk pratik adım, alan adını doğru yazdığını kanıtlamaktır. Bir harf hatası bile NXDOMAIN üretir. Sonra domainin aktif olup olmadığını kontrol edersin: registrar panelinde “expired” veya “suspended” gibi bir durum var mı? Domain düşmüşse, WordPress’te hiçbir ayar bunu düzeltmez. Domain aktifse, ikinci adım nameserver kontrolüdür. Domain hangi nameserver’ları kullanıyor? Bu nameserver’lar doğru DNS sağlayıcısına mı işaret ediyor? Özellikle taşımadan sonra nameserver yanlış kalırsa, DNS kayıtların bir yerde durur ama domain başka yere bakar ve NXDOMAIN görürsün. Bu senaryo, WordPress Hata sanılan en klasik DNS kazalarındandır.

Üçüncü adım DNS kayıtlarıdır. Siteyi bir sunucuya bağlıyorsan genelde A kaydı gerekir: alanadiniz.com → sunucu IP. www için de ya ayrı A kaydı ya da CNAME gerekir. Eğer bu kayıtlar yoksa veya yanlışsa, DNS çözümleme olmaz. Burada dikkat edilmesi gereken disiplin: tek bir doğru kaynak. Aynı alan adı için farklı DNS sağlayıcılarında farklı kayıtlar tutarsan, bir yerde doğru görünür, diğerinde NXDOMAIN alırsın. İnsanlar da “WordPress Hata yine” diye çıldırır. Oysa sorun, DNS yönetiminin dağınık olmasıdır.

Kullanıcı tarafında da olabilecek bir şey var: DNS cache. Bazen sen DNS’i düzeltirsin ama kullanıcı hâlâ eski bilgiyi tutar. Bu durumda kullanıcıya DNS önbelleğini temizlemesini söylemek gerekir. Windows’ta ipconfig /flushdns, macOS’ta dscacheutil gibi yöntemler var. Tarayıcıyı kapatıp açmak, router’ı yeniden başlatmak da bazen işe yarar. Ayrıca kullanıcı farklı DNS kullanıyorsa (kurumsal DNS, VPN DNS), o DNS’in güncellenmesi gecikebilir. Bu yüzden “bende açılıyor, onda açılmıyor” senaryosunda DNS cache konusu çok önemlidir. Bu durum WordPress Hata değil, internetin çalışma şeklidir.

Pratik bir test, dnslookup/dig ile DNS çözümlemesine bakmaktır. Eğer A kaydı dönmüyorsa veya NXDOMAIN dönüyorsa, sorun netleşir. Bu testler, “WordPress mi, DNS mi?” tartışmasını bitirir. Çünkü DNS çözülmüyorsa, WordPress hiç devreye girmiyordur.

nslookup alanadiniz.com

Domainin aktif olduğundan emin ol, doğru nameserver’ları gir, DNS sağlayıcında A/CNAME kayıtlarını doğru oluştur, TTL ayarlarını makul tut ve DNS değişikliği yaptıysan yayılım süresini hesaba kat (bazı durumlarda saatler sürebilir). Kullanıcı hâlâ NXDOMAIN görüyorsa, DNS cache temizliği ve farklı ağdan test öner. Bu adımlarla DNS_PROBE_FINISHED_NXDOMAIN gibi WordPress Hata sanılan ama aslında DNS kaynaklı problemleri hızlı ve temiz şekilde kapatırsın.

WordPress Beyaz Ekran Hatası Nedir?

WordPress Beyaz Ekran Hatası, sitenin açıldığında hiçbir içerik göstermeden tamamen beyaz bir sayfa vermesi durumudur. Bu problem bazen sadece ön yüzde görülür, bazen de yönetim panelini de kilitler. Kullanıcı için çok nettir: “site çöktü.” Site sahibi açısından da tipik bir WordPress Hata senaryosudur çünkü ortada hata mesajı yoktur; sadece boşluk vardır. Bu sessizlik, sorunu daha sinir bozucu yapar. Aslında beyaz sayfa “hata yok” demek değildir; çoğu zaman PHP fatal hata, bellek sınırı, bozuk dosya veya çakışma vardır ama hata ekrana basılmadığı için sen sadece beyaz ekran görürsün. Yani burada yapılması gereken şey tahmin yürütmek değil, hatayı görünür ve takip edilebilir hale getirmektir.

Bu sorunun en sık kaynağı eklenti çakışmalarıdır. Yeni bir eklenti yükledikten sonra, bir güncelleme yaptıktan sonra veya iki eklenti aynı fonksiyona farklı şekilde müdahale ettiğinde beyaz ekran başlayabilir. Özellikle performans, güvenlik, cache ve sayfa oluşturucu eklentileri bu konuda daha risklidir; çünkü sistemin çekirdeğine yakın yerlerde çalışırlar. Aynı şekilde tema kaynaklı hatalar da çok yaygındır. Tema dosyasında küçük bir PHP hatası, yanlış bir fonksiyon çağrısı veya eksik bir dosya, sayfanın tamamen boş dönmesine yol açabilir. Bu yüzden “beyaz ekran gördüm” dediğinde ilk refleksin, en son neyi değiştirdiğine bakmak olmalı. Çünkü çoğu WordPress Hata böyle çıkar: yeni eklenen bir parça, sistemin dengesini bozar.

Bir diğer klasik sebep bellek sınırıdır. WordPress bazı işlemlerde (özellikle admin panelindeki ağır ekranlar, büyük sorgular, yoğun içerikli sayfalar) daha fazla bellek kullanır. PHP’nin bellek limiti dolduğunda işlem kesilir ve beyaz ekran oluşabilir. Bu durumda bazen loglarda “Allowed memory size exhausted” gibi bir mesaj yakalarsın. Ama ekranda hiçbir şey göremeyebilirsin. Bu yüzden hatayı görünür yapmak şarttır. Canlı sitede hataları ekrana basmak güvenli değildir; doğru yöntem, hataları log dosyasına yazdırmaktır. Böylece WordPress Hata “gizli bir hayalet” olmaktan çıkar, somut bir kayda dönüşür.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Yukarıdaki ayarlar wp-config.php içine eklendiğinde, hatalar genellikle wp-content/debug.log dosyasına düşer. Beyaz ekran çıktığında, debug.log içinde hangi dosyanın patladığını görürsün. Bu dosya adı sana doğrudan hedef verir: problem bir eklenti mi, tema mı, çekirdek mi? Örneğin bir eklenti dosyası görünüyorsa, en hızlı test o eklentiyi devre dışı bırakmaktır. Panel açılmıyorsa FTP/SFTP ile wp-content/plugins klasörünün adını geçici olarak değiştirmen bile yeterlidir. WordPress eklentileri göremez ve hepsini devreden çıkarır. Site açılırsa, sorun eklentidedir. Sonra eklentileri tek tek açarak hangi eklentinin WordPress Hata ürettiğini net yakalarsın. Bu yöntem biraz zahmetlidir ama en güvenilir yöntemdir çünkü tahmin değil, kanıtla ilerlersin.

Eklentilerden değilse sıradaki hedef temadır. Tema kaynaklı beyaz ekranı test etmek için aktif temanın klasör adını değiştirirsin; WordPress otomatik olarak varsayılan bir temaya (kuruluysa) düşer. Site açılırsa, tema kaynaklı WordPress Hata kesinleşir. Bu durumda temayı güncellemek, çocuk tema düzenini kontrol etmek veya tema dosyalarındaki hatalı kodu düzeltmek gerekir. Tema dosyalarında yapılan “küçük bir ekleme” bile (örneğin functions.php’ye eklenen bir kod parçası) siteyi beyaza düşürebilir. Bu yüzden tema üzerinde değişiklik yaparken her zaman yedek ve kontrollü ilerlemek gerekir.

Bellek ihtimali güçlüyse, limit artırma bir test adımı olarak kullanılabilir. Ancak burada sert konuşacağım: bellek artırmak çoğu zaman semptomu saklar; asıl problem bir eklentinin veya temanın gereksiz yere şişmesi olabilir. Yine de hızlı test için wp-config.php içine aşağıdaki satırı ekleyip gözlem yapmak işe yarar. Eğer sorun çözülürse, sistemin kaynak tüketimini optimize etmen gerekir; aksi halde WordPress Hata farklı biçimde yeniden geri döner.

define('WP_MEMORY_LIMIT', '256M');

Son olarak cache katmanlarını unutma. Sunucu cache’i, CDN cache’i veya WordPress cache eklentisi bozulmuş bir çıktı döndürebilir. Bu durumda tüm cache’i temizlemek iyi bir testtir. Fakat cache temizleyince düzeliyorsa, cache’i bozan değişikliği (eklenti güncellemesi, tema düzeni, minify ayarı) bulmadan rahat etme; yoksa aynı WordPress Hata tekrar eder. Özetle: Beyaz ekran, görünmeyen bir arızanın işaretidir. Log ile görünür hale getir, eklenti ve tema testleriyle kaynağı izole et, bellek ve cache gibi yan faktörleri kontrol et. Bu disiplinle ilerlediğinde WordPress Beyaz Ekran Hatası “korku filmi” olmaktan çıkar, çözülebilir bir bakım işine dönüşür.

WordPress Yönetici Paneline Erişim Engellendi Sorunu Nedir?

Yönetici paneline girememek, WordPress tarafındaki en can sıkıcı durumlardan biridir. Çünkü panel yoksa kontrol yoktur: eklenti kapatamazsın, tema değiştiremezsin, ayar düzeltemezsin, güncelleme yapamazsın. Kullanıcıların çoğu bunu doğrudan WordPress Hata diye yaşar; çünkü “site var ama yönetemiyorum” demektir. Bu sorun bazen “403 Forbidden”, bazen “Bu sayfaya erişmenize izin verilmiyor”, bazen giriş ekranında takılı kalma, bazen de sürekli yönlendirme şeklinde görünür. Sebep tek değildir; güvenlik eklentisi, yanlış izinler, bozuk .htaccess, yanlış URL ayarı, kullanıcı rolü bozulması, saldırı tespiti veya cache/cookie karmaşası bu kilitlenmeyi doğurabilir. Bu yüzden doğru yaklaşım, panik değil; sistematik teşhistir.

İlk adım şudur: Panel erişimi engeli “kimden” geliyor? Sunucudan mı geliyor (403 gibi), WordPress’ten mi geliyor (izin mesajları), yoksa tarayıcı/oturum kaynaklı mı? Eğer 403 görüyorsan, bu çoğu zaman web sunucusu veya güvenlik katmanıdır: .htaccess kuralı, Nginx kuralı, WAF, CDN kuralı veya IP engeli devreye girmiş olabilir. Bu durumda WordPress’e bile girmeden kapı kapanır. Eğer “Bu sayfaya erişmenize izin verilmiyor” gibi WordPress içi mesaj görüyorsan, o zaman rol/kapasite sorunları veya güvenlik eklentisinin WordPress içinden koyduğu kısıtlar daha olasıdır. Bu ayrımı yapmadan yapılan her hamle, yanlış yere dokunmaya ve yeni WordPress Hata üretmeye çok açıktır.

En yaygın senaryolardan biri güvenlik eklentisidir. Özellikle brute force koruması, login URL gizleme, IP ban, iki faktör doğrulama veya firewall modülleri, yanlış ayarlanırsa seni de kilitler. Bu durumda en hızlı ve en temiz test, ilgili güvenlik eklentisini devre dışı bırakmaktır. Panel açılmıyorsa FTP/SFTP ile wp-content/plugins klasörüne girip güvenlik eklentisinin klasör adını değiştirirsin. WordPress o eklentiyi yüklemez. Eğer panel açıldıysa, WordPress Hata gibi görünen kilitlenmenin sebebi eklentidir. Bundan sonra işi düzgün yapmak gerekir: eklentiyi ya doğru ayarlarsın ya da daha uyumlu bir alternatifle değiştirirsin. Kötü yapılandırılmış güvenlik, güvenlik sağlamaz; siteyi içeriden kilitler.

Bir diğer sık sebep .htaccess bozulmasıdır (Apache kullanan sistemlerde). Yanlış bir yönlendirme kuralı, yanlış yetkilendirme kuralı veya panel dizinine konmuş bir kısıt, wp-admin erişimini kesebilir. Bu durumda pratik test şudur: .htaccess dosyasını geçici olarak yeniden adlandırırsın (örneğin .htaccess_old). Eğer panel açılırsa, sorun .htaccess kurallarındadır. Sonra WordPress’in kendi “kalıcı bağlantılar” ayarından temiz bir .htaccess yeniden oluşturursun. Bu yaklaşım yıllardır değişmeyen, eski usul ama garantili bir yöntemdir. Çünkü WordPress Hata gibi görünen birçok erişim sorunu, tek bir bozuk kuraldan çıkar.

URL uyuşmazlığı da panel erişimini kilitleyebilir. WordPress Adresi ve Site Adresi farklıysa (www’lu / www’suz veya http / https karışmışsa) login olur gibi olur ama geri atar, sürekli yeniler veya admin’e giremezsin. Bu durumda paneli açamıyorsan wp-config.php üzerinden URL’leri sabitlemek en pratik çözümdür. Bu adım, yönlendirme ve oturum cookie alanı gibi kritik noktaları düzeltir ve WordPress Hata gibi görünen “admin’e giremiyorum” döngüsünü sıkça bitirir.

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

Bir başka ciddi ihtimal, kullanıcı rolünün bozulmasıdır. Bazen phpMyAdmin üzerinden yanlış rol atanır, bazen bir eklenti rol tablolarını değiştirir, bazen de veritabanında wp_capabilities kaydı bozulur. Sonuç: Admin hesabın var ama yetkin yok. WordPress buna “erişemezsiniz” diye yanıt verir. Bu durumda çözüm veritabanı üzerinden rolün düzeltilmesidir. Bu iş dikkat ister; rastgele değişiklik yaparsan daha büyük WordPress Hata çıkarırsın. Doğru yöntem, sağlam bir admin hesabın capabilities değerini doğrulamak ve gerekiyorsa başka bir admin hesabı oluşturup erişimi geri kazanmaktır.

Cache ve cookie konusu da küçümsenmemeli. Özellikle login sayfası cache’lenirse veya güvenlik eklentileriyle çakışan bir cookie durumu olursa, admin paneline girişte saçma döngüler oluşur. Bu durumda tarayıcı çerezlerini temizlemek, gizli sekmede denemek, farklı tarayıcı denemek basit ama etkili testtir. Ancak bu sadece “kullanıcı tarafı”dır. Sorun herkeste oluyorsa, asıl kaynak yine sunucu kuralları, URL uyumsuzluğu veya eklentidir. Yani WordPress Hata teşhisinde “bende oldu düzeldi” ile “herkeste var” ayrımını mutlaka yap.

Yönetici paneline erişim engeli, WordPress Hata gibi görünse de çoğunlukla güvenlik eklentisi, .htaccess/Nginx kuralları, yanlış URL yapılandırması, IP engeli veya rol/capabilities bozulmasından çıkar. En pratik rota şudur: güvenlik eklentisini FTP ile devre dışı bırakıp test et, .htaccess’i geçici kaldırıp test et, URL’leri wp-config.php ile sabitle, sonra rol yetkilerini kontrol et. Bu zinciri düzgün uygularsan panel erişimini geri alır ve tekrar kilitlenmemesi için sistemi daha sağlam bir düzene oturtursun.

SSH veya SFTP Üzerinden Bağlantı Kurulamıyor Sorunu Nedir?

SSH veya SFTP ile sunucuya bağlanamamak, WordPress yönetiminde eli kolu bağlayan bir durumdur. Çünkü panel kilitlenince veya dosya müdahalesi gerekince en güvenli yol çoğu zaman SFTP/SSH olur. Bağlantı kurulamıyorsa, site tarafında yaşadığın bir WordPress Hata durumunu düzeltmek bile zorlaşır. Burada net bir gerçeği kabul etmek gerekir: SSH/SFTP problemi, WordPress’in içinden çıkan bir hata değildir. Bu tamamen sunucu erişimi, güvenlik ve ağ yapılandırmasıdır. WordPress dosyaları düzgün olsa bile, port kapalıysa, IP’n bloklandıysa veya kimlik bilgilerin yanlışsa erişemezsin.

Bu sorunun en sık nedeni, yanlış kimlik bilgileri ve yanlış port kullanımıdır. SFTP genelde 22 portunu kullanır ama bazı sistemlerde güvenlik için port değiştirilmiştir. Hosting sağlayıcın SFTP için 2222, 2200 gibi bir port tanımlamış olabilir. Aynı şekilde SSH da 22’den farklı bir portta çalışıyor olabilir. Kullanıcı adı da kritik: bazen “root” ile bağlanamazsın, sadece belirli bir kullanıcıyla bağlanırsın. Bir de klasik hata: FTP ile SFTP karıştırılır. FTP ayrı protokol, SFTP ayrı protokoldür. FileZilla gibi araçlarda protokol seçimi yanlışsa bağlantı kurulmaz. Sen bunu WordPress Hata gibi yaşarsın ama aslında “yanlış protokol” meselesidir.

İkinci büyük sebep firewall ve IP engelidir. Birçok hosting, brute force denemelerine karşı SSH/SFTP portlarını sıkı tutar. Çok fazla yanlış deneme yaptıysan IP’n otomatik ban yemiş olabilir. Kurumsal ağlar da bazen 22 portunu dışarı kapatır. Bu durumda ev internetinden bağlanamazsın ama mobil hotspot ile bağlanırsın. Böyle bir test, sorunun “sunucu mu, benim ağım mı” ayrımını netleştirir. Eğer farklı ağdan bağlanınca açılıyorsa, sorun büyük olasılıkla yerel ağ kısıtı veya IP ban’dır. Bu durumda WordPress Hata aramak boştur; erişimi düzeltmek gerekir.

Üçüncü sık sebep known_hosts çatışmasıdır. Özellikle daha önce bağlandığın bir IP’ye sunucu yeniden kurulmuşsa veya IP değişmişse, SSH “ben bu anahtarı tanımıyorum” diye bağlantıyı reddedebilir. Bu durumda kullanıcı “bağlanamıyorum” der. Çözüm, local makinadaki known_hosts kaydını temizlemektir. Bu durum WordPress Hata değildir; güvenlik önlemidir. Ancak sunucu değişikliklerinde çok sık yaşandığı için klasikleşmiştir. Windows kullanıyorsan PuTTY/WinSCP tarafında da benzer “host key changed” uyarıları çıkar.

Bir diğer önemli sebep, sunucuda SSH servisinin kapalı olmasıdır. Bazı paylaşımlı hosting paketlerinde SSH hiç açılmaz; sadece SFTP vardır veya sadece FTP vardır. Bazı sağlayıcılar SSH’yi sadece isteyene açar. VPS’de ise SSH servisi çökmüş olabilir. Bu durumda bağlantı hiç kurulmaz. Burada yapılacak iş, hosting panelinden SSH erişiminin aktif olduğundan emin olmak veya destek ekibine “SSH/SFTP erişimi aktif mi, hangi port, hangi kullanıcı” diye net sormaktır. Bu konuşma, WordPress Hata değil; altyapı prosedürüdür.

Teşhis için pratik bir yaklaşım: önce SFTP/SSH bilgilerinin doğruluğunu kontrol et (host, kullanıcı, şifre/anahtar, port). Sonra farklı ağdan dene. Sonra firewall/IP ban ihtimalini düşün. Eğer “host key changed” gibi bir uyarı varsa, known_hosts kaydını temizle. Eğer hiçbir şekilde bağlanamıyorsan, muhtemelen port kapalıdır veya servis yoktur; hosting desteği şart olur. Bu adımları izlersen “WordPress bozuldu” sanıp yanlış yere saldırmazsın. Çünkü WordPress Hata çözmek istiyorsan önce sunucuya erişebilmen gerekir; erişim yoksa çözüm de yoktur.

Son olarak, SSH ile bağlanma işini düzene sokmak uzun vadede sana rahat ettirir. Çünkü WordPress yönetiminde panik anlarında paneli beklemek yerine, dosyaya/log’a anında erişirsin. Bu da WordPress Hata süreçlerini hızlandırır. Eski usul ama sağlam bir alışkanlıktır: erişim kanallarını düzgün kur, sonra WordPress’in derdini çöz.

SSH Bağlantısı Reddedildi Sorunu Nedir?

SSH ile bağlanmaya çalıştığında “Connection refused” (bağlantı reddedildi) mesajı alıyorsan, bu mesajın anlamı nettir: Sunucuya istek gidiyor ama hedef portta SSH servisi seni karşılamıyor. Yani “kimlik bilgisi yanlış” seviyesine bile gelmemişsindir; daha kapıdan içeri giremeden geri çevrilmişsindir. Bu nedenle bunu WordPress Hata gibi görüp WordPress tarafında kurcalamak boş iştir. Çünkü SSH reddi, WordPress’ten bağımsız bir sunucu erişim problemidir. WordPress dosyaları ister sağlam olsun ister bozuk olsun; SSH servisi yoksa, port kapalıysa veya firewall engelliyorsa bağlanamazsın.

Bu hatanın en sık nedeni yanlış porttur. SSH varsayılan olarak 22 portunu kullanır ama birçok sistemde güvenlik için port değiştirilir. Sen 22’ye bağlanırken sunucu 2222’den dinliyor olabilir. Bazı hosting sağlayıcıları da bu portu müşteriden müşteriye farklı ayarlar. İkinci sık sebep, SSH servisinin kapalı olmasıdır. Paylaşımlı hosting paketlerinde SSH hiç sunulmayabilir veya panelden aktif edilmesi gerekebilir. VPS tarafında ise servis durmuş olabilir. Üçüncü sebep firewall’dur. Sunucu tarafındaki firewall 22’yi kapatmış olabilir ya da sadece belirli IP’lere izin veriyordur. Dördüncü sebep, kurumsal ağ kısıtlarıdır: bazı şirket ağları 22 portunu dışarıya kapatır. Bu durumda evden bağlanırsın, iş yerinden bağlanamazsın. Bu ayrımı yapmadan “WordPress Hata çıktı” diye siteyi dağıtmak, gereksiz yıkımdır.

Teşhiste en pratik yol, portun gerçekten açık olup olmadığını kontrol etmektir. Eğer bir terminalin varsa, alan adının veya IP’nin 22 portuna erişilebilirliğini test edebilirsin. Windows’ta PowerShell ile, Linux/macOS’ta nc ile port kontrolü yapılır. Port kapalıysa, zaten “refused” veya “timeout” görürsün. Bu test, “sunucu SSH dinliyor mu” sorusunu netleştirir. SSH dinlemiyorsa, WordPress tarafında zaman kaybetme; önce erişimi düzelt.

nc -vz alanadiniz.com 22

Eğer port 22 kapalıysa, önce hosting panelinden SSH erişimi aktif mi kontrol et. Birçok yönetilen hostingde SSH kapalı gelir ve talep üzerine açılır. Eğer VPS ise, sunucuda SSH servisi çalışıyor mu bakmak gerekir; ama zaten SSH yoksa bunu uzaktan yapmak zor olabilir. Böyle durumlarda sağlayıcının “console” erişimi veya kurtarma modu devreye girer. Yani bu işin çözümü, WordPress’in değil altyapının prosedürüdür. Bu noktada net konuşayım: SSH erişimi kritikse, sağlayıcının sana konsol erişimi sunması şarttır; yoksa her WordPress Hata anında kör kalırsın.

Firewall tarafında IP kısıtı varsa, iki şekilde anlarsın: Evden bağlanamazsın ama mobil internetten bağlanırsın veya tam tersi. Böyle bir test çok değerlidir. Eğer IP ban ihtimali varsa, firewall logları veya güvenlik katmanları (fail2ban gibi) kontrol edilir. Bazı sistemler yanlış şifre denemelerinde IP’yi otomatik banlar. Bu durumda çözüm ya IP whitelist ya da ban kaldırmadır. Burada da WordPress Hata değil, güvenlik önlemi konuşuyoruz.

Yanlış host adresi de unutulmaz bir klasik hatadır. Bazıları alan adını değil yanlış IP’yi kullanır, bazıları “ssh.alanadiniz.com” gibi var olmayan bir hostname girer. Doğru host ve doğru port olmadan zaten bağlanamazsın. Bu yüzden geleneksel, düzgün yöntem şudur: sağlayıcının verdiği SSH bilgilerini birebir uygula, kafadan port uydurma, kafadan kullanıcı uydurma. Aksi halde her deneme yeni bir WordPress Hata gibi hissettirir ama aslında hatayı kendin üretmiş olursun.

“SSH bağlantısı reddedildi” demek, SSH servisinin o adreste/portta seni karşılamadığı demektir. En sık nedenler yanlış port, kapalı SSH servisi ve firewall engelidir. Portu test et, farklı ağdan dene, hosting panelinde SSH aktif mi kontrol et, firewall/IP ban olasılığını değerlendir. Bunları çözdüğünde WordPress Hata çözmek için elin güçlenir; çünkü artık sunucuya gerçek anlamda erişebilirsin.

Planlı Bakım Nedeniyle Kısa Süreliğine Hizmet Dışı Kalacaktır Mesajı Nedir?

“Planlı bakım nedeniyle kısa süreliğine kullanılamıyor. Bir dakika sonra tekrar kontrol edin.” mesajı, WordPress’in güncelleme sırasında siteyi geçici olarak bakım moduna almasıyla ortaya çıkar. Bu mesajı gören kullanıcılar genelde paniğe kapılır ve bunu bir WordPress Hata sanır; çünkü sayfa açılmıyor ve site kapalı görünüyor. Fakat burada ince bir ayrım var: Bu mesaj normal şartlarda birkaç saniye ile birkaç dakika arasında görünür ve güncelleme bittiğinde kendiliğinden kaybolur. Yani çoğu zaman bu bir hata değil, WordPress’in “güncelleme yapıyorum, bekle” demesidir. Ancak mesaj uzun süre kaybolmuyorsa, işte o zaman gerçekten sorun vardır: site bakım modunda takılı kalmıştır.

Bu mesajın çıkmasının sebebi, WordPress’in kök dizine .maintenance adlı küçük bir dosya oluşturmasıdır. Güncelleme başlar başlamaz bu dosya oluşur ve WordPress ziyaretçilere bakım mesajını gösterir. Güncelleme düzgün bittiğinde de WordPress bu dosyayı siler ve site normale döner. Sorun şu: Güncelleme yarıda kesilirse, tarayıcı kapanırsa, bağlantı koparsa, sunucu kaynakları yetmezse veya aynı anda çok sayıda eklenti toplu güncellenirse, WordPress bu dosyayı silemeden kalır. Sonuç: Site bakım modunda kilitlenir ve mesaj sürekli görünür. İşte bu noktada olay artık “normal süreç” değil, gerçek bir WordPress Hata senaryosudur.

İlk yapılacak iş, gerçekten güncelleme yapılıp yapılmadığını kontrol etmektir. Bazen kullanıcı bu mesajı görür ama aslında güncelleme bitmiştir; sadece cache bunu gösteriyordur. Bu nedenle önce tarayıcı cache temizleyip farklı tarayıcıda denemek basit ama değerli bir testtir. Eğer hâlâ görünüyorsa, ikinci adım .maintenance dosyasını kontrol etmektir. Bu dosya genellikle WordPress’in kurulu olduğu kök dizindedir (wp-config.php ile aynı seviyede). Dosya duruyorsa, WordPress seni bakım modunda tutar.

Çözüm pratik ve nettir: FTP/SFTP veya dosya yöneticisi (cPanel gibi) ile site kök dizinine girip .maintenance dosyasını silersin. Bu kadar. Çoğu durumda site anında normale döner. Bu müdahale, WordPress Hata gibi görünen bakım kilidini en hızlı şekilde açar. Ancak burada önemli bir disiplin var: Eğer sunucuda hâlâ güncelleme işlemi devam ediyorsa (örneğin arka planda paket açıyorsa), .maintenance dosyasını silmek işleri yarım bırakabilir. Bu yüzden genelde birkaç dakika beklenmiş ve hâlâ düzelmemiş senaryolarda silmek doğru hamledir. Senin sitende mesaj uzun süre kalıyorsa, beklemek yerine müdahale etmek daha doğrudur.

Bakım modunda takılmanın nedenini de düşünmek gerekir. Çünkü sadece .maintenance dosyasını silip geçersen, aynı WordPress Hata tekrar eder. Bu kilitlenme çoğu zaman sunucu kaynak yetersizliğinden çıkar: düşük PHP max_execution_time, düşük memory_limit, yavaş disk, çok sayıda eklentiyi aynı anda güncelleme. Ayrıca güvenlik eklentileri veya cache eklentileri de güncelleme sürecini zorlaştırabilir. Bu yüzden toplu güncelleme yerine tek tek güncelleme yapmak, özellikle ağır eklentilerde daha güvenlidir. Eski usul ama sağlam yaklaşım budur: büyük değişikliği parça parça yap ki sorun çıkarsa kaynağı net olsun.

Panel erişimin varsa, güncelleme ekranına bakıp hangi güncellemenin yarıda kaldığını görmek de faydalıdır. Bazen bir eklenti güncellemesi takılır ve siteyi kilitler. Bu durumda o eklentiyi manuel güncellemek veya geçici devre dışı bırakmak gerekebilir. Eğer güncelleme sırasında dosya izinleri sıkıntılıysa, WordPress dosyayı yazamaz ve süreç yarım kalır; bu da yine WordPress Hata üretir. Yani bakım kilidi “sonuç”, asıl sebep “güncellemenin tamamlanamaması”dır.

Bu mesaj kısa süre görünüyorsa normaldir. Uzun süre kalıyorsa WordPress bakım modunda takılı kalmıştır ve bu bir WordPress Hata durumudur. En hızlı çözüm kök dizindeki .maintenance dosyasını silmektir. Sonra tekrar yaşanmaması için güncellemeleri toplu değil kontrollü yapmak, sunucu limitlerini (bellek/zaman) uygun tutmak ve izin problemlerini çözmek gerekir. Bu disiplinle bakım kilidi bir daha başını kolay kolay kaldırmaz.

WordPress Bakım Modunda Takılı Kaldı Sorunu Nedir?

WordPress bakım modunda takılı kalma sorunu, sitenin güncelleme süreci bittikten sonra bile “bakım var” ekranından çıkamaması durumudur. Bir önceki mesajdaki bakım uyarısı normalde geçicidir; birkaç saniye ya da birkaç dakika görünür ve kaybolur. Fakat süreç yarıda kesilirse, sunucu bir noktada takılırsa veya WordPress güncelleme dosyasını temizleyemezse site kilitlenir. Kullanıcılar bunu doğrudan WordPress Hata diye görür; çünkü site resmen kapanmış gibidir. En sinir bozucu tarafı şudur: Yönetim paneline de çoğu zaman erişemezsin, yani içeriden düzelteyim deme şansın azalır. Bu yüzden burada hızlı, temiz ve risk almadan yapılacak bir müdahale gerekir.

Bu sorunun temel mantığı şudur: WordPress güncelleme başlattığında sitenin kök dizinine .maintenance adlı bir dosya bırakır. Bu dosya durduğu sürece WordPress ziyaretçilere bakım mesajını gösterir. Güncelleme düzgün tamamlanırsa WordPress dosyayı siler. Ama bağlantı koparsa, tarayıcı kapanırsa, güncelleme sırasında zaman aşımı olursa, disk dolarsa, izin sorunu olursa veya aynı anda çok fazla eklenti güncellenirse WordPress bu dosyayı silemeden kalabilir. Sonuç: bakım ekranı sürekli görünür. Yani sorun WordPress’in bakım özelliği değil; güncellemenin düzgün bitmemesi veya bitse bile temizlik adımının gerçekleşmemesidir. Bu yüzden çözümün kalbi, o “kilit” dosyasını ortadan kaldırmaktır.

En pratik çözüm: .maintenance dosyasını silmek. FTP/SFTP ile site kök dizinine girersin (wp-config.php ile aynı seviyedir) ve .maintenance dosyasını kaldırırsın. Dosya silindiği anda site çoğu zaman normale döner. Bu hamle yıllardır değişmeyen, klasik ama en güvenilir çözümdür. Çünkü WordPress Hata gibi görünen bakım kilidinin sebebi doğrudan o dosyadır. Dosya yoksa WordPress bakım modunu gösteremez. Eğer dosyayı göremiyorsan, FTP istemcinde gizli dosyaları göster seçeneğini açman gerekir; çünkü nokta ile başlayan dosyalar bazen gizli sayılır.

Bununla birlikte, sadece dosyayı silip geçmek her zaman yeterli olmaz. Çünkü sorun bazen güncellemenin yarım kalmış olmasından kaynaklanır. Yani bakım kilidini kaldırırsın ama site hâlâ hatalı dosyalarla çalışıyordur. Bu durumda farklı WordPress Hata belirtileri görebilirsin: 500 hatası, beyaz ekran, eklenti hataları gibi. Böyle bir senaryoda ikinci adım, yarım kalan güncellemeyi tamamlamak veya sorunlu eklentiyi manuel güncellemektir. Özellikle toplu güncelleme yaptıysan ve site bakımda kaldıysa, muhtemelen bir eklenti güncellemesi takılmıştır. Burada geleneksel ve güvenli yöntem, güncellemeleri toplu değil, kontrollü ve tek tek yapmaktır. Büyük değişiklikleri parça parça yapmak, WordPress yönetiminde yıllardır en az WordPress Hata üreten yaklaşımdır.

Bakım modunda takılmayı tetikleyen teknik limitler de çok önemlidir. PHP max_execution_time düşükse, büyük eklenti güncellemeleri yarıda kesilir. PHP memory_limit düşükse paket açma sırasında işlem biter. Disk doluysa dosyalar yazılamaz. İzinler yanlışsa WordPress dosyaları güncelleyemez. Bu yüzden tekrar yaşanmasın istiyorsan bu limitlere bakmak gerekir. “Sadece .maintenance’i silerim” yaklaşımı kısa vadede işi çözer ama sistemin altyapısı zayıfsa, aynı WordPress Hata yine gelir. Özellikle yoğun sitelerde bu konu çok tekrar eder.

Bir de cache/CDN katmanı varsa, bakım ekranı kaldırıldıktan sonra bile kullanıcılar hâlâ bakım mesajını görebilir. Bu durumda tüm cache’i temizlemek gerekir: WordPress cache eklentisi, sunucu cache’i ve varsa CDN cache’i. Çünkü bazı sistemler bakım sayfasını cache’ler. Sen düzelttim sanırsın ama ziyaretçi hâlâ “bakım var” görür. Bu da gereksiz WordPress Hata algısı yaratır. Bu yüzden bakım kilidi kalktıktan sonra mutlaka farklı cihazdan ve farklı ağdan kontrol etmek iyi bir alışkanlıktır.

WordPress bakım modunda takılı kaldı sorunu, güncelleme sonrası .maintenance dosyasının silinmemesiyle oluşur ve kullanıcıların gördüğü şey tam bir WordPress Hata gibi durur. En hızlı çözüm kök dizindeki .maintenance dosyasını silmektir. Ardından yarım kalan güncellemeler, sunucu limitleri (zaman/bellek/disk), izinler ve cache katmanları kontrol edilmelidir. Bu disiplinle ilerlersen bakım modunda takılma tekrar eden bir problem olmaktan çıkar.

Değişiklikler Canlı Sitenizde Görünmüyor Sorunu Nedir?

Bu problem, WordPress tarafında en çok “ben yaptım ama olmuyor” diye çıldırtan türdendir. İçerik güncellersin, bir renk değiştirirsin, menüyü düzenlersin, yeni bir yazı eklersin; yönetim panelinde her şey doğru görünür ama ön yüze baktığında eski hali duruyordur. Kullanıcıya “site aynı” görünür, sana ise bu tam bir WordPress Hata gibi gelir. Oysa çoğu zaman ortada bozuk bir kod yoktur; sorun, sitenin farklı katmanlarda önbelleklenmesidir. Yani sen değiştirirsin, ama ziyaretçiye hâlâ eski kopya servis edilir. WordPress’te modern performans kurulumları cache üzerine kuruludur; doğru yönetilmezse bu tarz “görünmüyor” şikâyeti kaçınılmaz olur.

Birinci ve en sık sebep tarayıcı önbelleğidir. Tarayıcı CSS/JS dosyalarını veya sayfa içeriğini cache’lemiş olabilir. Bu yüzden ilk test, sayfayı sert yenilemek (hard refresh) ve gizli sekmede bakmaktır. Eğer gizli sekmede düzeliyorsa, sorun büyük ihtimalle tarayıcı cache’idir. Kullanıcılara da aynı şekilde “cache temizle” diyebilirsin. Ancak bu sadece başlangıçtır; sen site sahibi olarak asıl cache katmanlarını kontrol etmek zorundasın. Çünkü her kullanıcıya tek tek cache temizletmek ciddi bir iştir ve profesyonel değildir.

İkinci sebep WordPress cache eklentisidir. LiteSpeed Cache, WP Rocket, W3 Total Cache gibi eklentiler sayfayı statik hale getirip servis eder. Sen içerik güncellersin ama cache temizlenmediyse eski sayfa görünebilir. Bazı eklentiler otomatik temizleme yapsa bile, her zaman doğru tetiklenmeyebilir. Bu durumda ilk pratik adım, cache eklentisinin içinden “tüm cache’i temizle” yapmaktır. Eğer düzelirse, WordPress Hata değil; cache yönetimi sorunudur. Ama yine de işi burada bırakma: neden otomatik temizlemedi? Hangi sayfalar hariç tutulmalı? Özellikle “Hesabım”, “Sepet”, “Ödeme” gibi dinamik sayfalar cache’lenirse daha büyük sorun çıkar. Yani cache doğru ayarlanmadıysa bu “değişiklik görünmüyor” sorunu tekrarlar.

Üçüncü sebep sunucu tarafı cache’dir. Bazı hostingler Nginx FastCGI cache, Varnish veya benzeri sunucu cache’i kullanır. WordPress cache eklentisini temizlersin ama sunucu cache’i hâlâ eski sayfayı döndürebilir. Bu senaryoda içeride her şey güncel görünür ama dışarıda eski hal servis edilir. Bu noktada hosting panelinden cache temizlemek veya destekten temizletmek gerekir. Yani WordPress Hata sandığın şey, hosting katmanındaki cache olabilir. Bir de CDN varsa (Cloudflare gibi), iş bir katman daha büyür: CDN, sayfayı dünyanın farklı noktalarında cache’leyebilir. Sen Türkiye’den bakınca güncel görürsün, başka ülkeden bakan eski görür. Bu tür durumlar özellikle can sıkıcıdır.

Dördüncü sebep, tema ve eklentilerin birleştirme/minify ayarlarıdır. Bazı sistemler CSS/JS dosyalarını birleştirir ve yeni dosya üretir. Dosya adı aynı kalırsa tarayıcı yeni dosyayı çekmez. Bu yüzden iyi cache sistemleri “cache busting” yapar: dosya adının sonuna sürüm ekler. Eğer bu mekanizma yoksa, sen değiştirirsin ama kullanıcı eski CSS’yi görür. Bu da “tasarım değişmiyor” diye WordPress Hata sanılan klasik senaryodur. Burada çözüm, CSS/JS sürümleme ayarlarını düzeltmek veya minify/birleştirme modunu doğru yapılandırmaktır.

Pratik bir test daha var: Sayfanın kaynağında gerçekten yeni içerik var mı? Bazen sen admin’de değiştiriyorum sanırsın ama yanlış sayfayı düzenliyorsundur (özellikle çok dilli sitelerde, kopya sayfalarda, staging/live karışıklığında). Bu da olur ve insanı deli eder. Bu yüzden sistematik yaklaşım şart: önce doğru site mi (alan adı), doğru ortam mı (canlı mı test mi), doğru sayfa mı kontrol et. Çünkü yanlış ortamda çalışıp sonra “neden görünmüyor” demek, gereksiz WordPress Hata üretir.

Değişikliklerin canlıda görünmemesi çoğu zaman cache kaynaklıdır: tarayıcı cache’i, WordPress cache eklentisi, sunucu cache’i ve CDN cache’i katman katman devreye girebilir. İlk test hard refresh/gizli sekme, sonra WordPress cache temizliği, sonra hosting cache temizliği, sonra CDN purge. Eğer problem CSS/JS’deyse sürümleme ve minify ayarlarını gözden geçir. Bu zinciri doğru yönetirsen “değişiklik görünmüyor” tipi WordPress Hata hissi biter; değişikliklerin kontrolü tekrar sende olur.

Kaçırılan Program Sorunu Nedir?

Kaçırılan program (Missed Schedule), WordPress’te zamanlanmış yazıların belirlenen saatte yayınlanmaması durumudur. Sen yazıyı planlarsın, saat gelir geçer ama yazı hâlâ taslak veya zamanlanmış görünür. Bu durum içerik üreten sitelerde özellikle sinir bozucudur ve çoğu kişi bunu direkt WordPress Hata diye algılar. Çünkü “takvim var, plan var, sistem sözünü tutmuyor” demektir. Bu sorunun temelinde WordPress’in zamanlama mantığı yatar: WordPress gerçek bir sunucu cron’u gibi sürekli çalışan bir zamanlayıcı kullanmaz; WP-Cron denilen sistem, siteye ziyaretçi geldiğinde tetiklenir. Yani trafik yoksa veya tetikleme gecikiyorsa, zamanlanmış işler de gecikebilir.

Bu problemin en yaygın nedeni düşük trafiktir. Siteye belirli saatlerde kimse girmiyorsa, WP-Cron tetiklenmez ve zamanlanmış görev çalışmaz. İkinci önemli neden, WP-Cron’un devre dışı bırakılmasıdır. Bazı performans optimizasyonları veya hosting ayarları WP-Cron’u kapatır; yerine gerçek sistem cron’u koyulmadıysa zamanlama bozulur. Üçüncü neden, cache/CDN katmanlarıdır. Siteye gelen istekler cache’ten dönüyorsa, WordPress tarafında “gerçek sayfa yükleme” gerçekleşmeyebilir ve cron tetiklenmesi gecikebilir. Dördüncü sebep, cron kuyruğunu şişiren eklentilerdir. Bazı eklentiler çok sık cron işi yazar, sistem yoğunlaşır ve zamanlama aksar. Beşinci sebep de kaynak kısıtlarıdır: sunucu yavaşsa veya PHP zaman aşımına gidiyorsa cron işleri yarım kalabilir. Görüldüğü gibi bu WordPress Hata, basit bir “yazı çıkmadı” meselesi değildir; zamanlayıcı zincirinin aksamasıdır.

İlk teşhis adımı, WP-Cron’un çalışıp çalışmadığını anlamaktır. Bazı sitelerde wp-cron.php dış dünyaya kapatılmış olabilir, bazı sitelerde güvenlik eklentisi bunu engeller. Eğer wp-cron.php tetiklenemiyorsa zamanlama kaçırılır. Bu nedenle en sağlam çözüm, WordPress’in WP-Cron’una bel bağlamak yerine sistem cron’u kullanmaktır. Yani sunucuda her 5 dakikada bir wp-cron.php çağıran gerçek bir cron işi tanımlarsın. Bu, yıllardır kullanılan “eski usul ama sağlam” yöntemdir. Trafik olsun olmasın, görevler düzenli çalışır; kaçırılan program gibi WordPress Hata hissi ortadan kalkar.

WP-Cron’u kapatıp sistem cron’u ile çalıştırmak için wp-config.php içine aşağıdaki satır eklenir. Bu, WordPress’in otomatik cron tetiklemesini durdurur. Ardından sunucuda cron tanımlanır. Hosting panelinde (cPanel) cron jobs kısmından veya sunucu cron tablosundan ayarlanır. Bu yaklaşım özellikle içerik takvimi olan sitelerde şarttır; çünkü yayın planını şansa bırakamazsın.

define('DISABLE_WP_CRON', true);

Sistem cron örneği de klasik olarak şu mantıktadır: belirli aralıklarla wp-cron.php’yi çağır. Bu çağrı, cron görevlerini tetikler. Sunucuda cron satırı yazmak gerekir; ortamına göre değişir ama mantık aynıdır. Eğer hosting üzerinde cron tanımlama imkanın yoksa, bu kez “Scheduled Post Trigger” gibi eklentiler devreye girer. Bu eklentiler, WordPress’in zamanlama kusurunu daha sık tetikleme ve kontrol mekanizmalarıyla telafi eder. Fakat açık konuşayım: eklentiyle çözmek kısa yoldur, sistem cron ile çözmek daha kurumsal ve daha az WordPress Hata üretir.

wget -q -O - https://alanadiniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Bir diğer pratik nokta: Saat dilimi ayarları. WordPress Ayarlar > Genel bölümünde saat dilimi yanlışsa, sen “şu saatte yayınla” dersin ama WordPress başka saati baz alır. Bu durumda yazı “kaçırıldı” sanırsın ama aslında yanlış saat dilimiyle planlamış olursun. Bu yüzden saat dilimini İstanbul (UTC+3) gibi doğru ayarla. Ayrıca çok yoğun sitelerde cron kuyruğu şişer; bu durumda cron yönetimini izlemek gerekir. Cron’ı gereksiz şişiren eklentiler varsa azaltmak veya ayarlarını düşürmek gerekir. Yoksa kaçırılan program sorunu tekrar eder ve yine WordPress Hata diye uğraşırsın.

Kaçırılan program sorunu, WordPress’in WP-Cron sisteminin ziyaretçi tetiklemesine bağlı olmasından doğar. Düşük trafik, cron’un kapalı olması, cache/CDN, eklenti yoğunluğu ve kaynak kısıtları bunu tetikler. En sağlam çözüm, WP-Cron’u kapatıp sistem cron ile wp-cron.php’yi düzenli çalıştırmaktır. Alternatif olarak zamanlama eklentileri kullanılabilir ama uzun vadede en az WordPress Hata üreten yöntem sistem cron disiplinidir.

Otomatik Güncelleme Başarısız Oldu Sorunu Nedir?

WordPress otomatik güncellemeleri, güvenlik ve bakım açısından iyi niyetli bir kolaylıktır: çekirdek, tema ve eklentiler güncel kalsın diye sistem kendisi günceller. Fakat bazen bu süreç başarısız olur ve panelde “otomatik güncelleme başarısız” benzeri uyarılar görürsün. Bu durumda birçok kişi bunu doğrudan WordPress Hata diye algılar; çünkü “güncel kalması gereken sistem güncellenemedi” demektir. Otomatik güncelleme başarısızlığı, tek bir sebepten çıkmaz: dosya izinleri, disk alanı, bellek/zaman limitleri, güvenlik katmanları, bakım modunda takılma ve hatta bozuk güncelleme paketleri gibi birden fazla faktör bu sonucu doğurabilir. Burada doğru yaklaşım, sorunu “tek tıkla düzelir” diye düşünmeden, güncelleme zincirini baştan sona kontrol etmektir.

En yaygın sebep dosya izinleridir. WordPress’in güncelleme yapabilmesi için wp-content başta olmak üzere ilgili dizinlere yazabilmesi gerekir. Eğer izinler yanlışsa veya dosya sahipliği hatalıysa WordPress dosya yazamaz, güncelleme yarıda kalır. Bu tür durumda otomatik güncelleme başarısız olur, bazen de site bakım modunda takılır. İkinci sık sebep disk alanıdır. Disk doluysa paket indirir ama açamaz, yazamaz. Üçüncü sebep PHP limitleridir: memory_limit düşükse veya max_execution_time düşükse büyük bir eklenti güncellemesi tamamlanamaz. Dördüncü sebep güvenlik duvarı/WAF/CDN katmanlarıdır. Bazı sistemler WordPress’in dışarıya yaptığı istekleri (WordPress.org’a bağlantı gibi) kısıtlar; bu durumda güncelleme paketi indirilemez. Beşinci sebep cache ve bakım modudur: güncelleme sırasında .maintenance dosyası kalırsa süreç bozulur. Sonuçta sen “güncelleme niye olmuyor” diye uğraşırken, arka planda tam bir WordPress Hata zinciri çalışıyordur.

İlk pratik adım, başarısız güncellemenin türünü tespit etmektir: çekirdek mi, eklenti mi, tema mı? Çekirdek güncellemesi başarısızsa daha hassas davranmak gerekir; çünkü çekirdek dosyaları yarım kalırsa site bozulabilir. Eklenti güncellemesi başarısızsa daha kolay izole edilir: eklentiyi devre dışı bırakıp manuel güncellersin. Tema güncellemesi başarısızsa çocuk tema yapın ve özelleştirmelerin korunup korunmadığını kontrol edersin. Bu ayrım, gereksiz yere WordPress Hata büyütmeni engeller.

İkinci adım, otomatik güncellemeyi zorlamak yerine manuel güncellemeyi tercih etmektir. Çünkü otomatik süreç bir kez takıldıysa, aynı koşullar tekrar takılmaya yol açabilir. Manuel güncelleme, sorunu daha kontrollü yönetmeni sağlar. Örneğin eklentiyi panelden güncelleyemiyorsan, eklenti dosyalarını FTP/SFTP ile güncel sürümle değiştirirsin. Bu biraz eski usuldür ama kritiktir: kontrol sende olur. Aynı şekilde WordPress çekirdeği için de resmi WordPress paketinden temiz dosyalarla değişim yapılabilir. Tabii wp-content ve wp-config.php gibi özel dosyalara dokunmadan, sadece çekirdek dizinlerini güncellersin.

Üçüncü adım, WordPress’in güncelleme kilitlerini ve bakım modunu kontrol etmektir. Otomatik güncelleme sırasında sistem “kilit” bırakmış olabilir. Bu kilitler bazen “başka bir güncelleme devam ediyor” gibi uyarılara dönüşür, bazen de sessizce güncellemeyi engeller. Ayrıca .maintenance dosyası kaldıysa site bakımda takılır. Bu iki durum bir araya gelince, güncelleme tam bir WordPress Hata sarmalına döner: güncelleyemezsin, güncel kalamazsın, güvenlik riski büyür. Bu yüzden güncelleme sorunlarında bakım modunu ve kilitleri kontrol etmek, standardın standardıdır.

Dördüncü adım, WordPress’in dış bağlantı yapabildiğini doğrulamaktır. WordPress güncellemeleri için WordPress.org’a ve bazen başka servislere bağlantı gerekir. Sunucuda outbound bağlantılar kısıtlıysa, “güvenli bağlantı hatası” gibi uyarılar çıkar ve güncelleme başarısız olur. Bu durumda çözüm WordPress içinde değil, hosting tarafında ağ erişimindedir. Hosting desteğiyle “outbound bağlantılar, firewall kuralları, DNS çözümleme” kontrol edilir. Bu da yine WordPress Hata gibi görünür ama altyapı problemidir.

Beşinci adım, sorunun tekrar etmemesi için sistem disiplinini kurmaktır. Güncellemeleri toplu değil kontrollü yapmak, önce staging ortamında denemek, düzenli yedek almak, dosya izinlerini doğru tutmak, disk alanını izlemek ve PHP limitlerini makul seviyede tutmak uzun vadede en az WordPress Hata üreten yaklaşımdır. Özellikle üretim sitesinde “hepsini güncelle” butonuna basmak kolaydır ama bedeli bazen ağır olur. Geleneksel yönetim anlayışı şunu söyler: “Önce yedek, sonra küçük adım, sonra doğrulama.” Bu yaklaşım, otomatik güncelleme başarısızlığını bile rutin bir bakım işine indirir.

Otomatik güncelleme başarısızlığı; izinler, disk, PHP limitleri, güvenlik/ağ kısıtları, bakım modu ve kilitlerden kaynaklanabilir. İlk iş güncelleme türünü belirle, sonra manuel güncelleme ile kontrolü ele al, bakım/kilit durumlarını temizle, sunucunun dış bağlantı yapabildiğini doğrula ve tekrar etmemesi için güncelleme disiplinini kur. Böylece “otomatik güncelleme başarısız” uyarısı bir WordPress Hata kabusu olmaktan çıkar.

WordPress İçe Aktarma Sorunları Nedir?

WordPress’e içerik içe aktarma (import) işlemleri; başka bir siteden yazıları taşımak, ürünleri topluca yüklemek, demo içerik kurmak veya yedekten veri geçirmek gibi işlerde kullanılır. Kağıt üzerinde basittir ama pratikte sık sık sorun çıkarır. İçerik aktarımı yarıda kalır, sayfa zaman aşımına uğrar, medya dosyaları gelmez, karakterler bozulur, bazı kayıtlar atlanır. Bu tip durumlar kullanıcıya doğrudan WordPress Hata gibi yansır; çünkü “veriyi taşımam lazım ama sistem duruyor” anlamına gelir. Asıl mesele şudur: içe aktarma işlemleri genellikle ağırdır. Büyük dosya, çok kayıt, çok sorgu, çok dosya yazma… Sunucu limitleri ve WordPress’in çalışma sınırları bir araya gelince bu işler kolayca tıkanır.

En yaygın problem, zaman aşımıdır. PHP’nin max_execution_time limiti düşükse veya sunucu yoğun ise içe aktarma script’i tamamlanamaz ve yarıda kesilir. İkinci yaygın problem bellek sınırıdır. Büyük bir XML dosyası, çok sayıda ürün veya medya bağlantısı; belleği şişirir ve işlem “Allowed memory size exhausted” gibi bir noktada düşer. Üçüncü problem dosya boyutu limitidir. upload_max_filesize ve post_max_size düşükse içe aktaracağın dosyayı yükleyemezsin. Dördüncü problem dosya yazma izinleridir: WordPress medya indirip uploads klasörüne yazamazsa medya kısmı patlar. Beşinci problem de ağ/uzak bağlantıdır. Bazı içe aktarmalar medya dosyalarını dış URL’lerden çekmeye çalışır; sunucunun dışarı çıkışı kısıtlıysa veya uzak sunucu yavaşsa işlem sürünür ve WordPress Hata gibi görünür.

İşe yarayan ilk yaklaşım, içe aktarmayı parçalara bölmektir. Tek seferde 50 bin satırlık dosya yüklemek yerine, daha küçük parçalar halinde içe aktarırsın. Bu, eski usul ama en güvenilir yöntemlerden biridir; çünkü her parçada hangi noktada sorun çıktığını daha net görürsün. Aynı zamanda sunucu limitlerine çarpmadan ilerlersin. Eğer eklenti ile içe aktarıyorsan, eklentinin “batch / step import” gibi ayarları varsa mutlaka kullan. Bu ayarlar, işlemi küçük partiler halinde çalıştırıp time-out riskini azaltır. Bu disiplin, gereksiz WordPress Hata döngüsünü kırar.

İkinci sağlam yaklaşım, mümkünse içe aktarmayı panel yerine komut satırından yapmaktır. Çünkü tarayıcı üzerinden yapılan işlemler daha kolay kesilir: bağlantı kopar, sekme kapanır, zaman aşımı olur. Komut satırı (WP-CLI) ile yapılan işlemler daha stabil çalışır ve log tutmak daha kolaydır. Her hosting WP-CLI vermez ama varsa büyük içe aktarmalarda ciddi fark yaratır. Bu, “işi düzgün yapma” yöntemidir: riskli işlemleri tarayıcıya bırakma. Çünkü tarayıcı, WordPress Hata üretmeye en müsait ortamdır.

Üçüncü adım, sunucu limitlerini kontrol etmektir. İçe aktarma bir defalık bir iş gibi görünse de, limitler düşükse her seferinde patlar. upload_max_filesize, post_max_size, memory_limit ve max_execution_time değerleri bu işin omurgasıdır. Eğer bu değerler çok düşükse, içe aktarma kaçınılmaz olarak sorun çıkarır. Burada net konuşayım: limitleri “sonsuz artır” da doğru değil; ama gerçekçi bir seviyeye çekmek şart. Aksi halde her içe aktarmada aynı WordPress Hata tekrarlanır. Hosting panelinden veya destekten bu limitlerin artırılmasını isteyebilirsin.

Dördüncü adım, medya tarafını ayrı yönetmektir. Bazı import dosyaları medyayı da taşımaya çalışır; bu süreç yavaştır ve en çok burada patlar. Medyayı ayrı bir yöntemle (örneğin önce uploads klasörünü taşıyıp sonra içerik import etmek gibi) yönetmek, içe aktarmayı daha güvenli yapar. Ayrıca dosya isimlerinde Türkçe karakter veya özel karakter varsa bazı sistemler sorun çıkarabilir. Bu durumda dosyaları yeniden adlandırmak bile WordPress Hata gibi görünen medya problemlerini azaltır.

Son olarak, log olmadan bu iş yapılmaz. İçe aktarma yarıda kalıyorsa, hata loglarında time-out mı var, bellek mi doluyor, izin mi reddediliyor görmen gerekir. Çünkü her sebebin çözümü farklıdır. “Bir daha deneyeyim belki olur” yaklaşımı zaman kaybıdır. Geleneksel, sağlam yöntem: önce sebebi bul, sonra müdahale et. Böyle yaparsan içe aktarma sorunları kontrol altına girer ve WordPress Hata diye günlerce uğraşmazsın.

WordPress içe aktarma sorunları genelde zaman aşımı, bellek yetersizliği, dosya boyutu limitleri, izin problemleri ve ağ/medya çekme gecikmelerinden çıkar. En iyi pratikler; import’u parçalara bölmek, mümkünse WP-CLI ile yapmak, sunucu limitlerini makul seviyeye çekmek, medya transferini ayrı yönetmek ve loglar üzerinden kanıtla ilerlemektir. Bu disiplinle içe aktarma işi “kumar” olmaktan çıkar, yönetilebilir bir bakım adımına dönüşür

WordPress Performans Sorunları Nedir?

WordPress performans sorunları, sitenin “yavaş” hissedilmesinin ötesinde bir problemdir: geç açılan sayfalar, admin panelinde gecikme, görsel yüklenirken takılma, sepette/dinamik sayfalarda bekleme, hatta zaman zaman 500/503 gibi hatalara kadar uzanan bir zincir oluşturabilir. Kullanıcı yavaşlık yaşadığında bunu çoğu zaman WordPress Hata gibi algılar; çünkü sonuç aynıdır: siteyi kullanamaz, sabrı tükenir ve çıkar. Üstelik yavaş site, sadece kullanıcıyı kaçırmaz; SEO tarafında da darbe vurur. Bu nedenle performans konusu “lüks” değil, bakımın omurgasıdır. Geleneksel şekilde söyleyeyim: hızlı site, güvenilir sitedir; yavaş site, sorun çıkaran sitedir.

Performans sorunlarının ana kaynakları genellikle birkaç yerde toplanır. Birincisi kötü hosting veya yetersiz kaynak: CPU/RAM azsa, disk yavaşsa, aynı sunucuda çok site varsa WordPress ne yaparsa yapsın sürünür. İkincisi aşırı eklenti yükü: her eklenti ekstra sorgu, ekstra dosya, ekstra işlem demektir. Üçüncüsü kötü tema ve sayfa oluşturucular: ağır JS/CSS, gereksiz bileşenler, şişmiş DOM sitenin açılışını uzatır. Dördüncüsü veritabanı şişmesi: revision’lar, transients, log tabloları büyür, sorgular yavaşlar. Beşincisi görsel optimizasyon eksikliği: devasa görseller, WebP yokluğu, lazy-load kötü ayarı sayfayı taş gibi yapar. Altıncı sebep cache yokluğu veya yanlış cache: cache yoksa her istek dinamik üretilir, sunucu yorulur; cache yanlışsa dinamik sayfalar bozulur. Sonuç: performans problemleri, tek bir ayardan değil; bütün sistemin disiplininden doğar. Bu yüzden “tek eklentiyle hızlandır” masalına fazla inanma; yoksa yeni WordPress Hata üretirsin.

İlk adım ölçmektir. Ölçmeden iyileştirme olmaz. Sayfa nerede zaman kaybediyor? TTFB mi yüksek, yoksa render mı yavaş, yoksa görseller mi patlatıyor? Bir hız testi aracı kullanıp temel metriklere bakmak gerekir. Burada amaç “puan kasmak” değil, gerçek darboğazı görmektir. Eğer TTFB yüksekse, sunucu veya backend sorguları ağır demektir. Eğer LCP yüksekse, genelde görsel veya kritik CSS/JS problemidir. Eğer çok fazla istek varsa, tema/eklenti şişkinliği vardır. Bu analiz, performansı WordPress Hata olmaktan çıkarıp mühendislik problemine çevirir.

Cache tarafı performansın en büyük silahıdır ama doğru kullanılmazsa bela olur. Sayfa cache, düzgün yapılandırıldığında sunucunun yükünü dramatik biçimde düşürür. Ancak dinamik sayfaları cache’lersen (üyelik, sepet, ödeme, admin-ajax gibi), bu kez işlev bozulur ve kullanıcı WordPress Hata diye şikâyet eder. Bu yüzden cache’de altın kural: statik içerik cache’lenir, dinamik içerik hariç tutulur. Ayrıca tarayıcı cache politikaları ve CDN entegrasyonu da doğru yapılmalıdır. CDN yalnızca hız değil, aynı zamanda trafik yükünü dağıtma aracıdır. Fakat CDN yanlış kurgulanırsa 404, karışık içerik, yanlış cache gibi yeni sorunlar getirir.

Veritabanı tarafı da çoğu sitede ihmal edilir. Zamanla revision’lar, otomatik taslaklar, spam yorumlar, transients tabloları şişer. Bu şişme, admin panelini bile ağırlaştırır. Düzenli bakım şarttır. Ayrıca bazı eklentiler log tutmayı abartır; log tabloları büyüdükçe sorgular yavaşlar. Bu durumda eklentiyi değiştirmek veya log ayarını kısmak gerekir. Performansın geleneksel disiplini şudur: az eklenti, temiz veritabanı, iyi cache, optimize görsel, doğru hosting. Bu beşli oturursa WordPress Hata hissi yaratan yavaşlık büyük ölçüde biter.

Görsel optimizasyonu pratik bir kazanımdır. Büyük görselleri küçültmek, doğru boyutlandırmak, modern format kullanmak (WebP/AVIF) ve lazy-load uygulamak çoğu sitede fark yaratır. Ama burada da ölçüsüzlük zarar verir: aşırı sıkıştırma kaliteyi bozar, yanlış lazy-load kritik görseli geciktirir, kullanıcı deneyimi düşer. Yani “her şeyi sıfıra sıkıştır” değil; akıllı optimizasyon gerekir. Aynı şekilde JS/CSS tarafında da gereksiz dosyaları kaldırmak, kullanılmayan CSS’i azaltmak ve kritik kaynakları düzenlemek önemlidir. Fakat her şeyi birleştirip minify etmek bazen çakışma çıkarır ve WordPress Hata üretir. Bu yüzden değişiklikler kontrollü yapılmalıdır.

Son adım, performans sorunlarını “tek seferlik iş” gibi görmemektir. Site büyüdükçe, eklenti güncellendikçe, içerik arttıkça performans yeniden düşebilir. Bu yüzden periyodik test, periyodik bakım, periyodik temizlik şarttır. Bu düzeni kurarsan site hızlı kalır, kullanıcı memnun olur, Google tarafında da avantaj yakalarsın. Kurmazsan her ay başka bir WordPress Hata ile uğraşırsın; çünkü yavaşlık, hatayı çağırır.

WordPress performans sorunları; zayıf hosting, şişmiş eklentiler, ağır tema/JS, veritabanı şişmesi, optimize edilmemiş görseller ve yanlış cache/CDN kurgusundan çıkar. Ölçerek başla, darboğazı bul, cache ve CDN’i doğru kur, veritabanını temiz tut, görselleri optimize et, gereksiz eklentileri azalt. Bu disiplinle performans sorunu “kronik WordPress Hata” olmaktan çıkar, yönetilebilir bir bakım sürecine dönüşür.

WordPress E-posta Göndermiyor Sorunu Nedir?

WordPress’in e-posta göndermemesi, “küçük bir aksaklık” değildir; çoğu sitede doğrudan iş kaybıdır. İletişim formu çalışır sanırsın ama müşteri mesajı gelmez, şifre sıfırlama maili gitmez, sipariş bildirimleri düşmez. Kullanıcı tarafında “mail gelmedi” diye başlar ama site sahibi açısından bu tam bir WordPress Hata gibi yaşanır; çünkü kritik bildirim zinciri kopmuştur. Üstelik bu sorun sinsi olur: Form “başarılı” der, WordPress mail attım sanır, ama mail ya hiç çıkmaz ya da spam’a düşer. Bu yüzden “bana gelmedi” denildiğinde önce paniği değil, süreci kontrol etmek gerekir.

WordPress aslında mail gönderirken PHP’nin mail fonksiyonunu veya sunucunun mail transfer mekanizmasını kullanır. Sorunların büyük kısmı da buradan çıkar. Birincisi hosting tarafı outbound mail kısıtlamasıdır: bazı sağlayıcılar spam nedeniyle PHP mail’i sınırlar veya tamamen kapatır. İkincisi DNS doğrulama eksikleridir: SPF, DKIM, DMARC kayıtları yoksa veya yanlışsa gönderilen mailler spam’a düşer, hatta bazı alıcılar direkt reddeder. Üçüncüsü SMTP yapılandırması yoktur: WordPress “mail attım” zanneder ama sunucu güvenilir bir şekilde teslim edemez. Dördüncüsü form eklentisi veya güvenlik eklentisi çakışmasıdır: mail tetiklenmez, hook çalışmaz. Beşincisi de yanlış alıcı adresi veya hatalı “From” adresidir: bazı sunucular domain dışı From adreslerini engeller. Yani bu WordPress Hata, çoğu zaman WordPress’in değil, mail teslimat zincirinin problemidir.

İlk teşhis adımı, mail gerçekten çıkıyor mu sorusudur. “Spam’a mı düştü yoksa hiç mi gönderilmedi?” Bunu anlamanın en iyi yolu bir SMTP log/test eklentisi kullanmak veya form eklentisinin loglarını kontrol etmektir. Eğer log “gönderildi” diyorsa ama inbox’ta yoksa, teslimat (deliverability) problemidir. Eğer log bile oluşmuyorsa, tetikleme/uyumluluk problemidir. Bu ayrım, gereksiz WordPress Hata arayışını bitirir. Çünkü teslimat sorununda eklenti kapatıp açmak değil, SMTP ve DNS doğrulaması gerekir.

Kalıcı ve profesyonel çözüm SMTP kullanmaktır. WordPress’in PHP mail’ine güvenmek eski usulde bazı sunucularda çalışır, bazılarında çalışmaz. Bugünün internetinde mail tarafı ciddi filtreleniyor. Bu yüzden WordPress’i bir SMTP sağlayıcısına bağlamak gerekir: Google Workspace, Outlook, özel SMTP servisleri veya hostingin sunduğu SMTP. SMTP kurulduğunda mail gönderimi daha güvenilir olur ve log tutmak daha kolaydır. Bu yaklaşım, “WordPress Hata mı oldu yine?” tartışmasını azaltır; çünkü mailin yolu kontrol altına alınır.

DNS tarafı da şarttır. En azından SPF kaydı, mümkünse DKIM ve DMARC ile doğrulama yapılmalıdır. SPF, “bu domain adına kimler mail atabilir” bilgisini verir. DKIM, mailin imzalı olduğunu gösterir. DMARC ise politikanı belirler ve raporlama sağlar. Bunlar yoksa mailin spam’a düşmesi çok daha olasıdır. Burada net konuşayım: “Mail gidiyor ama spam’a düşüyor” da bir WordPress Hata’dır; çünkü sonuç olarak kullanıcı maili almıyor. Teknik olarak WordPress görevini yapmış gibi görünse bile iş sonucu bozulmuştur.

Form tarafında da temel kontroller var. Form eklentisinin alıcı adresi doğru mu? Mail başlıkları doğru mu? “From” adresi, domainin kendi adresi mi? Bazı sunucular “From: gmail.com” gibi dış domain kullanınca maili engeller. Bu durumda “From” alanını domain içi bir adrese çekmek gerekir (örneğin noreply@alanadiniz.com), “Reply-To” alanına da kullanıcının mailini yazmak gerekir. Bu klasik, geleneksel ama hâlâ en sağlam yöntemdir. Çünkü mail sunucuları sahte göndereni sevmez. Sahte görünürse keser. Sonuç: WordPress Hata gibi görünen “mail yok” problemi.

Bir de güvenlik katmanı var: bazı güvenlik eklentileri veya WAF kuralları, admin-ajax isteklerini veya form submitlerini kısıtlar. Form gönderilir gibi görünür ama arka planda mail tetiklenmez. Bu durumda geçici olarak güvenlik eklentisini test için devre dışı bırakmak veya whitelist kuralı eklemek gerekebilir. Ayrıca hostingin mail kuyruk limitleri de olabilir. Paylaşımlı hostingte kısa sürede çok mail atarsan throttle yer ve maillerin bir kısmı düşer. Bu da “WordPress Hata çıktı” diye şikâyet olarak geri döner.

WordPress’in e-posta göndermemesi çoğu zaman hosting kısıtı, SMTP yokluğu, SPF/DKIM/DMARC eksikliği, yanlış From adresi veya eklenti/güvenlik çakışmasından kaynaklanır. İlk iş “hiç mi gitmiyor, spam’a mı düşüyor?” ayrımını yap. Kalıcı çözüm SMTP kur, DNS doğrulamasını tamamla ve From/Reply-To düzenini doğru kur. Bu disiplinle mail sorunu kronik WordPress Hata olmaktan çıkar; güvenilir bir bildirim sistemine dönüşür.

WordPress Sözdizimi Hatası Nedir?

WordPress’te sözdizimi hatası, çoğu zaman “iyi niyetli bir dokunuşun” kötü sonuç vermesidir. Genellikle functions.php dosyasına, özel bir eklenti dosyasına ya da tema içindeki herhangi bir PHP dosyasına internetten bulduğun bir kod parçasını yapıştırırsın; bir noktalı virgül eksik kalır, bir tırnak kapanmaz, bir parantez açık unutulur ve site bir anda patlar. Kullanıcı tarafında bu durum beyaz ekran, 500 hatası veya “Parse error / Syntax error” gibi sert mesajlarla görünür. Bu tarz durumlar, tam anlamıyla panik yaratan WordPress Hata örnekleridir; çünkü çoğu zaman hem ön yüz hem de panel aynı anda etkilenir ve içeriden düzeltme şansın azalır.

Sözdizimi hatasının en önemli özelliği şudur: Sorun genellikle WordPress çekirdeğinde değil, senin son dokunduğun satırdadır. Bu yüzden “host bozuldu mu, veritabanı mı gitti” diye sağa sola savrulmak yerine, en son yapılan değişikliği hedef almak gerekir. Özellikle tema dosyalarında bir satır bile her şeyi kilitleyebilir. Bir de klasik senaryo var: Kod parçasını kopyalarken satır başları bozulur, akıllı tırnaklar girer, farklı karakter setiyle yapıştırırsın; görünüşte normal duran satır, PHP için geçersiz hale gelir. Sonuç: site çalışmaz, sen uğraştıkça daha da büyüyen bir WordPress Hata hissi oluşur.

Bu problemi hızlı çözmenin yolu “tahmin” değil, hatayı net okumaktır. Eğer ekranda hata mesajı görüyorsan, mesajın içinde genelde dosya yolu ve satır numarası yazar. İşte o satır, sorunun kalbidir. Mesela şu tip bir hata görürsün: “Parse error: syntax error, unexpected … in /wp-content/themes/temaadi/functions.php on line …”. Bu mesaj, sana açıkça “hangi dosya” ve “neresi” der. Burada yapılacak iş, o dosyayı FTP/SFTP ile açıp ilgili satırdaki hatayı düzeltmek veya yaptığın eklemeyi geri almaktır. Panel açılmıyorsa da sorun değil; zaten sözdizimi hatalarında en güvenilir yol dosyaya dışarıdan müdahaledir.

En sık yapılan hata örneklerinden biri, noktalı virgül unutulmasıdır. PHP’de küçük gibi duran bu eksik, koca siteyi durdurur. Aşağıdaki örnekte ilk blok hatalı, ikinci blok düzeltilmiş halidir. Bu tarz bir problem, bazen sadece tek bir karakter yüzünden günlerce uğraştıran cinsten olur; o yüzden sakin kalıp satır satır kontrol etmek gerekir. Unutma, bu tür bir problem “karmaşık” değildir; sadece “hassas”tır.

// HATALI: noktalı virgül eksik
add_action('init', 'dw_ornek_fonksiyon')
function dw_ornek_fonksiyon() {
    // ...
}

// DOĞRU: noktalı virgül eklendi
add_action('init', 'dw_ornek_fonksiyon');
function dw_ornek_fonksiyon() {
    // ...
}

Bir diğer klasik sözdizimi hatası, tırnak ve parantez uyuşmazlığıdır. Özellikle uzun bir satırda bir tırnak kapanmadığında PHP geri kalan her şeyi “string” sanabilir ve hata verir. Bu yüzden kod eklerken küçük parçalar halinde ilerlemek, her eklemeden sonra siteyi kontrol etmek eski usul ama çok sağlam bir alışkanlıktır. Büyük bir bloğu tek seferde yapıştırmak, hata olursa nerenin patladığını belirsizleştirir. Profesyonel bakım yaklaşımı şudur: küçük adım, test, sonra bir küçük adım daha. Böyle yaparsan sözdizimi hatası çıktığında geri dönüşün kolay olur.

Eğer senin sitende sık sık böyle hatalar oluyorsa, iki şeyi oturtman şart: birincisi, canlı sitede doğrudan dosya düzenlemek yerine önce staging/test ortamında denemek. İkincisi, düzenleme yapmadan hemen önce yedek almak. Bu ikisi, en sevimsiz WordPress Hata senaryolarında bile seni rahatlatır. Ayrıca yardım veya bakım hizmeti tarafında daha düzenli ilerlemek istersen bir referans noktan olsun: https://datweb.com.tr/ üzerinden süreçlerini daha sistemli hale getirip “tek satırla siteyi devirmek” gibi kazaları ciddi şekilde azaltırsın.

WordPress sözdizimi hatası, çoğu zaman yanlış eklenen bir kod parçası yüzünden ortaya çıkar ve çözümü de aynı kadar nettir: doğru dosyayı bul, doğru satırı düzelt veya değişikliği geri al. Burada başarıyı getiren şey, acele değil; disiplinli, satır satır ilerleyen bakımdır.

WordPress Kenar Çubuğu İçeriğin Altında Görünüyor Sorunu Nedir?

Kenar çubuğunun (sidebar) içerikle yan yana durması gerekirken içeriğin altına düşmesi, özellikle masaüstünde siteyi “dağılmış” gösteren klasik bir problemdir. Ziyaretçi sayfayı açar, menüler, arama kutusu, sosyal alanlar veya yan bileşenler aşağıya kaymıştır; ilk izlenim direkt bozulur. İnsan bunu çoğu zaman tasarım problemi diye küçümser ama işin gerçeği şu: Bu durum hem kullanıcı deneyimini hem de dönüşümü etkiler ve çok sık WordPress Hata diye raporlanır. Çünkü site sahibi “dün düzgündü, bugün bozuldu” der; aslında bir CSS/HTML düzen kuralı kırılmıştır.

Bu sorunun temel nedeni genellikle iki yerde çıkar: tema şablon yapısı (HTML) ve stil kuralları (CSS). En yaygın senaryo, bir yerde kapanmayan

/* Klasik float düzeni örneği */
.content-area { float: left; width: 70%; }
.sidebar-area { float: right; width: 30%; }

/* Float temizleme (clearfix) */
.site-wrap::after {
  content: "";
  display: block;
  clear: both;
}

// Örnek: tema içinden bir dosyayı güvenli çağırma
require get_template_directory() . '/inc/ornek-dosya.php';

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

define('WP_HOME', 'https://alanadiniz.com');
define('WP_SITEURL', 'https://alanadiniz.com');

-- phpMyAdmin / MySQL örneği
-- core_updater.lock kaydını silmek
DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

// Çöp kutusunu devre dışı bırakmak (geçici çözüm)
define('EMPTY_TRASH_DAYS', 0);

// wp-config.php içine eklenebilir (hosting izin veriyorsa)
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// wp-config.php içine (geçici) debug ayarı
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);