Güncelleme Siteyi Bozdu: WordPress Eklenti ve Tema Sürümünü Geri Alma

Panelde "6 güncelleme mevcut" uyarısı duruyordu, hepsini işaretleyip güncelle dediniz. Sayfa yenilendi, yeşil onay satırları geldi. Sonra ön yüzü açtınız: ürün sayfaları boş, sepet çalışmıyor ya da tüm site beyaz. Saat 21:40 ve siparişler akıyordu.

Bu anda yapılan en yaygın hata, sorunu çözmeye çalışırken bir şeyler daha kurmaktır — bir önbellek eklentisi, bir "tamir" eklentisi, bir tema değişikliği. Her yeni değişken, hangi güncellemenin bozduğunu bulmayı zorlaştırır ve geri dönüş noktasını uzaklaştırır.

Bu yazı, panik anına uygun sırayı veriyor: önce durumu dondurma, sonra suçluyu tespit, sonra doğru eski sürümü resmî kaynaktan indirme ve panel, WP-CLI ya da FTP ile geri alma. Ardından asıl mesele: aynı güncellemenin sizi bir hafta sonra tekrar vurmasını engellemek.

Geri Almadan Önce Yapılacak Üç Şey#

1. Şu anki hâlin yedeğini alın. Kulağa ters gelebilir — bozuk hâli neden yedekleyesiniz? Çünkü geri alma işlemi sırasında yapacağınız bir hata (yanlış klasörü silmek, yarım kalan bir dosya kopyası) sizi bozuk siteden bile geriye götürebilir. Bir de eklentinin yeni sürümde oluşturduğu veriler varsa, onları kaybetmeden inceleme şansınız olur. Bu, olması gereken düzenli yedekten ayrıdır; WordPress yedekleme yazısındaki plan zaten kuruluysa, güncelleme öncesi son yedeğin saatini not edin.

2. Hata mesajını okuyun, tahmin etmeyin. Beyaz ekran çoğu zaman gizlenmiş bir PHP fatal hatasıdır ve o hata suçlunun dosya yolunu adıyla yazar. wp-config.php içine geçici olarak ekleyin:

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

Ardından wp-content/debug.log dosyasının sonuna bakın:

tail -n 40 wp-content/debug.log

Fatal error: Uncaught Error: Call to undefined method ... in /wp-content/plugins/ornek-eklenti/includes/class-x.php on line 212 gibi bir satır, işinizin yarısını bitirir. Sorun tek eklentiyle sınırlı değilse çakışma senaryosunu WordPress eklenti çakışması yazısında ele alıyoruz.

3. Başka güncelleme yapmayın. Panelde kalan güncellemeleri bu iş bitene kadar bekletin. Aynı anda birden fazla değişken oynatmak, geri alma sonrası "düzeldi mi, neden düzeldi" sorusunu cevaplanamaz hâle getirir.

Hangi Güncelleme Bozdu: Suçluyu Bulma#

Hata günlüğü dosya yolunu verdiyse bu adımı atlayabilirsiniz. Vermediyse — örneğin site açılıyor ama bir özellik sessizce çalışmıyorsa — güncellenen dosyaların zaman damgası size listeyi verir.

WordPress bir eklentiyi güncellerken klasörünü yeniden yazar, dolayısıyla o klasörün değişim zamanı güncelleme anıdır:

# Son 24 saatte değişen eklenti ve tema klasörleri
find wp-content/plugins wp-content/themes -maxdepth 1 -mmin -1440 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

WordPress 6.3 ile birlikte, elle yapılan güncellemelerde eski sürüm geçici olarak wp-content/upgrade-temp-backup/ altına taşınıyor. Bu klasör hangi bileşenlerin son turda güncellendiğini de gösterir:

ls -la wp-content/upgrade-temp-backup/plugins/ wp-content/upgrade-temp-backup/themes/ 2>/dev/null

WP-CLI kuruluysa mevcut ve yeni sürümleri tek tabloda görebilirsiniz:

wp plugin list --fields=name,status,version,update,update_version

