WordPress tema güncellemesi, sıradan bir “Güncelle” tıklaması değildir; özelleştirmelerin kaybı, eklenti uyumsuzlukları ve CSS bozulmaları gibi riskler içerir. Bu rehber, tema güncellemesinden önce atılması gereken 7 zorunlu adımı, geri dönüş planını ve staging ortamı olmayanlar için pratik bir alternatif yolu anlatır. Adımlar sırasıyla uygulandığında güncelleme sonrası “site bozuldu” paniği yaşanmaz.
Tam Yedek Alma ve Geri Dönüş Planı

Tema güncellemesi öncesi eksiksiz bir yedek almak en kritik adımdır; ancak çoğu site sahibi yedeği aldıktan sonra onu gerçekten test etmez. Yedek geri yükleme çalışmıyorsa, hiç yedek almamışsınız demektir. Bu nedenle yedekleme stratejisinde üç katman vardır: hosting seviyesi yedek, eklenti tabanlı yedek, manuel yedek.
Çoğu paylaşımlı hosting sağlayıcısı (Hostinger, SiteGround, Bluehost) günlük otomatik yedek alır. Ancak bu yedekler genellikle son 7-30 günlük tutulur ve geri yükleme işlemi saatler sürebilir. Daha kontrollü bir seçenek: UpdraftPlus eklentisi ile hosting dışına (Google Drive, Dropbox, Amazon S3) yedek almak. Eklenti, hem veritabanı hem de /wp-content/ klasörünü ayrı arşivler halinde yedekler; geri yükleme tek tıkla yapılır.
Manuel yedek ise FTP üzerinden /wp-content/themes/ klasörünü indirmek ve phpMyAdmin’den veritabanını dışa aktarmaktır. Bu yöntem daha yavaştır ancak hosting tarafında hiçbir eklenti çalışmıyorsa son çare olarak uygulanabilir. Staging ortamınız yoksa, manuel yedek alarak yerel bilgisayarınızda bir kopya oluşturun ve güncellemeyi önce orada test edin. LocalWP, Local by Flywheel veya wp-cli kullanarak yerel WP kurulumu 5 dakikada hazırlanır.
Staging Ortamı ve Test Süreci

Staging ortamı, canlı sitenin birebir kopyasıdır; aynı tema, eklenti, içerik ve veritabanı kullanılır ancak arama motorlarından gizlenir. Tema güncellemesi öncesi staging’de test etmek, canlıda “sürpriz” yaşama riskini sıfıra indirir. Kinsta, WP Engine, Cloudways gibi yönetilen WP hosting sağlayıcıları tek tıkla staging oluşturma imkânı sunar. Paylaşımlı hostingde ise WP Staging eklentisi geçici staging subdomain’i oluşturur.
Staging’de test edilecek 4 temel kontrol noktası vardır:
- Ön yüz görünümü. Anasayfa, içerik sayfaları, arşivler, tekil yazılar ve 404 sayfası dahil tüm şablonları tarayıcıda açıp CSS bozulması, hizalama hatası, eksik font olup olmadığını kontrol edin. Mobil ve masaüstü görünümü ayrı test edin.
- JavaScript bileşenleri. Tema slider, menü açılır menüsü, modal pencereler, AJAX form gibi JS bileşenleri içeriyorsa hepsinin çalıştığını doğrulayın. Tarayıcı konsolunda hata mesajı olmamalı.
- Eklenti uyumluluğu. Sayfa oluşturucu (Elementor, WPBakery), form (Contact Form 7, WPForms), SEO (Yoast, Rank Math) gibi eklentileri staging’de tek tek aktifleştirip test edin. Tema güncellemesi sonrası kısa kod (shortcode) kırılmaları sıklıkla yaşanır.
- PHP hata logları.
wp-content/debug.logdosyasını staging’de izleyin. Tema güncellemesi tetiklenen ölümcül hatalar (fatal error) veya uyarılar (warning) varsa, canlıya geçmeden önce çözülmelidir.
Staging’de 1-3 gün süreyle test ettikten sonra, sorun yoksa staging’i canlıya “push” edin. WP Engine ve Kinsta’da bu tek tıkla yapılır; manuel yapıyorsanız staging’deki tema klasörünü FTP ile canlıya yükleyin ve wp_options tablosundaki tema ayarlarını (örn. theme_mods_twentytwentyfive) kopyalayın.
WP-CLI ile Otomatik Yedekleme

WP-CLI, WordPress için komut satırı arayüzüdür ve SSH erişimi olan sunucularda tema güncelleme, yedekleme, eklenti yönetimi gibi işlemleri 10 kat hızlandırır. Özellikle toplu tema güncellemesi yapan veya CI/CD pipeline’ı kuran geliştiriciler için vazgeçilmezdir.
Tema güncellemesi öncesi WP-CLI ile veritabanını export etmek tek satırlık bir komuttur:
wp db export /home/user/backups/db-$(date +%Y%m%d-%H%M).sql
Bu komut, veritabanının tamamını SQL dosyası olarak dışa aktarır. Ardından tema klasörünü yedeklemek için:
tar -czf /home/user/backups/wp-content-themes-$(date +%Y%m%d).tar.gz -C /path/to/wp wp-content/themes
Bu iki komutu bir pre-update-backup.sh script’inde birleştirip cronjob ile her gün çalıştırabilirsiniz. Geri dönüş gerekirse: wp db import /home/user/backups/db-20260609.sql ile veritabanını, FTP ile tema klasörünü geri yüklersiniz. Tüm süreç 5 dakikadan kısa sürer.
Tema güncellemesini WP-CLI ile yapmak ise:
wp theme update twentytwentyfive
komutu kadar basittir. WP-CLI, güncelleme öncesi otomatik olarak yedek almaz (bu sizin sorumluluğunuzdadır), ancak güncelleme sonrası tema klasörünü korur ve geri alma işlemini yine wp theme install twentytwentyfive --version=2.0 gibi bir komutla yapmanıza izin verir.
Child theme kullanımı da güncelleme güvenliği için kritik bir katmandır. Child theme, üst temadan tüm özellikleri miras alır; özelleştirmeleriniz (custom CSS, functions.php‘ye eklenen kodlar, şablon dosyaları) child theme’de tutulur. Üst tema güncellendiğinde child theme etkilenmez, özelleştirmeleriniz korunur. Eğer hâlâ doğrudan üst temada özelleştirme yapıyorsanız, tema güncellemesi öncesi mutlaka child theme’e taşıyın.
Sonuç
WordPress tema güncellemesi, doğru hazırlıkla 10 dakikada tamamlanabilen kontrollü bir işlemdir. Üç katmanı asla atlamayın: tam yedek, staging testi, geri dönüş planı. WP-CLI ve child theme kombinasyonu, ileri düzey güvenlik sağlar. Eğer bu adımları uygulamadan güncelleme yaparsanız, “site bozuldu” senaryosu kaçınılmazdır; her güncelleme öncesi 15 dakika ayırarak bu riski sıfıra indirebilirsiniz.
Bir Cevap Yaz
E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir.