WordPress Güncelleme Politikası: Çekirdek, Eklenti ve Tema için Test Akışı

Kurumsal WordPress sitelerinde güncelleme genelde iki uçtan birinde yönetilir. Ya her şey otomatiğe bağlanır ve bir sabah ödeme sayfası beyaz ekran verir, ya da “bozulmasın” diye aylarca dokunulmaz ve bilinen bir zafiyet açık kalır. İki yol da aynı yere çıkar: plansız kesinti. Aşağıdaki akış çekirdek, eklenti, tema ve çeviri güncellemelerini risk sınıfına ayırır, staging’de test eder, WP-CLI ile kayıt altında uygular ve geri dönüşü işe başlamadan yazar. Siteyi işleten IT ekibi de bakım sağlayıcısı da aynı belgeyle çalışabilir.

Güncelleme türleri ve risk seviyeleri

“Güncelleme” tek bir iş değildir. Çekirdek yaması ile bir sayfa oluşturucunun ana sürümü aynı kurala bağlanırsa ya gereksiz yere yavaşlarsınız ya da gereksiz risk alırsınız. Politikanın ilk işi bu türleri ayırmaktır.

Güncelleme türü	Tipik içerik	Risk	Önerilen yol
Çekirdek küçük sürüm (6.x.y)	Güvenlik ve hata düzeltmesi	Düşük	Otomatik, sonrasında izleme
Çekirdek ana sürüm (6.x)	Yeni özellik, editör ve API değişikliği	Orta–yüksek	Staging testi, bakım penceresi
Eklenti yama sürümü	Hata ve güvenlik düzeltmesi	Düşük–orta	Haftalık toplu, staging’de hızlı test
Eklenti ana sürümü	Veri yapısı, ayar ve şablon değişikliği	Yüksek	Ayrı değişiklik kaydı, tam test
Tema / alt tema	Şablon dosyaları, CSS	Orta	Görsel regresyon kontrolü
Çeviri dosyaları	.mo/.po, JSON çeviriler	Düşük	Otomatik veya toplu
PHP sürümü	Çalışma ortamı	Yüksek	Ayrı proje olarak ele alınır

Risk sınıfını yalnız sürüm numarası belirlemez; eklentinin sitede taşıdığı işlev de hesaba girer. WooCommerce, ödeme ağ geçidi, üyelik, çok dillilik ve sayfa oluşturucu (Elementor, Elementor Pro) küçük bir sürüm atlamasında bile ayrı ele alınır. Envanterde “kritik” diye işaretlenir, otomatik güncelleme listesinin dışında tutulur. Tartışmaya gerek yok.

Sahada en sık gördüğümüz kırılma bağımlı eklenti çiftlerinde olur. Elementor güncellenir, Elementor Pro eski kalır; ya da WooCommerce yeni sürüme geçer, eklenti ailesindeki bir add-on desteklediği sürüm aralığının dışında kalır. Sonuç widget’ların kaybolması veya ölümcül PHP hatasıdır. Bu yüzden çiftin iki üyesi aynı test turunda, sürüm notlarındaki uyumluluk satırı okunarak güncellenir ve bağımlılık grupları politikada açıkça listelenir.

Güncelleme sıklığı ve bakım penceresi

İki ritim tanımlayın: planlı ve acil. Planlı ritimde güncellemeler biriktirilir, belirli bir günde test edilerek topluca uygulanır. Acil ritim, aktif istismar edilen ya da kimlik doğrulama gerektirmeden kullanılabilen bir açık yayımlandığında başlar.

• Haftalık: eklenti yama sürümleri, çeviriler, tema küçük sürümleri. Staging’de duman testi yeterli.
• Aylık: eklenti ana sürümleri ve kritik eklentiler. Tam regresyon testi ve iş birimi onayı şart.
• Çekirdek ana sürüm: ilk düzeltme sürümü (6.x.1) beklenebilir; bekleme süresi politikada gün olarak yazılır, “bir süre” denmez.
• Acil: bülten değerlendirilir; istismar koşulu sitede geçerliyse aynı gün staging’de kısa test, ardından canlıya alma.

Bakım penceresi sitenin en az kullanıldığı ve geri dönüşü yapacak kişinin ulaşılabilir olduğu aralıktır. Gece yarısı güncelleme yapıp sorun çıktığında telefonu açacak kimse yoksa pencere kâğıt üzerinde doğru, sahada yanlıştır. E-ticaret sitelerinde kampanya dönemleri ve ay sonu için “değişiklik dondurma” tarihleri de politikaya girer.

Bültenlere göre önceliklendirme kurumun genel zafiyet sürecinden ayrı düşünülmemeli; çerçeve için zafiyet yönetimi programı ve yama SLA’ları rehberine bakın.

Staging’de test akışı

Staging, canlının yakın tarihli kopyası olmalı: aynı PHP sürümü, aynı eklenti ve tema sürümleri, aynı önbellek katmanı, mümkünse anonimleştirilmiş güncel veri. Canlı PHP 8.2, staging PHP 8.1 ise test sonucu yalnızca staging’i anlatır. “Staging’de çalışıyordu” cümlesinin en sık kaynağı budur. Kurulum ve senkronizasyon için staging ortamı kurulumu rehberi kullanılabilir.

Kontrol sırası:

1. Canlı veritabanı ve wp-content staging’e çekilir; URL’ler staging alan adına çevrilir, e-posta gönderimi ve ödeme ağ geçitleri test moduna alınır.
2. Bekleyen güncellemeler listelenir ve değişiklik kaydına yazılır.
3. Sıra: önce çekirdek, sonra eklentiler, en son tema. Kritik eklentiler tek tek güncellenir.
4. PHP hata günlüğü ve tarayıcı konsolu kontrol edilir.
5. Duman testi ve görsel regresyon kontrolü yapılır.
6. Sonuç kayda işlenir; onaylanan sürüm listesi canlıya aynen taşınır.

E-posta ve ödemeyi test moduna almayı atlamayın. Staging’den müşterilere sipariş e-postası gitmesi, sahada beklenenden sık yaşanan bir hatadır.

Görsel regresyon için önemli şablonlardan (ana sayfa, bir hizmet sayfası, blog yazısı, form sayfası, ürün ve sepet) güncelleme öncesi ve sonrası ekran görüntüsü alınıp karşılaştırılır. Playwright veya BackstopJS bu işi otomatikleştirir; küçük sitelerde masaüstü ve mobil genişlikte elle karşılaştırma da başlangıç için yeterlidir.

WP-CLI ile kontrollü güncelleme

Paneldeki “Tümünü güncelle” düğmesi hangi sürümden hangi sürüme geçtiğinizi kaydetmez. Üç hafta sonra bir form çalışmayı bıraktığında elinizde iz olmaz. WP-CLI aynı işi tekrarlanabilir, günlüğe yazılabilir ve sürüm sabitlenebilir biçimde yapar. Bir bakım penceresindeki tipik akış:

# 1. Mevcut durumu kaydet
wp core version --extra
wp plugin list --fields=name,status,version,update_version,auto_update > oncesi-eklentiler.txt
wp theme list --fields=name,status,version,update_version > oncesi-temalar.txt

# 2. Yedek al (dosya yedeği ayrıca alınmalıdır)
wp db export yedek-$(date +%F-%H%M).sql

# 3. Ne güncellenecek, önce gör
wp core check-update
wp plugin update --all --dry-run

# 4. Kritik eklentileri dışarıda bırakarak toplu güncelle
wp plugin update --all --exclude=woocommerce,elementor,elementor-pro

# 5. Kritik eklentiyi staging'de onaylanan sürüme sabitle
wp plugin update woocommerce --version=<onaylanan-surum>

# 6. Çekirdek (staging'de onaylanan sürüm), veritabanı şeması ve çeviriler
wp core update --version=<onaylanan-surum>
wp core update-db
wp language core update
wp language plugin update --all

# 7. Bütünlük kontrolü
wp core verify-checksums
wp plugin verify-checksums --all

Sahada takıldığımız ayrıntılar:

• Multisite’ta veritabanı şeması tüm alt siteler için wp core update-db --network ile güncellenir. Tek sitede çalıştırıp bırakmak, diğer alt sitelerde panelde “veritabanı güncellemesi gerekli” uyarısı bırakır.
• wp plugin verify-checksums yalnız WordPress.org dizinindeki eklentiler için sağlama verisi bulur; ticari eklentilerde “doğrulanamadı” uyarısı normaldir.
• Ticari eklentiler (örneğin Elementor Pro) genellikle lisans o sitede etkinse WP-CLI ile güncellenir. Lisans düşmüşse güncelleme sessizce görünmez. Bu da envanterde izlenir.
• Uzun süren işlerde wp maintenance-mode activate ve deactivate ile ziyaretçiye kontrollü bakım ekranı gösterilebilir.

Otomatik güncellemenin kapsamını wp-config.php belirler. define( 'WP_AUTO_UPDATE_CORE', 'minor' ); yalnız küçük çekirdek sürümlerine izin verir. Eklenti bazında otomatik güncelleme wp plugin auto-updates enable <eklenti> ve disable ile yönetilir; düşük riskli eklentiler otomatikte, kritikler manuelde kalır. Ayrıntılar WordPress’in otomatik arka plan güncellemeleri belgesinde ve WP-CLI komut başvurusunda.

Güncelleme sonrası doğrulama kontrol listesi

“Site açılıyor mu?” doğrulama değildir. Ana sayfa açılırken iletişim formu e-posta göndermiyor ya da ödeme dönüş adresi hata veriyor olabilir; bunu çoğu zaman ilk kaybolan talepten öğrenirsiniz. Aşağıdaki liste canlıda güncellemeden sonraki ilk otuz dakika içinde uygulanır:

• Ana sayfa, bir hizmet sayfası ve bir blog yazısı önbellek atlanarak (giriş yapmış kullanıcıyla ve gizli pencerede) açılıyor.
• PHP hata günlüğünde yeni “Fatal error” veya “Deprecated” yoğunluğu yok.
• İletişim ve teklif formu gönderiliyor, bildirim e-postası ulaşıyor, kayıt veritabanına veya CRM’e düşüyor.
• E-ticarette sepete ekleme, ödeme adımları ve sipariş e-postası test modunda veya düşük tutarlı test siparişiyle doğrulanıyor.
• Elementor kullanan sitelerde CSS dosyaları yeniden üretildi (Elementor araçlarındaki dosya ve veri yeniden oluşturma ya da wp elementor flush-css) ve stil kayması yok.
• Sayfa ve CDN önbelleği temizlendi; wp cron event list çıktısında beklenmeyen biriken görev yok.
• Panelde eklenti, lisans veya veritabanı güncelleme uyarısı kalmadı.
• Harici izleme aracında yanıt süresi ve hata oranı güncelleme öncesiyle karşılaştırıldı.

Geri dönüş planı ve sürüm kaydı

Geri dönüş planı güncellemeden önce yazılır. Sorun çıktıktan sonra yazılan plan, panik altında verilmiş bir karardır. İki seviye tanımlayın.

Bileşen düzeyinde geri dönüş: Sorun tek bir eklentiden geliyorsa o eklentinin önceki sürümü geri yüklenir. WordPress.org eklentileri için wp plugin install <eklenti> --version=<eski-surum> --force bu işi yapar. Ama eklenti güncelleme sırasında veritabanı şemasını değiştirdiyse yalnız dosyaları döndürmek yetmeyebilir; eski kod yeni şemayla çalışmaya çalışır ve hata derinleşir. Sürüm notlarında “database update” ibaresi varsa tam geri dönüşü esas alın. Ticari eklentilerin önceki sürüm paketlerini güncellemeden önce ayrıca arşivleyin.

Tam geri dönüş: Güncelleme öncesi alınan veritabanı dökümü ve dosya yedeği birlikte geri yüklenir. Bedeli var: güncelleme ile geri dönüş arasında oluşan siparişler, form kayıtları ve yorumlar kaybolur. E-ticaret ve başvuru alan sitelerde pencereyi kısa tutun ve tam geri dönüş kararı için bir son saat belirleyin. O saatten sonra ileriye doğru düzeltilir.

Her pencere için sürüm kaydı en az şu alanları taşır: tarih ve saat, uygulayan kişi, bileşen, eski sürüm, yeni sürüm, test sonucu, varsa sorun ve alınan aksiyon. Haftalar sonra ortaya çıkan bir hatanın hangi değişiklikle başladığını bulmanın en hızlı yolu budur. Yukarıdaki akışta alınan “öncesi” listeleri, aynı komutların sonrası çıktılarıyla karşılaştırılıp kayda eklenir.

Politika belgesinde bulunması gereken başlıklar

Kurumsal web sitelerinde politika uzun olmak zorunda değil; şu sorulara yazılı cevap vermesi yeterli: Hangi bileşenler otomatik güncellenir? Kritik eklenti listesi kimin onayıyla değişir? Planlı ve acil ritmin süreleri nedir? Staging’de hangi testler zorunlu? Bakım penceresi ve dondurma tarihleri ne? Geri dönüş kararını kim verir? Sürüm kaydı nerede tutulur? Cevabı olmayan her soru, ilk arızada telefonda tartışılır.

Güncelleme politikası sıkılaştırmanın yerini tutmaz; dosya izinleri, yönetici hesapları ve WAF için kurumsal WordPress güvenlik rehberi tamamlayıcıdır. Güncellemesi zorlaşan ya da güncelleme almayı bırakan eklentilerin envanterden nasıl çıkarılacağı eklenti seçimi ve envanter yönetimi yazısında. Bu döngüyü dışarıdan işletmek isteyen ekipler WordPress güvenlik, güncelleme ve bakım hizmetine, kapsamı sözleşmeye bağlamak için web sitesi bakım ve destek sözleşmeleri sayfasına bakabilir.

Sık sorulan sorular

WordPress eklentilerinde otomatik güncellemeyi açık bırakmak güvenli mi?

Düşük riskli, bakımı düzenli ve işlevi kritik olmayan eklentilerde açık kalabilir. Ödeme, üyelik, sayfa oluşturucu ve çok dillilik eklentilerinde kapatın; bunları staging’de test edip elle güncelleyin.

Çekirdek ana sürüm çıktığında ne kadar beklemek gerekir?

Sabit bir doğru süre yok; birçok ekip ilk düzeltme sürümünü bekler. Önemli olan sürenin politikada gün olarak yazılması ve bu sürede kritik eklentilerin yeni sürümle uyumunun staging’de doğrulanmasıdır.

Eklentiyi eski sürüme döndürmek her zaman sorunu çözer mi?

Hayır. Yeni sürüm veritabanı şemasını veya ayar yapısını değiştirdiyse eski dosyalar yeni veriyle uyumsuz çalışır. Bu tür güncellemelerde dosya ve veritabanı yedeğinin birlikte geri yüklendiği tam geri dönüş planlanmalıdır.

Küçük bir kurumsal sitede staging ortamı gerçekten gerekli mi?

Ana sürüm güncellemeleri ve kritik eklentiler için evet. Basit bir sitede bile sorunu ziyaretçiden önce görmenizi sağlar. Kaynak kısıtlıysa en azından canlıyla aynı PHP sürümünde çalışan, güncellemeden önce kopyalanan bir test kurulumu tutun.