Suçlu hâlâ belirsizse klasik yöntem işe yarar: tüm eklentileri devre dışı bırakıp teker teker açmak. Site açılmıyorsa bunu panelden yapamazsınız, ama FTP ile wp-content/plugins klasörünü plugins-kapali olarak yeniden adlandırmak hepsini birden devre dışı bırakır. Site açıldıysa klasörü eski adına döndürüp eklentileri sırayla etkinleştirin.

# Komut satırında daha hızlısı: hepsini kapat, sonra tek tek aç
wp plugin deactivate --all
wp plugin activate ornek-eklenti

Sıra dışı bir ipucu: soruna yeni sürümün kendisi değil, onun gerektirdiği PHP sürümü de neden olabilir. Eklentinin readme.txt dosyasındaki Requires PHP satırını sunucunuzdaki sürümle karşılaştırın.

WordPress.org Gelişmiş Görünümünden Doğru Sürümü İndirme#

Resmî dizindeki her eklentinin sayfasında, sağ menüde "Advanced View" (Gelişmiş Görünüm) bağlantısı vardır. Bu sayfanın altında "Previous Versions" başlıklı bir açılır liste bulunur; buradan istediğiniz sürümü seçip indirebilirsiniz. Adres kalıbı şudur:

https://wordpress.org/plugins/EKLENTI-SLUG/advanced/

Aynı sayfada değişiklik günlüğü (changelog) de listelenir. Geri alacağınız sürümü seçmeden önce burayı okuyun: aradaki sürümlerden birinde bir güvenlik yaması varsa, çok geriye gitmek yerine yamayı içeren en eski sürümü hedefleyin.

ZIP dosyalarına doğrudan da erişebilirsiniz. Kalıplar sabittir:

Slug, eklentinin dizin adresindeki addır — wordpress.org/plugins/wordpress-seo/ için slug wordpress-seo'dur ve sunucudaki klasör adıyla aynıdır. Sürüm numarasını noktalı hâliyle yazın:

# Sunucuya doğrudan indir
cd ~/public_html/wp-content/plugins
wget https://downloads.wordpress.org/plugin/ornek-eklenti.4.9.7.zip

Adres 404 dönüyorsa o sürüm numarası yayınlanmamıştır; gelişmiş görünüm sayfasındaki listeden gerçek numarayı doğrulayın (bazı eklentiler 4.9.7.1 gibi dört haneli sürümler kullanır).

Üç Geri Alma Yöntemi: Panel, WP-CLI, FTP#

Hangisini seçeceğiniz, sitenin şu anki durumuna ve elinizdeki erişime bağlı.

WP Rollback ile panelden geri alma#

WP Rollback, resmî dizindeki eklenti ve temaların yanına "Rollback" bağlantısı ekler. Bağlantıya tıkladığınızda yayınlanmış tüm sürümleri radyo düğmesi olarak listeler, seçtiğinizi kurar. Panel açılıyorsa en pratik yol budur.

Kurulumdan sonra Eklentiler listesinde her satırın altında yeni bir bağlantı belirir; temalar için ise tema detay penceresinde görünür. Premium eklentilerde bu bağlantı çıkmaz, çünkü sürüm listesi WordPress.org'dan çekilir.

WP-CLI ile geri alma#

Site hiç açılmıyorsa en hızlı çözüm budur. --force bayrağı, kurulu sürüm daha yeni olsa bile üzerine yazılmasını sağlar:

# Eklentiyi belirli bir sürüme döndür
wp plugin install ornek-eklenti --version=4.9.7 --force

# Temayı belirli bir sürüme döndür
wp theme install ornek-tema --version=2.3.1 --force

# Çekirdeği geri almak gerekiyorsa (içeriğe dokunmaz)
wp core update --version=6.8.1 --force

--force olmadan komut "zaten kurulu" diyip çıkar. Kurulum bittikten sonra eklentinin etkin kaldığını doğrulayın:

wp plugin list --name=ornek-eklenti --fields=name,status,version

