WordPress Güncellemesi Yapılmazsa Ne Olur? Risk ve Plan

WordPress güncellemesi yapılmazsa site ertesi gün kapanmaz; olan şey, riskin sessizce birikmesidir. Bilinen açıkları kapatan yamalar sitenize gelmez, eklentiler yeni WordPress sürümleriyle ve sunucunun PHP sürümüyle uyumunu kaybeder, ertelenen her ay bir sonraki güncellemeyi daha büyük bir sıçramaya çevirir. Çözüm her düğmeye hemen basmak da değildir: güncellemeyi türüne göre ayırmak, öncesinde geri yüklenebilir bir yedek almak, mümkünse bir test kopyasında denemek ve bozulursa nasıl geri dönüleceğini önceden bilmektir.

Yönetim paneline giren bir işletme sahibi sol menüde küçük bir rozet görür: "Güncellemeler 7". Yanında eklentiler menüsünde bir sayı daha vardır. Sitenin ön yüzü sorunsuz açıldığı için o sayı haftalarca, bazen yıllarca orada kalır. Kimse basmaz, çünkü kimse "bastığımda site bozulursa ne yaparım" sorusunun cevabını bilmez. O sorunun cevabı, rozetin saydığı güncellemelerin türünü ayırmakla başlar.

Paneldeki rozet hangi güncellemeleri sayıyor?

Panelde tek bir sayı görünür, ama arkasında dört farklı iş vardır ve her birinin riski ayrıdır.

