WordPress Veritabanı Bağlantısı Kurulurken Hata Oluştu: Nedenleri ve Çözümü

WordPress veritabanı bağlantısı kurulurken hata oluştu uyarısı ne anlama gelir ve ilk ne yaparsınız?

Veritabanı bağlantısı kurulurken hata oluştu uyarısı, WordPress'in sitenizin içeriğini tuttuğu MySQL veritabanına ulaşamadığını bildirir. WordPress sayfaları veritabanından okuduğu için bağlantı kopunca sitenin tamamı çöker. Genellikle yanlış wp-config.php bilgisi, yanıt vermeyen veritabanı sunucusu ya da bozuk tablo bu sonucu doğurur.

Ekranda bu uyarıyı gördüğünüzde sakin kalın ve şu sırayı izleyin:

1. Sayfayı bir dakika sonra yenileyin, çünkü kısa süreli sunucu yoğunluğu aynı mesajı verebilir.
2. Hosting panelinize girin ve veritabanı bölümüne ulaşıp ulaşamadığınıza bakın.
3. wp-config.php dosyasındaki veritabanı adı, kullanıcı, parola ve host bilgilerini panelle karşılaştırın.
4. Bilgiler doğruysa hosting sağlayıcınıza veritabanı sunucusunun çalışıp çalışmadığını sorun.
5. Hiçbir şeyi değiştirmeden önce dosya ve veritabanı yedeğini bilgisayarınıza indirin.

Bu yazıda her adımı, nedenlerine göre ayırarak anlatıyoruz. Böylece rastgele deneme yapmak yerine doğru noktadan başlarsınız. Ayrıca hiçbir adımda gerçek parola ya da kullanıcı adı paylaşmanızı istemiyoruz.

Bu hata mesajı hangi durumlarda karşınıza çıkar?

WordPress her sayfa isteğinde veritabanıyla konuşur. Yazılar, sayfalar, ayarlar ve kullanıcılar orada durur. Bağlantı kurulamazsa WordPress ekrana kısa bir hata metni basar ve sayfayı yüklemeyi bırakır. İngilizce arayüzde bu metin "Error establishing a database connection" olarak belirir. Almanca arayüzde de buna karşılık gelen bir çeviri çıkar.

Hata çoğunlukla şu anlarda ortaya çıkar:

• Hosting ya da alan adı taşıdıktan hemen sonra.
• Veritabanı parolasını panelde değiştirdikten sonra.
• Trafik aniden arttığında ve kaynak sınırı dolduğunda.
• Hosting sağlayıcısı bakım yaptığında ya da sunucu yeniden başladığında.
• Eklenti ya da güncelleme sırasında tablolar bozulduğunda.

Dolayısıyla hatanın zamanlaması size önemli bir ipucu verir. Değişiklik yaptıktan hemen sonra başladıysa bilgi uyuşmazlığına bakın. Kendiliğinden başladıysa sunucu ya da kaynak sorununu araştırın. Bu ayrım, yarım saatlik denemeyi beş dakikalık kontrole indirir.

Bir örnek senaryo düşünelim. Bir işletme sitesini yeni hostinge taşıyor ve dosyaları aynı gün kopyalıyor. Alan adı yeni sunucuya yönleniyor, ancak yapılandırma dosyasında eski veritabanı bilgileri duruyor. Site hemen bu uyarıyı veriyor. Bu senaryoda sorun sunucuda değil, tek bir dosyadaki dört satırdadır. Yani çoğu zaman çözüm düşündüğünüzden basittir.

Hata gerçekten veritabanı bağlantısından mı geliyor?

Her boş ekran veritabanı hatası değildir. Bu yüzden önce doğru hatayı teşhis etmeniz gerekir. WordPress'te benzer görünen birkaç farklı sorun vardır ve her birinin çözümü farklıdır.

Örneğin "Bu sitede kritik bir hata oluştu" mesajı, bir eklenti ya da tema kodunun çökmesinden gelir. Bu durumu kritik hata çözümü rehberimizde ayrıca anlattık. Tamamen beyaz bir ekran ise PHP hatası ya da bellek yetersizliği olabilir. Sunucu kaynaklı genel bir çöküşte 500 Internal Server Error rehberi işinize yarar.

Veritabanı hatasını şu özellik ayırt eder: mesaj doğrudan veritabanı bağlantısından söz eder ve sitenin hiçbir bölümü ekrana gelmez. Bazı kurulumlarda mesajın metni biraz farklı olabilir. Bu durumda benzeri bir uyarı gördüğünüzü kabul edin ve aynı kontrol sırasını izleyin.

Teşhisi hızlandırmak için kendinize iki soru sorun. Birincisi, yönetim paneline giriş sayfası açılıyor mu? İkincisi, hata tüm sayfalarda mı, yoksa yalnızca belirli sayfalarda mı çıkıyor? Tüm sayfalar ve panel birlikte düşüyorsa bağlantı sorunu güçlü bir adaydır. Yalnızca tek sayfa bozuksa sorun büyük olasılıkla o sayfanın eklentisindedir.

wp-config.php içindeki veritabanı bilgilerini nasıl kontrol edersiniz?

WordPress'in resmi belgeleri bu hatanın en sık nedenini wp-config.php dosyasındaki yanlış bilgiler olarak gösterir. Dosyaya FTP istemcisi ya da hosting panelindeki dosya yöneticisi aracılığıyla ulaşırsınız. Dosya, WordPress'in ana klasöründe durur.

Dosyada dört bilgiyi panelle karşılaştırın:

• Ad: Panelde gördüğünüz adla birebir aynı olmalı, çünkü bazı hostingler başına hesap öneki ekler.
• Kullanıcı adı: Bu ad da önek içerebilir ve büyük küçük harfe duyarlı olabilir.
• Parola: Başta ya da sonda fazladan boşluk kalmamalı.
• Sunucu (host): Çoğu hostingte localhost yeterlidir, ancak bazı sağlayıcılar farklı bir adres verir.

Kontrol sırasında dosyayı kod düzenleyicisiyle açın, kelime işlemci kullanmayın. Kelime işlemciler düz tırnakları eğik tırnağa çevirerek dosyayı bozar. Değişiklikten önce dosyanın bir kopyasını bilgisayarınıza kaydedin. Böylece yanlış bir düzenleme yaptığınızda hemen eski haline dönersiniz.

Dosyayı düzenlerken yapıyı bozmamaya özen gösterin. Her bilgi tırnak işaretleri arasında durur. Tırnakları silmeyin, yalnızca içindeki değeri değiştirin. Parolada özel karakter varsa değeri panelden kopyalayın. Düzenlemeden sonra dosyayı sunucuya yüklerken eski dosyanın üzerine yazdığınızdan emin olun.

Parola uyuşmuyorsa ne yaparsınız?

Parola farkı çok yaygın bir nedendir. Özellikle hosting panelinde parolayı yenileyip dosyayı güncellemeyi unutursanız hata anında başlar. Ayrıca eski bir yedeği geri yüklediğinizde de eski parola dosyaya geri gelir. Yani yedek, parolayı da geriye götürür.

En güvenli yöntem şudur:

1. Hosting panelinde ilgili veritabanı kullanıcısına yeni bir parola atayın.
2. Parolayı bir parola yöneticisine kaydedin.
3. Aynı değeri wp-config.php dosyasındaki parola alanına kopyalayıp yapıştırın.
4. Dosyayı kaydedin ve siteyi yeniden açın.

WordPress belgeleri, yapılandırmanız doğru görünüyorsa MySQL parolasını elle sıfırlamayı da önerir. Karmaşık karakterli parolalarda elle yazmak yerine kopyala yapıştır kullanın. Gerçek parolalarınızı hiçbir yerde paylaşmayın. Destek ekibine bile yazıyla göndermek yerine panelin güvenli kanalını tercih edin.