WP-CLI'yi kurmadıysanız WP-CLI kullanımı yazısındaki adımlarla birkaç dakikada hazır hâle getirebilirsiniz; bu tür acil durumlarda tek başına panele bağımlılığı ortadan kaldırır.

FTP ya da dosya yöneticisi ile elle geri alma#

Ne panel ne kabuk varsa dosyaları elle değiştirirsiniz. Sıra önemlidir:

1. Eski sürümün ZIP'ini bilgisayarınıza indirin ve açın.
2. FTP ile wp-content/plugins/ornek-eklenti klasörünü ornek-eklenti-yeni olarak yeniden adlandırın — silmeyin. WordPress klasörü bulamayınca eklentiyi otomatik olarak devre dışı bırakır, bu da beyaz ekranı hemen kaldırır.
3. Açtığınız eski sürüm klasörünü wp-content/plugins/ altına, orijinal adıyla yükleyin.
4. Panele girip eklentiyi tekrar etkinleştirin.
5. Site düzeldiyse -yeni sonekli klasörü silin.

Tema için aynı sıra wp-content/themes/ altında geçerlidir; ancak etkin temanın klasörünü yeniden adlandırırsanız WordPress varsayılan temaya düşer. Alt tema kullanıyorsanız üst temayı değiştirirken alt temanın etkin kaldığını kontrol edin — ayrıntı için WordPress child tema yazısına bakabilirsiniz.

Premium Eklenti ve Temada Sürüm Nasıl Geri Alınır?#

Ücretli bir eklentinin eski sürümü WordPress.org'da bulunmaz; tek kaynak satıcının kendisidir. Uygulamada üç yol var:

• Satıcı hesabınızın indirme sayfası. Çoğu satıcı "Version History" ya da "Previous Releases" başlığı altında geçmiş ZIP'leri tutar. Lisansınızın süresi dolmuşsa bu sayfaya erişemeyebilirsiniz.
• Kendi arşiviniz. İyi bir alışkanlık: her premium paketin kurduğunuz sürümünü bir klasörde saklamak. Ayda bir dakikalık iş, acil durumda tek çözüm oluyor.
• Destek talebi. Satıcıya sürüm numarasını ve hatayı bildirin; genellikle önceki ZIP'i doğrudan gönderirler ve zaten bilinen bir hataysa yamanın ne zaman geleceğini de öğrenirsiniz.

Kaynağı belirsiz sitelerden "eski sürüm" indirmek bu noktada özellikle riskli. Bir hatayı çözmek için, içeriğini doğrulayamadığınız bir paketi sunucunuzda çalıştırmış olursunuz.

Veritabanı Değiştiyse Sadece Dosyayı Geri Almak Yetmez#

Bu, rollback rehberlerinin çoğunun atladığı ve en pahalıya patlayan nokta.

Bazı güncellemeler yalnızca PHP dosyalarını değiştirmez; etkinleştirildikleri anda veritabanı şemasını da günceller. Yeni tablo açar, sütun ekler, mevcut kayıtları yeni biçime dönüştürür ve "bu sürüme kadar göç tamamlandı" bilgisini bir seçenek kaydında tutar. WooCommerce'te bu woocommerce_db_version, birçok eklentide ..._db_version benzeri bir isimdir.

# Eklentinin veritabanı sürüm damgasını oku
wp option get woocommerce_db_version

# Şema göçü tutan seçenekleri genel olarak ara
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%_db_version';"

Dosyaları eski sürüme döndürdüğünüzde veritabanı yeni şemada kalır. İki sonuçtan biri olur: eski kod tanımadığı bir yapıyı okumaya çalışıp hata verir, ya da göç kodu baştan çalışıp veriyi ikinci kez dönüştürür. İkincisi sessizce veri bozar ve genellikle günler sonra fark edilir.

Belirti ile karar arasındaki ilişkiyi şöyle kurun:

