Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma

Changelog

For the full history of older releases, see changelog.txt in the plugin folder.

1.62.0 — 2026-08-31

GÜVENLİK — panel ile eklenti arasındaki kimlik doğrulaması sıkılaştırıldı.

• direct-restore ucu artık SÜRESİZ statik sırla ÇAĞRILAMAZ. Panel her istekte
  zaman sınırlı (±10 dk) ve TEK KULLANIMLIK bir imza gönderir; yakalanan bir istek
  tekrar oynatılamaz. Bu koruma PHP modülünde zaten vardı, eklentiye taşındı (SEC-902).
• Geri yükleme arşivlerine zip-bomb tavanı eklendi: açılmış toplam boyut 20 GB’ı
  aşarsa arşiv AÇILMADAN reddedilir (yalnız metadata okunur, ek maliyeti yoktur).
  yedekalma_max_uncompressed_bytes filtresiyle yükseltilebilir (SEC-907).

• REST uçlarına hız sınırı eklendi: geri yükleme 5/dk · 60/saat, yedek tetikleme
  60/dk. Yedek kovası bilinçli olarak fail-open’dır — sayaç bozulursa yedekleme durmaz.

• wp-admin’den baslatilan geri yukleme, HMAC zorunlulugu eklendiginde kirilmisti —
  yayin oncesi duzeltildi (WP-201). Eklentinin kendi ic cagirisi (ya_call_direct_restore)
  istegi HTTP uzerinden degil surec icinde kurup uca DOGRUDAN veriyor; yani ayni kapidan
  geciyor. Yeni zorunlu X-Yedekalma-Auth basligini uretmedigi icin panel disindan
  baslatilan HER geri yukleme (yerel arsiv ve bulut bileti dallarinin IKISI de)
  “stale_or_missing_auth” ile reddedilecekti. Token artik elde bulunan sirdan uretiliyor;
  “guvenilir ic cagri” muafiyeti EKLENMEDI — o, SEC-902’yi geri alirdi.

⚠ YÜKSELTME SIRASI: bu sürüm paneli 2026-08-31 ve sonrası bir sürümde olan
kurulumlar içindir. Panel eski ise panelden başlatılan geri yükleme
“stale_or_missing_auth” ile reddedilir (yedekleme etkilenmez; wp-admin’den başlatılan
geri yükleme WP-201 düzeltmesiyle panelden bağımsız çalışır).
yedekalma.com panelini kullanıyorsanız yapmanız gereken bir şey yok.

1.61.1 — 2026-08-29

• Panel bir yedegi silmek istediginde, arsiv diskinizde KALDIGI HALDE “silindi”
  sayilabiliyordu (CORE-622). Indirme defterinde karsiligi olmayan bir jeton
  “adreslenemez” degil “dosya yok” gibi ele aliniyordu; panel kaydi dusuruyor, arsiv
  sunucunuzda duruyordu — yani disk dolmaya devam ederken panel “yer acildi” diyordu.
  Iki uc birden duzeltildi: (1) adreslenemeyen jeton artik HATA doner, panel kaydi KORUR
  ve yeniden dener; (2) defterin 500 kayitlik tavani, isaret ettigi dosya HALA DISKTE
  olan bir kaydi artik dusurmez (ayni kural TTL budamasinda zaten vardi, tavana
  uygulanmamisti).
• Veritabani dokumu GORUNUMLERI (VIEW) tablo saniyordu; TRIGGER ve saklı yordamlar hic
  yedeklenmiyordu (CORE-603). Tablo listesi SHOW TABLES ile aliniyordu ve o liste
  gorunumleri de dondurur: dokum bir gorunum icin DROP TABLE + CREATE VIEW yaziyor,
  ardindan satirlarini INSERT INTO <gorunum> olarak dokuyordu. Boyle bir sitede geri
  yukleme ILK HATADA duruyor ve veritabaninizi YARIM birakiyordu. Artik BASE TABLE ile
  VIEW ayriliyor; gorunumler, tetikleyiciler, sakli yordamlar ve olaylar tum tablolardan
  SONRA ve dogru soz dizimiyle yaziliyor.
• Bir e-posta hesabina baglanilamadiginda bu size HIC bildirilmiyordu (WP-602). Yedek
  “basarili” damgasi aliyor, eksik hesap yalnizca o anki gecici kayitta goruunup siliniyordu.
  Artik atlanan hesaplar panele raporlaniyor.
• Parcali yedekte “okunamayan klasor” sayaci panele hic gitmiyordu (WP-601). Izin hatasi
  ya da bozuk bir baglama yuzunden hic gezilemeyen bir klasor arsivden dusuyor, panelin
  kapsama denetimi ise bunu goremeden yedegi “tam” sayiyordu.
• component=email istegi sessizce “tum site” yedegine donusuyordu (WP-603). Artik
  desteklenmeyen bilesen acik bir hata donduruyor; sessiz genisletme yok.
• Geri yuklemede adinda iki nokta gecen mesru dosyalar (foto..jpg) sessizce atlaniyordu
  (WP-604). Dizin-atlatma korumasi yol ayracina bakmiyordu; artik bakiyor ve elenen girdi
  ayri bir sayaca yaziliyor.
• Guvenlik/temizlik: hata mesaji ayristirmasi artik DOMParser kullaniyor (WP-605); panel
  adresinin https zorunlulugu tek bir okuma kapisina alindi (WP-606); menuden kaldirilmis
  “Yedekleme Ayarlari” ekraninin olu kodu ve ona bagli olu betikler paketten cikarildi.
• Veritabani geri yuklemesinden sonra sitedeki yedeklerinize ulasilamiyordu (WP-901).
  Geri yukleme oncesi korunan eklenti ayarlarinin listesi ELLE tutuluyordu ve iki kritik
  kayit o listede YOKTU: yedek klasorunuzun (rastgele uretilen) ADI ve indirme jetonu
  defteri. DB geri yuklendikten sonra eklenti YENI bir klasor adi uretiyor, diskte duran
  ESKI klasoru ise hicbir yerde aramiyordu — arsivleriniz yerli yerinde dururken panelde
  listelenen her yedegin indirme / geri yukleme / silme baglantisi 404 veriyordu. Liste
  artik elle tutulmuyor: yedekalma onekli TUM ayarlar varsayilan olarak KORUNUYOR
  (yani ileride eklenecek bir ayar da kendiliginden korunur). Hicbir yedek dosyasi
  kaybolmamisti; kaybolan yalnizca onlara ulasan yoldu.
