WordPress bakım modu takıldı, .maintenance dosyası nasıl silinir?

WordPress bakım modu takıldı ve siteniz yalnızca 'Planlı bakım için kısa bir süreliğine kullanılamıyor. Bir dakika içinde tekrar kontrol edin.' yazısını gösteriyorsa, büyük ihtimalle bir güncelleme yarıda kesilmiş ve kök dizinde .maintenance dosyası kalmıştır. Bu dosyayı silmek siteyi çoğu zaman saniyeler içinde geri getirir.

Aşağıda dosyayı FTP, hosting dosya yöneticisi ve SSH ile nasıl sileceğinizi, yarım kalan eklentiyi nasıl tespit edip WP-CLI ile onaracağınızı ve aynı sorunun tekrarlanmaması için hangi PHP ayarlarını değiştirmeniz gerektiğini bulacaksınız.

WordPress neden bakım modunda takılı kalır?​

Yarıda kalan güncelleme siteyi bakım ekranında bırakır. — Fotoğraf: Christina Morillo / Pexels
WordPress bir eklenti, tema veya çekirdek güncellemesine başladığında kök dizine .maintenance adlı geçici bir dosya yazar ve iş bitince bu dosyayı siler. Güncelleme tarayıcı sekmesinin kapanması, PHP zaman aşımı, bellek yetersizliği ya da bağlantı kopması yüzünden yarıda kalırsa silme adımı hiç çalışmaz ve site bakım ekranında kalır.

İngilizce arayüzde aynı ekran Briefly unavailable for scheduled maintenance. Check back in a minute. metniyle görünür. Hangi dilde olursa olsun sebep aynıdır. Sorunu doğru teşhis edebilmek için güncellemenin arka planda hangi sırayla ilerlediğini bilmek işe yarar:

1. Yeni sürümün zip paketi indirilir ve wp-content/upgrade klasörüne açılır.
2. Kök dizinde .maintenance dosyası oluşturulur; ziyaretçiler bu andan itibaren bakım mesajını görür.
3. Eski eklenti veya tema klasörü kaldırılır. Yeni WordPress sürümlerinde eski klasör önce wp-content/upgrade-temp-backup altına yedeklenir.
4. Yeni dosyalar asıl yerine kopyalanır.
5. Gerekiyorsa veritabanı güncellemesi çalışır.
6. .maintenance silinir ve site normale döner.

Zincir 2 ile 6 arasındaki herhangi bir noktada koparsa dosya yerinde kalır. En sık görülen nedenler, yaygınlık sırasıyla şunlardır: toplu güncelleme sırasında sayfanın kapatılması veya yenilenmesi, PHP'nin max_execution_time süresinin dolması, memory_limit değerinin büyük bir paketi açmaya yetmemesi, hosting disk kotasının dolması, klasör izinlerinin kopyalamaya engel olması ve güncelleme sırasında sunucunun yeniden başlatılması.

Bir ayrıntı daha var. WordPress çekirdeği, dosyadaki zaman damgası 10 dakikadan eskiyse bakım modunu sona ermiş kabul edecek şekilde yazılmıştır. Yani 10 dakikadan uzun süredir aynı ekranı görüyorsanız ya bir önbellek katmanı eski bakım sayfasını sunuyordur ya da otomatik güncelleme aynı işlemi tekrar tekrar deneyip zaman damgasını tazeliyordur. Her iki durumda da ilk iş dosyayı elle silmektir.

.maintenance dosyası nedir, içinde ne yazar?​

.maintenance dosyası, WordPress'in kurulu olduğu kök dizinde, yani wp-config.php dosyasının bulunduğu klasörde oluşturulan tek satırlık bir PHP dosyasıdır. İçinde yalnızca güncellemenin başladığı anı gösteren bir Unix zaman damgası bulunur ve WordPress her istekte bu dosyanın varlığını kontrol eder.

Normal bir dosyanın içeriği şuna benzer (sayı sizde farklı olacaktır):


Dosyayı açtığınızda bu satırdan başka kod görüyorsanız, örneğin uzun şifrelenmiş satırlar, eval veya base64_decode gibi ifadeler varsa, sorun bir güncelleme değil zararlı yazılım olabilir. Bu durumda WordPress sitesine virüs bulaştığında izlenecek adımlara geçmeniz daha doğru olur.