Tam yedekten dönüş, güncelleme sonrası gelen içeriği (yeni siparişler, yorumlar, form kayıtları) da geri alır. Bu yüzden e-ticaret sitelerinde tercih edilen yol genellikle geri almak değil, yeni sürümde kalıp sorunu bir kod düzeltmesi ya da geçici devre dışı bırakmayla çözmektir. Kararın ayrıntılı çerçevesini güncelleme sonrası site bozuldu yazısında bulabilirsiniz.

WordPress'in Kendi Kurtarma Mekanizması Nereye Kadar Yeter?#

WordPress'te üç yerleşik koruma var ve üçünün de sınırı net:

Kurulum hatasında geri alma (6.3+). Elle güncelleme sırasında eski sürüm wp-content/upgrade-temp-backup/ altına taşınır; kurulum başarısız olursa WordPress eski sürümü geri koyar. Bu mekanizma yalnızca yükleme adımının çuvallamasını kurtarır. Yeni sürüm sorunsuz kurulup sonrasında siteyi bozuyorsa devreye girmez.

Kurtarma modu (5.2+). Etkin bir eklenti fatal hata verirse WordPress onu geçici olarak duraklatır ve yönetici e-postasına bir kurtarma bağlantısı gönderir. Bu bağlantı panele girmenizi sağlar ama sürümü geri almaz — yalnızca sorunlu bileşeni devre dışı bırakma imkânı verir.

Site Sağlığı ekranı. PHP sürümü, eksik modüller ve sorunlu bileşenler hakkında ipucu verir; bir güncellemeden sonra "neden bozuldu" sorusuna bakılacak ikinci yerdir.

Üçü birlikte, "site tamamen erişilemez kalmasın" güvencesi sunar. Sürüm yönetimi ise sizde kalır.

Geri Aldıktan Sonra Aynı Güncelleme Sizi Tekrar Vurmasın#

Geri alma işlemi bittiğinde WordPress o eklentiyi hâlâ "güncellenmesi gereken" olarak görür. Otomatik güncelleme açıksa birkaç saat içinde aynı sürüm geri gelir ve site ikinci kez bozulur. Kapatın:

# Belirli bir eklenti için otomatik güncellemeyi kapat
wp plugin auto-updates disable ornek-eklenti

# Durumu doğrula
wp plugin auto-updates status --all

Panelden yapmak isterseniz Eklentiler listesinde her satırın sağındaki "Otomatik güncellemeleri devre dışı bırak" bağlantısı aynı işi görür.

Güncelleme uyarısını tamamen susturmak isterseniz — özellikle satıcı yamayı yayınlayana kadar — tema veya site eklentisi içinde filtre kullanabilirsiniz:

// Yalnızca bu eklenti için otomatik güncellemeyi engelle
add_filter( 'auto_update_plugin', function( $update, $item ) {
    $engellenen = array( 'ornek-eklenti' );

    if ( isset( $item->slug ) && in_array( $item->slug, $engellenen, true ) ) {
        return false;
    }

    return $update;
}, 10, 2 );

Bu filtreyi eklerken yanına tarih ve gerekçe yazan bir yorum satırı bırakın. Altı ay sonra "bu neden kapalı" sorusunun cevabı orada olsun; aksi hâlde sabitlenmiş sürüm unutulur ve güvenlik yaması da kaçırılır.

Son olarak hatayı satıcıya bildirin. WordPress.org eklentilerinde destek forumunda, premium olanlarda bilet sistemi üzerinden. Bildiriminizde şunlar olsun: eklentinin çalışan ve bozulan sürüm numaraları, WordPress ve PHP sürümü, debug.log içindeki fatal hata satırı. Bu üç bilgi çoğu zaman düzeltmeyi günler kısaltır.

Kalıcı Çözüm: Güncellemeyi Önce Staging'de Denemek#

Bir güncellemenin canlıda bozulmasının nedeni neredeyse hiçbir zaman "kötü eklenti" değildir; sizin kurulumunuza özgü kombinasyondur — belirli bir tema, belirli bir PHP sürümü, belirli bir önbellek katmanı. Bunu önceden görmenin tek yolu aynı kombinasyonu kopyalayıp orada denemektir.

Pratik bir akış şöyle işler:

1. Canlı siteyi staging'e klonlayın (birçok panelde tek tıkla yapılır).
2. Güncellemeleri staging'de uygulayın, hepsini birden değil, gruplar hâlinde.
3. Kısa bir kontrol listesi geçin.
4. Sorun yoksa aynı sırayla canlıya uygulayın.
5. Canlıda önbelleği temizleyin ve aynı listeyi bir kez daha geçin.

Kontrol listesi kısa ama sabit olmalı:

Staging ortamının kurulumu ve canlıya aktarma sırasındaki tuzaklar için WordPress staging ortamı yazısına bakın. Güncellemeleri hangi sıklıkla ve hangi sırayla uygulayacağınıza dair bir takvim kurmak isterseniz WordPress güncelleme yönetimi yazısı bu işi tamamlıyor.

Sıkça Sorulan Sorular#

Eklentiyi eski sürüme döndürünce ayarlarım silinir mi?#

Hayır. Eklenti ayarları dosyalarda değil veritabanında, çoğunlukla wp_options tablosunda tutulur; sürüm değiştirmek bu kayıtlara dokunmaz. Ancak yeni sürüm ayar yapısını değiştirdiyse eski kod bazı değerleri tanımayabilir ve varsayılana dönebilir. Geri almadan önce ayar ekranlarının ekran görüntüsünü almak, birkaç saniyelik ama sık işe yarayan bir önlemdir.

Kaç sürüm geriye gitmeliyim?#

Bir sürüm geriye gidip test edin; sorun devam ederse bir daha geriye. Doğrudan çok eski bir sürüme atlamak iki risk taşır: aradaki güvenlik yamalarından mahrum kalırsınız ve bu arada değişmiş olan veritabanı yapısıyla uyumsuzluk ihtimali artar. Değişiklik günlüğünde "security fix" geçen sürümü geçmemeye çalışın.

WordPress çekirdeğini de aynı şekilde geri alabilir miyim?#

Teknik olarak evet, wp core update --version=X --force komutu ya da eski sürüm ZIP'ini elle açmak işe yarar. Ama çekirdek rollback'i eklentiden çok daha risklidir: ara sürümlerde veritabanı şeması değişmiş olabilir ve eklentileriniz yeni çekirdeğe göre güncellenmiştir. Çekirdeği geri almadan önce sorunun gerçekten çekirdekten geldiğini doğrulayın; genellikle suçlu bir eklenti çıkar.

Otomatik güncellemeyi tamamen kapatmalı mıyım?#

Hayır. Otomatik güncellemeler, açığı yayınlanan eklentilerde en etkili korumadır ve kapatıldığında yamalar aylarca uygulanmadan kalır. Doğru yaklaşım, sorun çıkaran tek eklenti için otomatik güncellemeyi kapatmak, diğerlerini açık bırakmak. Kapattığınız her bileşen için gerekçeyi ve tarihi yazın, sonra düzenli olarak gözden geçirin.

WP Rollback premium eklentilerde neden çalışmıyor?#

WP Rollback, sürüm listesini WordPress.org'un eklenti dizini API'sinden çeker. Premium bir eklenti bu dizinde yayınlanmadığı için geçmiş sürüm listesi yoktur ve eklenti o satır için "Rollback" bağlantısını göstermez. Ücretli paketlerde tek kaynak satıcının indirme sayfası ya da kendi sakladığınız ZIP arşividir.

Site tamamen açılmıyor ve panele giremiyorum, nereden başlamalıyım?#

FTP ya da dosya yöneticisinden wp-content/plugins klasörünü plugins-kapali olarak yeniden adlandırın; bu, tüm eklentileri devre dışı bırakır ve site genellikle açılır. Panele girdikten sonra klasörü eski adına döndürün, eklentileri tek tek etkinleştirerek suçluyu bulun ve yalnızca onu eski sürüme döndürün. Sunucu erişiminiz varsa aynı sonucu wp plugin deactivate --all komutuyla saniyeler içinde alırsınız.