Bir tema güncellendiğinde WordPress, wp-content/themes/ altındaki tema klasörünün eski içeriğini kaldırır ve yerine yeni sürümün dosyalarını koyar. Klasörün içinde elle yaptığınız her değişiklik bu sırada kaybolur. Veritabanında duran ayarlar ise yerinde kalır. Güncellemeden önce neyin yedeklenmesi gerektiğini anlamak için bu ayrımı bilmek yeterli; aşağıda iki tarafı da resmî belgelere dayanarak ayırıyoruz.
Klasördeki değişiklikler gider
Theme Handbook’un alt tema (child theme) sayfası bunu bir örnekle anlatır: Üst temanın functions.php dosyasına doğrudan bir işlev eklerseniz, tema bir sonraki güncellemede işleviniz kaybolur. Aynı durum style.css dosyasına eklenen CSS kuralları, düzenlenen şablon dosyaları ve klasöre elle kopyalanan görseller için de geçerli.
Bu dosyaları değiştirmenin üç yaygın yolu var ve üçü de aynı sonuca götürür:
- Yönetim panelindeki tema dosyası düzenleyicisi,
- FTP ya da barındırma panelindeki dosya yöneticisi,
- bir geliştiricinin sunucuda doğrudan yaptığı düzeltme.
Handbook’un önerdiği çözüm alt tema. Alt temada yapılan değişiklikler, belgenin ifadesiyle üst temanın gelecekteki güncellemelerinden etkilenmez. Alt temanın var olması için tek zorunlu dosya style.css ve bu dosyanın başlığında Template alanı bulunmalı; alanın değeri üst temanın klasör adıyla birebir aynı olmalı. Alt temadaki bir şablon dosyası, üst temadaki aynı adlı dosyanın yerine geçer. functions.php ise bu kuralın dışında: alt temanınki üst temanınkinin yerine geçmez, ikisi de yüklenir ve alt temanınki önce çalışır.
Veritabanındaki ayarlar kalır
Özelleştirici (Customizer) üzerinden seçtiğiniz tema ayarları, yani temanın “theme mod” olarak kaydettiği değerler, tema dosyalarında değil veritabanında tutulur. get_theme_mods() işlevinin kaynak kodu bunu açıkça gösteriyor: ayarlar theme_mods_ ve ardından temanın kısa adından oluşan bir seçenekten okunur. Tema güncellendiğinde bu seçenek silinmez.
Blok temalarında site düzenleyicide yaptığınız değişiklikler de aynı tarafta. Handbook, kullanıcının yaptığı şablon, desen ve stil değişikliklerini üst temanın, alt temanın ve WordPress’in varsayılanlarının üzerine eklenen bir katman olarak tarif ediyor ve bu katmanın dosya sisteminde değil veritabanında saklandığını yazıyor.
Ayrımı bir tabloda toplarsak:
| Değişikliğin yeri | Güncellemede |
|---|---|
| Üst temanın dosyaları (functions.php, style.css, şablonlar) | Silinir |
| Alt temanın dosyaları | Kalır |
| Özelleştirici ayarları | Kalır |
| Site düzenleyicide yapılan değişiklikler | Kalır |
“Kalır” demek “her zaman aynı görünür” demek değil. Yeni sürümde bir ayarın adı değiştiyse ya da bir şablon kaldırıldıysa, veritabanındaki eski değer artık kullanılmayabilir. Bu yüzden ayarlar silinmese bile güncellemeden sonra sitenin görünüşünü kontrol etmek gerekir.
Ne sıklıkla bu kararla karşılaşırsınız
Bu konu, temanızın ne sıklıkla güncellendiğine göre yılda bir kez de karşınıza çıkabilir, her hafta da. Sitemizde ayrı sayfası olan 183 temanın son 12 aydaki sürüm sayılarına baktık:
- Ortanca tema son 12 ayda 2 sürüm yayımladı. 31 tema hiç yayımlamadı.
- 24 tema 12 ya da daha fazla, 12 tema 24 ya da daha fazla sürüm yükledi.
- Blocksy 43, Astra 28 sürümle en sık güncellenen büyük temalar arasında. GeneratePress ise aynı dönemde tek bir sürüm yayımladı, 1 Aralık 2025’te.
Haftada bir güncellenen bir temada, her güncellemeden önce tam yedek almak gerçekçi değil. Bu durumda düzenli otomatik yedek ve hazır bir geri dönüş planı daha mantıklı. Yılda bir iki kez güncellenen bir temada ise her güncelleme daha fazla değişikliği bir arada getirir ve elle yedek almak zahmete değer. Bu hafta hangi temaların güncellendiğini bu hafta güncellenen temalar sayfasında görebilirsiniz.
Yedek iki parçadan oluşur
WordPress’in yedekleme belgesi bir sitenin iki parçası olduğunu söyler: veritabanı ve dosyalar. Siteyi eksiksiz geri getirmek için ikisine de ihtiyaç vardır. Dosyalar tarafında belge şunları sayar: WordPress çekirdek kurulumu, eklentiler, temalar, görseller ve yüklenen dosyalar, kod dosyaları ve ek statik sayfalar.
Sıklık konusunda belge, az yazı yayımlanan küçük siteler için haftada bir, çok hareketli siteler için günlük yedek önerir. Güncellemelerle ilgili cümlesi ise net: veritabanını düzenli olarak ve her yükseltmeden önce mutlaka yedekleyin.
Yalnızca tema güncellemesi için düşündüğünüzde iki parçanın önemi farklıdır. Tema klasörünün eski hali, güncelleme sonrası bir sorunda geri dönmek için gerekir. Veritabanı yedeği ise yeni sürüm ilk açılışta ayarları dönüştürüyorsa ya da bir sorun sonrası ayarları eski haline getirmeniz gerekirse işe yarar.
WordPress 6.3’ün geri alma özelliği neyi kapsar
WordPress 6.3 ile gelen bir özellik, elle başlatılan tema ve eklenti güncellemelerinde eski sürümü geçici olarak saklıyor. Çekirdek ekibinin geliştirici notuna göre güncelleme başlamadan önce eski tema wp-content/upgrade-temp-backup/themes/ altına taşınıyor. Güncelleme başarısız olursa bu kopya yerine geri konuyor, başarılı olursa siliniyor. Site Sağlığı ekranı da bu klasörün yazılabilir olup olmadığını ve yeterli disk alanı bulunup bulunmadığını kontrol ediyor.
Not, özelliğin sınırlarını da yazıyor:
- Yalnızca kurulum sürecinin kendisi hata verdiğinde devreye giriyor; örneğin indirilen paket boşsa ya da klasör değiştirilemiyorsa.
- Başarıyla tamamlanmış bir güncellemeden sonra geri dönmek için kullanılamıyor. Güncelleme başarılı olduysa ama site yeni sürümde bozuk görünüyorsa, bu özellik size eski sürümü vermez.
- Bu aşama yalnızca elle yapılan güncellemeleri kapsıyor.
Yani bu özellik yarım kalmış bir kurulumda sitenin bozulmasını önlüyor; kendi yedeğinizin yerini tutmuyor.
Test kopyası
Büyük ya da orta sürüm atlamalarında, güncellemeyi önce sitenin bir kopyasında denemek en az riskli yoldur. WordPress 5.5’ten bu yana wp_get_environment_type() işlevi sitenin hangi ortamda çalıştığını bildirebiliyor. Geliştirici notuna göre dört değer var: production (varsayılan, canlı site), staging (test sitesi), development ve local. development değerinde WordPress hata ayıklama modunu (WP_DEBUG) kendiliğinden açıyor. Değer wp-config.php içindeki WP_ENVIRONMENT_TYPE sabitiyle belirlenir; not, izin verilen dört değerin dışında bir şey yazılırsa değerin production olarak kabul edildiğini belirtiyor. Test kopyanızı bu sabitle staging olarak işaretlemek, kopyayla canlı siteyi karıştırma ihtimalini azaltır ve ortam türüne bakan eklentilere doğru bilgiyi verir.
Hangi güncellemenin denemeye değer olduğunu sürüm numarasından tahmin edebilirsiniz: Yalnızca son hanenin değiştiği bir güncelleme çoğu zaman düzeltmedir, orta ve büyük hane değişimleri daha fazla değişiklik getirir. Ayrıntısı tema sürüm numarası nasıl okunur yazısında.
Güncellemeden önce kısa kontrol listesi
- Tema klasörünü değiştirdiniz mi? Tema dosyalarının değişiklik tarihleri temanın sürüm tarihinden yeniyse ya da birinin dosyaya ekleme yaptığını biliyorsanız, değişiklikleri önce bir alt temaya taşıyın.
- Yedek tarihi. Son tam yedeğiniz ne zaman alındı? Veritabanı ve dosyalar birlikte mi?
- Atlanan sürümler. Sitenizdeki sürüm ile güncel sürüm arasında kaç sürüm var? Arada bir orta ya da büyük atlama varsa önce test kopyasında deneyin.
- Hızlı düzeltme ihtimali. Verimizdeki temalarda bir sürümün ardından birkaç gün içinde ikinci bir düzeltme sürümünün gelmesi sık görülüyor; son bir yılda yaklaşık her altı sürümden birinde bu oldu. Acil değilse, büyük bir sürümü birkaç gün bekletmek makul.
- Güncelleme sonrası kontrol. Ana sayfa, bir yazı, bir sayfa, menüler ve iletişim formu. Mağaza siteniz varsa ürün ve sepet sayfası.
Otomatik güncellemeyi açmayı düşünüyorsanız bu listedeki ilk iki madde daha da önemli hale geliyor; otomatik güncellemenin nasıl çalıştığını ve hangi temalarda mantıklı olduğunu tema otomatik güncellemesi yazısında anlattık.