• “Artik dosyalari temizle” ekrani, artiklarin YARISINI goremiyordu (WP-907). Yonetim
  ekranindan baslatilan yedeklerin biraktigi gecici dosyalar (.tmp-full-…, .tmp-db-…,
  .tmp-list-…) ve Pro zamanlayicinin artiklari ekranin tanidigi listede yoktu. Ekran
  “temizlenecek artik dosya yok” derken GB’larca yarim arsiv diskinizde duruyordu — WP-Cron
  kapali sitelerde bu ekran tek cikis kapisidir. Artik iki dosya ailesini de goruyor ve
  siliyor. Calisan bir yedege ait dosyalara dokunmayan koruma her iki aileye de uygulaniyor.
  Ayni artiklar bundan boyle yedeginizin ICINE de girmiyor.
• Sembolik bagli uploads klasorunde geri yukleme medya kutuphanenizi dusurebiliyordu
  (WP-913). Bazi paylasimli hostinglerde wp-content/uploads baska bir diske BAG ile
  bagli olur. O sitelerde geri yukleme uploads altindaki her dosyayi sessizce atliyor,
  kok dizindeki dosyalar yazildigi icin de “basarili” donuyor ve ardindan silme adimini
  calistiriyordu. Yazma ve silme koruma cemberi artik WordPress’in kendi yapilandirilmis
  dizinlerini de taniyor.
• URL degistirme, birincil anahtari olmayan tablolarda yanlis satirlari yazabiliyordu
  (WP-914). Geri yukleme sirasinda site adresi degistiginde ucuncu taraf eklenti
  tablolarinda arama/degistirme kosuyor. Boyle bir tabloda anahtar yoksa ILK SUTUN
  anahtar sayiliyordu: ayni degeri paylasan tum satirlar birlikte yaziliyor, o sutun bos
  (NULL) ise degisim hic uygulanmiyordu. Artik satir tum sutunlariyla eslestiriliyor ve
  bos degerler dogru sinaniyor.
• Zararli yazilim taramasi, eklenti klasoru TAKLIDI eden yollari atliyordu (WP-912).
  Muafiyet yalnizca yolun SEKLINE bakiyordu; bu yuzden uploads altina birakilan
  yedekalma/includes/… gorunumlu bir dosya uc tarayicinin ucunden de muaf kaliyor ve
  taranan sayisina bile girmiyordu. Muafiyet artik konuma duyarli: yuklemeler klasorunde
  gecerli degil, diger yerlerde ise kopyanin gercekten eklentiye ait oldugu dogrulaniyor.
  Mesru kopyalar (WordPress guncelleme kalintisi, elle birakilmis eski surumler) eskisi
  gibi muaf kalmaya devam ediyor.
• Site boyutu olcumu, yedege GIRMEYECEK dosyalari sayiyordu (WP-910). Panelin
  gosterdigi “kaynak boyutu” — kapasite ve paket kararlarinin girdisi — kendi gecici
  artiklarimizi, sifreleme anahtari klasorunu ve okunamayan dosyalari da topluyordu.
  Olcum artik yedegin kendi eleme kurallarinin AYNISINI kullaniyor.
• Sifreleme anahtarini kaybetmis sitelerde her istek bir kayit yaziyordu (WP-917).
  Panel sirri cozulemeyen (zaten bozuk) bir kurulumda, kimlik dogrulanmadan ONCE calisan
  kontrol her istekte veritabanina yazip hata gunlugune satir ekliyordu; disaridan gelen
  istek seli gunlugu sisirebiliyordu. Uyari artik bir kez birakiliyor.
• Ic tutarlilik: indirme baglantisi yenilemede klasor siniri kontrolu kardes yollarla
  ayni hale getirildi (WP-909); yedek tamamlama bildiriminde iki alan yola gore
  degisiyordu, artik dort yol da ayni govdeyi uretiyor (WP-920).

1.61.0 — 2026-08-26

• Yonetim ekranlarindaki JavaScript metinleri artik cevriliyor (WP-956). PHP tarafi bes
  dilde tam cevriliydi; ama yedegin en kritik akisini yazan JavaScript — ilerleme adimlari,
  “Yedek basarisiz.”, “Iptal ediliyor…”, geri yukleme sonuc karti — TURKCE gomuluydu.
  Yabanci bir kullanici yedeginin basarili mi basarisiz mi oldugunu okuyamiyordu. Bu
  dizgeler artik eklentinin normal ceviri katalogundan (.pot/.po/.mo) geciyor.
  Davranis DEGISMEDI: ceviri gelmezse eskisi gibi ayni metin gosterilir.
• Sifreleme anahtariniz artik DB parolanizi degistirince kaybolmuyor (QA-960). WordPress
  guvenlik anahtari (AUTH_KEY) tanimsiz olan kurulumlarda sirlarinizi (panel baglantisi,
  depolama hedefi parolalari, sifreleme parolasi) cozün anahtar uploads/.yedekalma/
  altinda saklanir ve govdesi wp-config.php sabitlerinden turetilen bir maskeyle
  kariştirilir. O maskenin malzemesine veritabani bilgileri de dahildi: DB parolasi
  rotasyonu, localhost ↔ 127.0.0.1 degisimi ya da siteyi tasima/geri yukleme
  anahtari okunamaz yapiyor, eklenti de dosyanin uzerine YENI bir anahtar yazip eskisini
  GERI DONUSSUZ yok ediyordu. Iki degisiklik: (1) maske artik yalniz guvenlik tuzlarindan
  turer, veritabani bilgilerinden DEGIL; (2) anahtar okunamazsa dosya artik ezilmiyor —
  kopyasi fbk-onceki.php olarak saklaniyor ve yonetim panelinde bir uyari cikiyor, yani
  eski wp-config.php degerlerini geri koyarsaniz anahtar kurtarilabiliyor. Mevcut
  kurulumlar kendiliginden yeni bicime tasinir; elle bir sey yapmaniz gerekmez.
• Bazi yedeklerde butunluk ve veritabani dogrulamasi hic olculemiyordu (WP-951). Panel,
  her yedek icin arsivin uctan uca SHA/MD5 esligini ve dokumun tam olup olmadigini olcer.
  Yuklemeyi tamamlayan dort koddan biri bu iki olcumu (md5, db_summary) hic
  gondermiyordu — o yoldan gecen her yedekte iki dogrulama katmani kalici olarak
  “olculemedi” kaliyordu. Dort yol da artik AYNI govdeyi uretiyor.
