WordPress bakım modunda takılı kalma hatası nasıl çözülür?

Kısa yanıt

WordPress bakım modunda takılı kalma hatası, bir çekirdek, tema veya eklenti güncellemesi tam bitmeden kesintiye uğradığında ortaya çıkar; siteniz “Briefly unavailable for scheduled maintenance” mesajıyla saatlerce açılmaz hâle gelebilir. Nedeni her zaman aynıdır: güncelleme sırasında oluşturulan .maintenance dosyası silinmemiştir. Dosyayı bulup silmek genellikle beş dakikadan kısa sürer ve veri kaybı.

Riski taşımaz.

WordPress bakım modunda takılı kalma hatası neden oluşur?

WordPress, çekirdek, tema veya eklenti güncellemesi başlattığınızda ziyaretçilere yarım kalmış bir sürümü göstermemek için siteyi geçici olarak kilitler; bunu kök dizine bıraktığı .maintenance adlı gizli bir dosyayla yapar. Güncelleme normal şekilde bittiğinde WordPress bu dosyayı otomatik olarak siler ve site anında eski hâline döner. WordPress’in kendi geliştirici referansına göre bu kontrol tam olarak dosyanın varlığına bakarak yapılır; dosya orada olduğu sürece site bakım modunda kabul edilir.

Sorun, güncelleme herhangi bir nedenle tam bitmeden kesildiğinde başlar: dosya kök dizinde kalır, WordPress hâlâ “güncelleme sürüyor” sanır ve ziyaretçilere göstermeye devam ettiği tek şey aynı bakım mesajıdır. Kesintinin kendisi genellikle üç kaynaktan birine dayanır: paylaşımlı hostingde PHP çalışma süresi sınırının güncelleme paketini indirip açmaya yetmemesi, güncelleme sırasında tarayıcı sekmesinin kapatılması veya bağlantının kesilmesi, ya da aynı anda ikinci bir güncellemenin başlatılması. Hangi neden olursa olsun sonuç aynıdır: WordPress bakım modunda takılı kalır ve kendi kendine çıkamaz.

.maintenance dosyasını FTP veya dosya yöneticisiyle silin

En hızlı ve en güvenli çözüm, .maintenance dosyasını doğrudan silmektir. FTP istemcinizle (FileZilla gibi) veya hosting panelinizin dosya yöneticisiyle sitenizin kök dizinine gidin; bu, wp-config.php dosyasını gördüğünüz aynı klasördür. Dosya adının başındaki nokta onu gizli dosya yapar; dosya yöneticinizde gizli dosyaları gösterme seçeneği kapalıysa .maintenance’ı listede göremezsiniz.

Dosyayı bulduğunuzda tek yapmanız gereken onu silmektir; içeriğini incelemenize veya yedeklemenize gerek yoktur, WordPress onu bir sonraki güncellemede yeniden oluşturur. Silme işleminden sonra sitenizi yenileyin, gerekirse tarayıcı önbelleğini de temizleyin; bakım modu mesajı anında kaybolmalı ve site normal hâline dönmelidir.

Dosyayı bulamıyorsanız: gizli dosyaları gösterin

cPanel Dosya Yöneticisi’nde “Ayarlar” menüsünden “Gizli dosyaları göster” (dotfiles) seçeneğini işaretleyin. FTP istemcilerinde bu genellikle “Sunucu” veya “Görünüm” menüsünde “Gizli dosyaları göster” olarak geçer. Bazı hosting sağlayıcıları .maintenance dosyasını farklı bir zaman damgasıyla bırakabilir; kök dizinde nokta ile başlayan ve güncelleme tarihinizle eşleşen başka bir dosya görürseniz onu da kontrol edin.

Yönetim paneline girebiliyorsanız bu kısa yolu deneyin

Bazı durumlarda bakım modu yalnızca ön yüzü kilitler, /wp-admin/ paneline hâlâ girebilirsiniz. Bu senaryoda dosyaya hiç dokunmadan panelden Araçlar > Site Sağlığı ekranına gidip güncellemeler sekmesini kontrol edebilir, yarım kalan bir güncelleme varsa “Şimdi güncelle” seçeneğiyle işlemi elle tamamlayabilirsiniz. Panel yanıt veriyorsa bu, dosyaya elle dokunmaktan daha az risklidir çünkü WordPress güncellemeyi kendi mantığıyla bitirir ve dosyayı doğru zamanda kendisi kaldırır.

WP-CLI ile bakım modunu kapatma

Sunucunuzda komut satırı erişiminiz ve WP-CLI kuruluysa sorunu tek komutla çözebilirsiniz:

wp maintenance-mode deactivate

Bu komut .maintenance dosyasını WP-CLI üzerinden güvenli biçimde kaldırır ve dosyaya FTP ile dokunmadan aynı sonucu verir; özellikle yönetilen sunucu ortamlarında veya birden fazla siteyi aynı anda yöneten ekipler için pratik bir seçenektir.

Bakım modu neden kendi kendine kapanmıyor