Parolayı değiştirdikten sonra aynı kullanıcıyı kullanan başka bir uygulamanız varsa onu da güncelleyin. Örneğin aynı veritabanına bağlanan ikinci bir site ya da zamanlanmış bir yedek görevi eski parolayla çalışmaya devam eder. Böylece bir hatayı çözerken yenisini yaratmazsınız.

Veritabanı sunucusu (host) bilgisi neden yanlış olabilir?

Host alanı, WordPress'e veritabanının hangi sunucuda durduğunu söyler. Birçok paylaşımlı hostingte bu değer localhost olur, çünkü veritabanı web sunucusuyla aynı makinededir. Ancak bazı sağlayıcılar veritabanını ayrı bir makinede çalıştırır ve size özel bir adres verir.

Şu durumlarda host bilgisi yanlış kalabilir:

• Yeni hostinge geçtiniz ve eski adres dosyada duruyor.
• Sağlayıcınız veritabanı sunucusunu başka bir makineye taşıdı.
• Port numarası gerekiyor ama siz eklemediniz.

Doğru değeri bulmak için hosting panelindeki veritabanı bilgi ekranına ya da sağlayıcınızın destek belgelerine bakın. Tahmin yürütmeyin. Yanlış host değeri çoğu zaman aynı genel hata mesajını verir. Bu yüzden değeri kaynağından doğrulamak size zaman kazandırır.

Veritabanı kullanıcısının yetkisi eksikse ne olur?

Bilgiler doğru olsa bile kullanıcıyı veritabanına bağlamadıysanız sunucu bağlantıyı geri çevirir. Hosting panelinde veritabanı oluşturmak ile kullanıcı oluşturmak ayrı adımlardır. Kullanıcıyı veritabanıyla eşleştirmeyi ve gerekli yetkileri vermeyi unutursanız aynı hata çıkar.

Bu durum en çok yeni kurulumlarda ve taşımalarda ortaya çıkar. Örneğin yeni bir veritabanı oluşturdunuz, içeriği içe aktardınız, ancak kullanıcıyı eklemediniz. WordPress parolayı doğru gönderse bile sunucu kullanıcıya erişim izni vermez.

Panelde şunu kontrol edin: ilgili kullanıcı doğru veritabanında yer alıyor mu ve yetkileri tanımlı mı? Adım adım anlatım için cPanel'de MySQL veritabanı, kullanıcı ve yetki rehberimize bakabilirsiniz. Oluşturma sürecini orada ayrıntılı işlediğimiz için burada tekrar etmiyoruz.

Bazı panellerde yetkiler tek tek işaretlenir. WordPress'in tabloları oluşturabilmesi, okuyabilmesi ve değiştirebilmesi için kullanıcının ilgili veritabanında tam yetkiye ihtiyacı vardır. Eksik bir yetki sitenin bir kısmını çalıştırıp bir kısmını bozabilir. Kesin yetki listesi sağlayıcıya göre değiştiği için panelin sunduğu "tüm yetkiler" seçeneğini kontrol edin.

Veritabanı sunucusunun yanıt vermediğini nasıl anlarsınız?

Bilgileriniz doğruysa sorun sunucu tarafında olabilir. Veritabanı sunucusu çökmüş, bakımda ya da aşırı yüklü olabilir. WordPress belgeleri de hosting kaynaklı nedenler arasında sunucunun kapalı olmasını sayar.

Aşağıdaki işaretler sunucu sorununa işaret eder:

• Hosting panelindeki veritabanı yönetim aracı hiç gelmiyor ya da çok yavaş geliyor.
• Aynı sunucudaki diğer siteleriniz de aynı hatayı veriyor.
• Hata aralıklı olarak geliyor ve sayfayı yenileyince bazen düzeliyor.
• Sağlayıcınızın durum sayfası ya da duyuruları bakım olduğunu söylüyor.

Bu işaretleri görürseniz wp-config.php dosyasını değiştirmeyin. Çünkü doğru bilgileri bozmak sorunu büyütür. Bunun yerine sağlayıcınıza, hata saatini ve etkilenen alan adlarını belirterek yazın. Ayrıca sorunun süresini not edin, böylece destek ekibiyle konuşurken somut bilgi verirsiniz.

Sağlayıcıya yazarken somut bir soru sorun: veritabanı sunucusunda şu saatlerde bir kesinti ya da bakım var mıydı? Böyle bir soru, genel bir şikayetten çok daha hızlı yanıt alır. Ayrıca yanıt gelene kadar siteyi bakım sayfasıyla kapatmayı düşünebilirsiniz. Böylece ziyaretçileriniz ham hata metni yerine anlaşılır bir bilgi görür.

Kaynak sınırı ve kota bu hatayı nasıl tetikler?

Paylaşımlı hostinglerde veritabanı bağlantı sayısı, bellek ve işlem süresi sınırlıdır. Siteniz bu sınırı aşarsa sağlayıcı bağlantıları geçici olarak reddeder. Bu durumda WordPress veritabanına ulaşamaz ve aynı hatayı gösterir.

WordPress belgeleri, veritabanınızın kotayı doldurup kapanabileceğini de belirtir. Kota dolunca yazma işlemleri durur, bazen veritabanı tamamen yanıt vermez olur.

Sınıra yaklaşmanın tipik nedenleri şunlardır:

• Ani trafik artışı ya da botların yoğun taraması.
• Ağır çalışan, özensiz kodlu bir eklenti.
• Şişmiş geçici veri ve eski sürüm kayıtları.
• Hosting paketinin site büyüklüğüne göre küçük kalması.

Kaynak mantığını öğrenmek için hosting kaynak limitleri (CPU, RAM, I/O) yazımıza göz atın. Ayrıca yükü azaltmanın faydasını site hızı SEO'yu nasıl etkiler yazısında görürsünüz.

Bu noktada paket yükseltmek tek çözüm değildir. Önce yükün nereden geldiğine bakın. Gereksiz eklentileri kaldırmak, önbellek kullanmak ve görselleri küçültmek çoğu zaman paket yükseltmeden daha ucuza gelir. Yine de trafiğiniz gerçekten büyüdüyse daha güçlü bir pakete geçmek mantıklıdır. Güncel kota ve limit değerlerini sağlayıcınızın kendi sayfasından kontrol edin.

Bozuk tablolar için WP_ALLOW_REPAIR sabitini nasıl kullanırsınız?

Bazen bağlantı sağlamdır ama veritabanı tabloları bozulmuştur. Ani elektrik kesintisi, sunucu çökmesi ya da yarım kalan bir güncelleme buna yol açabilir. WordPress bu durum için yerleşik bir onarım aracı sunar.

Resmi belgelere göre onarımı etkinleştirmek için wp-config.php dosyasına WP_ALLOW_REPAIR sabitini true değeriyle tanımlayan bir satır eklersiniz. Ardından sitenizin adresinin sonuna wp-admin/maint/repair.php yolunu yazıp sayfayı açarsınız. Sayfada onarım ya da onarım ve en iyileştirme seçeneklerini görürsünüz.

Burada dikkat edeceğiniz üç nokta var:

1. Önce yedek alın, çünkü onarım tabloları değiştirir.
2. Belgelere göre bu özellik etkinken kullanıcının giriş yapması gerekmez, bu yüzden sayfaya herkes ulaşır.
3. Onarım biter bitmez eklediğiniz satırı silin.

Satırı unutursanız başkaları da onarım sayfasına ulaşabilir. Bu nedenle işlemi kısa tutun ve sonunda sayfanın kapandığını kontrol edin. Kod bloğu paylaşmıyoruz, çünkü satırın tam biçimi resmi belgede zaten yer alıyor.

Onarım tamamlanınca WordPress hangi tabloları kontrol ettiğini ve hangilerini onardığını listeler. Hata devam ederse tablo sorunu dışında bir neden vardır. Onarım aracı bağlantı bilgisi hatalarını çözmez, yalnızca tabloları düzeltir. Dolayısıyla bilgiler yanlışsa onarım sayfası da açılmaz, önce bağlantı sorununu çözmeniz gerekir.

Taşıma sonrası bu hata neden sık çıkar?

Siteyi yeni hostinge, yeni alan adına ya da yerel ortamdan canlıya taşıdığınızda bu hata sık çıkar. Çünkü veritabanı adı, kullanıcı ve host değerleri her ortamda farklıdır. Dosyaları kopyalayıp wp-config.php içindeki eski değerleri bırakırsanız bağlantı kurulamaz.

Taşıma sonrası şu listeyi kontrol edin:

• Yeni hostingte veritabanını oluşturdunuz mu?
• Yedekteki veritabanını doğru veritabanına içe aktardınız mı?
• Kullanıcıyı veritabanına bağlayıp yetki verdiniz mi?
• wp-config.php dosyasındaki dört bilgiyi yeni değerlerle güncellediniz mi?
• İçe aktarma sırasında hata ya da yarım kalma oldu mu?

Yedek alma ve geri yükleme tarafında veritabanı yedekleme ve geri yükleme rehberimiz yol gösterir. Taşımanın tamamını planlamak için hosting değiştirme kontrol listesini kullanın. Böylece eski sunucuyu silmeden önce her şeyi doğrulamış olursunuz.

Alan adı taşıma ile hosting taşımayı karıştırmayın. Alan adını başka bir yere yönlendirmek veritabanı bilgilerini değiştirmez. Değişen şey, sitenizin dosyalarının bulunduğu sunucudur. Dolayısıyla taşıma sonrası hata alıyorsanız yeni sunucudaki değerleri yazın. Eski sunucudaki değerler artık geçerli olmayabilir.

Yönetim panelinde farklı bir mesaj çıkarsa ne anlama gelir?

Bazen ön yüz çalışır ama yönetim panelinde başka bir mesaj çıkar. Bu, WordPress'in veritabanına bağlanabildiğini, ancak bir sorunla karşılaştığını gösterir. Dolayısıyla "bağlantı kurulamadı" mesajıyla aynı çözüme gitmemelisiniz.

Panelde karşılaşabileceğiniz durumları şöyle özetleriz:

• Veritabanı tablolarının eksik ya da onarım gerektirdiğini söyleyen benzeri bir uyarı. Bu durumda onarım aracını deneyin.
• Yönetim panelinin veritabanını güncellemenizi istemesi. Bu, ayrı bir güncelleme akışıdır.
• Yalnızca yönetim ekranının gelmemesi, ön yüzün sorunsuz çalışması. Bu genellikle eklenti ya da tema çakışmasıdır.

Mesajın tam metni sürüme ve dile göre değişebilir. Bu yüzden birebir metne takılmayın. Mesajın bağlantı mı, tablo mu, yoksa güncelleme mi konusunda olduğuna bakın ve nedene göre ilerleyin.

Site saldırıya uğradığında da veritabanı hatası çıkar mı?

Evet, çıkabilir. WordPress belgeleri, hata mesajının nedenleri arasında ele geçiren bir saldırıyı da sayar. Saldırgan veritabanı bilgilerini değiştirmiş, tabloları silmiş ya da dosyaları bozmuş olabilir.

Şu işaretler güvenlik sorununa işaret eder:

• Hatadan önce siteyi hiç değiştirmediniz ama bilgiler aniden hatalı hale geldi.
• Dosyalarda tanımadığınız yeni dosyalar ya da değişen tarihler var.
• Arama sonuçlarında sitenizle ilgisiz içerik çıkıyor.
• Hosting sağlayıcınız kötü amaçlı yazılım uyarısı gönderdi.

Böyle bir durumda parolaları değiştirin ve yedeğinizi kontrol edin. Ayrıntılı adımlar için WordPress sitem saldırıya uğradı rehberimize bakın. Ayrıca para karşılığı site kurtarma vaat eden tanımadık kişilere yönetim erişimi vermeyin. Bu, ikinci bir güvenlik sorunu yaratır.

Güvenlik şüphesinde sırayı doğru kurun. Önce yönetim ve hosting parolalarını değiştirin. Ardından dosya değişikliklerini sağlayıcınızın kayıtlarıyla karşılaştırın. Temiz bir yedeğe dönmek çoğu zaman en güvenli yoldur. Bu süreçte sistemi atlatan kısa yollar denemeyin, çünkü hesabınızı ve müşterilerinizi riske atarsınız.

Hangi belirti hangi nedene işaret eder?

Aşağıdaki tablo, belirtiyi olası nedenle eşleştirir. Kesin teşhis yerine ilk bakacağınız yeri gösterir.

Tablodaki sıra kesin değildir. Birden fazla neden aynı anda var olabilir, bu yüzden her kontrolü sırayla bitirin.

Eklenti ve tema veritabanı bağlantısı kurulurken hata oluştu uyarısını tetikler mi?

Genellikle tetiklemez, çünkü bağlantı bilgisi eklentilerden bağımsızdır. Yine de dolaylı etkileri olabilir. Ağır çalışan bir eklenti her sayfada onlarca sorgu çalıştırır ve kaynak sınırını doldurur. Sınır dolunca sağlayıcı bağlantıları reddeder, siz de aynı mesajı görürsünüz.

Bir eklentiden şüpheleniyorsanız şu yolu izleyin:

1. Hata başlamadan hemen önce hangi eklentiyi eklediğinizi ya da güncellediğinizi hatırlayın.
2. FTP ile wp-content klasörüne girin ve eklentiler klasörünün adını geçici olarak değiştirin.
3. Siteyi yeniden açın ve hatanın gidip gitmediğine bakın.
4. Hata gittiyse klasörün adını geri verin ve eklentileri tek tek etkinleştirin.

WordPress belgeleri de eklenti sorunlarında aynı klasör adını değiştirme yöntemini önerir. Ancak bağlantı bilgisi gerçekten yanlışsa bu deneme sonuç vermez. Bu nedenle eklenti kontrolünü, bilgi kontrolünden sonra yapın.

Veritabanı bağlantısı kurulurken hata oluştu mesajı SEO'nuzu etkiler mi?

Kısa süreli kesintiler genellikle kalıcı bir zarar bırakmaz. Arama motorları sitenize ulaşamadığında sayfayı hemen sonuçlardan çıkarmaz, daha sonra yeniden dener. Ancak hata saatlerce ya da günlerce sürerse tarama sıklığı düşebilir ve sayfalarınız sonuçlarda geriye düşebilir.

Bu süreçte iki şeyi yapın. İlk olarak sorunu olabildiğince hızlı çözün. Ardından Google Search Console'da tarama hatalarının arttığını gözlemleyin. Sunucu kaynaklı geçici hataların mantığını 503 Service Unavailable rehberimizde anlattık.

Sorun çözüldükten sonra site haritanızı ve önemli sayfalarınızı kontrol edin. Ayrıca raporlarda anormal bir düşüş görürseniz Search Console ile trafik düşüşü tespiti yazısındaki adımlara bakın. Kesin bir etki süresi vaat edemeyiz, çünkü sonuç sitenize ve kesintinin uzunluğuna göre değişir.

Yerel ortamda aynı hata neden çıkar?

Bilgisayarınızda yerel bir WordPress kurulumu çalıştırıyorsanız aynı uyarıyı yine görebilirsiniz. Yerel araçlar veritabanı sunucusunu ayrı bir hizmet olarak çalıştırır. Hizmet kapalıysa WordPress bağlanacak yer bulamaz.

Yerel ortamda en sık şu nedenlerle karşılaşırsınız:

• Veritabanı hizmetini başlatmayı unuttunuz.
• Bilgisayarı yeniden başlattıktan sonra hizmet kendiliğinden açılmadı.
• Başka bir program aynı bağlantı noktasını kullanıyor.
• Canlı sitenin yapılandırma dosyasını yerel ortama kopyaladınız.

Son madde özellikle sık görülür. Canlı sitenin bilgileri yerelde işe yaramaz. Dolayısıyla yerel ortama özel bir veritabanı ve kullanıcı tanımlayın. Canlıya geçerken de bilgileri yeniden güncellemeyi unutmayın.

Yedeğiniz yoksa veritabanı sorununu nasıl çözersiniz?

Yedek yoksa en önemli kural, onarımı ve silme işlemlerini aceleyle yapmamaktır. Önce mevcut durumu koruyun. Hosting panelinde veritabanını dışa aktarabiliyorsanız hemen bir kopya alın. Panel de açılmıyorsa sağlayıcınızdan sunucu tarafı yedeği isteyin.

Birçok sağlayıcı kendi sistem yedeğini belli bir süre saklar. Bu yedeğin kapsamı ve tarihi sağlayıcıya göre değişir, bu yüzden varlığını garanti sayamayız. Kendi yedeğiniz olmadığında bile sağlayıcının destek ekibi seçenekleri anlatır.

Kopyayı aldıktan sonra tablolara onarım aracıyla dokunun. Böylece onarım beklenmedik bir sonuç verirse geri dönebilirsiniz. Gelecekte aynı riski taşımamak için yedek düzeni kurmak şarttır. Bu konuda yedekleme rehberimiz size bir başlangıç noktası sunar.

Çözerken hangi hatalardan kaçınmalısınız?

Panik halinde atılan adımlar sorunu büyütebilir. Aşağıdaki hatalar en sık yaptığımız gözlemlerdir ve genel bir saha deneyimi olarak paylaşıyoruz.

• Birden fazla şeyi aynı anda değiştirmek. Hangisinin işe yaradığını anlayamazsınız.
• Yedek almadan onarım aracını çalıştırmak.
• Onarım sabitini açık bırakmak.
• Canlı sitenin yapılandırma dosyasını sohbet ya da e-posta ile paylaşmak.
• Veritabanını silip sıfırdan kurmak. Böylece tüm içeriğinizi kaybedebilirsiniz.
• Tanımadığınız kişilere yönetim erişimi vermek.

Her seferinde tek bir değişiklik yapın, sonucunu test edin ve not alın. Bu disiplin, destek ekibine anlatacağınız bilgiyi de netleştirir. Ayrıca yanlış gittiğinde geri dönmenizi sağlar.

Veritabanı bağlantısı kurulurken hata oluştu sorunu için tam kontrol listesi nedir?

Aşağıdaki sıra, yazının tamamını tek listede toplar. Adımları atlamadan ilerleyin.

1. Sayfayı yenileyin ve başka bir tarayıcıda deneyin.
2. Hosting panelinin ve veritabanı aracının açılıp açılmadığına bakın.
3. Aynı hesaptaki diğer sitelerin durumunu kontrol edin.
4. Yedeği indirin.
5. wp-config.php dosyasındaki ad, kullanıcı, parola ve host bilgilerini panelle karşılaştırın.
6. Kullanıcının doğru veritabanına bağlı ve yetkili olduğunu doğrulayın.
7. Kaynak kullanımına ve kota durumuna bakın.
8. Gerekirse onarım aracını açın, kullanın ve kapatın.
9. Eklenti klasörünü geçici olarak yeniden adlandırarak test edin.
10. Çözülmediyse sağlayıcınıza toplu bilgiyle başvurun.

Bu listeyi hata anında yanınızda tutun. Çoğu durumda ilk beş adımda sorunu bulursunuz.

Hatanın tekrar etmesini nasıl önlersiniz?

Sorunu çözdükten sonra tekrar yaşamamak için birkaç alışkanlık edinin. Çoğu veritabanı hatası, önlenebilir değişiklik hatalarından doğar.

• Düzenli yedek alın. Hem dosyaları hem veritabanını saklayın. Web sitesi yedekleme stratejisi yazımız size bir düzen sunar.
• Parolayı değiştirirken iki yeri birlikte güncelleyin: panel ve wp-config.php.
• Eklentileri ve temayı güncel tutun, ancak güncellemeden önce yedek alın.
• Kullanmadığınız eklentileri silin, böylece veritabanı yükünü azaltırsınız.
• Hosting kaynak kullanımını izleyin ve sınıra yaklaşınca paketi gözden geçirin.
• Taşıma yaparken bir kontrol listesi izleyin.

Ayrıca onarım sabitini ya da hata ayıklama sabitlerini işiniz biter bitmez kapatın. Açık kalan her tanı özelliği küçük bir güvenlik riskidir. Düzenli bakım, hatanın size en pahalıya patlayacağı anı, yani yoğun satış gününü de korur.

Bakım takvimi oluşturmak da işe yarar. Ayda bir kez yedeğinizi gerçekten geri yükleyebildiğinizi deneyin. Yedek dosyası olması başka, çalışan bir yedek olması başkadır. Ayrıca sağlayıcınızın bakım duyurularını takip edin ve önemli kampanya günlerinden önce büyük değişiklik yapmayın.

Ne zaman hosting sağlayıcınızdan ya da bir uzmandan destek almalısınız?

Kontrol listesini bitirdiyseniz ve hata sürüyorsa destek isteme zamanı gelmiştir. Veritabanı sunucusuna yalnızca sağlayıcınız erişir. Bu yüzden önce onlara yazın.

Destek talebinde şunları belirtin:

• Hatanın başladığı tarih ve saat.
• Hatadan önce yaptığınız son değişiklik.
• Hosting panelindeki veritabanı yönetim aracına ulaşıp ulaşamadığınız.
• Aynı hesaptaki başka sitelerin durumu.
• wp-config.php bilgilerini panelle karşılaştırdığınız.

Böylece destek ekibi sorunu daha çabuk daraltır. Hata kodla ilgiliyse deneyimli bir WordPress geliştiricisine başvurun. Sonuç garantisi veren, ön ödeme isteyen ya da erişim bilgisini mesajla isteyen kişilere güvenmeyin. Hiçbir kurtarma yönteminin sonucu garanti değildir.

Talha Aslan ve ekibi bu konuda nasıl destek olur?

Biz, İstanbul merkezli bir dijital pazarlama ekibiyiz ve hosting firması değiliz. Sunucu işletmiyoruz. Ancak web sitenizin yapısını, WordPress kurulumunu ve olası sorun noktalarını sizinle birlikte değerlendirebiliriz.

Yeni bir site kurarken ya da mevcut siteyi yenilerken web tasarım hizmetimiz bakım, yedek ve taşıma planını baştan planlar. Böylece bu tür kesintileri en baştan azaltmayı hedefleriz. Ayrıca sayfa performansınızı ölçmek için araçlarımızı deneyebilirsiniz.

Bu yazı genel bilgi amaçlıdır. Sunucu ayarlarınız sağlayıcıya göre değişir, bu nedenle menü adları ve adımlar farklı görünebilir. Güncel belge için WordPress'in resmi kaynaklarını kontrol edin: yaygın WordPress hataları, wp-config.php belgesi ve WordPress destek forumları.