Güncelleme Sonrası Site Bozuldu: Eski Sürüme Nasıl Dönülür

Dün akşam sorunsuz çalışan site, sabah açtığınızda tanınmaz haldedir: ana sayfanın düzeni dağılmış, iletişim formu kaybolmuş, ürün sayfaları boş geliyor ya da panelde beyaz bir ekran duruyordur. Panelde tek yeni olay, gece çalışan otomatik güncellemedir. WordPress güncelleme sonrası site bozuldu diye aradığınızda karşınıza çıkan ilk tavsiye genelde "eski sürüme dön" olur — doğru bir tavsiyedir ama yarım bir tavsiyedir, çünkü neyi geri alacağınızı bilmeden yapılan geri dönüş kör atıştır.

Bu yazı işi doğru sıraya koyuyor: önce hangi güncellemenin bozduğunu kanıtlamayı, sonra sadece o bileşeni önceki sürümüne döndürmeyi, en sonunda da geri dönüşün neden geçici bir manevra olduğunu ve kalıcı çözüme nasıl bağlanacağını anlatıyor. Ayrıca çoğu Türkçe kaynağın atladığı iki şeyi de ele alıyoruz: eklenti dizininin "Gelişmiş Görünüm" bölümünden istediğiniz eski sürümü nasıl indireceğinizi ve WordPress'in kendi çekirdek sürümünü geri almanın neden eklenti geri almaktan çok daha riskli olduğunu.

Geri Dönmeden Önce: Neyin Bozduğunu Bulmak Şart#

Bir güncelleme oturumunda genelde tek bir şey güncellenmez. Panelde "Güncellemeler" ekranındaki Tümünü Seç kutusuna basıp bıraktıysanız aynı anda sekiz eklenti, bir tema ve bazen çekirdek de güncellenmiş olabilir. Sekizini birden geri almak siteyi belki açar ama size hiçbir şey öğretmez: hangisinin sorunlu olduğunu bilmediğiniz için o eklentiyi bir daha asla güncelleyemez, aylarca yamasız kalırsınız.

Bu yüzden ilk iş suçluyu bulmaktır. Elinizde dört araç var ve genelde ilki yeter.

1. Hata kaydına bakın. En hızlı ve en kesin yol budur. wp-config.php dosyasına şunları ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Sayfayı bir kez yenileyip wp-content/debug.log dosyasını açın. Aradığınız satır tipik olarak şuna benzer:

PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_page_id()
in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/includes/class-front.php:214

Dosya yolundaki plugins/ornek-eklenti kısmı size suçluyu doğrudan söyler. Sunucu tarafındaki hata kayıtlarına da bakmak isterseniz cPanel hata kayıtları yazısı bu ekranı anlatıyor. Site tamamen beyazsa ve hiçbir çıktı yoksa WordPress beyaz ekran hatası yazısındaki teşhis akışı bu duruma özel.

2. Eklentileri topluca kapatıp tek tek açın. Panele giremiyorsanız FTP ya da Dosya Yöneticisi ile wp-content/plugins klasörünün adını plugins-kapali yapın; WordPress hiçbir eklentiyi bulamadığı için hepsini pasife alır. Site açıldıysa suçlu bir eklentidir. Sonra klasör adını geri alıp eklentileri tek tek etkinleştirin, site hangi eklentide bozulursa o. Aynı mantığın ayrıntılı hali WordPress eklenti çakışması yazısında.

3. Temayı varsayılana çevirin. Sorun sadece görünümdeyse (düzen kayması, yazı tipleri, boş bölümler) muhtemelen temadır. Görünüm → Temalar ekranından WordPress'in kendi varsayılan temasını etkinleştirin. Düzen düzeliyorsa suçlu tema güncellemesidir.

4. Zaman damgasını okuyun. FTP istemcisinde wp-content/plugins klasörünü değiştirilme tarihine göre sıralayın. Dün gece 03:14'te değişmiş üç klasör varsa şüpheli listeniz sekizden üçe iner.

Son satır özellikle önemli: e-ticaret kurulumlarında bozulmanın sebebi çoğu zaman ana eklentinin kendisi değil, ana eklenti güncellenirken güncellenmeyen bir ek modüldür. Bu durumda geri alınması gereken şey ana eklenti değil, ek modülün ana eklentiye uyumlu sürümünün yüklenmesidir.

Geri Almadan Önce Yedek Alın#

Kulağa tuhaf gelebilir — zaten bozuk bir siteyi neden yedekleyeyim? Çünkü geri alma işleminin kendisi de yanlış gidebilir ve o zaman "bozuk site" ile "hiç site yok" arasındaki farkı korumak istersiniz. Ayrıca bozuk halin bir kopyası, sorunu eklenti geliştiricisine bildirmek istediğinizde elinizdeki tek kanıttır.

Asgari yedek şudur:

cd /home/kullanici
tar -czf yedek-oncesi.tar.gz public_html
mysqldump -u db_kullanici -p db_adi > yedek-oncesi.sql

Panelden çalışıyorsanız cPanel'in Yedekleme aracı ya da kullandığınız yedekleme eklentisi de aynı işi görür. Sistematik bir düzen kurmak için WordPress yedekleme yazısına bakabilirsiniz.

Tek Bir Eklentiyi Önceki Sürüme Döndürme#

En sık ihtiyaç duyulan işlem budur ve iki yolu vardır.

Rollback eklentisiyle#

Panele girebiliyorsanız en pratik yol bir geri alma eklentisidir. Kurduktan sonra Eklentiler listesinde her eklentinin altında yeni bir "Rollback" bağlantısı belirir; tıkladığınızda o eklentinin dizinde yayımlanmış tüm eski sürümleri listelenir, birini seçip onaylarsınız.

Adımlar:

1. Eklentiler → Yeni Ekle'den geri alma eklentisini kurup etkinleştirin.
2. Eklentiler listesinde sorunlu eklentinin altındaki geri alma bağlantısına tıklayın.
3. Açılan ekranda bir önceki sürümü seçin, en eskisini değil. Bozulmanın sebebi son güncelleme ise bir adım geri gitmek yeter.
4. Onaylayın, işlem bitince siteyi kontrol edin.
5. İşiniz bitince geri alma eklentisini devre dışı bırakın. Sürekli açık durması gereken bir araç değildir.

Bu yöntemin tek sınırı, yalnızca WordPress eklenti dizinindeki ücretsiz eklentiler için çalışmasıdır. Ücretli/premium eklentilerin eski sürümleri dizinde bulunmaz; onları satıcının kendi hesap panelinden indirmeniz gerekir.

Manuel yöntem: eski sürümü elle indirip yerleştirme#

Panele hiç giremiyorsanız veya eklenti dizin dışıysa manuel yöntem tek seçenektir. Çoğu Türkçe kaynağın atladığı kısım burasıdır: WordPress eklenti dizinindeki her eklentinin sayfasında, sağ sütunun aşağısında "Gelişmiş Görünüm" (Advanced View) diye bir bağlantı vardır. O sayfanın en altında "Önceki Sürümler" başlıklı bir açılır liste bulunur; oradan istediğiniz sürümü seçip indirebilirsiniz. Bu, tüm eski sürümlerin herkese açık biçimde durduğu resmî kaynaktır.

Adımlar:

1. Eklentinin dizin sayfasını açın, sağ sütundan Gelişmiş Görünüm bağlantısına gidin.
2. Sayfanın altındaki "Önceki Sürümler" listesinden bir önceki sürümü seçip ZIP dosyasını indirin.
3. FTP veya Dosya Yöneticisi ile wp-content/plugins/eklenti-adi klasörünü silmeyin, adını eklenti-adi-yedek yapın.
4. İndirdiğiniz ZIP'i wp-content/plugins içine çıkarın. Klasör adı orijinaliyle aynı olmalı.
5. Siteyi kontrol edin. Düzeldiyse eklenti-adi-yedek klasörünü silebilirsiniz.

SSH erişiminiz varsa aynı işlem WP-CLI ile tek satıra iner:

wp plugin update ornek-eklenti --version=3.4.2

Evet, update komutu geriye doğru da çalışır; --version bayrağıyla istediğiniz sürümü zorlarsınız. Hangi sürümlerin mevcut olduğunu görmek ve kurulu sürümü öğrenmek için:

wp plugin get ornek-eklenti --field=version
wp plugin list --update=available

WP-CLI'yi hiç kullanmadıysanız WP-CLI kullanımı yazısı kurulumu ve temel komutları anlatıyor.

⚠️ Bir eklentiyi geri alırken veritabanı tarafını unutmayın. Bazı eklentiler güncellenirken kendi tablolarında şema değişikliği yapar. Yeni sürüm bir sütun eklediyse ve siz eski sürüme dönerseniz eski kod o sütunu tanımaz — genelde sorun çıkmaz ama bazı e-ticaret ve form eklentilerinde veri kaybı riski vardır. Bu yüzden geri almadan önce alınan veritabanı yedeği pazarlık konusu değildir.

Temayı Eski Sürüme Döndürme#

Tema geri alma mantık olarak aynıdır, tek farkı klasörün wp-content/themes altında olmasıdır:

wp theme update ornek-tema --version=2.8.1

Manuel yapıyorsanız temanın ZIP'ini indirip wp-content/themes/ornek-tema klasörünün adını değiştirin ve yeni klasörü çıkarın.

Burada kritik bir uyarı var: tema dosyalarını doğrudan düzenlediyseniz geri alma o düzenlemeleri siler. style.css veya functions.php içine elle eklediğiniz her satır, tema klasörü değiştiği an kaybolur. Bu, alt tema (child theme) kullanmanın neden zorunlu bir alışkanlık olduğunun en somut kanıtıdır; WordPress child tema yazısı kurulumu on dakikada anlatıyor. Alt tema kullanıyorsanız ana temayı istediğiniz kadar ileri geri alabilirsiniz, özelleştirmeleriniz ayrı klasörde durduğu için hiç etkilenmez.

WordPress Çekirdeğini Eski Sürüme Döndürmek#

Çekirdek sürümünü geri almak teknik olarak mümkündür ama eklenti geri almakla aynı ligde değildir ve son çare olarak düşünülmelidir.

WP-CLI ile:

wp core update --version=6.4.3 --force

Manuel yapmak isterseniz sıra şudur: ilgili sürümün ZIP arşivini WordPress'in resmî sürüm arşivinden indirin, wp-content klasörünü ve wp-config.php dosyasını hariç tutarak wp-admin ve wp-includes klasörlerini silin, arşivdeki karşılıklarını yükleyin, sonra kökteki dosyaların üzerine yazın.

Neden riskli olduğunu net söyleyelim:

• Veritabanı şeması geriye uyumlu değildir. WordPress büyük sürümlerde veritabanında yapı değişikliği yapar. Yeni sürüm veritabanını güncellemişse, eski çekirdek o yapıyla karşılaştığında beklenmedik davranabilir.
• Eklentileriniz artık yeni çekirdeğe göre yazılmış olabilir. Çekirdeği geri alınca bu kez eklentiler bozulur, sorunu bir yerden alıp başka yere taşımış olursunuz.
• Güvenlik yamalarından da vazgeçmiş olursunuz. Çekirdek güncellemelerinin önemli kısmı güvenlik düzeltmesidir; geri dönmek bilinen bir açığı geri açmak demektir.

Pratikte çekirdek güncellemesinin siteyi tek başına bozması nadirdir. Neredeyse her zaman gerçek sebep, yeni çekirdekle uyumsuz kalan bir eklenti veya temadır. Doğru hamle çekirdeği geri almak değil, o eklentiyi geri almak veya uyumlu sürümünü beklemektir.

Geri Döndükten Sonra Otomatik Güncelleme Sizi Tekrar Vurmasın#

Eski sürüme döndünüz, site açıldı. Şimdi tehlike şudur: WordPress birkaç saat içinde aynı eklentiyi tekrar güncelleyip sizi aynı noktaya geri getirebilir. Bu, geri alma yapan herkesin en az bir kez düştüğü tuzaktır.

Eklentiler ekranında ilgili eklentinin satırındaki "Otomatik güncellemeleri devre dışı bırak" bağlantısına tıklayın. Tüm site için otomatik güncellemeleri yönetmek isterseniz wp-config.php içinde:

// Yalnızca güvenlik/küçük sürüm güncellemeleri otomatik olsun
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Eklenti otomatik güncellemelerini toplu kapatmak için temanın functions.php dosyasına (tercihen alt temanın):

add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

⚠️ Bunu yaparken şunu bilerek yapın: otomatik güncellemeyi kapatmak, güncellemeyi yapmamak anlamına gelmez. Güncellemenin sorumluluğunu makineden alıp kendi üstünüze aldınız demektir. Takvime aylık bir hatırlatma koymuyorsanız bu ayar kısa sürede "hiç güncellenmeyen site"ye dönüşür ve bu, bozuk düzenden çok daha tehlikelidir.

Geri Dönmek Kalıcı Çözüm Değildir#

Bu bölümü atlamayın, çünkü rehberlerin çoğu tam burada bitiyor ve okuyucu geri döndüğü sürümde aylarca kalıyor.

Eski sürümde kalmanın üç maliyeti var. Birincisi güvenlik: eklenti güncellemelerinin büyük bölümü açık kapatır ve siz geri döndüğünüzde o açık tekrar açılır. Bilinen bir açığı olan eski sürüm, otomatik tarayan botlar için en kolay hedeftir. İkincisi uyumluluk: diğer eklentiler ve PHP sürümü ilerlemeye devam eder, geride kalan eklenti bir noktada tamamen çalışmaz hale gelir. Üçüncüsü birikim: altı ay sonra tek seferde on sürüm birden atlamak zorunda kaldığınızda, kırılma ihtimali her seferinde artar.

Doğru kapanış sırası şudur:

1. Geri alın, site açılsın (acil durum kapatıldı).
2. Eklentinin sürüm notlarını okuyun; kırılan şeyin ne olduğu genelde orada yazar.
3. Geliştiriciye durumu bildirin — hata kaydındaki satırı da ekleyin.
4. Bir kopya (staging) ortamı kurun ve düzeltme sürümünü orada deneyin. WordPress staging ortamı yazısı bunu nasıl kuracağınızı anlatıyor.
5. Kopyada sorunsuz çalıştığını gördüğünüzde canlıda güncelleyin ve otomatik güncellemeyi tekrar açın.

Bu döngüyü bir kez kurarsanız güncelleme korkusu biter. Genel çerçeve için WordPress güncelleme yönetimi yazısına da göz atın; hangi güncellemenin ne zaman yapılacağına dair bir takvim önerisi içeriyor.

Tablodaki dördüncü satır önemli: tam yedekten dönmek en kesin çözümdür ama yedek anından sonra gelen siparişleri, yorumları ve formları da geri alır. E-ticarette bu kabul edilemez olabilir; o yüzden hedefli geri alma her zaman önce denenmelidir.

Sıkça Sorulan Sorular#

Güncellemeyi geri alınca verilerim kaybolur mu#

Hayır, eklenti veya tema sürümünü geri almak yazılarınızı, sayfalarınızı, ürünlerinizi ve kullanıcı kayıtlarınızı etkilemez. Geri alma yalnızca wp-content/plugins veya wp-content/themes altındaki dosyaları değiştirir, veritabanına dokunmaz. Tek istisna, güncelleme sırasında kendi tablolarında yapı değişikliği yapan eklentilerdir; bu tür eklentilerde eski kod yeni yapıyla karşılaşınca bazı ayarları okuyamayabilir. Bu yüzden geri almadan önce veritabanı yedeği almak yine de doğru alışkanlıktır.

Hangi eklentinin bozduğunu bulamıyorum, hepsini birden geri alabilir miyim#

Teknik olarak alabilirsiniz ama önerilmez, çünkü sorunu çözmez sadece erteler. Hepsini birden geri aldığınızda site açılır fakat suçluyu öğrenemediğiniz için hiçbirini bir daha güvenle güncelleyemezsiniz. Daha iyi yol, eklenti klasörünün adını değiştirerek hepsini bir anda pasife almak, site açıldığını doğrulamak ve sonra tek tek etkinleştirerek sitenin hangisinde bozulduğunu görmektir. Bu işlem on eklenti için genelde on dakikadan kısa sürer ve size kesin cevabı verir.

Premium eklentinin eski sürümünü nereden bulurum#

Ücretli eklentilerin eski sürümleri WordPress eklenti dizininde bulunmaz; satın aldığınız satıcının kendi hesap panelinden indirilir. Çoğu satıcı hesabınızın indirmeler bölümünde sürüm geçmişini tutar. Orada bulamazsanız satıcının destek kanalından talep etmeniz gerekir, çünkü lisanslı yazılımın eski sürümü herkese açık biçimde dağıtılmaz. Bu yüzden ücretli eklentilerde en güvenilir kurtarma yolu, güncelleme öncesi alınan yedeğinizdir.

Otomatik güncellemeyi tamamen kapatmak doğru mu#

Tamamen kapatmak çoğu site için doğru değildir, çünkü güncellemelerin büyük bölümü güvenlik açığı kapatır. Makul yaklaşım, çekirdek için küçük sürüm güncellemelerini açık bırakmak, geçmişte sorun çıkarmış belirli eklentilerin otomatik güncellemesini kapatmak ve bunlar için elle bir kontrol takvimi belirlemektir. Otomatik güncellemeyi kapatıyorsanız yerine bir düzen koymak zorundasınız; aksi halde site birkaç ay içinde yamasız kalır ve bu, bozuk bir düzenden çok daha büyük bir risktir.

Site tamamen beyaz, panele hiç giremiyorum, nereden başlamalıyım#

Doğrudan dosya sistemine geçin: FTP ya da hosting panelinin Dosya Yöneticisi ile wp-content/plugins klasörünün adını plugins-kapali olarak değiştirin. WordPress hiçbir eklentiyi bulamayınca hepsini pasife alır ve panel genelde açılır. Panel açıldıysa sorun bir eklentidedir; klasör adını geri alıp eklentileri tek tek etkinleştirerek suçluyu bulun. Panel yine açılmıyorsa aynı işlemi aktif tema klasörü için tekrarlayın, o da işe yaramazsa hata kaydını açıp debug.log dosyasına bakın.

Yedekten dönmek mi daha iyi yoksa tek eklentiyi geri almak mı#

Sebep belliyse tek eklentiyi geri almak her zaman daha iyidir, çünkü yedekten dönmek yedek anından sonraki tüm veriyi siler. Bir e-ticaret sitesinde bu, gece gelen siparişlerin kaybolması demektir. Yedekten dönmeyi yalnızca birden fazla şey aynı anda bozulduğunda, sebep bulunamadığında ya da geri alma denemeleri işi daha kötü hale getirdiğinde tercih edin. Yedekten döndüğünüzde de ilk iş aynı güncellemeyi tekrar yapmadan önce bir kopya ortamda denemek olmalıdır.

Güncelleme sırasında bağlantı koptu, site yarım kaldı, ne yapmalıyım#

Önce panelde ya da kökte .maintenance adlı bir dosya olup olmadığına bakın; güncelleme yarıda kalınca bu dosya silinemez ve site "kısa süreliğine bakımda" mesajında takılır. Dosyayı silmek siteyi normale döndürür. Ardından yarım kalan eklenti veya temanın klasörünü kontrol edin; içi boş veya eksikse ilgili sürümün ZIP'ini indirip klasörü elden yerleştirin. Bağlantı kopması sık yaşanıyorsa güncellemeleri tarayıcı yerine WP-CLI ile yapmak daha güvenlidir, çünkü işlem sunucuda çalışır ve tarayıcı bağlantısına bağımlı değildir.

Kapanış#

Güncelleme sonrası bozulan bir siteyi kurtarmanın sırrı hızda değil sırada: önce hata kaydından veya eklenti kapatma yönteminden suçluyu kanıtla, sonra yedek al, sonra sadece o bileşeni bir sürüm geri çek, en sonunda otomatik güncellemeyi o bileşen için geçici olarak durdur. Çekirdeği geri almak listede en sonda ve neredeyse hiç gerekmeyen bir hamledir; sorun genelde çekirdekte değil, ona ayak uyduramayan bir eklentidedir. Ve unutmayın, geri dönmek bir onarım değil bir mola: kalıcı çözüm, düzeltme sürümünü bir kopya ortamda test edip canlıya güvenle almaktır.

Bu döngüyü kendi başınıza yürütmek istemiyorsanız işin altyapı tarafında kolaylaştırıcılar var. Günlük otomatik yedek, tek tıkla geri dönüş ve kopya (staging) ortamının hazır geldiği WordPress hosting paketleri bu senaryoyu doğrudan hedefler; güncellemeleri sizin yerinize test edip uygulayan, bozulma anında geri alan bir ekip isterseniz WordPress bakım hizmeti tam olarak bu işi üstlenir. Yedekleri siteden bağımsız ayrı bir katmanda tutmak için yedekleme çözümlerine, kendi sunucunuzda çalışıyor ve güncelleme/bakım yükünü devretmek istiyorsanız sunucu yönetimi hizmetine bakabilirsiniz.