Bakım ekranının görünümünü değiştiren ikinci bir dosya daha vardır: wp-content/maintenance.php. Bazı temalar ve bakım eklentileri bu dosyayı özel bir bakım sayfası için oluşturur. Bu dosya tek başına siteyi bakıma sokmaz; yalnızca .maintenance varken gösterilecek sayfayı belirler. Yine de sorunu çözdükten sonra kim tarafından oluşturulduğunu bilmediğiniz bir maintenance.php görüyorsanız içeriğine göz atın.

WordPress bakım modundan çıkma, dosyayı ortamınıza göre silin​

.maintenance dosyası wp-config.php ile aynı klasörde bulunur. — Fotoğraf: Cup of Couple / Pexels
Bakım modundan çıkmanın yolu, kök dizindeki .maintenance dosyasını silmektir. Bunu hosting panelinizin dosya yöneticisinden, FileZilla gibi bir FTP istemcisinden, SSH ile rm komutundan veya WP-CLI'ın maintenance-mode komutundan yapabilirsiniz. Hangisini kullanırsanız kullanın, dosyanın görünmesi için gizli dosyaların açık olması gerekir.

Silmeden önce doğru klasörde olduğunuzdan emin olun. WordPress alt klasöre kuruluysa (örneğin public_html/blog) dosya da o klasördedir. Ölçüt basit: wp-config.php, wp-admin ve wp-content hangi klasördeyse .maintenance da oradadır.

cPanel dosya yöneticisi ile silme​

1. cPanel'e girip Dosyalar bölümünden Dosya Yöneticisi'ni açın.
2. Sağ üstteki Ayarlar düğmesine tıklayın ve gizli dosyaları gösterme seçeneğini (dotfiles) işaretleyip kaydedin.
3. Sol ağaçtan public_html veya WordPress'in kurulu olduğu klasöre girin.
4. .maintenance dosyasına sağ tıklayıp Sil'i seçin.
5. Siteyi gizli (incognito) pencerede açarak kontrol edin.

Plesk üzerinden silme​

1. Web Siteleri ve Alan Adları altında ilgili alan adının Dosyalar (Dosya Yöneticisi) bağlantısına tıklayın.
2. httpdocs klasörüne veya WordPress'in kurulu olduğu alt klasöre girin.
3. .maintenance satırının yanındaki kutuyu işaretleyip Kaldır'a basın.

Plesk sürümüne göre menü adları biraz farklı olabilir; WP Toolkit kuruluysa aynı klasöre oradaki dosya yöneticisi kısayolundan da ulaşabilirsiniz.

FTP ile silme​

FileZilla'da sunucuya bağlandıktan sonra üst menüden Sunucu → Gizli dosyaları göstermeye zorla seçeneğini açın, sağ paneldeki listeyi yenileyin ve kök dizindeki .maintenance dosyasını silin. Dosya listede yine görünmüyorsa FTP kullanıcınızın başka bir klasöre kilitli olup olmadığını kontrol edin; bazı hostinglerde FTP hesabı yalnızca bir alt klasörü görür.

SSH ile rm komutu​

Sunucuya SSH erişiminiz varsa en hızlı yol budur:


ls -la gizli dosyaları da listeler, dolayısıyla dosyanın gerçekten orada olup olmadığını silmeden önce görürsünüz. VPS'te site kökü genellikle /var/www/siteadi gibi bir yoldadır; cd satırını kendi yolunuza göre değiştirin.

WP-CLI ile bakım modunu kapatma​

WP-CLI kuruluysa dosyayı elle aramanıza gerek kalmaz. Komutları WordPress kök dizininde çalıştırın:


İlk komut bakım modunun açık olup olmadığını söyler, ikincisi .maintenance dosyasını kaldırır. Komutların tam listesi ve parametreleri için WP-CLI resmi komut dokümantasyonuna bakabilirsiniz.

Gizli dosyalar görünmüyorsa .maintenance dosyasını nerede bulursunuz?​

Adı noktayla başlayan dosyalar Linux sunucularda gizli kabul edilir ve çoğu dosya yöneticisi ile FTP istemcisi bunları varsayılan olarak listelemez. 'Dosya yok ama site bakımda' şikâyetinin büyük kısmı bundan kaynaklanır. Aşağıdaki tablo, yaygın araçlarda gizli dosyaları açmanın yolunu özetliyor:


Menü adları programın ve panelin sürümüne göre küçük farklılıklar gösterebilir. Gizli dosyaları açtığınızda aynı klasörde .htaccess dosyasını da göreceksiniz; onu silmeyin, yalnızca .maintenance ile işiniz var.

Dosyayı sildim ama site hâlâ açılmıyor, ne yapmalı?​

Dosyayı sildikten sonra ekranda ne gördüğünüz, sorunun nerede olduğunu doğrudan söyler. Bakım yazısı sürüyorsa sorun büyük ihtimalle önbellektir; kritik hata ya da beyaz ekran görüyorsanız güncellemesi yarım kalan bir eklenti veya tema siteyi çökertiyordur. Aşağıdaki eşleştirmeyi yukarıdan aşağıya takip edin.

• Bakım mesajı hâlâ görünüyor: Siteyi gizli pencerede ve adresin sonuna ?test=1 ekleyerek açın. Orada düzgün açılıyorsa önbellek eklentinizin önbelleğini temizleyin; panele giremiyorsanız wp-content/cache klasörünün içini boşaltın. Cloudflare kullanıyorsanız Önbellek → Yapılandırma altından tüm önbelleği temizleyin. Gizli pencerede de mesaj çıkıyorsa dosyayı yanlış klasörden silmiş olabilirsiniz.
• 'Bu web sitesinde kritik bir hata oluştu' yazıyor: Yarım kalan eklenti veya tema PHP hatası veriyordur. Bir sonraki bölümdeki teşhis adımlarına geçin.
• Bembeyaz bir sayfa geliyor: Sebep genellikle yine yarım dosyalardır; ayrıntılı çözüm için WordPress beyaz ekran hatası ve çözüm yolları konusuna bakın.
• 500 Internal Server Error alıyorsunuz: Bozuk bir .htaccess ya da eksik kopyalanmış bir dosya olabilir; WordPress 500 Internal Server Error hatasının düzeltilmesi başlığındaki adımlar burada da geçerli.
• 'Veritabanı güncellemesi gerekli' ekranı çıkıyor: Çekirdek dosyaları kopyalanmış ama veritabanı adımı çalışmamış demektir. Ekrandaki WordPress veritabanını güncelle düğmesine basın ya da wp core update-db komutunu çalıştırın.
• 'Veritabanı bağlantısı kurulurken hata' görüyorsunuz: Bu, güncellemeden bağımsız bir sorundur; veritabanı bağlantı hatasının çözüm yolları konusundan devam edin.

WordPress güncelleme yarım kaldıysa bozulan eklenti nasıl tespit edilir?​

verify-checksums komutu bozuk eklenti dosyalarını listeler. — Fotoğraf: Nemuel Sereti / Pexels
Yarım kalan güncellemeyi bulmak için üç yere bakın: wp-content/upgrade klasöründe kalan paketler, wp-content/upgrade-temp-backup içindeki eski sürüm yedekleri ve Eklentiler sayfasındaki 'Eklenti dosyası mevcut değil' uyarısı. Bunlara ek olarak eklentinin dosyalardaki sürüm numarasını beklenen sürümle karşılaştırarak eksik kopyalamayı yakalayabilirsiniz.

Klasörlerde kalan izleri okuyun​

Dosya yöneticisinde wp-content/upgrade klasörünü açın. Normalde bu klasör boştur ya da neredeyse boştur. İçinde bir eklentinin adını taşıyan klasör görüyorsanız paket açılmış ama asıl yerine taşınamamıştır; takılan güncelleme odur. Bu klasörün içeriğini güvenle silebilirsiniz.

wp-content/upgrade-temp-backup/plugins (temalar için themes) altında bir klasör kaldıysa, o eklentinin eski sürümü güncelleme öncesinde buraya yedeklenmiş demektir. wp-content/plugins altında aynı eklenti hiç yoksa ya da yarım görünüyorsa, yedeği geri taşıyarak siteyi eski sürümle ayağa kaldırabilirsiniz.

Panele girebiliyorsanız Eklentiler sayfasının üstüne bakın. 'Eklenti dosyası mevcut değil' gerekçesiyle devre dışı bırakılan bir eklenti listeleniyorsa, eski klasör silinmiş ama yenisi kopyalanamamıştır.

Sürüm numaralarını karşılaştırın​

Klasör yerinde görünse bile dosyaların yalnızca bir kısmı kopyalanmış olabilir. Eklentinin ana PHP dosyasını açıp başlıktaki Version: satırına bakın ve bunu eklentinin wordpress.org sayfasındaki güncel sürümle karşılaştırın. SSH erişiminiz varsa bu iş tek komutla yapılır:


İlk komut her eklentinin kurulu sürümünü ve bekleyen güncellemesini gösterir. İkincisi, wordpress.org dizinindeki eklentilerin dosyalarını resmi sağlama toplamlarıyla (checksum) karşılaştırır; eksik ya da farklı dosya varsa hangi eklentinin bozulduğunu satır satır listeler. Üçüncüsü aynı kontrolü çekirdek dosyaları için yapar. Ücretli, wordpress.org dışından gelen eklentilerde checksum doğrulaması çalışmaz; onlar için sürüm satırına ve dosya tarihlerine bakmanız gerekir.

Eklenti güncellemesi takıldıysa WP-CLI ile nasıl tekrar güncellenir?​

Bozuk eklentiyi tespit ettikten sonra WP-CLI ile o eklentiyi tek başına yeniden güncellemek ya da --force parametresiyle sıfırdan kurmak en temiz yoldur. Komut satırında çalışan PHP, web isteklerindeki zaman aşımına takılmadığı için tarayıcıda yarım kalan güncelleme burada genellikle sorunsuz tamamlanır.

Örnek olarak WooCommerce'in takıldığını varsayalım:


İlk komut normal güncellemeyi tekrar dener. Eklenti klasörü yarım kaldığı için güncelleme hata verirse ikinci komut, mevcut klasörün üzerine güncel sürümü baştan yazar. Ayarlar veritabanında durduğu için yeniden kurulum ayarlarınızı silmez. Tema ve çekirdek için karşılıkları şunlardır:


Ücretli bir eklentiyse geliştiricinin sitesinden güncel zip dosyasını indirip sunucuya yükleyin ve şu şekilde kurun:

SSH erişiminiz yoksa​

Paylaşımlı hostinglerin bir kısmında WP-CLI yoktur. Bu durumda elle ilerleyebilirsiniz:

1. Dosya yöneticisinde wp-content/plugins/eklenti-adi klasörünün adını eklenti-adi-eski olarak değiştirin. WordPress eklentiyi bulamayınca onu devre dışı bırakır ve site açılır.
2. Yönetim panelinde Eklentiler → Yeni Ekle → Eklenti Yükle yolunu izleyip güncel zip dosyasını yükleyin.
3. Eklentiyi etkinleştirin, siteyi kontrol edin ve her şey yolundaysa eklenti-adi-eski klasörünü silin.

Panele bile giremiyorsanız zip dosyasını bilgisayarınızda açıp klasörü FTP ile doğrudan wp-content/plugins altına yüklemek de aynı sonucu verir.

Bakım modu takılması bir daha yaşanmasın diye ne yapmalı?​

max_execution_time ve memory_limit değerleri güncelleme başarısını doğrudan etkiler. — Fotoğraf: panumas nikhomkhai / Pexels
Tekrarı önlemenin iki temel yolu var: güncellemeleri küçük gruplara bölmek ve PHP'nin max_execution_time ile memory_limit değerlerini büyük paketleri kaldıracak seviyeye çekmek. Bunlara ek olarak güncelleme sırasında sekmeyi kapatmamak ve disk kotasında boş alan bırakmak takılma riskini belirgin biçimde azaltır.

Toplu güncellemeyi bölün​

Eklentiler sayfasında hepsini seçip tek seferde güncellemek, bütün işi tek bir PHP isteğine yükler. On beş eklentiden biri yavaş inerse süre dolar ve geri kalan her şey yarıda kalır. Güncellemeleri ikişer üçer yapın; WooCommerce, Elementor gibi büyük paketleri ve sayfa oluşturucuları tek başına güncelleyin. Çok sayıda eklentiyi yönetiyorsanız WordPress'te toplu eklenti yükleme konusundaki yöntemlere de göz atabilirsiniz; ama kurulumla güncellemeyi aynı anda yapmamaya dikkat edin.

Otomatik güncellemeleri tamamen kapatmak zorunda değilsiniz. Küçük eklentilerde açık bırakıp siteye bağımlı büyük eklentilerde Eklentiler sayfasındaki otomatik güncelleme bağlantısını kapatmak dengeli bir yoldur.

max_execution_time değerini yükseltin​

PHP'nin resmi dokümantasyonuna göre max_execution_time varsayılan olarak 30 saniyedir ve komut satırında (CLI) bu sınır uygulanmaz; ayrıntılar php.net yapılandırma sayfasında yer alıyor. Güncellemeler için 300 saniye makul bir değerdir.


VPS'te php.ini konumunu öğrenip değeri düzenlemek için:


Yoldaki ve servis adındaki 8.2 kısmını sunucunuzdaki PHP sürümüyle değiştirin. Dosyada şu satırları bulup güncelleyin:


PHP-FPM kullanan paylaşımlı hostinglerde kök dizine .user.ini adlı bir dosya oluşturup aynı iki satırı yazabilirsiniz; değişikliğin etkinleşmesi birkaç dakika sürebilir. Apache'nin mod_php modülüyle çalışan sunucularda ise .htaccess içine şu satır eklenir:


PHP-FPM kullanan bir sunucuda bu .htaccess satırı 500 hatasına yol açar; öyle bir durumda satırı silip .user.ini yöntemine geçin. Bellek tarafındaki ayarlar ve WP_MEMORY_LIMIT sabiti için WordPress PHP bellek limit hatası konusunu inceleyebilirsiniz.

Küçük ama işe yarayan alışkanlıklar​

• Güncellemeden önce hosting panelinden disk kullanımına bakın; kota doluysa paket açılamaz ve dosyalar yarım kopyalanır.
• Güncelleme sürerken sayfayı yenilemeyin, sekmeyi kapatmayın, bilgisayarı uyku moduna sokmayın.
• Büyük güncellemelerden önce dosya ve veritabanı yedeği alın; yarım kalan bir güncellemede yedekten dönmek dakikalar sürer.
• SSH erişiminiz varsa güncellemeleri tarayıcı yerine wp plugin update ile yapın; zaman aşımı sorunu büyük ölçüde ortadan kalkar.

Sıkça Sorulan Sorular​

Bakım modu kendiliğinden kalkar mı?​

WordPress çekirdeği, .maintenance dosyasındaki zaman damgası 10 dakikadan eskiyse bakım modunu bitmiş sayar. Ancak önbellek eski bakım sayfasını sunmaya devam edebilir ya da otomatik güncelleme yeniden denendikçe dosya tazelenebilir. Beklemek yerine dosyayı silmek her zaman daha hızlı ve güvenlidir.

.maintenance dosyasını silmek siteye zarar verir mi?​

Hayır. Dosya yalnızca bakım ekranını tetikleyen geçici bir işarettir ve içinde site verisi yoktur. Zarar varsa o, yarım kalan güncellemeden gelir; dosyayı sildikten sonra eklenti ve temaların düzgün çalıştığını kontrol etmeniz bu yüzden önemlidir.

Dosyayı bulamıyorum ama site hâlâ bakımda görünüyor, neden?​

En olası neden gizli dosyaların gösterilmemesidir; dosya yöneticinizde dotfiles seçeneğini açın. İkinci ihtimal yanlış klasöre bakmanızdır, dosya wp-config.php ile aynı dizindedir. Dosya gerçekten yoksa gördüğünüz şey önbellekteki eski bakım sayfasıdır.

Hangi eklentinin güncellemesinin yarım kaldığını nereden anlarım?​

wp-content/upgrade klasöründe adı geçen paket, wp-content/upgrade-temp-backup içinde kalan yedek ve Eklentiler sayfasındaki 'Eklenti dosyası mevcut değil' uyarısı doğrudan ipucudur. SSH erişiminiz varsa wp plugin verify-checksums --all komutu bozuk dosyaları içeren eklentiyi listeler.

Siteyi kasıtlı olarak bakıma almak için bu dosyayı kullanabilir miyim?​

Teknik olarak mümkündür ama zaman damgası 10 dakikadan eski olduğunda WordPress dosyayı yok sayar. Planlı bakım için wp maintenance-mode activate komutu ya da bir bakım modu eklentisi daha kontrollü sonuç verir.

Otomatik güncellemeleri kapatmalı mıyım?​

Tamamen kapatmak güvenlik açıklarının geç kapanmasına yol açabilir. Küçük eklentilerde otomatik güncellemeyi açık bırakıp büyük ve siteye kritik eklentileri elle, tek tek ve yedek aldıktan sonra güncellemek daha dengeli bir yaklaşımdır.

Kısacası, bakım ekranında takılan bir sitede önce kök dizindeki .maintenance dosyasını silin, ardından ekranda gördüğünüz belirtiye göre önbelleği ya da yarım kalan eklentiyi ele alın. Güncellemeleri küçük gruplara bölüp PHP süre ve bellek sınırlarını yükselttiğinizde bu ekranla karşılaşma ihtimaliniz epey düşer.

Sizin sitenizde bakım modu hangi eklentinin güncellemesi sırasında takıldı ve hangi yöntemle çözdünüz?