Çekirdek (WordPress'in kendisi). İki türü vardır. Küçük sürümler (6.x.1, 6.x.2 gibi) hata ve güvenlik düzeltmesi taşır; büyük sürümler (6.x'ten 6.y'ye) yeni özellik, editör değişikliği ve bazen eski işlevlerin kaldırılmasını getirir.

Eklentiler. Formlar, önbellek, SEO ayarları, güvenlik duvarı, yedekleme, e-ticaret: bu işlevlerin her biri WordPress'e bir eklentiyle eklenebilir. Her eklentinin kendi geliştiricisi, kendi güncelleme sıklığı ve kendi uyumluluk sorunu vardır.

Tema. Görünümü belirler. Hazır bir tema kullanılıyorsa ve dosyalarına doğrudan müdahale edildiyse, tema güncellemesi o müdahaleleri silebilir. Bu yüzden temada yapılan değişiklikler bir alt temada (child theme) tutulmalıdır.

Çeviriler. Türkçe arayüz dosyalarıdır; riski düşüktür ama aynı listede görünür.

Rozetin saymadığı beşinci bir saat daha vardır: sunucudaki PHP sürümü. O panelde görünmez, hosting firmasının kontrol panelinde durur ve WordPress'in, eklentilerin ve temanın hepsi onun üzerinde çalışır. Siteniz WordPress yerine başka bir altyapıdaysa bu katmanların adları değişir ama mantık aynı kalır; iki yolun bakım yükü farkı, WordPress ile özel yazılım kararı verilirken hesaba katılır.

Güncelleme yapılmazsa zamanla ne değişir?

Güncellenmemiş bir site için "şu tarihte hacklenir" demek mümkün değildir; risk bir olasılık değil bir birikimdir. Değişen şey, sitenin bilinen sorunlara karşı ne kadar süre açık kaldığı ve geri dönüşün ne kadar zorlaştığıdır. Aşağıdaki tablo ertelemenin mekanizmasını anlatır, bir süre tahmini vermez.

Bu birikimin dört somut sonucu vardır.

1. Bilinen açık, bilinen kalır. Bir eklentide güvenlik açığı bulunup düzeltme yayımlandığında, açığın neyi etkilediği sürüm notlarında ya da güvenlik bildirimlerinde kamuya açık hale gelebilir. Güncellenmemiş site, tarifi yayımlanmış bir kusuru taşımaya devam eder.
2. Uyumluluk kopar. Eklenti geliştiricileri yeni sürümlerini güncel WordPress ve PHP sürümlerine göre test eder. Çekirdeği güncelleyip eklentiyi güncellemeyen ya da tersini yapan site, birbirini hiç görmemiş iki sürümü yan yana çalıştırır.
3. Sıçrama büyür. İki yıl beklemiş bir siteyi güncellemek, iki yıl boyunca her ay biraz güncellemekten daha risklidir; çünkü aradaki bütün değişiklikler tek seferde gelir ve hangisinin sorunu çıkardığı ayırt edilemez.
4. Arıza görünmeden başlar. Bozulan bir iletişim formu, çalışmayan bir önbellek ya da kayan bir mobil menü sitenin "açık" görünmesine engel olmaz. Ziyaretçi şikâyet edene ya da Search Console'da hatalı sayfa sayısı artana kadar fark edilmeyebilir; dizin durumundaki değişikliğin nedenini okumak için Search Console durum teşhisi bir başlangıç noktasıdır.

Güvenlik yaması ile yeni özellik aynı aciliyette mi?

Değildir, ve bu ayrımı yapmak hem riski hem iş yükünü küçültür. Rozetteki her satırı aynı ağırlıkta görmek, ya hepsini korkuyla ertelemeye ya da hepsine aynı anda basmaya götürür.

Bir güncellemenin güvenlik içerip içermediği, eklentinin sürüm notlarında (changelog) yazılır. "Security fix" ya da "güvenlik düzeltmesi" ifadesi geçen bir satır bekletilmez; yalnız yeni bir düğme ekleyen bir sürüm planlı güne bırakılabilir.

PHP sürümü: panelde görünmeyen ikinci saat

WordPress'in kendi gereksinim sayfası, sunucunun PHP 8.3 veya üzerini, MariaDB 10.11 veya MySQL 8.0 ve üzerini ve HTTPS desteğini karşılamasını öneriyor. Aynı sayfa, eski ortamlarda WordPress'in PHP 7.4 ile de çalıştığını ama bu sürümlerin resmi destek ömrünün bittiğini ve siteyi güvenlik açıklarına maruz bırakabileceğini açıkça yazıyor.

Bu, güncellemenin iki katmanlı olduğu anlamına gelir. Panelde her şeyi güncel tutsanız bile sunucu eski bir PHP sürümünde kalıyorsa yeni eklenti sürümleri ya kurulmaz ya da kurulup hata verir. Tersi de olur: hosting firması PHP'yi yükselttiğinde, yıllardır güncellenmemiş bir eklenti yeni sürümde çalışmayan bir işlev kullanıyorsa site bir sabah hata verir.

PHP yükseltmesi için pratik sıra şöyledir: hosting panelinde mevcut sürümü not edin, yedek alın, test kopyasında yeni sürüme geçip formları ve ana sayfaları deneyin, sorun yoksa yayındaki sitede aynı değişikliği yapın. Hosting firmanız yeni PHP sürümünü hiç sunmuyorsa sorun artık bir güncelleme sorunu değil bir altyapı kararıdır. Bu durumda hosting değiştirirken yapılan taşıma sırasında adreslerin ve tarayıcı erişiminin korunması ayrı bir plan ister.

Otomatik güncelleme neyi kendiliğinden yapar, neyi yapmaz?

"Otomatik güncellemeyi açtım, bakım bitti" düşüncesi yarı doğrudur. WordPress'in güncelleme belgesine göre 3.7 sürümünden beri küçük sürümler ve güvenlik güncellemeleri çoğu sitede arka planda kendiliğinden uygulanabiliyor. Büyük çekirdek sürümleri, eklentiler ve temalar ise ayrı bir karardır.

Eklenti ve tema otomatik güncellemesi WordPress 5.5 ile geldi ve tek tek açılır: belgeye göre yöneticiler eklenti ve tema bazında otomatik güncellemeyi seçerek etkinleştirebiliyor, eklenti listesinde toplu açıp kapatmak da mümkün. Aynı belge, WordPress'in varsayılan olarak günde iki kez otomatik güncelleme denediğini ve bir eklenti ya da tema başarıyla güncellendiğinde, güncellenemediğinde ya da bir kısmı başarılı bir kısmı başarısız olduğunda site sahibine e-posta gönderdiğini yazıyor.

Otomatik güncellemenin yapmadığı üç iş vardır:

• Güncellemeden sonra iletişim formunun gerçekten e-posta gönderip göndermediğini denemez.
• Bir eklenti güncellemesinin başka bir eklentiyle çakışıp bir sayfanın düzenini bozup bozmadığına bakmaz.
• Gelen bildirim e-postasını okumaz. E-posta, yıllar önce siteyi kuran kişinin artık kullanılmayan adresine gidiyorsa uyarı kimseye ulaşmaz.

Bu yüzden güvenlik yamalarının gecikmeden gelmesi için otomatik güncelleme açık kalabilir, ama yanına bir kontrol alışkanlığı eklenmelidir: bildirim e-postasının gittiği adresi güncel tutmak ve her otomatik güncellemeden sonra en az bir form gönderimi ile ana sayfaların mobil görünümünü denemek.

Güncelleme siteyi bozar mı? Bozulma nasıl görünür?

Bozabilir; bu yüzden güncelleme bir düğme değil bir işlemdir. Bozulma her zaman beyaz bir ekran olarak gelmez, ve hangi biçimde geldiğini bilmek geri dönüşü hızlandırır.

Tablodaki ikinci satır WordPress belgesinde ayrıca anlatılıyor: başarısız bir güncellemeden sonra "failed update" uyarısı kalıyorsa, WordPress dizinindeki .maintenance dosyası FTP ile silinir. Son satırdaki yavaşlama ise sitenin kapanmasından daha zor fark edilir; yavaşlamayı site hızının satışa etkisi açısından tartmak, önce hangi ölçüye bakılacağını belirler.

Güncellemeden önce yedek: var olması yetmez

WordPress belgesi güncellemeye başlamadan önce siteyi yedeklemeyi öneriyor ve sorun çıkarsa yedeğin geri yüklenebileceğini yazıyor. Yedekleme belgesi ise iki noktayı açıkça belirtiyor: bir WordPress sitesinin yedeği veritabanı ve dosyalar olmak üzere iki parçadan oluşur ve siteyi tam geri yüklemek için ikisi de gerekir; veritabanı düzenli olarak ve her yükseltmeden önce mutlaka yedeklenmelidir. Aynı belge en az üç ila beş güncel yedeğin, farklı yerlerde saklanmasını öneriyor: biri sunucuda, biri bulut depolamada, biri yerel bilgisayarda.

Pratikte yedeğin üç sorusu vardır:

• Nerede duruyor? Yalnız hosting sunucusunda duran bir yedek, sunucunun kendisi sorun yaşadığında işe yaramaz.
• İkisi de var mı? Yalnız dosyaları kopyalamak yazıları, sayfaları ve ayarları taşıyan veritabanını kapsamaz.
• Geri yüklendi mi? Hiç geri yüklenip denenmemiş bir yedeğin çalışıp çalışmadığı, ona ihtiyaç duyulan gün öğrenilir. Yılda birkaç kez yedeği bir test ortamına açıp sitenin göründüğünü doğrulamak bu soruyu önceden cevaplar.

Test kopyası ve güncelleme sırası

Test kopyası (staging), yayındaki sitenin ziyaretçiye kapalı bir ikizidir. Bazı hosting panelleri tek tıkla oluşturmayı sunar; sunmuyorsa bir alt alan adında ve arama motorlarına kapalı biçimde kurulur. Güncelleme önce orada denenir, sonra yayına alınır.

Planlı bir bakım gününde izlenebilecek sıra:

1. Yayındaki sitenin veritabanı ve dosya yedeğini alın, yedeğin dosya boyutunun beklenen büyüklükte olduğuna bakın.
2. Test kopyasını yayındaki sitenin güncel haliyle yenileyin.
3. Test kopyasında önce eklentileri tek tek güncelleyin; her birinden sonra ana sayfayı, bir iç sayfayı ve formu açın.
4. Ardından temayı, en son çekirdeği güncelleyin.
5. Formu gerçek bir gönderimle deneyin, mobil görünüme bakın.
6. Sorun yoksa aynı sırayı yayındaki sitede uygulayın.
7. Yayındaki sitede de formu deneyin ve neyin hangi sürüme geçtiğini bir kayda yazın.

Tek tek ilerlemenin değeri, sorun çıktığında suçlunun hemen bilinmesidir. On eklentiyi birlikte güncelleyip bozulan bir siteyi düzeltmek, on olasılığı tek tek elemek demektir.

Güncelleme siteyi bozarsa geri dönüş planı

Geri dönüş planı, bir sorun çıkmadan önce yazılır. Panik anında hangi dosyanın nerede olduğunu aramak, kesinti süresini uzatır.

Yönetim paneline girilebiliyorsa: son güncellenen eklentiyi devre dışı bırakın ve siteyi kontrol edin. Sorun kalktıysa eklentinin önceki sürümüne dönmek ya da geliştiricinin düzeltme sürümünü beklemek arasında karar verilir.

Panele girilemiyorsa: FTP ya da hosting dosya yöneticisiyle wp-content/plugins klasöründe şüpheli eklentinin klasör adını değiştirmek, WordPress'in o eklentiyi yüklemesini durdurur. Tema kaynaklı bir sorunda aynı işlem temalar klasöründe yapılır ve WordPress varsayılan temaya döner.

Sorun eklentiden değil çekirdekten ya da veritabanından geliyorsa: güncelleme öncesi alınan yedek geri yüklenir. WordPress belgesi de yükseltme sonrası sorun yaşanırsa yedeğin geri yüklenip dosyaların önceki sürümle değiştirilebileceğini yazıyor.

Planın sonunda bir kayıt satırı olmalıdır: ne güncellendi, ne bozuldu, nasıl dönüldü, kalıcı çözüm ne. Bu kayıt, aynı eklentinin bir sonraki sürümünde ne bekleneceğini söyler.

Yıllardır güncellenmemiş site: birikmiş işi sırayla almak

Rozetteki sayı yirmiyi geçmişse ve çekirdek birkaç büyük sürüm gerideyse, işi tek oturumda bitirmeye çalışmak en riskli yoldur. WordPress'in yükseltme belgesi, iki büyük sürümden fazla atlanacaksa olası çakışmaları önlemek ve veritabanı hasarı riskini azaltmak için yükseltmenin kademeli yapılmasını öneriyor.

Birikmiş bir sitede iş şu sırayla planlanabilir:

1. Envanter. Her eklentinin mevcut sürümü, son güncellenme tarihi ve geliştiricisinin hâlâ destek verip vermediği listelenir. Uzun süredir güncelleme almamış bir eklenti, listeye "yerine geçecek seçenek aranacak" notuyla yazılır.
2. Ayıklama. Kullanılmayan eklentiler ve temalar kaldırılır; devre dışı durmaları yetmez, dosyaları sunucuda kalır.
3. PHP katmanı. Sunucunun desteklediği PHP sürümü ile hedef sürüm belirlenir.
4. Kademeli yükseltme. Test kopyasında çekirdek ara sürümlerden geçirilerek, her adımda site kontrol edilerek yükseltilir.
5. Yayına alma. Test kopyasında her şey çalıştıktan sonra yayındaki sitede aynı sıra uygulanır.

Bu iş bir öğleden sonraya sığmayabilir ve sığdırılmaya çalışılmamalıdır. Bazen envanter, sitenin yenilenmesinin güncellenmesinden daha mantıklı olduğunu da gösterir; o kararı kalıcı bir altyapı sorusu olarak ele almak gerekir.

Güncelleme takvimini kim tutacak?

Ertelenen güncelleme teknik olduğu kadar bir sahiplik sorunudur. Site kurulduğunda ajans güncellemeleri yapıyordu, sonra ilişki bitti; hosting firması "biz sunucudan sorumluyuz" dedi; işletme sahibi panelde rozeti gördü ama dokunmadı. Takvim kimsenin değilse, güncelleme de kimsenin değildir.

Hangi yol seçilirse seçilsin, dört bilginin işletmenin elinde olması gerekir: hosting paneline, alan adı kaydına ve WordPress yönetimine kimin eriştiği; son yedeğin nerede durduğu. Bu erişimlerin işletme adına açılıp açılmadığı ve bir ilişki bittiğinde nasıl devredileceği dijital varlık mülkiyeti ve devir listesiyle kontrol edilebilir. Bakımı dışarıdan alacaksanız işin sıklığını, yanıt süresini ve çıkış koşullarını bakım sözleşmesinin içeriği belirler. Bakım bedeli de alan adı ve hosting gibi her yıl tekrarlanan bir kalemdir; web sitesinin yıllık maliyeti hesaplanırken ayrı satır olarak yazılmalıdır.

Güncelleme takvimini dışarıya verdiğinizde web sitesi bakım hizmeti şu düzenle yürür: çekirdek, eklenti ve tema güncellemeleri önce bir test kopyasında denenir, her güncellemeden önce yedek alınır ve yedek belirli aralıklarla geri yüklenerek doğrulanır; ay içindeki güncellemeler, ertelenenlerin nedeni ve form testleri tek bir raporda tarihleriyle yazılır. İlk görüşmede sorulan şey, panelinize ve son yedeğinize bugün kimin eriştiğidir.

Sıkça Sorulan Sorular

WordPress güncellemesi yapılmazsa site hacklenir mi?

Güncellenmemiş her site hacklenmez, ama bilinen güvenlik açıklarına karşı açık kalma süresi uzar. Bir eklentideki açık düzeltildiğinde, açığın neyi etkilediği sürüm notlarında ya da güvenlik bildirimlerinde kamuya açık hale gelebilir; güncellemeyi almayan site o kusuru taşımaya devam eder. Risk tek bir tarihte gerçekleşen bir olay değil, ertelenen her ayla büyüyen bir birikimdir. Güvenlik düzeltmesi içeren sürümler bu yüzden planlı güne bırakılmadan, önce yedek alınarak hemen uygulanmalıdır.

WordPress güncellemesi siteyi bozar mı?

Bozabilir. Görülebilecek biçimler arasında bir eklentinin yeni sürümünün PHP sürümüyle ya da başka bir eklentiyle uyumsuzluğu nedeniyle sitenin "kritik hata" vermesi, tasarımın kayması veya formun e-posta göndermemesi vardır. Riski küçültmek için güncellemeden önce veritabanı ve dosya yedeği alınır, güncelleme önce test kopyasında denenir ve eklentiler tek tek güncellenir. Böylece sorun çıktığında hangi güncellemenin neden olduğu hemen bilinir ve yalnız o geri alınır.

WordPress'te otomatik güncellemeyi açık bırakmalı mıyım?

Güvenlik yamalarının gecikmeden gelmesi için açık bırakmak savunulabilir. WordPress 3.7'den beri küçük sürümleri ve güvenlik güncellemelerini çoğu sitede arka planda kendiliğinden uyguluyor; eklenti ve tema otomatik güncellemesi ise 5.5'ten beri tek tek açılabiliyor ve sonuç site sahibine e-postayla bildiriliyor. Ama otomatik güncelleme, güncelleme sonrasında formun çalışıp çalışmadığını ya da bir sayfanın bozulup bozulmadığını kontrol etmez. Bildirim e-postasının gittiği adres güncel tutulmalı ve her güncellemeden sonra en az bir form testi yapılmalıdır.

Eklenti güncellemesi siteyi bozduysa nasıl geri alınır?

Yönetim paneline girilebiliyorsa son güncellenen eklenti devre dışı bırakılıp site kontrol edilir. Panele girilemiyorsa FTP veya hosting dosya yöneticisiyle wp-content/plugins klasöründe o eklentinin klasör adı değiştirilir; WordPress eklentiyi yüklemeyi bırakır; sorun o eklentideyse site yeniden açılır. Sorun çekirdekten ya da veritabanından geliyorsa güncelleme öncesinde alınan yedek geri yüklenir. Kalıcı çözüm, eklentinin önceki sürümüne dönmek ya da geliştiricinin düzeltme sürümünü beklemektir.

WordPress güncellemesinden önce ne yapılmalı?

Önce veritabanı ve dosyaların ikisini de kapsayan bir yedek alınmalıdır; WordPress belgesi veritabanının her yükseltmeden önce yedeklenmesini ve en az üç ila beş güncel yedeğin farklı yerlerde saklanmasını öneriyor. Ardından sunucunun PHP sürümü ve eklentilerin uyumluluk notları kontrol edilir. Mümkünse güncelleme önce test kopyasında denenir, eklentiler tek tek güncellenir, en son çekirdek alınır. Güncellemeden sonra form gerçek bir gönderimle denenir ve neyin hangi sürüme geçtiği kayda yazılır.