WordPress Güncelleme Rehberi: Sıra, Yedek ve Geri Alma Adımları

WordPress panosuna girdiğinizde beliren turuncu güncelleme rozeti iki farklı riski aynı anda taşır. Güncellemeyi yaparsanız site bozulabilir; yapmazsanız bilinen bir açıktan siteniz ele geçirilebilir. Saldırıya uğrayan WordPress sitelerinin büyük çoğunluğu sıfırıncı gün açıklarından değil, aylardır yayınlanmış ve yamalanmış açıklardan giriliyor.

Doğru yaklaşım “hemen tıkla” ile “hiç dokunma” arasında değil. Güncellemeyi bir işleme dönüştürmek gerekiyor: neyi hangi sırayla güncelleyeceğiniz belli olacak, öncesinde geri dönebileceğiniz bir yedek duracak ve sonrasında bakacağınız kısa bir kontrol listesi olacak.

Aşağıda bu işlemi sıradan bir kurumsal sitede uygulanabilir hale getiriyoruz. On beş dakikalık bir rutin, gecelerce süren kurtarma çalışmasından ucuza gelir.

Güncelleme sırası: önce ne, sonra ne?

Hepsini aynı anda “Tümünü seç, güncelle” ile yapmak en kötü yöntemdir, çünkü bir şey bozulduğunda hangisinin bozduğunu bilemezsiniz. Şu sırayı izleyin:

1. PHP sürüm uyumu kontrolü. Sunucuda çalışan PHP sürümü ile güncellenecek sürümün gereksinimi uyuşuyor mu bakın.
2. Yedek. Dosyalar ve veritabanı birlikte.
3. Eklentiler, teker teker. Önce güvenlik ve önbellek eklentileri gibi kritik olanlar; her birinden sonra ana sayfayı yenileyin.
4. Tema. Çocuk tema kullanıyorsanız ana temayı güncelleyin.
5. WordPress çekirdeği. Ana sürüm atlamalarında (örneğin 6.4’ten 6.7’ye) en sona bırakın.
6. Çeviri dosyaları. Panoda ayrıca listelenir, en zararsız adımdır.

İstisna: güvenlik açığı duyurulmuş tek bir eklenti varsa sıra beklemeden onu güncelleyin. WooCommerce, form eklentileri ve dosya yükleme eklentileri bu grupta en sık kritik yama alanlardır.

Otomatik güncellemeleri açmak mantıklı mı?

WordPress küçük sürümleri (6.7.1 gibi bakım ve güvenlik sürümleri) varsayılan olarak otomatik yükler ve bunu kapatmak için bir sebebiniz yoksa açık kalmalı. Asıl karar eklenti ve tema için verilir. Panoda Eklentiler > Yüklü Eklentiler ekranında her satırın sağında “Otomatik güncellemeleri etkinleştir” bağlantısı bulunur.

E-ticaret sitelerinde otomatik güncellemeyi ödeme akışına dokunan hiçbir bileşende açmayın; hangi bileşenlerin bu kapsama girdiğini WooCommerce barındırma yazısında ayrıntılandırdık.

Güncelleme öncesi yedek: neyi, nereye

Panodaki “Güncelle” düğmesine basmadan önce elinizde iki parça olmalı: wp-content klasörü (tema, eklenti, yüklenen dosyalar) ve veritabanının SQL dökümü. cPanel kullanıyorsanız Yedekler > Tam Yedek İndir ikisini birlikte verir; hızlı yol isterseniz phpMyAdmin > veritabanı seç > Dışa Aktar > Hızlı > SQL ile veritabanını, Dosya Yöneticisi ile public_html/wp-content klasörünü sıkıştırıp indirin.

Yedeğin en kritik özelliği geri yüklenebilir olmasıdır. Hiç denenmemiş yedek, yedek sayılmaz. Yılda bir kez yedeği boş bir alt alan adına geri yükleyip açılıyor mu bakın. Yedekleme sıklığı ve saklama süresi kararlarını WordPress yedekleme rehberinde ayrıca ele alıyoruz.

Hazırlık (staging) ortamı nasıl kullanılır?

Staging, canlı sitenin birebir kopyasının ayrı bir adreste çalışmasıdır; genelde staging.siteadi.com gibi bir alt alan adında durur. Güncellemeyi önce burada yapar, sonuçları görür, sorun yoksa aynı işlemi canlıda tekrarlarsınız. Modern cPanel paketlerinde WP Toolkit üzerinden tek tıkla kopya oluşturulabiliyor.

İki noktaya dikkat edin. Birincisi, staging kopyası arama motorlarına kapatılmalı: Ayarlar > Okuma > Arama motorlarının siteyi indekslemesini engelle işaretli olsun, aksi halde kopya içerik olarak taranır. İkincisi, staging üzerinde gerçek e-posta gönderimi ve gerçek ödeme testi yapmayın; form eklentilerinin bildirim adreslerini kendi adresinize çevirin.

Güncelleme sonrası kontrol listesi

Güncelleme bittiğinde pano “Başarılı” yazar ama bu sitenin çalıştığı anlamına gelmez. Beş dakikalık şu turu atın:

• Ana sayfa, bir kategori sayfası ve bir yazı sayfasını gizli sekmede (oturum açmadan) açın.
• İletişim formunu gerçekten doldurup gönderin, e-posta düşüyor mu bakın.
• E-ticaret varsa sepete ürün ekleyip ödeme adımına kadar ilerleyin.
• Tarayıcıda F12 ile Konsol sekmesine bakın; kırmızı JavaScript hatası düzenin bozulacağının habercisidir.
• Arama kutusu, menü ve mobil menüyü test edin.
• Ayarlar > Kalıcı Bağlantılar ekranını açıp kaydete basın; kural dosyası yenilenir, 404 sorunlarının bir kısmı burada çözülür.
• Site hızını ölçen bir araçla önceki değerle kıyaslayın; güncelleme bazen yeni bir betik yükler.

Bozulan siteyi geri alma

Güncelleme sonrası beyaz ekran ya da “Bu sitede kritik bir hata oluştu” mesajı görüyorsanız panik yapmadan sırayla ilerleyin. WordPress böyle durumlarda site yöneticisinin e-posta adresine “Sitenizde teknik bir sorun var” başlıklı bir kurtarma modu bağlantısı gönderir; bu bağlantı sorunlu eklentiyi devre dışı bırakmış bir panoya sokar.

E-posta gelmediyse FTP veya cPanel Dosya Yöneticisi ile wp-content/plugins klasörünün adını plugins-eski yapın. Site açılırsa sorun bir eklentidedir; klasör adını geri alıp eklentileri tek tek etkinleştirerek suçluyu bulun. Site hâlâ açılmıyorsa wp-content/themes içinde varsayılan bir tema (örneğin twentytwentyfour) duruyorsa aktif temanın klasör adını değiştirin, WordPress varsayılana düşer. Bu tür arızaların tam teşhis akışını beyaz ekran hatası yazısında adım adım anlatıyoruz.

Son çare yedekten dönmektir. Veritabanını geri yüklemeden önce mevcut halinin de bir dökümünü alın; iki kayıt arasında karşılaştırma yapmanız gerekebilir.

PHP sürümü uyumu

Güncelleme sorunlarının sessiz sebebi genelde PHP’dir. Güncel WordPress sürümleri PHP 7.4 ile çalışır ama 8.1 ve üstünü önerir; buna karşılık eski bir tema PHP 8’de Deprecated uyarıları veya ölümcül hata üretebilir. cPanel’de Yazılım > PHP Sürümü Seç ekranından sürümü değiştirebilirsiniz.

Sürüm yükseltmeden önce sitenin kopyasını yeni sürümde açıp gezinin. Hata görünmüyorsa canlıya geçin; eski bir eklenti nedeniyle takılıyorsanız o eklentiyi değiştirmek, PHP’yi eski sürümde tutmaktan daha güvenlidir çünkü desteği biten PHP sürümleri güvenlik yaması almaz. Seçim ölçütlerini PHP sürümü seçimi yazısında ayrıntılı bulabilirsiniz.

Özetle

• Güncellemeyi sıraya sokun: PHP uyumu, yedek, eklentiler tek tek, tema, çekirdek.
• Çekirdek küçük sürümlerde otomatik güncelleme açık kalsın; ödeme ve düzenle ilgili bileşenlerde kapalı olsun.
• Her güncellemeden önce dosya artı veritabanı yedeği alın ve yedeğin geri yüklenebildiğini yılda bir test edin.
• Riskli güncellemeleri önce arama motorlarına kapalı bir staging kopyasında deneyin.
• Bozulma halinde önce kurtarma modu e-postasına, sonra plugins klasörünü yeniden adlandırmaya, en son yedeğe başvurun.