• Pro zamanli e-posta yedeginde uc hata (WP-955). (1) Ayni sunucuda ikinci bir posta
  hesabi yedeklenirken birinci hesabin oturumu devralinabiliyor ve yanlis hesabin
  postasi arsive girebiliyordu. (2) Bazi Turk cPanel/Plesk sunucularinda baglanti hic
  kurulamiyordu (bilinen SASL duzeltmesi bu yola uygulanmamisti). (3) INBOX/Sent gibi
  alt klasorler INBOX_Sent olarak kaydediliyor, geri yuklemede klasor agaci
  duzlesiyordu — postaniz dogru kutuya donmuyordu. Ucu de duzeltildi.
• Eklenti silinince sifreleme anahtari diskte kaliyordu (WP-957). uploads/.yedekalma/
  klasoru kaldirma listesinde yoktu. Artik siliniyor (yedek dosyalarinizin silinmesi ise
  eskisi gibi yalniz siz isaretlerseniz olur — o ayar DEGISMEDI).

1.60.1 — 2026-08-26

• Duzeltme (AGT-960): sifreli arsiv yerine konurken once silinip sonra yeniden adlandiriliyordu.
  rename() POSIX’te hedefi zaten ATOMIK degistirir; onceden silmek gereksizdi ve rename
  duserse (izin / farkli dosya sistemi / kota) HER IKI kopya da yok oluyordu — saatler suren
  paketleme + sifreleme tek bir basarisiz islemle cope gidebiliyordu. Artik duz arsive
  dokunulmuyor ve hata halinde .enc kopyasi da diskte birakiliyor (elle kurtarilabilir).

1.60.0 — 2026-08-25

• Aynı sitede iki yedek birden başlayabiliyordu — son iki yol da kilide bağlandı. Panelden
  başlatılan bir yedek sürerken sitenin kendi zamanlayıcısı (WP-Cron) İKİNCİ bir tam arşiv
  üretmeye başlayabiliyordu: iki kat disk, iki kat CPU ve çoğu zaman ikisinin de bitememesi.
  Canlıda ölçülmüştü — 6,5 GB’lık bir arşiv aynı akşam iki kez üretildi. Koruma daha önce
  panel ve yönetim ekranı yollarına konmuştu; zamanlanmış (cron) iki yol onu ALMAMIŞTI.
  Artık altı yedek üreticisinin hepsi TEK bir ortak kilitten geçiyor, yani ileride eklenecek
  bir yol da korumayı kendiliğinden alır. Meşgulken cron sessizce çekilir ve sıradaki turda
  yeniden dener — yedek ATLANMAZ, yalnız çakışma önlenir.
• Şifreleme anahtarı, olağandışı kurulumlarda yedeğe geri girebiliyordu. Anahtar dosyası
  arşivden SABİT bir yol yazılarak eleniyordu; oysa yolu hesaplanıyor. Yükleme klasörü
  varsayılan yerinde değilse (çoklu site alt sitesi, taşınmış “uploads”, özel sabitler) o
  sabit yol tutmuyor ve anahtar arşive giriyordu — arşiv aynı zamanda şifreli ayarları da
  taşıdığı için tek bir arşiv sızıntısı hepsini çözebilirdi. Artık anahtar klasörü, yedek
  klasöründe zaten kullanılan gerçek-yol yöntemiyle eleniyor. Varsayılan kurulumlarda
  davranış DEĞİŞMEDİ; hariç-tut ekranındaki rozet de aynı kararı gösteriyor.
• Hariç tutma ekranı, eski yedek klasörünü tanımıyordu. 1.x’ten kalan yedekalma-backups
  klasörü arşive zaten girmiyordu, ama Pro etki tahmini, hariç-tut gezgini ve klasör boyutu
  ekranları onu normal bir klasör gibi GB’larca boyutla listeliyor ve ona “hariç tut” düğmesi
  gösteriyordu. Üç ekran da artık yedeği üreten kodla aynı klasör listesini kullanıyor:
  ekranda gördüğünüz sayı, arşive gerçekten girecek olanı anlatıyor.
• 30 günden eski yedekler yeniden “kayıp” görünebiliyordu. 1.59.9 indirme bağlantısının
  tazelenmesini getirmişti, ama bağlantı defteri 30 gün sonra yine de temizleniyordu — oysa
  arşivlerin ömrü sınırsız. Sonuç, 1.59.9’da kapatılan sorunun 30 gün sonra aynen dönmesiydi.
  Defter artık takvime değil, arşivin diskte olup olmadığına bakıyor: dosya duruyorsa
  kaydı korunuyor. Defter dolduğunda da yalnız süresi geçmiş kayıtlar budanıyor; kullanımdaki
  bir bağlantı artık silinmiyor.
• Karantinadaki zararlı dosya, yedek arşivine artık ham hâlde girmiyor. Temizlenen dosyalar
  “Geri Yükle” ile kurtarılabilsin diye karantinada saklanıyor ve yedeğe de giriyor (bu
  bilinçli — aksi hâlde yanlış pozitif bir dosya geri getirilemezdi). Ama içerik düz durduğu
  için bazı virüs programları TÜM yedek arşivini karantinaya alıp erişilemez kılabiliyordu.
  Karantinaya alınan dosya artık etkisizleştirilmiş biçimde saklanıyor; “Geri Yükle” onu
  birebir eski hâline döndürüyor. Eski karantina kayıtları da okunmaya devam ediyor.
• Çeviri kataloglarındaki boşluk artık ölçülüyor. Şablon (.pot) 1.59.8’de tamamlanmıştı
  ama dil dosyaları (.po) geride kalmıştı ve bunu ölçen bir kontrol YOKTU. Artık her dil
  için eksik/bayat girdi sayılıyor; dil dosyaları şablonla eşitlendi ve kullanılmayan 50
  bayat girdi temizlendi. Çeviri metinleri UYDURULMADI — boş kalan girdiler çevrilene kadar
  kaynak metinle gösterilmeye devam eder.

1.59.9 — 2026-08-25

• Panel, sunucunuzda DURAN yedekleri “kayıp” gösteriyordu. İndirme bağlantısı 72 saatte
  güvenlik gereği ölüyor (bu doğru ve kalıyor) — ama süresi dolan bağlantının kaydı da
  siliniyordu, dolayısıyla panel onu tazeleyemiyor ve arşivi silinmiş sanıyordu. Ölçüldü:
  dört sitede 72 saatten eski yedeklerin tamamı panelde “kayıp” görünüyordu, oysa
  dosyaların hepsi sunucularında duruyordu. En ağır sonucu, o yedekler için geri
  yüklemenin kapanmasıydı. Panelin aylardır çağırdığı tazeleme ucu eklentiye eklendi;
  bağlantı artık kimlik doğrulamalı olarak yenileniyor. Hiçbir yedek kaybolmamıştı.
  ⚠ Güvenlik gevşemedi: süresi dolmuş bağlantı hâlâ reddediliyor; yalnızca yetkili panel
  yeni bir bağlantı isteyebiliyor.

1.59.8 — 2026-08-24

• Kontrol Paneli ile Yedekler sayfası aynı yedeği farklı sayabiliyordu. İki ekran
  “tek kaynak”tan besleniyordu ama tekilleştirme KURALI ayrıydı: Yedekler sayfası önce
  içerik özetine (checksum), Kontrol Paneli yalnız dosya adına bakıyordu — oysa bulut
  kayıtlarında dosya adı gerçek değil, üretilmiş bir addır. Sıralama da ayrıydı:
  tamamlanmamış bir yedek Kontrol Paneli’nde listenin sonuna düşüyordu, oysa en yeni koşu
  odur. İkisi de tek ortak kurala bağlandı.
• “1 hariç yol” yazan rozet, klasörün içini hariç tutmuyordu. Eğik çizgi içermeyen
  joker kalıplar (logs[0-9], cache*) yalnız DOSYA adlarıyla eşleşiyor; aynı adlı
  klasörün İÇİNDEKİ dosyalar yedeğe girmeye devam ediyordu. Kural gerçekten çalıştığı
  için rozet onu sayıyordu — yani ekrandaki sayı doğru, kullanıcının anladığı şey
  yanlıştı. Artık böyle kalıplar sarı bir notla işaretleniyor ve çalışan doğru biçim
  (logs[0-9]/*) öneriliyor. Davranış DEĞİŞMEDİ: hiçbir dosya yedekten düşmedi.
• Çeviriler tamamlandı — özellikle KVKK rıza ekranı. Eklenti arayüzünün büyük bölümü
  çeviri şablonunda (.pot) hiç görünmüyordu; İngilizce, Almanca, Rusça ve Arapça
  kullanan müşteriler o ekranlarda Türkçe metin görüyordu. Bunlardan biri hesap açan
  açık rıza ekranıydı — yani kullanıcı anlamadığı bir dilde bir metne “onaylıyorum”
  işaretliyordu. Rıza ve onay dizgeleri dört dile çevrildi; şablon artık kaynaktan
  otomatik üretiliyor ve eksik kalırsa yayın öncesi kapı uyarıyor.
• Şifreleme anahtarı yedek arşivinin içine giriyordu. Tam yedek arşivi hem şifreli
  ayarları hem onları açan anahtar dosyasını taşıyordu; tek bir arşiv sızıntısı tüm
  sırları çözebilirdi. Anahtar klasörü artık yedeğe hiç girmiyor.
• Şifreleme anahtarı kaybolduğunda artık SESSİZ KALMIYOR. Site taşındığında ya da
  WordPress güvenlik anahtarları (AUTH_KEY) değiştiğinde eklenti panel bağlantı sırrını
  çözemiyordu ve o durumda sessizce yeni bir sır üretip üzerine yazıyordu. Panel eski
  sırrı tuttuğu için siteye gelen her istek reddediliyor, site tarafında ise hiçbir hata
  görünmüyordu — domain sessizce yedeklenmez hâle geliyordu. Artık sır ezilmiyor,
  yöneticiye açık bir uyarı ve tek tıkla sıfırlama düğmesi gösteriliyor.
• Anahtar dosyasının yolu doğrulanıyor. Taşınmış sitede wp_upload_dir() eski
  sunucunun mutlak yolunu döndürüyor ve o klasör yeni sunucuda yok; eklenti bunu fark
  etmeden oraya yazmaya çalışıyordu. Yol artık var-mı/yazılabilir-mi diye sınanıyor.
• Aynı sitede iki yedek aynı anda çalışamaz. wp-admin’deki “Şimdi Yedekle”, panelden
  ya da zamanlayıcıdan gelen bir yedek sürerken artık uyarı verip duruyor; kendi yedeği
  de ortak kilidi gerçekten tutuyor. Öncesinde iki yol birbirini göremiyor ve aynı arşiv
  iki kez üretilebiliyordu.
• Yedek doğrulamasının iki katmanı bu kanalda kördü — artık ölçüyor. Eklenti, arşivin
  md5 özetini ve veritabanı döküm özetini (kaç tablo / kaç satır / kaynakta kaç tablo
  vardı) panele hiç göndermiyordu. Panel bu yüzden “veritabanı doğrulaması” katmanını
  hiçbir zaman hesaplayamıyor ve — üstelik — “Modül tablo/satır sayısı bildirmedi (eski
  sürüm)” diyerek yanlış bir teşhis gösteriyordu. Bütünlük katmanı da uçtan uca
  karşılaştırma yapamadığı için kesik/bozuk bir yüklemeyi yakalayamıyordu.
• Ek depolama hedefine giden kopya artık birincille aynı bilgiyi taşıyor. Aynı arşivin
  ikinci kopyası, arşive giremeyen dosya bilgisini taşımadığı için farklı bir doğrulama
  rozeti alabiliyordu.
• Arşive giremeyen dosyalar artık raporlanıyor. Okunamayan ya da eklenemeyen dosyalar
  sessizce atlanıyor, yedek yine de “Başarılı” damgası alıyordu; eksiklik ancak geri
  yükleme günü anlaşılıyordu. Böyle yedekler artık “Uyarılı” olarak işaretleniyor,
  kaç dosyanın etkilendiği yazılıyor ve geri yükleme yine yapılabiliyor.

1.59.7 — 2026-08-24

• Yalnızca eklenti sayfası metinleri: WordPress.org’daki “Upgrade Notice” bölümü
  1.57.8’de kalmıştı; 1.58–1.59 hattının kullanıcıyı ilgilendiren değişiklikleri
  (devralınan sitede önceki sahibin arşivleri, Kontrol Paneli’nin “yedeğiniz yok”
  demesi, çeviri metinlerindeki ters bölü işaretleri) orada hiç görünmüyordu.
• Eklenti kodunda değişiklik YOKTUR — 1.59.6 ile aynı dosyalar.

1.59.6 — 2026-08-22

• Site el değiştirdiğinde önceki sahibin arşivleri artık işaretleniyor. Bir site başka
  bir Yedekalma hesabına bağlandığında, diskte duran eski arşivler “Önceki dönem” rozetiyle
  gösterilir. O arşivler önceki sahibin veritabanını içerir (müşteri kayıtları, e-posta
  adresleri); kime ait olduklarını bilmek hem yeni hem eski sahip için önemlidir.
  Arşivler gizlenmez — gizlemek, onları silme imkânını da ortadan kaldırırdı.
• Önceki döneme ait bir yedeği geri yüklemek artık ayrı onay istiyor. Böyle bir arşivi
  geri yüklemek sitenizin içeriğini önceki sahibin verisiyle değiştirir; kullanıcı hesapları
  ve müşteri kayıtları dahil. Artık tek tıkla yapılamıyor.

1.59.5 — 2026-08-22

• Kontrol Paneli hâlâ “yedeğiniz yok” diyordu — asıl sebep bulundu. 1.59.4’teki
  düzeltme yalnız hesapsız (yerel) kuruluma dokunuyordu. Yedekalma hesabına BAĞLI
  kurulumlarda Kontrol Paneli sadece panele soruyor, sitenin kendi diskindeki yedekleri
  hiç görmüyordu. Artık Yedekler sayfasıyla aynı kaynağı kullanıyor ve aynı listeyi
  gösteriyor. Aynı yedek iki kaynakta birden varsa tek kez gösterilir.
• Sol menüde Destek, Ayarlar’ın üstüne alındı. Yardım arayan kişi menünün dibine
  bakmak zorunda kalmasın.

1.59.4 — 2026-08-22

• Kontrol Paneli “hiç yedeğiniz yok” diyordu, oysa yedekler duruyordu. Yedekler sayfası
  üç başarılı yedeği listelerken Kontrol Paneli aynı anda “Henüz yedek alınmamış”
  gösteriyordu. Sebep: panel üzerinden alınan (ya da kaydı düşmüş) arşivler diskte durur
  ama WordPress kaydında bulunmaz; Yedekler sayfası bunları tarayıp buluyordu, Kontrol
  Paneli taramıyordu. Artık ikisi de aynı şeyi gösteriyor.
• Metinlerdeki ters bölü işaretleri temizlendi. Çeviri dosyalarında çift kaçış vardı;
  ekranda \"Tam Yedek\" gibi görünüyor, bazı yerlerde de bağlantıları bozuyordu.
  Beş dilin tamamında düzeltildi.

1.59.3 — 2026-08-22

• Sayfa başlığındaki uzun açıklama kaldırıldı. Dört satırlık paragraf, mavi bilgi
  kutusu ve ayrı bir yönlendirme satırı vardı; üçü birden ekranın üstünü dolduruyor ve
  aynı bilgiyi bağlanma kartındaki açıklamayla ikinci kez tekrar ediyordu. İki kez
  söylenen şey bir kez bile okunmuyor.
• Yerine tek satır: hizmetin ne yaptığı + iki yön tarifi — yerel yedekleme Kontrol
  Paneli’nde, geri yükleme ve .zip/.sql içe aktarma Yedekler sayfasında. Bu ikisi
  anlatım değil, yanlış sayfada arama hatasını önleyen kısayol.

1.59.2 — 2026-08-22

• Bağlanma ekranı sadeleşti. Dört özellik alt alta madde olarak yer kaplıyordu; artık
  yan yana kısa etiketler hâlinde. Yerine, asıl merak edilen soruya tek cümleyle cevap
  veren bir açıklama kondu: yedeğin nerede hazırlandığı, nereye gittiği ve bağlanmanın
  ne işe yaradığı.
• “Google ile bağlan” düğmesi boydan boya. Küçük bir düğmeyi aramak yerine, yapılacak
  işlem doğrudan görünüyor.
• Bağlı değilken “Ayarları Kaydet” çubuğu artık çıkmıyor. O ekranda kaydedilecek bir
  ayar yok; çubuk yine de görünüyor ve yapılacak bir iş varmış izlenimi veriyordu.
  Anlamsız bir eylem çağrısı, gerçek olanların da güvenilirliğini düşürür.

1.59.1 — 2026-08-22

• Bağlanma ekranı toparlandı. “Google ile bağlan” düğmesi ve seçimler artık sayfanın
  en üstünde, tek bakışta görünüyor. “Yedekalma nedir, verim nereye gidiyor” anlatımı
  aşağıya alındı — okumak isteyen için orada duruyor, ama karar vermek için sayfayı
  aşağı kaydırmanız gerekmiyor.
• Otomatik temizlemenin isteğe bağlı olduğu netleştirildi. Kutunun altında artık şu
  yazıyor: şimdi kaldırabilirsiniz, ya da bağlandıktan sonra yedekalma.com panelinizden
  dilediğiniz zaman açıp kapatabilir, sayıları değiştirebilirsiniz. Sağdaki kutuda da
  sayıların sabit olmadığı ve her domain için ayrı ayrı ayarlanabildiği belirtiliyor.

1.59.0 — 2026-08-22

• Bağlanma ekranı iki sütuna ayrıldı. Solda onaylar ve “Google ile bağlan”, sağda
  onayladığınız saklama politikasının içeriği: dosya, veritabanı, e-posta ve tam yedekten
  kaçar tane saklanacağı. Neyi kabul ettiğinizi sayısıyla, aynı ekranda görüyorsunuz.
• Otomatik eski yedek temizleme artık bir seçim. Kutu işaretli gelir ama
  kaldırabilirsiniz; tercihiniz hesabınıza kaydedilir ve bağlandıktan sonra panelden
  dilediğiniz zaman değiştirebilirsiniz. Diğer iki onaydan farkı budur: bu isteğe bağlıdır.
• Saklama sayıları eklentiye gömülü değil, panelden gelir. Politika güncellenirse ekranda
  gösterilen sayı da kendiliğinden güncellenir — yani gördüğünüz sayı ile hesabınıza
  uygulanan sayı her zaman aynıdır.

1.58.2 — 2026-08-22

• “Pro özelliklerini açmak için bağlanın” başlığı yeniden en üstte. 1.58.1’de tanıtım
  bölümü onay kutularının üstüne alınırken başlığın da üstüne geçmişti; ekranın ne için
  olduğunu söyleyen çağrı, uzun anlatımın altında kalıyordu. Sıra artık şöyle:
  başlık → kısa özet → “Yedekalma nedir / verim nereye gidiyor” → onay → bağlan.
  Böylece hem çağrı ilk görünen şey oluyor, hem de aydınlatma rızadan önce geliyor.

1.58.1 — 2026-08-22

• Bağlanmadan önce ne olduğunu okuyorsunuz. “Yedekalma nedir, yedeğim nerede
  hazırlanıyor, verim nereye gidiyor” anlatımı artık onay kutularının ve “Google ile
  bağlan” düğmesinin üstünde. Önceden düğmenin altındaydı; yani kullanıcı önce karar
  verip sonra okuyordu. Onay ancak bilgilendirmeden sonra anlamlıdır — KVKK’da da
  aydınlatma, açık rızadan önce gelir.
• Sözleşme bilgisi alınamadığında artık “Tekrar dene” bağlantısı var. Önceden tek çare
  koca yönetim sayfasını yeniden yüklemekti; geçici bir ağ hatası gereksiz bir çıkmaza
  sokuyordu.

1.58.0 — 2026-08-22

• Yedekalma hesabı açılırken artık açık rıza alınıyor (KVKK). “Google ile bağlan”
  düğmesi yalnız bağlantı kurmuyor — yedekalma.com’da sizin adınıza bir müşteri hesabı
  açıyor. Panelden kayıt olurken Kullanım Koşulları ve KVKK aydınlatma metni onayı
  zorunluyken, bu yol onları hiç sormuyordu. Artık iki onay kutusu işaretlenmeden düğme
  açılmıyor; onayınız tarih, sürüm ve IP ile birlikte kaydediliyor.
• Sözleşme bağlantıları yeni sekmede yedekalma.com üzerinden açılır. Metinler ve sürüm
  bilgisi eklentiye gömülü DEĞİL, panelden çekilir — böylece belgeler güncellendiğinde
  eklentiyi yeniden yayınlamak gerekmez ve onay kaydınız her zaman gerçekten okuduğunuz
  metnin sürümünü gösterir.
• Sözleşme bilgisi alınamazsa bağlantı başlatılmaz ve sebebi ekranda yazılır. Bilinçli
  bir karar: hangi metne onay verildiği bilinmeden hesap açmak, kaydı baştan değersiz kılar.

1.57.13 — 2026-08-21

• Büyük satırlı veritabanlarında yedek artık bellek yetmediği için durmuyor. Veritabanı
  dökümü partileri şimdiye kadar SATIR SAYISIYLA ölçülüyordu (sabit 500). Satır sayısı
  belleği ölçmez: şişmiş bir ayar kaydı ya da serileştirilmiş büyük bir meta değeri tek
  başına megabaytlarca olabilir. Böyle bir sitede 500 satır PHP bellek sınırını aşıyor ve
  yedek her denemede aynı noktada, birkaç saniye içinde ölüyordu. Parti boyutu artık
  tablonun ortalama satır büyüklüğüne göre BAYT bütçesiyle belirleniyor; ölçüm alınamazsa
  eski davranış aynen korunur (parti yalnızca küçültülür, asla büyütülmez).
• Her partiden sonra WordPress’in tuttuğu ikinci kopya serbest bırakılıyor. WordPress
  sorgu sonucunu ayrıca kendi içinde saklar ve bir sonraki sorguya kadar bırakmaz; bu,
  döküm sırasında tepe bellek kullanımını gereksiz yere iki katına çıkarıyordu. Düzeltme
  yedekleme, döküm ve geri yükleme (ara/değiştir) yollarının ÜÇÜNE de uygulandı.

1.57.12 — 2026-08-20

• Yedek biletleri artık adres satırında taşınmıyor. Yükleme/indirme isteklerinde
  kullanılan tek kullanımlık bilet, sunucu erişim kayıtlarına ve aradaki vekillere
  düşmesin diye yalnızca istek başlığında gönderiliyor. Eski sürüm alıcı modüllerle
  uyum korunuyor: karşı taraf yeni biçimi tanımıyorsa önceki yöntem kullanılmaya devam eder.

1.57.11 — 2026-08-20

• Yarım kalan yükleme artık kilitlenmiyor. Büyük bir yedek parça parça gönderilirken
  son parçanın yanıtı kaybolursa, eklenti “her şey karşıda” cevabını alıp gönderimi
  tamamlanmış saymıyor; tamamlama sinyalini yeniden gönderiyor. Önceden bu durumda arşiv
  hedefe hiç taşınmıyor, her yeni deneme aynı noktada başarısız oluyor ve yedek
  tamamlanamıyordu.
• Yedek biletleri artık istek başlığında da gönderiliyor. Sunucu erişim kayıtlarına ve
  aradaki vekillere adres satırıyla birlikte düşmemesi için; eski sürüm alıcılarla uyum
  korunuyor.

1.57.10 — 2026-08-20

• Yedek klasörü artık kendi kendini yedeklemiyor. Klasör adı yeniden adlandırılamayıp
  eskisi yerinde kaldığında, eski klasör yedeğin içine giriyordu — arşiv kendi eski
  arşivlerini taşıyor ve gereksiz yere büyüyordu. Hariç tutma artık tüm yedek klasörlerini
  tanıyor (yalnızca güncel adı değil).
• Sağlaması olmayan katman artık geri yüklemede açık onay ister. Bütünlük doğrulaması
  yapılamayan bir yedek katmanı sessizce uygulanmıyor; ne olduğu ekranda yazıyor ve
  kullanıcı bilerek onaylamadan işlem başlamıyor.

1.57.9 — 2026-08-20

• Parçalı yedekte kesik arşiv koruması. Arşiv, büyük sitelerde birden çok istekte
  parça parça yazılır. Bir parça yarıda kesilirse (hosting zaman aşımı, bellek sınırı)
  aynı dosya ikinci kez yazılabiliyor ve arşiv tutarsız hâle gelebiliyordu. Yazıcı artık
  arşivin yan kaydını okuyup hangi dosyaların gerçekten TAM yazıldığını doğruluyor;
  yarım kalmış bir girdi “tamam” sayılmıyor.
• Virüs tarama ekranında dosya adı kaçışı. Taranan bir dosyanın adı ekrana
  kaçırılmadan basılıyordu; siteye kötücül adlı bir dosya bırakabilen biri, tarama
  ekranını açan yöneticinin tarayıcısında kod çalıştırabilirdi.
• Yedek klasörü adı. Klasör adı yeniden oluşturulurken tahmin edilebilir bir ada
  düşebiliyordu; artık her durumda rastgele ad üretiliyor ve mevcut yedek kayıtları
  öksüz kalmıyor.
• Manuel yedekte geçici dosya konumu. wp-admin üzerinden alınan yedeklerde
  veritabanı dökümü ve arşiv, bazı sunucularda web’den erişilebilen bir klasöre
  yazılabiliyordu; artık sertleştirilmiş geçici klasör kullanılıyor.
• Hariç tutma listesi. Virgülle ayrılmış satırlar ve nicelik aralığı içeren düzenli
  ifadeler (\d{1,3} gibi) artık modülle birebir aynı biçimde yorumlanıyor — panelde
  görünen kural sayısı ile yedeğe gerçekten uygulanan kural aynı.

1.57.8 — 2026-08-19

• Güvenlik/kararlılık: bozuk ya da kötücül bir şifreli yedek artık belleği tüketip
  geri yüklemeyi öldüremiyor. Şifreli arşivler çerçeve çerçeve okunur ve her çerçevenin
  başında 4 baytlık bir uzunluk alanı vardır. Doğrulama geçişinde (HMAC) bu uzunluk için
  bir üst sınır YOKTU — dosya bozulmuş ya da kasten değiştirilmişse tek bir çerçeve 4 GB’a
  kadar okuma istetebiliyor ve PHP “Allowed memory size exhausted” ile ölüyordu; WordPress
  tarafında bu, geri yüklemenin 500 ile düşmesi demek. Çözme geçişinde sınır zaten vardı
  ama doğrulama geçişi ONDAN ÖNCE koştuğu için sıra ona hiç gelmiyordu. Sınır artık her
  iki geçişte de var (meşru azami çerçeve 1 MB; sınır 5 MB).
• Not: bu, aynı hatanın üçüncü kopyasıydı. Panel modülü ve sunucu tarafındaki kopyalar aynı
  gün düzeltilmişti; eklentideki kopyayı otomatik “ikiz parite” kapımız yakaladı.

1.57.7 — 2026-08-19

• Yeni: geri yüklemede “sunucu yapılandırma dosyalarını da geri yükle” seçeneği. 1.57.6’dan
  beri wp-config.php, .htaccess ve .user.ini geri yüklemede korunuyordu — doğru varsayılan,
  çünkü yedek alındığından bu yana veritabanı bilgileriniz ya da hosting sunucunuz değiştiyse eski
  ayarların geri gelmesi siteyi ONARMAK yerine DÜŞÜRÜR. Ama bu üç dosyayı bilerek geri istemenin
  hiçbir yolu yoktu (sunucu taşımasından sonra eski .htaccess kurallarını geri almak gibi).
  Artık geri yükleme penceresinde açık bir onay kutusu var: işaretlemediğiniz sürece davranış
  aynı (dosyalar korunur), kutu her açılışta kapalı başlar ve “Sadece Veritabanı” modunda hiç
  görünmez.
• Yeni uyarı: geri yüklenen wp-config.php farklı bir AUTH_KEY taşıyorsa artık söylüyoruz.
  Panel bağlantınız ve yedek şifreleme (BYOK) parolanız bu sitede AUTH_KEY’den türetilen bir
  anahtarla şifreli saklanır. Eski bir sunucudan gelen wp-config.php geri yüklenirse ikisi de
  okunamaz hâle gelir — önceden bunu hiçbir yerde göremiyor, ancak bir sonraki yedek
  başarısız olunca fark ediyordunuz. Artık dosya yazılmadan ÖNCE ölçülüyor ve sonuç ekranında
  ne yapmanız gerektiği yazıyor (paneli yeniden bağlayın, şifreleme parolanızı yeniden girin).
• Geri yükleme sonucu artık ne olduğunu SÖYLÜYOR. “Başarıyla tamamlandı” mesajının altında
  yapılandırma dosyalarının korunup korunmadığı ve — yedek bir sağlama (SHA-256) kaydı
  taşımıyorsa — arşivin yalnızca YAPISAL olarak doğrulandığı yazıyor. Bu bilgiler 1.57.6’dan beri
  üretiliyordu ama ekrana hiç gelmiyordu; üretilip gösterilmeyen uyarı, verilmemiş uyarıdır.
• Düzeltildi: “Alıcı Modül” hedefine yedek yüklenemiyordu. Kendi sunucunuza kurduğunuz
  Alıcı Modül’ü depolama hedefi olarak seçtiyseniz, WordPress eklentisi bu yükleme yöntemini
  HİÇ uygulamıyordu: yedek hazırlanıyor, sonra yükleme adımında düşüyordu. (Panel modülü bu
  yöntemi destekliyordu, eklenti desteklemiyordu.) Artık destekleniyor — büyük arşivlerde
  parçalı ve kopan bağlantıda kaldığı yerden devam edebilen biçimde.

1.57.6 — 2026-08-19

• Düzeltildi: wp-admin’den BULUT yedeğini geri yükleme her zaman “403” veriyordu. Yerel
  (bu sunucudaki) yedeklerden geri yükleme çalışıyordu, ama bulut hedefinizdeki (Google
  Drive/S3/FTP) yedeği wp-admin’den geri yüklemeye çalıştığınızda işlem daima yetki hatasıyla
  düşüyordu. Gerekli kimlik başlığı iki çağrı yerinden yalnız birine eklenmişti. Felaket anında
  ilk basacağınız düğme buydu; artık iki yol da TEK bir kapıdan geçiyor.
• Düzeltildi: sembolik bağlı site kökünde geri yükleme “başarılı” diyor ama HİÇBİR dosyayı
  yazmıyordu. Birçok paylaşımlı hostingde public_html gerçek bir klasör değil, başka bir
  yola işaret eden bir bağdır. Eklenti site kökünü çözümlemeden karşılaştırdığı için o
  sunucularda arşivdeki her dosya sessizce “atlandı” sayılıyor, işlem yine de “Geri yükleme
  başarıyla tamamlandı” diyordu — site ONARILMAMIŞ oluyordu ve bu ancak felaket gününde
  anlaşılıyordu. Kök artık çözümleniyor; ayrıca arşivde dosya varken hiçbiri yazılamadıysa
  bu artık bir HATADIR, başarı değil. Aynı kök neden Pro klasör gezginini de o hostlarda
  kullanılamaz hâle getiriyordu; o da düzeldi.
• Geri yükleme öncesi arşiv doğrulaması sertleşti. Bir yedek katmanı sağlama (SHA-256)
  taşımıyorsa eskiden HİÇBİR bütünlük kontrolü yapılmıyordu; indirmenin başarısı yalnızca
  “dosya 22 bayttan büyük mü” ile ölçülüyordu (22 bayt = boş bir zip). Artık indirilen boyut
  sunucunun bildirdiği boyutla karşılaştırılıyor (HTTP/FTP/SFTP), arşiv sitenizin üzerine
  yazılmadan ÖNCE içerik tutarlılığı denetleniyor ve yarım/kesik aktarım “başarılı” sayılmıyor.
• Düzeltildi: hariç tutma kalıpları hostinga göre FARKLI davranıyordu. logs[0-9] gibi
  karakter aralıkları ve büyük/küçük harf duyarlılığı, PHP’nin fnmatch fonksiyonu bulunmayan
  sunucularda başka türlü yorumlanıyordu — yani aynı eklenti, aynı kalıp, iki hostta İKİ FARKLI
  arşiv içeriği üretebiliyordu ve size hiçbir uyarı gitmiyordu. İki yol artık birebir aynı
  kararı veriyor.
• Düzeltildi: geri yüklemede tam veritabanı dökümü sunucuda kalabiliyordu. İşlem bir hata
  ya da zaman aşımıyla yarıda kesilirse, geçici olarak açılan .sql.gz dökümü yükleme
  klasöründe kalıyordu. Artık istek nasıl biterse bitsin siliniyor.
• Ek depolama hedefleri artık sessiz kalmıyor. Birden çok hedef tanımladıysanız, ek
  hedeflerden birine yükleme başarısız olduğunda hiçbir iz kalmıyordu: panelde de,
  kütükte de. Ödediğiniz ikinci/üçüncü kopyanın yazılmadığını öğrenemiyordunuz. Sonuç artık
  panele raporlanıyor ve başarısızlıkta bildirim gidiyor. Ayrıca “Sadece değişenler” rejimi
  açıkken WordPress kopyaları da zincir klasörüne düşüyor (önceden yalnız modül kopyaları
  düşüyordu).
• Güvenlik: site anahtarını (pull_secret) döndüren uç, kardeşlerinde bulunan ikinci yetki
  kontrolünü taşımıyordu. Bugün açık bir kapı değildi; yine de eklendi.

1.57.5 — 2026-08-18

• Düzeltildi: bazı paylaşımlı hostinglerde yedek ilk saniyesinde ölüyordu. PHP’nin
  set_time_limit, ignore_user_abort, php_uname ve fsockopen fonksiyonları
  hostingler tarafından disable_functions ile kapatılabilir. Kapalı olduklarında
  @ işareti KORUMAZ — PHP ölümcül hata verir ve yedekleme, geri yükleme ya da parçalı
  yedek o anda durur. Aynı sınıf hata bu eklentide daha önce disk_free_space için
  düzeltilmişti; bu sürüm kalan 13 çağrıyı da tek bir güvenli kapıya aldı.
• Düzeltildi: geri yükleme wp-config.php ve .htaccess dosyalarını eziyordu.
  Yedek alındıktan sonra veritabanı bilgileriniz, sunucunuz ya da .htaccess
  kurallarınız değiştiyse, geri yükleme sitenizi ESKİ yapılandırmaya döndürüyor ve
  “Error establishing a database connection” hatasına yol açabiliyordu. Bu dosyalar
  artık geri yüklemede KORUNUR — kurtarma işlemi sitenizi düşürmez.
• Güvenlik: yükleme sınırı ayarı yetki kontrolü olmadan çalışıyordu. Eklenti,
  yükleme sınırlarını yükseltmek için site kökünde .user.ini oluşturuyor; bu işlem
  herhangi bir oturum açmış kullanıcı (ör. Abone) tarafından tetiklenebiliyordu. Artık
  yalnızca yöneticiler tetikleyebilir.
• Düzeltildi: yedek klasörünün yanındaki benzer adlı klasör sessizce yedeğe girmiyordu.
  Klasör karşılaştırması ayraç sınırı kullanmadığı için yedekalma-backups tabanının
  yanında duran yedekalma-backups-eski gibi bir klasörün TAMAMI “yedek klasörü”
  sayılıyor ve yedeğin dışında kalıyordu — hiçbir uyarı çıkmadan.
• Düzeltildi: geri yüklemede bilinmeyen bileşen seçimi “her şeyi geri yükle”ye
  düşüyordu. Artık geçersiz bir seçim sessizce en yıkıcı seçeneğe çevrilmek yerine
  reddediliyor (REST ucunda zaten böyleydi).
• Güvenlik/sağlamlık: arka plan yedek işinin gizli anahtarı artık yalnızca POST
  gövdesinden okunuyor (adres satırından geçtiğinde sunucu erişim kütüğüne düşüyordu);
  yedek dosya adı çözümünde dizin dışına çıkma koruması; arşiv içi dosya adı eşlemeleri
  artık büyük/küçük harfe duyarsız (modüldeki davranışla eşitlendi).

1.57.4 — 2026-08-18

• Düzeltildi: taşınmış sitelerde wp-admin “Yedekler” listesi BOŞ görünüyordu. 1.57.3
  yedek klasörünün yolunu tek bir doğrulanmış kaynağa bağlamıştı, ama yalnızca panel/REST
  tarafında. WordPress yönetim ekranları (yedek listesi, silme, indirme, içe aktarma,
  klasör gezgini, geçici dosya temizleyici, karantina ve destek tanılaması) hâlâ eski
  yöntemle hesaplıyordu. Sitesi başka bir sunucuya taşınmış kurulumlarda WordPress’in
  bildirdiği yükleme klasörü yolu ESKİ sunucuya ait olabildiği için bu ekranlar var
  olmayan bir klasöre bakıyordu: yedekler diskte dururken listede görünmüyor, temizlik
  yanlış klasörü hedefliyor, zamanlanmış yedek sessizce kayboluyordu.
• Sebebi söylemeyen hata kalktı: yükleme klasörü gerçekten kullanılamıyorsa artık
  “izinleri kontrol edin” yerine ne yapılması gerektiği yazıyor (Ayarlar > Medya’daki
  yükleme klasörü yolunu boşaltmak çoğu taşınma sorununu çözer).
• Destek tanılamasındaki “Yedek klasörü” satırı eski sabit klasör adına bakıyordu ve bu
  yüzden her sitede “henüz oluşmamış” diyordu; artık gerçek klasörü raporluyor. WordPress’in
  bildirdiği yol ile gerçekte kullanılan yol farklıysa bu da ayrıca gösteriliyor.
• Eklentiyi silerken “yedekleri de sil” seçeneği taşınmış sitelerde arşivleri diskte
  bırakıyordu; artık olası tüm yükleme klasörü …