WordPress’in bu dosyayı otomatik silmesi için güncelleme betiğinin sonuna kadar çalışması gerekir; betik ortada kesilirse temizlik adımı da hiç çalışmaz. Bu yüzden “biraz bekleyeyim, kendi kapanır” beklentisi çoğu zaman yanılgıdır: dosya orada durduğu sürece WordPress her istek geldiğinde aynı kontrolü yapar ve aynı mesajı göstermeye devam eder. Tek gerçek çözüm dosyayı elle kaldırmak veya güncellemeyi WP-CLI ya da panel üzerinden yeniden tetiklemektir.

Bakım modu hatasını diğer WordPress hatalarından ayırt edin

WordPress bakım modunda takılı kalma hatası, beyaz ekran hatasıyla veya “kritik bir hata oluştu” mesajıyla sık sık karıştırılır, ama üçü farklı sinyallerdir. Beyaz ekran genellikle tamamen boş, mesajsız bir sayfadır ve bir PHP hatasına işaret eder; “kritik bir hata oluştu” mesajı bir eklenti veya tema çakışmasını gösterir. Bakım modu ise her zaman aynı, tanıdık bir metinle (“Briefly unavailable for scheduled maintenance, check back in a minute”) gelir ve bu netlik aslında iyi haberdir: mesajın kendisi size sorunun tam olarak nerede olduğunu söyler; hata ayıklama günlüğüne bakmanıza gerek kalmaz.

Bu ayrımı doğru yapmak zaman kazandırır. Bakım modu mesajını görüp doğrudan eklenti listesini teker teker devre dışı bırakmaya çalışmak (beyaz ekran veya kritik hata için doğru bir ilk adım olsa da) burada gereksizdir; sorun bir kod çatışmasında değil, tek bir dosyanın varlığındadır. Doğru teşhis, doğru çözüme daha hızlı ulaştırır.

Güncellemeleri güvenli şekilde yeniden başlatın

Dosyayı sildikten sonra sitenizin gerçekten güncel olup olmadığını kontrol etmeden bırakmayın. Panel > Güncellemeler ekranına girip yarım kalan çekirdek, tema veya eklenti güncellemesi varsa bunu tek tek yeniden başlatın; birden çok eklentiyi aynı anda güncellemek yerine teker teker güncellemek, aynı kesintinin tekrarlanma riskini azaltır. Güncelleme büyükse, özellikle bir çekirdek sürüm atlamasıysa, işlemi trafiğin düşük olduğu bir saatte yapmak PHP çalışma süresi sınırına çarpma riskini de düşürür.

Bu hatayı tekrar yaşamamak için

Bakım modunda takılı kalma büyük ölçüde önlenebilir bir sorundur. Paylaşımlı hostingde PHP max_execution_time değerini hosting panelinizden makul bir üst sınıra (örneğin 120-300 saniye) çıkarmak, büyük güncellemelerin zaman aşımına uğramasını azaltır. Güncellemeleri yoğun trafik saatlerinde değil, düşük trafikli bir zaman diliminde yapmak, kesinti anında az ziyaretçinin etkilenmesini sağlar. Otomatik arka plan güncellemelerini özellikle küçük sürüm güncellemeleri için açık tutmak, elle başlatılan bir güncellemeyle çakışma olasılığını azaltır; büyük sürüm güncellemelerinde ise önce bir hazırlık (staging) ortamında test etmek en güvenli yoldur. Büyük bir çekirdek güncellemesinden önce güncel bir yedek almak da bakım modunda takılı kalma riskini sıfırlamaz ama güncelleme başka bir nedenle daha ciddi bir hataya dönüşürse geri dönüş süresini dakikalara indirir. Bu tür kritik hataların WordPress’teki diğer yaygın biçimlerini WordPress beyaz ekran hatası rehberimizde ele alıyoruz; üçü de aynı köke, yarım kalmış bir işleme dayanır.

Ne zaman hosting desteğine ihtiyaç duyarsınız

.maintenance dosyasını sildikten sonra site hâlâ açılmıyorsa veya güncelleme her denemede aynı noktada kesiliyorsa, sorun artık dosyanın kendisinde değildir; hosting altyapısında bir kaynak sınırı (disk kotası, bellek limiti) veya sunucu tarafı bir kesinti olabilir. Bu durum, veritabanı bağlantısı kurulamadı hatasında anlattığımız sunucu kaynaklı senaryolara benzer. Bu noktada hosting sağlayıcınızın teknik destek ekibine hangi güncellemeyi denediğinizi ve tam hata mesajını net biçimde iletmek, sizin panelden göremeyeceğiniz bir seviyeyi çözebilir.

Sonraki adım

WordPress bakım modunda takılı kalma hatası, görüntüsü kadar ürkütücü değildir; çoğu durumda tek bir dosyayı bulup silmekle, veri kaybı riski taşımadan dakikalar içinde çözülür. Sorun sunucu tarafında tekrarlıyorsa veya güncellemeleriniz büyüdükçe bu tür kesintilere karşı daha dayanıklı bir altyapı istiyorsanız, grup şirketimiz Web Tasarım Ofisi WordPress kurulumu, bakımı ve teknik sorun giderme konusunda destek veriyor.

Sitenizin teknik altyapısını veya özel yazılım ihtiyaçlarınızı birlikte değerlendirmek için özel yazılım hizmetimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz.