Tema güncelleme ve teknik destek: kurulumdan sonra neler gerekir

Siteniz yayına girdi: tasarım onaylandı, sayfalar dolu, formlar çalışıyor. Peki bundan sonra ne gerekiyor? Cevap kısa. Site, bir kez teslim edilip bırakılan bir dosya olmaz; tema, eklentiler, içerik ve hosting birbirine bağlı çalışan, bu yüzden de düzenli bakım isteyen bir sistemdir. Tema güncelleme, bu bakımın en sık karşınıza çıkan parçasıdır.

Biz web sitesi, reklam ve e-ticaret projelerini kuruyor ve yönetiyoruz. Bizim için yayın günü, yönetimin başladığı gündür. Bu yazıda tema güncelleme kararının neden gerektiğini, neyi bozabileceğini, hangi sırayla yapılacağını ve destek planına neleri yazmanız gerektiğini anlatıyoruz; anlatım platformdan bağımsızdır, örnekleri açık kaynaklı bir sistemin resmî belgelerinden alıyoruz.

Tema güncelleme neden gerekir

Tema, sitenizin görünümünü ve sayfa şablonlarını belirleyen yazılım katmanıdır. Yazılım olduğu için bakım ister. Vikipedi yazılım bakımını dört türe ayırır: hata düzelten düzeltici bakım, değişen ortama uyum sağlayan uyarlayıcı bakım, kaliteyi artıran iyileştirici bakım ve henüz görünmeyen sorunları önleyen önleyici bakım. Bir güncelleme çoğu zaman bunlardan birkaçını birlikte taşır.

Güvenlik tarafı en acil olanıdır. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), yamaların güvenlik açıklarını kapatan güncellemeler olduğunu ve saldırganların düzeltme yayımlandıktan aylar, hatta yıllar sonra bile bu açıkları hedefleyebildiğini yazar. Yani yayımlanmış bir düzeltmeyi kurmamak, açığın herkese duyurulduğu ama sizin sitenizde hâlâ durduğu bir durum yaratır. NIST de yama yönetimini aynı mantıkla tanımlar: yamaları belirlemek, önceliklendirmek, edinmek, kurmak ve kurulumu doğrulamak. Bu işi işletmenin olağan maliyeti ve önleyici bakımın gerekli bir parçası olarak görür.

İkinci neden uyumluluktur. Platform yeni sürüme geçtiğinde eski bir tema onunla çalışmayabilir. Üçüncü neden desteğin bitmesidir: CISA, üreticisi destek vermeyi bırakmış yazılımın sistemi saldırıya açtığını, uyumluluk ve performans sorunları doğurduğunu belirtir ve bu ürünlerin kullanımdan kaldırılmasını önerir. Temanızı geliştiren taraf güncelleme yayımlamayı bıraktıysa tema değiştirme zamanı gelmiştir.

OWASP'ın savunmasız ve eski bileşenler başlığı bunu üç soruya indirir: kullandığınız bileşenlerin sürümlerini biliyor musunuz, yazılım hâlâ destekleniyor mu, güncellenen parçanın uyumunu test ediyor musunuz? Üçüne de evet diyemiyorsanız OWASP sizi savunmasız sayar.

Tema güncelleme neyi bozabilir

Tema güncelleme risksiz değildir. Riski çoğunlukla güncellemenin kendisi değil, onunla çarpışan şeyler doğurur.

• Elle yapılan değişiklikler. Temanın dosyalarını doğrudan düzenlediyseniz yeni dosyalar eskilerin üstüne yazılabilir. WordPress tema el kitabı alt temayı tam bunun için tarif eder: alt tema, ana temaya dokunmadan özelleştirme yapmanızı ve ana tema güncellenirken değişikliklerinizin kaybolmamasını sağlar, ancak aynı belge alt temada çok kapsamlı değişiklik yapmanın zamanla yönetimi zorlaştırabileceğini de ekler.
• Eklenti çatışması. Tema ile eklentiler aynı sayfada birlikte çalışır, bu yüzden biri değişince diğeri beklenmedik davranabilir ve sonuçta form gönderilmez, menü açılmaz ya da ödeme adımı donar.
• Görünüm kayması. Yazı tipi, boşluk ya da düğme boyutu değişebilir. W3C'nin WCAG 2.2 tavsiyesi, AA düzeyinde işaretçi hedeflerinin en az 24x24 CSS pikseli olmasını ister; istisnalar vardır, yine de güncelleme sonrası düğme ve menü boyutuna bakmak yerinde bir kontroldür.
• Hız kaybı. Yeni sürüm daha fazla betik ya da görsel yükleyebilir.
• Arama görünürlüğü. Google Search Central, trafik düşüşü nedenleri arasında teknik sorunları sayar: sunucu erişilebilirliği, robots.txt, "sayfa bulunamadı" hataları ve yanlış yerleştirilmiş noindex etiketi. Güncelleme sırasında sıfırlanan bir ayar bunlardan birini tetikleyebilir.

Sürüm numarası ipucu verir. Anlamsal sürümleme kuralına göre (semver.org) MAJOR sayısı uyumsuz değişiklikte, MINOR sayısı geriye uyumlu yeni işlevde, PATCH sayısı geriye uyumlu hata düzeltmesinde artar. Her tema bu kurala uymaz, bu yüzden ipucundan fazlası sayılmaz.

Tema güncelleme öncesi: yedek

WordPress belgeleri güncellemeden önce siteyi yedeklemeyi ve sorun çıkarsa o yedeğe dönmeyi önerir. Yedeğin içeriği ise sık yanlış anlaşılır. Aynı belgeler, tipik bir sitede dosyaların ve veritabanının iki ayrı parça olduğunu ve tam geri yükleme için ikisinin birden gerektiğini vurgular; yani dosyaları indirmek veritabanını yedeklemez, oysa sayfa içerikleriniz, ürünleriniz ve siparişleriniz veritabanında durur.

Belgenin önerdiği düzen şöyle:

1. Yedeği düzenli alın ve her yükseltmeden önce ayrıca alın. Belge küçük sitelerde haftalık, yoğun sitelerde günlük sıklığı önerir.
2. En az üç ila beş kopya tutun, farklı yerlerde saklayın: sunucuda, bulut depoda, kendi bilgisayarınızda.
3. Otomatik yedeklerin çalıştığını, arada elle bir yedek alarak doğrulayın.

Bir kopyanın çevrim dışı durması gerekir. Birleşik Krallık Ulusal Siber Güvenlik Merkezi (NCSC), her an en az bir yedeğin çevrim dışı olmasını önerir ki bir olay bütün yedekleri aynı anda etkileyemesin, aynı yazıda yedeğin geri yüklenebilir olup olmadığının da sorulmasını ister, çünkü hiç denenmemiş bir yedek çalıştığı bilinen bir yedek sayılmaz. Yılda bir kez bile olsa yedeği hazırlık kopyasına yükleyin ve sitenin açıldığını kendi gözünüzle görün.

Hosting tarafındaki yedek düzenini hosting nedir yazımızda ele aldık; orada da kendi bağımsız kopyanızı tutmanızı öneriyoruz.

Hazırlık kopyasında tema güncelleme denemesi

Tema güncellemesini canlı sitede ilk kez denemek gereksiz bir risktir. Bunun yerine hazırlık (staging) kopyası kullanılır. Vikipedi hazırlık ortamını, üretim ortamına olabildiğince benzeyen bir test ortamı olarak tanımlar ve amacını, kurulum, yapılandırma ve geçiş adımlarını gerçek ortama uygulamadan önce denemek diye anlatır.

Kopya gerçek siteye benzemelidir: aynı tema sürümü, aynı eklentiler, aynı sunucu yazılımı ve gerçeğe yakın içerik. Güncellemeyi önce burada yapar, test listesini burada çalıştırırsınız; bir şey bozulursa canlı siteniz hiç etkilenmemiş olur.

Kopya, arama sonuçlarında görünmemeli. Google, noindex kuralının sayfayı sonuçlardan çıkardığını, ama bunun için sayfanın robots.txt ile engellenmemiş ve tarayıcıya açık olması gerektiğini yazar. Kopyanın nasıl korunduğunu destek ortağınıza sorun.

Tema güncelleme sonrası test listesi

Test, "site açılıyor" demek değildir. Tablo, her güncellemeden sonra baktığımız alanları gösterir.

Hız satırındaki üç değer, Google'ın web.dev sayfasında yayımladığı Core Web Vitals eşikleridir: en büyük içeriğin yüklenmeye başladıktan sonra 2,5 saniye içinde görünmesi, tıklamaya yanıtın 200 milisaniye veya altında kalması, sayfa kaymasının 0,1 veya altında olması. Güncellemeden önce ve sonra aynı sayfaları aynı araçla ölçün; karşılaştırma ancak böyle anlam taşır. Listeyi bir kez yazın, her güncellemede aynısını kullanın. Tasarım aşamasındaki eşikleri web sitesi nasıl tasarlanır yazımızda ayrıca işledik.

Otomatik tema güncelleme mi, elle mi

CISA, otomatik güncelleme seçeneği varsa kullanılmasını önerir, çünkü güncelleme ne kadar çabuk kurulursa açık o kadar kısa süre açık kalır; OWASP da yamaları aylık ya da üç aylık bir değişiklik kontrolüne bağlayan kuruluşların günler ya da aylar boyunca düzeltilmiş açıklara açık kaldığını yazar.

Öte yandan otomatik güncelleme, yukarıdaki hazırlık ve test adımlarını kendiliğinden yapmaz. WordPress belgeleri, arka plan güncellemelerinin varsayılan olarak eklentiler ve temalar için yalnızca özel durumlarda çalıştığını, temalar için otomatik güncellemenin ise bir ayarla açılıp kapatılabildiğini anlatır. Hangi ayarın açık olduğunu bilmek, destek ortağınıza soracağınız ilk sorudur.

Çoğu işletme için makul denge şu: küçük güvenlik düzeltmeleri otomatik kalır, büyük sürüm geçişleri hazırlık kopyasında denenip elle yayımlanır. Kural değil, başlangıç noktası. Sitenizin ne kadar özelleştirildiğine göre değişir.

Tema güncelleme yayını ve geri dönüş

Hazırlık kopyasında her şey geçtiyse aynı tema güncelleme adımlarını canlı siteye uygularsınız. Üç kural işi kolaylaştırır:

1. Yedeği yenileyin. Hazırlık sırasında aldığınız yedek eskimiş olabilir. Yayından hemen önce taze bir yedek alın.
2. Sakin saati seçin. Sipariş ve formun en az geldiği saatte, sorun çıkarsa kaybınız en küçük olur.
3. Geri dönüş ölçütünü önceden yazın. "Ödeme adımı hata verirse ya da form ulaşmazsa yedeğe dönülür" gibi iki üç cümle yeter.

Yayından sonraki bir iki gün kayıtlara bakın. Google, trafik düşüşündeki teknik sorunları ararken Search Console'daki sayfa dizine ekleme ve tarama istatistikleri raporlarına bakılmasını önerir; sorun varsa bu raporlarda hata sayısının ani değiştiğini görürsünüz.

Teknik destek planında neler yazılı olmalı

Destek, "sorun olursa ararım" cümlesinden ibaret olamaz. Yazılı plan, sorun çıktığı anda kimin neyi yapacağını önceden belirler. Vikipedi hizmet seviyesi sözleşmesini (SLA), hizmet sağlayıcı ile müşteri arasında hizmetin kalitesini, erişilebilirliğini ve sorumluluklarını tanımlayan, genellikle bağlayıcı bir sözleşme olarak anlatır ve ölçütleri arasında kesintisiz çalışma süresi ile dönüş süresini sayar; yanıt süresi de sağlayıcının sorunu incelemeye başlayacağı süredir, sorunu çözeceği süre değil.

Bu ayrım önemli. İlk yanıt süresi ile çözüm süresi aynı şey değildir, bu yüzden planda ikisini ayrı satırlarda görmek istersiniz.

Yedi madde yazılı olmalı:

1. Kapsam. Pakette hangi işler var: tema, eklenti ve çekirdek güncellemeleri, yedek, izleme, küçük içerik değişiklikleri. Hangileri ayrıca istenir: yeni sayfa tasarımı, yeni özellik.
2. Güncelleme ritmi. Güvenlik düzeltmeleri ne kadar sürede uygulanır, büyük sürümler hangi sırayla denenir.
3. Yedek düzeni. Sıklık, saklama süresi, çevrim dışı kopyanın yeri, geri yükleme denemesinin tarihi.
4. Yanıt süreleri. İlk yanıt süresi ve acil durumun tanımı. Satış durduysa acildir, bir yazım hatası acil değildir.
5. Raporlama. Güncellemelerin ve hız ölçümlerinin size nasıl iletildiği.
6. Erişim ve veri koruma. Destek ortağı yönetici paneline girdiğinde sitedeki kişisel verileri de görebilir. 6698 sayılı Kanun'un 12. maddesi veri sorumlusunu uygun güvenlik düzeyi için teknik ve idari tedbirleri almakla yükümlü kılar ve kişisel veriler sizin adınıza başkası tarafından işleniyorsa sizi o kişilerle birlikte müştereken sorumlu tutar. Hukuki değerlendirmeyi avukatınız yapmalıdır. Planda ise kimin hangi yetkiyle erişeceği ve yetkinin ne zaman kapanacağı yazılı olmalıdır.
7. Hesap sahipliği. Hosting, alan adı, tema lisansı ve yönetici hesapları sizin adınıza açılmalıdır. Destek ilişkisi bittiğinde sitenin kontrolü sizde kalır.

Bir soru daha var: tema hâlâ güncelleniyor mu? Destek ortağınız bunu her güncelleme döneminde sormalı, çünkü cevap hayırsa CISA'nın destek süresi dolmuş yazılım için yazdığı risk geçerlidir ve tema değişikliği bir tasarım kararı olmaktan çıkıp bir güvenlik kararına dönüşür.

İşi kim yapar

Bu işleri üç şekilde dağıtabilirsiniz. Hepsini kendiniz yaparsınız; yedek, test ve geri dönüş yükü sizde kalır. Ya da hosting sağlayıcınızın yönetilen paketine bırakırsınız; neyin kapsandığını yazılı sorun. Üçüncü yol, siteyi kuran ekiple devam etmektir.

Biz üçüncüsünü savunuyoruz ama nedeni satış değil, bilgi sürekliliği. Siteyi kuran ekip hangi özelleştirmenin nerede durduğunu bilir, test listesini de o bilgiyle hazırlar. 5 yıldır 500'den fazla firmayla çalışırken sorunun çoğunlukla güncellemenin kendisinde değil, kimin neyi yapacağının belli olmamasında çıktığını gördük.

Yedek ve desteğin hosting fiyatının içinde mi dışında mı kaldığını hosting maliyetleri yazısında anlattık. Kurulumdan sonraki yönetim kapsamı için hizmet paketlerimize bakabilirsiniz.

Tema güncelleme sıkıcı bir iştir. Başarılı olduğunda kimse fark etmez. İyi bakılan bir sitenin belirtisi de budur: ziyaretçileriniz yalnızca çalışan bir site görür.

Yazar: Blakfy Studio ekibi, web sitesi, reklam ve e-ticaret projelerinde kurulum ve yönetim. Kaynaklar aşağıda listelenmiştir.

Kaynaklar

• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA, Understanding Patches and Software Updates
• OWASP Top 10:2021, A06 Vulnerable and Outdated Components
• Wikipedia, Software maintenance
• Wikipedia, Deployment environment
• Wikipedia, Service-level agreement
• WordPress.org, Updating WordPress
• WordPress.org, WordPress Backups
• WordPress.org, Configuring Automatic Background Updates
• Developer.WordPress.org, Child Themes
• NCSC, Offline backups in an online world
• web.dev, Web Vitals
• Google Search Central, Block Search indexing with noindex
• Google Search Central, Debugging drops in Google Search traffic
• W3C, Web Content Accessibility Guidelines 2.2
• Semantic Versioning 2.0.0
• 6698 sayılı Kişisel Verilerin Korunması Kanunu, mevzuat.gov.tr