== Changelog ==

Full release history for Yedekalma. The readme.txt file only lists the most
recent releases; everything else is kept here.

= 1.65.1 — 2026-09-13 =

**GUVENLIK + GIZLILIK surumu. Her kuruluma onerilir.**

**Bu surum, WordPress.org'a HIC CIKMAMIS 1.65.0'in tum icerigini de tasir** — `changelog.txt`deki
1.65.0 girdisi (panel komutlarinin zaman sinirli, tek kullanimlik imzayla dogrulanmasi)
bu surumle birlikte yayinlanir. O girdideki YAYIN SIRASI uyarisi aynen gecerlidir:
Yedekalma panelini kendiniz barindiriyorsaniz ONCE paneli, SONRA bu surumu guncelleyin.

**Panele artik yonetici e-posta adresi gonderilmiyor.**

* Baglanti kurulurken ve periyodik nabizda gonderilen site bilgisi, sitenin WordPress
  yonetici e-posta adresini de tasiyordu. Panelde bu alani okuyan hicbir kod yoktu ve
  readme'nin "External services" bolumu onu anmiyordu. Alan kaldirildi; gonderilen
  bilgilerin tam listesi o bolume yazildi.

**ext-openssl olmayan sunucuda sirlar artik "sifreli" gibi SAKLANMIYOR.**

* Baglanti anahtari, yedek sifreleme parolasi ve FTP/SFTP, S3, e-posta ve veritabani
  parolalari, PHP'nin OpenSSL eklentisi yoksa DUZ base64 olarak yaziliyordu — yani
  sifresiz — ve kod bunun tersini iddia ediyordu. Artik bu durumda sir YAZILMAZ: kaydetme
  acik bir hatayla durur ve yonetim panelinde kalici bir uyari gorunur.
* Daha once bu bicimde yazilmis degerler okunmaya DEVAM EDER; guncellemeden sonra
  baglantiniz kopmaz. OpenSSL mevcutsa yonetim panelinin ilk acilisinda bir kez SIFRELI
  bicime tasinirlar — artik bir sonraki kayda kadar sifresiz beklemiyorlar.
* OpenSSL sonradan gelir ya da giderse okuma ile yazma ayrisiyordu: sifreli bir deger
  OpenSSL'siz okununca anlamsiz baytlar sir diye donuyor, OpenSSL'siz yazilmis bir deger
  ise OpenSSL gelince okunamiyordu. Iki bicim artik ayirt ediliyor ve cozulemeyen bir
  deger hicbir zaman anlamsiz baytlar olarak geri donmuyor.

**Diger**

* Eklenti kaldirildiginda, geri yukleme imzalarinin tekrar-oynatma defteri (`ya_rn_*`
  kayitlari) artik veritabaninda kalmiyor.
* Eklenti kaldirilirken gonderilen "baglanti kesildi" bildirimi, wp-config.php'de AUTH_KEY
  tanimli olmayan kurulumlarda ve eski sifresiz bicimde saklanan anahtarla HIC gitmiyordu:
  kaldirma betigi kendi, eskimis anahtar hesabini kullaniyordu. Artik eklentinin kendi
  cozucusunu kullaniyor ve kaldirma sirasinda yeni bir anahtar dosyasi OLUSTURMUYOR.
* Readme: bulut hizmetine bagli AES-256 (BYOK) sifreleme de "(istege bagli)" olarak
  isaretlendi.
* Readme artik gercegi soyluyor: artimli yedekleme yalnizca istege bagli bulut
  hizmetinde calisir; tek tikla alinan yerel yedek her zaman TAM yedektir. Hicbir kodun
  okumadigi bir ayar alani (`incremental`) kaldirildi.

= 1.65.0 (2026-09-09 · yayinlanmadi, icerigi 1.65.1 ile cikiyor) =

**GUVENLIK surumu. Her kuruluma onerilir.**

**Panelin sitenize verdigi komutlar artik SURESIZ bir sirla degil, zaman sinirli ve tek kullanimlik bir imzayla dogrulaniyor.**

* Eklentinin panele acik dokuz ucu (`ping`, `nettest`, `config-summary`, `size`,
  `preflight`, `dl-remove`, `dl-renew`, `direct-backup`, `verify`) bugune kadar
  yalnizca PAYLASILAN SIR (`X-Yedekalma-Secret`) ile korunuyordu. O sir SURESIZDIR ve
  DEGISMEZ: bir kez sizmasi (bir erisim logu, eski bir yedek kopyasi, ayrilmis bir
  yonetici) KALICI erisim demektir.
* En pahalisi `direct-backup` idi: bu uc sitenizin TAM ARSIVINI uretir ve istegin
  govdesinde verilen adrese YUKLER. Yani sirri ele geciren biri, sitenizin tamamini
  kendi sectigi bir sunucuya kopyalatabilirdi.
* 1.62.0'da geri yukleme ucu (`direct-restore`) icin yazilan koruma — ±10 dakikalik
  zaman penceresi, tek kullanimlik imza, tekrar oynatma defteri — simdi bu dokuz ucun
  HEPSINDE gecerli. Imza UCA OZGUDUR: yakalanan bir `ping` imzasi `direct-backup`ta
  kullanilamaz.
* Ayrica `dl-renew` (indirme jetonunun omrunu uzatan uc) govdesinde yetkiyi hic
  olcmuyordu; kardeslerinin tamami olcuyordu. Artik o da olcuyor.

🔴 **PANELINIZ GUNCEL OLMALIDIR.** Bu surum imzayi ZORUNLU kilar. Yedekalma panelini
kendiniz barindirmiyorsaniz yapmaniz gereken bir sey yok (panel zaten guncel).
Kendi kurulumunuz varsa ONCE paneli guncelleyin, SONRA bu surume gecin; ters sirada
yedekleme ve geri yukleme `403 stale_or_missing_auth` ile durur.

= 1.64.0 — 2026-09-03 =

**SESSIZ EKSIK YEDEK + GUVENLIK surumu. Her kuruluma onerilir.**

**Okunamayan bir klasor artik yedekten SESSIZCE dusmuyor.**

* Yedek agacini gezen yineleyici `CATCH_GET_CHILD` kullaniyor; bu bayrak
  acilamayan bir klasorun istisnasini YUTAR ve o alt agacin TAMAMI listeden
  duser. Eklentide bu olayi sayan hicbir kod yoktu: `dir_unreadable` daima 0
  kaliyor, yedek `completed` damgalaniyordu. Kisitli izinli ya da karisik
  sahiplikli paylasimli hostingde bir klasor okunamazsa altindaki her sey arsive
  girmiyor ve HICBIR YERDE iz kalmiyordu -- eksiklik ancak geri yukleme gunu
  goruluyordu. Artik atlanan her klasor sayiliyor ve panele bildiriliyor.

**Veritabani olmadan "tam yedek" uretilmiyor.**

* Parcali (chunked) yedekte veritabani dokumu gecici dosyasi kaybolursa (hosting
  /tmp temizligi ya da 6 saatlik supurucu) arsiv veritabani OLMADAN
  sonlandiriliyor ve `completed` damgalaniyordu. Kayit saklama sayacina giriyor,
  boylece gercekten tam olan ESKI bir yedegi budayabiliyordu. Artik bu durum
  hata veriyor ve yedek TAMAMLANMIYOR.

**E-posta geri yuklemesi artik dogru soyluyor.**

* Hicbir ileti yazilamadiginda bile "basarili" donuluyordu: ZipArchive yoksa,
  arsiv acilamazsa ya da IMAP her denemede reddederse hicbir sayac artmiyor ve
  hicbir hata bildirilmiyordu. Musteri "posta kutumu geri yukle" deyip yesil
  onay goruyor, posta kutusu bos kaliyordu. Artik 0 ileti yazildiysa islem
  basarisiz raporlaniyor ve IMAP hata metni de iletiliyor.

**Zararli yazilim tarayicisi artik atlatilamiyor.**

* Tarayicinin eleme kurali ALT DIZE ile calisiyordu (`.git` yolun herhangi bir
  yerinde). Yedek tarafi ise onek-capali kanonik kurali kullaniyor. Sonuc:
  `uploads/2026/01/x.git.php` gibi adlandirilan bir arka kapi TARANMIYOR ama
  YEDEKLENIYORDU; tarayici ekrani "temiz" diyordu. Karar artik yedek tarafiyla
  TEK KAYNAKTA.

**Diger duzeltmeler**

* Parcali dosya dongusunde okunamayan dosya sessizce atlaniyordu; artik sayilip
  raporlaniyor (dogrudan yol bunu zaten yapiyordu).
* Acilamayan IMAP klasoru atlaniyor ama raporlanmiyordu; envanter o kutuyu
  "yedeklendi" diye yaziyordu. Artik `mail_errors` ile bildiriliyor.
* Ek veritabani tavani rozet ile dokumcu arasinda ayrisikti (50 vs 20); artik
  tek sabitten okunuyor.
* Arsiv merkezi dizin imzasi kaynakta ham kontrol bayti tasiyordu; herhangi bir
  bicimlendirme onu dusurse tum arsivler sonlandirilamaz hale gelirdi.

**Parcali e-posta yedegi artik bir iletiyi atlayamaz.**

* Yedek, sunucunuzun istek suresine sigmak icin parcalara bolunur ve her parca
  kaldigi yerden devam eder. Devam noktasi IMAP **sira numarasi** olarak
  tutuluyordu. Sira numarasi kalici DEGILDIR: kutudan bir ileti silinip expunge
  edilirse ondan sonraki butun numaralar bir asagi kayar.
* Parcalar arasinda dakikalar gecer; bu arada kendi posta istemcinizin bir
  iletiyi silmesi yetiyordu. Parca N 1..100'u aldi ve imleci 101'e koydu;
  50. ileti silindi; eski 101 artik 100 oldu; parca N+1 101'den basladi ve
  **bir ileti tamamen atlandi**.
* Ekranda hata yoktu, kosu "tamamlandi" damgasi aldi ve o ileti yedege hic
  girmedi. Eksikligi ancak geri yukleme gunu fark ederdiniz.
* Imlec artik **UID**'dir ve UID kalicidir. Sunucu UID uzayini sifirlarsa
  (UIDVALIDITY degisimi) klasor bastan taranir ve olay rapora YAZILIR.
* PHP modulu (panele domain ekleyen surum) bunu zaten UID ile yapiyordu;
  eklenti ikizine tasinmamisti.

**`..` adli bir posta kutusu artik geri yuklenemez arsiv girdisi uretmiyor.**

* Klasor adi suzgeci `.` ve `/` karakterlerini gecerli sayiyordu; `..` adli bir
  kutu oldugu gibi geciyor ve arsive `eposta/<hesap>/../<n>.eml` yaziliyordu.
* Dosya sistemine yazim YOKTU, ama HER IKI geri yukleme yolu da `..` iceren
  girdileri REDDEDER. Yani o kutunun iletileri yedege giriyor, "yedeklendi"
  sayiliyor ve **asla geri yuklenemiyordu**.

**Geri yukleme, NUL bayti tasiyan bir arsiv girdisinde yarida durmuyor.**

* PHP 8'de NUL iceren bir yol `is_link()`/`fopen()`a ulasinca yakalanmamis bir
  hata firlatir ve geri yukleme O NOKTADA durur — site kismen yazilmis kalir.
  PHP modulu bu bayti zaten eliyordu, eklenti elemiyordu. Reddedilen girdi
  artik SAYILIR (sessiz eleme yok).

**Geri yukleme tekrar-oynatma korumasi artik atomik.**

* Panelden gelen `direct-restore` istegi tek kullanimlik bir imza tasir ve
  kullanilmis imzalar bir deftere yazilir. Defter tek bir secenek satiriydi ve
  "oku -> bak -> geri yaz" adimlarinin arasinda kilit YOKTU: yakalanmis ayni
  imzayla gonderilen iki es zamanli istek ikisi de gecebiliyordu. Bu ucun
  yaptigi is sitenizin arsivden UZERINE YAZILMASIDIR.
* Her imza artik KENDI satirinda tutuluyor; veritabaninin tekil-anahtar kisiti
  "bak" ile "yaz"i tek bir atomik isleme indiriyor. Suresi gecen kayitlar
  otomatik budaniyor.

= 1.63.0 — 2026-09-03 =

**GUVENLIK + GERI YUKLEME surumu. Her kuruluma onerilir.**

**Geri yukleme, sizin secmediginiz seye artik DOKUNMUYOR.**

* URL arama-degistirme adimi (geri yuklemeden sonra eski alan adini yenisiyle
  degistiren adim) bilesen ve veritabani secim kapilarinin HICBIRINI tasimiyordu.
  "Veritabanimi geri yukleme" secili olsa bile sitenin CANLI veritabanindaki tum
  onekli tablolarda metin ve blob sutunlari yeniden yaziliyordu; geri alma yoktu.
  Ayni sekilde eklentinin kendi ayarlarinin geri yazimi da kosulsuzdu. Ikisi de
  artik ayni kapidan geciyor.
* Panelden "yalnizca su posta kutularini geri yukle" secildiginde eklenti bu
  secimi HIC okumuyordu: isaretini kaldirdiginiz kutularin iletileri de canli
  IMAP hesabina yaziliyordu. Bu geri alinamaz bir kirlenmedir. Secim artik
  uygulaniyor (PHP modulu bunu aylardir yapiyordu).
* Arsivdeki EK veritabanlari (`veritabani/<ad>.sql.gz`) yedege giriyor ama geri
  yuklemede HIC uygulanmiyor ve islem yine "basarili" raporlaniyordu. Her ek
  veritabani artik kendi hedefine, kendi kimligiyle geri yukleniyor; secim her
  veritabani icin AYRI soruluyor ve uygulanamayan bir veritabani islemi
  BASARISIZ yapiyor (sessiz gecmiyor).

**Ek veritabani yedegi artik gercekten aliniyor.**

* 1.62.1'de eklenen ek veritabani dokumu, panelin hic kullanmadigi bir kod
  dalina yazilmisti: panel her WordPress yedegini PARCALI modda calistirir, dokum
  ise yalnizca parcasiz dalda vardi. Sonuc, urunun en pahali arizasidir —
  panelde "2 veritabani" yazar, arsivde yalniz WordPress'in kendi veritabani
  bulunur ve eksik ancak felaket gunu gorulur. Dokum parcali akisa tasindi;
  her tur en az bir veritabani doker, boylece buyuk veritabanlari hosting'in
  istek suresini asmaz. Yedegin icerik envanteri de artik gercekten arsive
  gireni bildiriyor (once parcali yolda daima bostu).

**Yedek dosyalariniz ve sifreleme anahtariniz geri yuklemede korunuyor.**

* Korunan dosya listesi yalnizca site KOKUNDEKI `wp-config.php`, `.htaccess` ve
  `.user.ini` ile eslesiyordu. Yedek klasorunuzun kendi "erisimi engelle"
  (`.htaccess`) dosyasi bu listeye girmiyordu; disaridan aktarilan bir tam site
  arsivi onu ezdiginde o klasordeki TUM arsivler ve veritabani dokumleri
  dogrudan URL ile indirilebilir hale geliyordu — ve dosya kendiliginden geri
  gelmiyordu. Sifreleme anahtari diziniz de ayni sekilde korumasizdi; eski bir
  arsivden geri gelen anahtar, kayitli sirlarinizi cozulemez yapip siteyi
  sessizce yedeksiz birakabiliyordu. Iki dizin de artik her derinlikte, hem
  YAZMA hem SILME adiminda korunuyor ve geri yukleme sonunda sertlestirme
  dosyalari yeniden kontrol ediliyor.
* E-posta geri yuklemesinde posta kutusu adlari arsiv icerigiden suzgecsiz
  turetiliyordu; artik temizleniyor ve derinligi sinirlaniyor.
* Panel imzasinin zaman penceresi PHP moduluyle esitlendi: gelecege damgali bir
  jeton icin tolerans 10 dakikadan 1 dakikaya indi.

**Basarili bir yedek, gecici bir ag hatasi yuzunden "basarisiz" gorunmuyor.**

* Yukleme izni ve kayit istekleri tek denemelikti. Arsiv o noktada depolama
  hedefinize ZATEN yuklenmis oluyor; istek gecici bir 502/503 alirsa yedek
  basarisiz sayiliyor, hedefte panelin bilmedigi bir arsiv kaliyor ve bir
  sonraki tur her seyi bastan uretiyordu. Bu iki istek artik 3 kez, artan
  beklemeyle deneniyor (PHP modulundeki kural).
* Yedek raporu "N tablo atlandi" derken hangi tablolarin atlandigini da
  soyluyor; dogrulama ucunun indirdigi gecici arsiv artik her durumda siliniyor.

= 1.62.1 — 2026-09-02 =

**Parcali yedek artik kendi hiz sinirimiza takilmiyor (buyuk siteler).**

* Yedek istegi hiz siniri, parcali (chunked) yedegin HER parcasi icin ayri ayri
  sayiliyordu. Buyuk bir sitede parca sayisi saatlik kovayi kacinilmaz olarak
  doldurup yedegi 429 ile dusuruyordu — yani yedegi kendi savunma mekanizmamiz
  olduruyordu. Parcali istekler artik muaf (kimlik dogrulamasi degismedi).

**Geri yuklemede veritabani secimi ARTIK ONURLANDIRILIYOR.**

* Panelden "yalnizca su veritabanini geri yukle" secildiginde eklenti bu secimi
  okumuyor ve sitenin canli veritabanini kosulsuz uzerine yaziyordu. Secim artik
  hem `.sql.gz` hem zip dallarinda uygulaniyor; secilmeyen veritabanina
  DOKUNULMUYOR ve panele acik gerekce donuyor.

= 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&uuml;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` &harr; `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ü konumları temizleniyor.

= 1.57.3 — 2026-08-18 =
* **Düzeltildi: yedek başarıyla alınıyordu ama panel "dosya bulunamadı" diyordu.** Arşiv
  doğru klasöre yazılıyor, ancak indirme ve silme işlemleri klasörü BAŞKA bir kaynaktan
  hesaplıyordu. Sitesi başka bir sunucuya taşınmış kurulumlarda WordPress'in bildirdiği
  yükleme klasörü yolu ESKİ sunucuya ait olabiliyor; yazma tarafı bunu 1.57.0'da
  doğrulamaya başlamıştı ama okuma/silme tarafı ham değeri kullanmaya devam ediyordu.
  Sonuç: yedek 3-4 dakika boyunca paketleniyor, tamamlanıyor, sonra panel dosyayı
  bulamayıp işi başarısız sayıyordu. Dosya aslında YERİNDEYDİ.
* **Aynı hata yedeğin İÇERİĞİNİ de bozuyordu:** yedek klasörünün yeni arşive dahil
  EDİLMEMESİNİ sağlayan kural da aynı yanlış yoldan hesaplandığı için taşınmış sitelerde
  çalışmıyordu — arşiv kendi önceki arşivlerini içine alıp gereksiz yere büyüyordu.
* Artık yedek klasörünün yolu tek bir doğrulanmış kaynaktan geliyor: yazma, okuma, silme,
  geçici dosya ve dışlama kuralı aynı yeri gösteriyor.

= 1.57.2 — 2026-08-18 =
* **Düzeltildi: yedek %97'de "kayıt onayı bekleniyor"da takılıp başarısız oluyordu.**
  Arşiv aslında hedefe SORUNSUZ yüklenmiş oluyordu; eklenti son adımda panele kayıt
  bilgisini yalnızca BİR KEZ gönderiyor, o tur tamamlanamazsa sonraki denemelerde boş
  gönderiyordu. Panel de bunu "bilgi gelmedi" sayıp yedeği başarısız işaretliyordu.
  Artık kayıt bilgisi saklanıyor ve gerektiğinde tekrar gönderiliyor.
* Bu durumda takılı kalmış eski bir oturum varsa artık otomatik temizleniyor; eskiden
  o oturum sonraki her yedeği de düşürüyordu.

= 1.57.1 — 2026-08-18 =
* **Düzeltildi: bazı hostinglerde yedek "Call to undefined function disk_free_space()"
  hatasıyla düşüyordu.** 1.57.0'daki yeni disk/kota kontrolü, bu fonksiyonu kapatan
  paylaşımlı hostinglerde ölümcül hataya yol açıyordu. Artık fonksiyonun varlığı tek bir
  yerden kontrol ediliyor; yoksa disk bilgisi "ölçülemedi" olarak geçiliyor ve yedek
  normal şekilde devam ediyor.
* Not: aynı sınıf hata 1.53.x'te de yaşanmıştı. Kontrolün her çağrı yerinde elle
  tekrarlanması hatayı geri getirdiği için artık tek bir yardımcıdan geçiliyor ve
  otomatik bir kontrol, korumasız çağrı eklenmesini engelliyor.

= 1.57.0 — 2026-08-18 =
* **Yedek artık BAŞLAMADAN önce sistemi kontrol ediyor.** Eskiden bir sorun varsa (klasör
  yazılamıyor, disk dolu, veritabanına erişilemiyor, ZipArchive yok) bunu ancak yedek %95'e
  geldiğinde, 15-20 dakika sonra öğreniyordunuz. Artık yedek başlamadan önce tek bayt
  paketlenmeden kontrol yapılıyor ve sorun varsa saniyeler içinde net bir mesajla duruyor.
  Kontrol edilenler: PHP sürümü, gerekli eklentiler (ZipArchive, cURL), yedek klasörüne
  GERÇEK yazma testi, disk/kota, veritabanı erişimi, bellek ve süre limitleri, yarım kalmış
  yedek artıkları.
* Yazma testi bilerek gerçek bir dosya yazıp siliyor: paylaşımlı hostingde izin bilgisi
  "yazılabilir" dese bile kota veya bağlama sorunu yüzünden yazma başarısız olabiliyor —
  bugün yaşanan arıza tam olarak bu türdendi.
* Uyarılar yedeği durdurmaz, yalnızca bildirilir; yedek yalnızca gerçekten engelleyici bir
  sorun varsa başlatılmaz.

= 1.56.0 — 2026-08-18 =
* **Yedek klasörü artık eklenti etkinleştirilirken oluşturuluyor.** Eskiden klasör ilk yedeğin
  SONUNDA, arşiv paketlendikten sonra yaratılıyordu. Bu yüzden yazılamayan bir klasör ancak
  saatler sonra, yedek %95'teyken hata veriyordu; o zamana kadar harcanan süre boşa gidiyordu.
  Artık kurulumda deneniyor: klasör oluşturulup korumaları (.htaccess, index.php) HEMEN
  uygulanıyor. Bir sorun varsa yönetim panelinde net bir uyarı görüyorsunuz — yedeğin
  başarısız olmasını beklemenize gerek kalmıyor.
* **Sorunu düzeltince uyarı kendiliğinden kalkıyor.** Yükleme klasörü yolunu düzelttiğinizde
  eklentiyi yeniden etkinleştirmeniz gerekmez; panel her açılışta (saatte en fazla bir kez)
  yeniden deneyip klasörü oluşturur ve uyarıyı kaldırır.

= 1.55.8 — 2026-08-18 =
* **Sunucu taşıması sonrası yedek alınamıyordu (kritik).** Site başka bir sunucuya taşındığında
  veritabanı, ESKİ sunucunun mutlak klasör yolunu taşımaya devam edebiliyor (Ayarlar > Medya
  altındaki "upload_path" ayarı). WordPress yükleme klasörünü oradan bildirdiği için eklenti,
  yeni sunucuda HİÇ VAR OLMAYAN bir yola yazmaya çalışıyor ve yedek her seferinde
  "Hedef klasör oluşturulamadı — Permission denied" ile ölüyordu. Diskte 30 GB boş yer olsa bile.
  Eklenti artık bu yola körü körüne güvenmiyor: kullanılabilir olduğunu (var + yazılabilir)
  doğruluyor, değilse kurulumun gerçek yapısından (WP_CONTENT_DIR, ardından ABSPATH) sağlam bir
  klasöre düşüyor. Yol hiçbir şekilde kullanılamıyorsa hata mesajı ne yapmanız gerektiğini
  söylüyor.

= 1.55.7 — 2026-08-18 =
* **"Hedef klasör oluşturulamadı" hatası artık sebebini ÖLÇEREK söylüyor.** Önceki sürüm
  "üst klasörde yazma izni yok olabilir" diyordu; "olabilir" sizi doğru yere götürmez, çünkü
  bu hata hem izin, hem disk/kota dolması, hem de bir üst klasörün hiç bulunmaması yüzünden
  oluşur ve çözümleri birbirinden farklıdır. Artık mesaj şunları içeriyor: en derin VAR OLAN
  üst klasör hangisi, o klasör yazılabilir mi, orada ne kadar boş alan var ve sistemin kendi
  hata mesajı. Böylece disk mi dolu yoksa izin mi eksik, bakar bakmaz görülüyor.

= 1.55.6 — 2026-08-17 =
* **"Ne kadar yer kazandırır?" ölçümü ile yedeğin gerçekte aldığı dosya sayısı ayrışıyordu.**
  İlerleme ekranı "5717 dosya" derken ölçüm paneli "5724 dosya" diyordu. Sebep: ölçüm, yedeği
  üreten kodun iki elemesini yapmıyordu — eklentinin kendi geçici artıkları ve okunamayan
  dosyalar. Yani panel, yedeğe girmeyecek dosyaları "girecek" diye sayıyordu.
  Artık üç yer de (parçalı yedek listesi, tam yedek ve ölçüm paneli) tek bir karar noktasını
  kullanıyor; gösterilen sayı yedeğin gerçekte yaptığı işle aynı olmak zorunda.
* Ölçüm paneli artık yalnızca SİZİN kalıplarınızın elediğini "kazanç" olarak sayıyor; varsayılan
  olarak zaten hariç olanlar (önbellek, yedek klasörü, okunamayan dosya) rakamı şişirmiyor.

= 1.55.5 — 2026-08-17 =
* **Başka eklentilerin uyarıları Yedekalma ekranlarında görünmüyor artık.** WordPress uyarı
  kancasını tüm yönetim sayfalarında çalıştırdığı için, temanızın "şu eklenti pasif" uyarısı
  veya başka bir eklentinin "veri toplamamıza izin verir misiniz?" kutusu Yedekalma ayar
  sayfasının en üstünde çıkıyordu; bir yedekleme ekranında bunları görmek "bu benim yedeğimle
  mi ilgili?" karışıklığı yaratıyordu. Artık yalnızca KENDİ ekranlarımızda üçüncü taraf
  uyarıları gizleniyor. WordPress çekirdeğinin uyarıları (güvenlik/güncelleme) KORUNUR ve
  sitenizin diğer sayfalarına hiç dokunulmaz.
* **Simge (dashicons) bağımlılığı açıkça beyan edildi.** Arayüzdeki simgeler çekirdeğin
  stil dosyasını zaten yüklemiş olmasına dayanıyordu; bir tema veya eklenti onu kaldırırsa
  simgelerin yerinde boş kutular kalıyordu. Artık kendi stilimizin bağımlılığı olarak
  yükleniyor.

= 1.55.4 — 2026-08-17 =
* **"Önerilen gereksiz dosya ve klasörleri hariç tut" özelliği kaldırıldı.** Tek tıkla 35 kural
  uygulamak, yedeğinizin içeriğini daraltan kararları görmeden kabul etmenize yol açıyordu.
  Neyin hariç tutulacağına artık siz karar veriyorsunuz: sağdaki klasör gezgininden istediğiniz
  klasörü seçip hariç tutabilir, kaydetmeden önce "Ne kadar yer kazandırır?" ile etkisini
  ölçebilirsiniz. Önbellek klasörleri, .git, node_modules ve tanınan yedek eklentisi klasörleri
  zaten varsayılan olarak hariçtir — onlar için bir şey yapmanız gerekmez.

= 1.55.3 — 2026-08-17 =
* **"Önerilen gereksiz dosyaları hariç tut" artık NEDEN gereksiz olduklarını da gösteriyor.**
  Düğme 35 kalıbı tek tıkla ekliyordu ama her kalıbın gerekçesi ayrı bir pencerede duruyor ve
  yalnızca ayrı bir bağlantıyla açılıyordu. Yani yedeğinizin içeriğini daraltan 35 kuralı
  görmeden kabul etmiş oluyordunuz. Artık kalıplar eklendiği anda gerekçe listesi açılıyor:
  her satırda kalıp, ne olduğu ve neden yedeğe girmesine gerek olmadığı yazıyor; eklenenler
  "✓ eklendi" olarak işaretleniyor. Katılmadığınız satırı kaydetmeden önce kutudan silebilirsiniz.
  Listede site içeriği (yüklemeler, temalar, eklentiler, çeviriler, vendor/) ASLA yer almaz.

= 1.55.2 — 2026-08-17 =
* **Yedek, kendi eski arşivini yedeklemeye çalışıyordu (kritik).** Eklenti yedeği geçici bir
  dosyada kurar (`wp-content/uploads/yedekalma_full_…`). Bir yedek koşusu yarıda kalırsa bu
  geçici dosya diskte kalıyor ve SONRAKİ yedek onu normal bir site dosyası sanıp arşive
  eklemeye çalışıyordu. Artık yüzlerce MB olan bu artık tek bir adıma sığmadığı için yedek
  ilerleyemiyor, hosting isteği kesiyor ve yedek hiç tamamlanmıyordu. Aynı şey eski
  kurulumdan kalan `YedekAlmaBackup-…` klasörleri için de geçerliydi.
  Artık eklentinin kendi geçici dosyaları ve yedek klasörleri her koşuda hariç tutuluyor.
  Belirti: yedeğin sonlara doğru tıkanıp saatlerce aynı dosyada beklemesi, sitenizin gerçekte
  olduğundan çok daha büyük ölçülmesi.
* Not: diskte kalmış eski `yedekalma_full_…` dosyalarını silmek yer kazandırır; yedeğe artık
  girmiyorlar ama yer kaplamayı sürdürürler.

= 1.55.1 — 2026-08-17 =
* **"Yükleme başarısız" artık SEBEBİNİ söylüyor.** Yedek kendi sunucunuzda saklanırken (domain
  içi depolama) bir sorun çıkarsa panelde yalnızca "Yükleme başarısız: upload_failed" yazıyordu;
  disk mi doldu, klasöre yazma izni mi yok, hiç belli olmuyordu. Bu adımda beş ayrı hata yolu
  vardı ve hiçbiri gerekçe döndürmüyordu. Artık disk boş alanı ölçülüyor, yazma izni sınanıyor
  ve mesaj net: "Diskte yeterli yer yok: arşiv 412,0 MB, boş alan 63,4 MB — eski yedekleri
  silip yeniden deneyin." gibi.
* **Yarım yazılan arşiv artık fark ediliyor.** Disk yazma sırasında dolarsa dosya eksik kalıyor
  ve bu sessizce "başarılı" sayılabiliyordu. Artık yazılan boyut beklenenle karşılaştırılıyor;
  eksikse yarım dosya siliniyor ve durum açıkça bildiriliyor.

= 1.55.0 — 2026-08-17 =
* **Yedeğe giremeyen dosyalar artık BİLDİRİLİYOR (kritik).** Bir dosya izin hatası, açılamayan
  klasör ya da disk/kota sorunu yüzünden okunamazsa, eklenti onu SESSİZCE atlıyordu: yedek
  "tamamlandı" damgası alıyor, o dosyalar arşivde bulunmuyordu. Daha kötüsü, klasör gezinmesi
  bir izin hatasıyla kesilirse YARIM dosya listesi tam liste gibi kullanılıyordu — yani bütün
  bir klasör sessizce yedeğin dışında kalabiliyordu. Bunu ancak geri yüklerken fark ederdiniz.
  Artık okunamayan her dosya/klasör sayılıyor ve yedekalma.com paneline bildiriliyor; panelde
  yedeğin yanında "⚠ N dosya arşive eklenemedi — bu yedek EKSİK" uyarısı görünüyor.
* Panel tarafı da aynı gün düzeltildi: bu bilgi eskiden gönderiliyor ama panelde OKUNMUYORDU.

= 1.54.9 — 2026-08-17 =
* **Hariç tutma kalıplarında karakter sınıfı (`[0-9]`) uygulanmıyordu.** `logs[0-9]` ya da
  `20[12][0-9]` gibi bir kalıp yazdıysanız, ekranda "hariç tutulan yol" olarak sayılıyor ama
  yedeğe GİRİYORDU. Aynı kalıp panelin PHP modülünde doğru çalıştığı için iki üründe farklı
  sonuç doğuyordu; artık ikisi birebir aynı davranıyor. Yalnız `*` ve `?` kullandıysanız
  bu sorundan etkilenmediniz.

= 1.54.8 — 2026-08-17 =
* **"Diskte bulundu" yedekleri silinemiyordu (kritik kullanılabilirlik).** Yedek listesi iki
  kaynağı birleştirir: eklentinin kendi kaydı ve diskte tarama ile bulunan arşivler (satırda
  "Diskte bulundu" etiketiyle görünür). İkinci gruptaki bir yedeği seçip "Sil" dediğinizde
  işlem tamamlanmıyor, satır listede kalıyordu. Sebep: bu satırların kaydı olmadığı için
  eklenti onları bulut yedeği sanıp yedekalma.com'a bilmediği bir kimlikle silme isteği
  gönderiyordu. Artık disk taramasında bulunup dosya doğrudan siliniyor (yol güvenlik
  denetiminden geçirilerek).
* **Arşivi elle sildiyseniz kayıt artık temizlenebiliyor.** Bir yedek dosyasını FTP/dosya
  yöneticisiyle kendiniz sildiyseniz, "Sil" işlemi "dosya bulunamadı" diyerek duruyor ve
  listeyi hiç temizleyemiyordunuz. Silme artık idempotent: dosya zaten yoksa istenen sonuç
  sağlanmış sayılır ve kayıt kaldırılır. Dosya diskte VARSA ama silinemiyorsa (izin/kilit)
  bu yine açıkça hata olarak bildirilir — kaydın kalkıp dosyanın kalması engellenir.
  Aynı kural bulut tarafında da geçerli: panelde kaydı bulunmayan bir yedek "zaten silinmiş"
  sayılır.

= 1.54.7 — 2026-08-17 =
* **Sayfa önbelleği panelin sitenizi okumasını engelliyordu (kritik).** LiteSpeed Cache,
  WP Rocket veya benzeri bir önbellek eklentisi kullanıyorsanız, eklentinin yedekalma.com
  ile konuştuğu `/wp-json/` yanıtları önbelleğe alınabiliyordu. Sonucu: panelde "Modül
  durumu alınamadı — eklentiyi güncelleyin" uyarısı çıkıyor, eklentiyi güncellemek de bir
  şey değiştirmiyordu; çünkü sorun eklentide değil, araya giren önbellekteydi.
  Ayrıca aynı önbellek, yetkili bir isteğe verilen yanıtı yetkisiz bir ziyaretçiye
  sunabiliyordu — sitenizin dosya ve veritabanı boyutu bu yolla görünür hâle gelebiliyordu.
  Eklenti artık kendi REST yanıtlarını açıkça önbelleklenemez olarak işaretliyor
  (`no-store` + `DONOTCACHEPAGE` + LiteSpeed kontrolü). Yedeklemeniz bundan etkilenmiyordu;
  etkilenen yalnızca panelin ayarlarınızı okuması ve durum göstergeleriydi.
* **S3 uyumlu depolamada özel port kullanan hedeflerde imza hatası (kritik).** Kendi
  sunucunuzda çalışan MinIO gibi, adresinde port bulunan (`https://depo.ornek.com:9000`)
  bir S3 hedefi tanımladıysanız, eklentinin ürettiği imza panelin ürettiğinden FARKLI
  olabiliyordu ve yükleme `SignatureDoesNotMatch` hatasıyla sessizce reddediliyordu.
  Sebep: `Host` başlığı varsayılan portu (http'de 80, https'te 443) göstermez; eklenti
  ise portu her koşulda ekliyordu. Artık panelle birebir aynı kural uygulanıyor.
  Amazon S3, Google Cloud Storage, Wasabi gibi standart portlu hedefleri kullanıyorsanız
  bu sorundan etkilenmediniz.

= 1.54.6 =
* Bu sürüm SAHAYA HİÇ ÇIKMADI. Sürüm numarası deponun içinde bir an için ayarlandı ama
  yayınlanmadan önce bir sonraki düzeltmeyle birleştirildi ve 1.54.7 olarak yayınlandı.
  Kayıt, "1.54.6'ya ne oldu?" sorusunun cevabı olarak burada duruyor.

= 1.54.5 — 2026-08-17 =
* **Hariç tutma listesi yedeğe HİÇ uygulanmıyordu (kritik).** Dosya bölümünde belirlediğiniz
  hariç tutma kalıpları yalnızca ekranda çalışıyordu: rozet doğru sayıyı gösteriyor,
  "ne kadar yer kazandırır?" ölçümü doğru sonucu veriyor, panele bildirilen liste de
  doğruydu — ama yedeği ÜRETEN kod bu listeyi BAŞKA bir kayıttan okuyordu ve oraya hiçbir
  zaman bir şey yazılmıyordu. Sonuç: liste daima boş sayılıyor ve hariç tuttuğunuz her şey
  arşive giriyordu. Aynı hata boyut ölçümünü de etkiliyordu (site boyutu olduğundan büyük
  görünüyordu). Sahada ölçüldü: tahmin "yedeğe giren 9.214 dosya" derken yedek 16.669 dosya
  işliyordu — aradaki ~8,1 GB tam olarak hariç tutulmuş olması gereken veriydi. Artık
  liste tek bir kaynaktan okunuyor; eski kayıtta değer bırakmış kurulumlar için o kayıt da
  birleştiriliyor (hiçbir ayar kaybolmaz).

= 1.54.4 — 2026-08-17 =
* **Aynı sitede iki yedek birden başlayabiliyordu (kritik).** Eklentinin iki yedek yolu
  vardı ve her biri AYRI bir çalışma kilidi kullanıyordu: panelin sürdürdüğü parçalı
  yedek ile zamanlayıcının tetiklediği yedek birbirini hiç görmüyordu. Panel bir yedeği
  parça parça sürdürürken gelen zamanlı tetik, aynı sitede İKİNCİ bir tam yedek
  başlatabiliyordu — iki kat disk, iki kat CPU ve zaten sınırlı bir sunucuda ikisinin de
  bitememesi. Artık iki yol tek kilidi paylaşıyor: hangisi önce başladıysa diğeri
  ilerlemeyi bozmadan "meşgul" deyip çekiliyor.

= 1.54.3 — 2026-08-17 =
* **Eklentinin KENDİ zamanlanmış yedeği büyük sitelerde sonsuz döngüye giriyordu (kritik).**
  Panelden tetiklenen yedek 1.49'da yeni arşiv motoruna geçirilmişti; eklentinin kendi
  zamanlamasıyla çalışan yedek ise eski motorda (PHP ZipArchive) kalmıştı. Bu motor arşivi
  her kapanışta BAŞTAN YAZAR — üstelik açık dosya sınırı yüzünden her 400 dosyada bir
  kapanış yapılıyordu. Sonuç: arşiv büyüdükçe her tur, arşivin tamamını yanına açtığı
  geçici bir dosyaya (`.part`) yeniden kopyalıyor; paylaşımlı hosting isteği 60 saniyede
  kestiği için kopya hep yarım kalıyor ve bir sonraki tur sıfırdan başlıyordu. Geçici
  klasörde büyüyüp büyüyüp sıfırlanan bir dosya, sürekli meşgul bir sunucu ve hiç bitmeyen
  bir yedek. Artık her iki yol da aynı akış motorunu kullanıyor: girdiler arşivin sonuna
  eklenir, hiçbir aşamada yeniden yazma ve geçici kopya olmaz.

= 1.54.2 — 2026-08-17 =
* **Büyük sitelerde yedek asla bitmiyordu — arşiv artık kopyalanmıyor, TAŞINIYOR (kritik).**
  "Domain içi depolama" hedefinde son adım, tamamlanan arşivi geçici klasörden yedek
  klasörüne koymaktı ve bunu KOPYALAYARAK yapıyordu. 7-9 GB'lık bir sitede bu kopya
  dakikalar sürer; paylaşımlı hosting isteği 60 saniyede kestiği için kopya hep yarım
  kalıyor ve bir sonraki tur AYNI kopyayı sıfırdan başlatıyordu. Sonuç: yedek klasöründe
  büyüyüp büyüyüp sıfırlanan bir dosya, dolan disk ve hiç tamamlanmayan bir yedek.
  Kaynak ve hedef zaten aynı disktedir; artık dosya taşınıyor — işlem anında bitiyor,
  ek disk alanı istemiyor ve yarıda kalamıyor. Ek bir yedek hedefiniz (mirror) varsa
  arşive hâlâ ihtiyaç duyulduğu için eski davranış sürüyor.
* **Arşivin SHA-256 özeti her turda yeniden hesaplanıyordu (kritik).** Yükleme aşamasına
  birden çok kez girilir (izin iste → yükle → kayıt onayı) ve her girişte 7-9 GB'lık
  arşivin tamamı baştan sona okunup özetleniyordu. Tek geçiş bile 60 saniyelik istek
  penceresine sığmadığı için yedek, arşiv çoktan hazırken %95'te takılı kalıyordu.
  Arşiv o noktadan sonra değişmediği için özet artık bir kez hesaplanıyor.
* **Yarım kalan yedeklerin GB'lık artıkları geride kalabiliyordu.** Yarıda kesilen bir
  yedeğin oturum bilgisi kaybolursa (nesne önbelleği temizlenir, veritabanı budanır)
  eklentinin elinde silinecek dosyanın yolu kalmıyordu; sahada iki terk edilmiş arşiv
  (9,0 GB + 7,6 GB) aynı anda görüldü. Geçici dosya yolları artık oturumdan bağımsız
  olarak da tutuluyor ve bir sonraki yedek başlarken önceki koşunun artıkları siliniyor.

= 1.54.1 — 2026-08-17 =
* **Arşiv yazıcısında kısa yazma artık yakalanıyor (yedek bütünlüğü).** Disk ya da hosting
  kotası dolduğunda işletim sistemi bir yazmayı YARIM tamamlayabilir. Yazıcı yalnızca "yazma
  tamamen başarısız oldu mu" diye bakıyordu; yarım yazma başarı sayılıyor ve arşivde izlenen
  konum gerçek dosya boyutundan kayıyordu. Bu kayma, o noktadan sonraki tüm dosya kayıtlarını
  yanlış yere işaret ettirir — arşiv "geçerli" görünür ama açılamaz. Artık yarım yazmalar
  tamamlanıyor, gerçekten yazılamıyorsa paketleme durduruluyor. Aynı boşluk 4 GB üstü
  arşivlerin son kaydında ve dosya küçüldüğünde yazılan dolguda da vardı.
* **Şifreli yedekte "yer yok" hatası artık doğru söyleniyor.** Şifreleme geçici olarak
  arşivin ~2 katı boş alan ister; alan yetmediğinde mesaj "openssl yok ya da doğrulama
  başarısız" diyordu ve sorun yanlış yerde aranıyordu. Artık gereken/mevcut alan yazılıyor
  ve şifreleme daha başlamadan kontrol ediliyor.

= 1.54.0 — 2026-08-17 =
* **Yedek bütünlüğü — arşiv artık yüklenmeden ÖNCE doğrulanıyor (kritik).** Eklenti, ürettiği
  arşivi bugüne kadar hiç sınamıyordu: yazma sırasında bir hata olsa bile (disk dolu, hosting
  kotası, geçici I/O hatası) paketleme sonuna kadar devam ediyor, dosya "geçerli bir zip" gibi
  görünüyor ve bulut alanınıza öyle yükleniyordu. Bozukluk ancak GERİ YÜKLEME günü ortaya
  çıkıyordu. Artık: (1) yazma hatası olduğu anda paketleme durdurulur ve yarım arşiv silinir —
  yanlış bir "başarılı" kaydı oluşmaz; (2) tamamlanan her arşiv, yüklemeden ve şifrelemeden
  önce yapısal olarak doğrulanır; doğrulamayı geçemeyen arşiv gönderilmez.
* **Artımlı yedeklerde "değişmemiş dosyayı atla" kuralı düzeltildi.** Kaynak sınırı olan
  hosting'lerde devreye giren parçalı yedekleme yolunda bu kural hesaplanıyor ama
  UYGULANMIYORDU: yedek "artımlı" olarak işaretlense de her turda sitenin TAMAMI yeniden
  paketlenip yükleniyordu. Bu, gereksiz süre, bant genişliği ve bulut alanı tüketiyordu.
* **Yedeklenemeyen dosya artık sessiz kalmıyor.** Bir dosya izin/okuma hatası yüzünden arşive
  eklenemediğinde eskiden hiçbir iz kalmıyor, üstelik o dosya "yedeklendi" listesine yazıldığı
  için SONRAKİ artımlı yedeklerde de atlanıyordu — yani bir daha hiçbir yedeğe girmiyordu.
  Artık yalnızca gerçekten arşive giren dosyalar listeye yazılır ve eklenemeyen dosya sayısı
  ilerleme ekranında uyarı olarak gösterilir.
* **Veritabanı olmadan "tam yedek" üretilmiyor.** Doğrudan yedekleme yolunda veritabanı dökümü
  arşive eklenemese bile yedek başarılı sayılıyordu; içinde veritabanı olmayan bu arşiv
  saklama sayacına girip gerçekten tam olan eski bir yedeğin silinmesine yol açabiliyordu.
  Artık bu durumda yedek açıkça başarısız olur.
* **E-posta yedeğinde de aynı koruma.** Bir e-postanın arşive yazılması başarısız olduğunda
  ileti artık "yedeklendi" sayılmıyor.
* PHP sürüm kapısı eklendi: eklenti, gerektirdiği PHP sürümünün altındaki sunucularda
  dosyalarını yüklemeden önce durur ve yönetici paneline açıklayıcı bir uyarı basar.

**Geri yükleme düzeltmeleri (aynı sürümde):**

* **Geri yüklemede bileşen seçimi artık UYGULANIYOR (kritik).** Panelde "Veritabanı" kutusunu
  kapatıp yalnızca dosyaları geri yüklediğinizde eklenti bu seçimi YOK SAYIYOR ve yedekteki
  veritabanı dökümünü canlı veritabanınıza uyguluyordu — açıkça hariç tuttuğunuz, geri dönüşü
  olmayan bir üzerine yazma. Dosya, veritabanı ve e-posta seçimlerinin üçü de artık dikkate
  alınıyor.
* **"Bu dosyaya dokunma" listesi artık SİLME adımında da geçerli.** Hariç tutma yalnızca yazma
  sırasında uygulanıyordu; artımlı geri yüklemenin "silinenler" listesinde yer alan korumalı
  bir yol (tipik olarak `wp-config.php` veya `wp-content/uploads` altındaki dosyalar) yine de
  siteden siliniyordu — yani koruma tam tersine dönüyordu.
* **Hiçbir dosya yazılamadıysa silme adımı artık çalışmıyor.** Arşiv açıldı ama izin/disk
  sorunu yüzünden tek bir dosya bile yazılamadıysa, geri yükleme siteyi onarmak yerine yalnızca
  silme uyguluyordu — kurtarma anında ek veri kaybı. Artık bu durumda silme atlanır ve sebebi
  raporlanır.
* **Yarım veritabanı dökümü artık uygulanmadan reddediliyor.** Sıkıştırılmış (.sql.gz) dökümde
  "tamamlandı" işareti yalnızca tüm ifadeler ÇALIŞTIRILDIKTAN sonra kontrol ediliyordu: yarım
  bir döküm canlı veritabanına zaten uygulanmış oluyor, ardından "kısmi geri yükleme iptal
  edildi" deniyordu — geri alma diye bir şey yoktu. Artık döküm önce taranıyor; işaret yoksa
  veritabanına tek bir ifade bile uygulanmıyor.
* **Yarım yazılan dosya artık sitede bırakılmıyor.** Geri yükleme sırasında disk dolarsa kesik
  bir dosya yazılıp "başarılı" sayılıyordu. Artık kesik dosya siliniyor, sayılıyor ve sonuç
  "kısmi" olarak işaretleniyor.
* **Geri yükleme artık eklentinin kendi dosyalarının üzerine yazmıyor.** Arşivdeki eski eklenti
  sürümü, işlem sürerken çalışan eklentinin üzerine yazılabiliyordu.
* **Kullanılmayan üç geri yükleme uç noktası kaldırıldı** (`/restore-zip`, `/restore-db`,
  `/restore-wpconfig`). Bunlar yukarıdaki korumaların hiçbirini uygulamıyordu ve zaten
  çağrılmıyorlardı; ayrıca sitenizin kök dizinindeki dosyaları (`index.php`, `wp-config.php`,
  `.htaccess` …) sessizce atlayan bir hata içeriyorlardı.

= 1.53.3 — 2026-08-16 =
* **Geri yüklemede "bu dosyayı koru" seçimi artık UYGULANIYOR (önemli).** Panelde bir dosyayı
  ya da klasörü geri yükleme dışında bıraktığınızda, eklenti bu seçimi YOK SAYIYOR ve dosyanın
  üzerine yazıyordu. Tipik olarak `wp-config.php`, `.htaccess` ve `wp-content/uploads` bundan
  etkileniyordu; hiçbir uyarı da gösterilmiyordu. Artık hariç tutulan yollar atlanıyor ve
  atlanan dosya sayısı sonuç raporunda görünüyor.
* **Yanlış klasöre açılan arşiv sorunu giderildi.** Özel modül biçiminde üretilmiş bir arşiv
  eklenti üzerinden geri yüklendiğinde site dosyaları gerçek yerlerine değil `dosya/` alt
  klasörüne açılıyor, veritabanı dökümü de sıradan bir dosya gibi site köküne yazılıyordu —
  yani geri yükleme "başarılı" görünse de site onarılmıyor, üstelik dökümün web üzerinden
  indirilebilir kalması riski doğuyordu. Her iki önek de artık doğru ele alınıyor.

= 1.53.2 — 2026-08-15 =
* **Yedek bütünlüğü (önemli).** Bir dosya arşive eklenirken okuma hatası oluşursa, o dosya
  eskiden sessizce SIFIR baytlarla doldurularak yedeğe giriyordu. Arşiv "başarılı" görünüyor,
  boyut ve tarih doğru yazıldığı için sonraki artımlı yedekler de o dosyayı atlıyordu; bozukluk
  bir sonraki tam yedeğe kadar zincirde kalıyordu. Artık okuma hatası ile "dosya kopyalanırken
  küçüldü" durumu birbirinden ayrılıyor: gerçek okuma hatasında dosya arşive DOĞRU İÇERİKMİŞ
  gibi yazılmıyor, bir sonraki turda yeniden deneniyor. (Canlı bir sitede log dosyasının
  yedekleme sırasında döndürülmesi gibi olağan durumlar eskisi gibi sorunsuz çalışır.)
* Arşiv üretiminde tutarlılık doğrulaması ve ofset takibi sıkılaştırıldı; kesilen bir yazma
  işlemi artık arşivin geri kalanını kaydırmıyor.

= 1.53.1 — 2026-08-13 =
* Güvenlik/kararlılık: Şifreli arşiv çözülürken bozuk bir dosyadaki hatalı uzunluk
  alanı belleği sınırsız doldurabiliyordu; artık makul bir üst sınır uygulanıyor
  (PHP Yedekleme Modülü'ndeki aynı düzeltmenin eklenti karşılığı).

= 1.53.0 — 2026-08-13 =
* Düzeltme: Şifreli yedeklerde parola parmak izi panele bildirilmiyordu. Bu yüzden geri
  yüklemede yanlış parola ön-kontrolü hiç çalışmıyor, arşiv indirilip çözülmeye
  çalışıldığında hata veriyordu; ayrıca şifreli yedekler panelde "şifresiz" görünüyordu.
* Düzeltme: Yedeğin başlama anı ve süresi panele bildirilmiyordu — yedek geçmişinde
  "ne kadar sürdü" alanı boş kalıyordu.
* Her iki bilgi artık doğrudan yedek, parçalı yedek ve çoklu depolama hedefi (fan-out)
  yollarının hepsinde gönderiliyor (PHP Yedekleme Modülü ile aynı sözleşme).

= 1.52.0 — 2026-08-12 =
* **FIX (data loss):** Files you excluded from backups could be **deleted from your live site** during a restore. In an incremental backup the plugin listed "files that exist in the previous backup but are gone from disk" so a restore could remove them — but it was actually measuring "files that did not enter this archive". Exclusion rules and temporarily unreadable files landed in that same list. So if you added a folder to the exclusion list after a full backup (to make backups smaller), the next incremental marked every file in it as deleted, and restoring that chain removed the folder from your site. Those files were not in any backup either, because they were excluded. The check now looks at the disk directly, which is what the code always claimed to do.
* **FIX:** Read-only backup verification works again on WordPress. The `/verify` REST route was removed in 1.51.x on the assumption that nothing called it; the panel calls it in two places (manual dry-run and the weekly verification drill). With the route gone WordPress answered 404, so verification silently checked nothing — it looked green because zero checks ran, not because zero problems were found.
* **FIX:** An unrecognised restore mode is now rejected instead of silently falling back to "restore everything". The most destructive option should never be the default for an instruction the plugin does not understand.
* **FIX:** Size measurement no longer walks into folders it is going to skip anyway. Scans stop at the folder boundary for local backup archives, caches, `node_modules`, version control and other backup plugins' folders. On sites holding several GB of old archives the 10-second measurement budget was spent listing files that were then discarded, so the reported site size came back far too small — and the panel had no way to tell that the number was incomplete.
* **FIX:** The folder browser used for choosing exclusions no longer counts already-skipped subfolders in its totals, so the sizes you base your decision on reflect what actually goes into the backup.

= 1.51.4 — 2026-08-12 =
* FIX: Exclusion rules written as a regular expression now actually work. The settings screen has always documented three rule types (path, wildcard, regex) and even showed `/^backup_\d+\.sql$/i` as an example, but the matcher had no regex branch at all: such a line was treated as a literal folder name, so it never matched anything — and never reported an error either. If you relied on a regex rule, files you believed were excluded were still being backed up.
* FIX: A rule that cannot be compiled is no longer swallowed in silence. Invalid patterns are reported back to the panel and excluded from the "N excluded paths" badge, so the number on screen matches what the backup actually does. Previously the badge counted raw lines, which meant it could say "1 excluded path" while zero paths were excluded.

= 1.51.3 — 2026-08-11 =
* SECURITY: Removed seven REST endpoints that were still registered but no longer used by anything (`/db`, `/files`, `/manifest`, `/file`, `/diag`, `/zip-batch`, `/verify`). They belonged to an older "pull" transfer model that was replaced by direct backup, yet each one still accepted the shared secret and could stream your full database dump or read any file under the site root. Dead code is not harmless when it is also an open door, so the doors are gone. Backup, restore and download are unaffected — they never used these routes.
* FIX: Site size measurement now works for sites connected with this plugin. The `/size` endpoint existed and worked, but the panel only ever asked the standalone PHP module for it, so the "current size / monthly upload" box stayed permanently empty for WordPress sites. The two halves are now connected.

= 1.51.2 — 2026-08-10 =
* FIX: Your exclusion list was ignored when the site size was measured and when the incremental baseline was built. The backup itself honoured the list, so excluding a large folder did shrink the backup — but the panel kept reporting the old size, and the incremental baseline still listed files that would never be backed up. Measuring and producing now use the exact same matching code.

= 1.51.1 — 2026-08-08 =
* UX: After sending a support request you now get a confirmation screen instead of the empty form again. Seeing the form a second time made it look as if nothing had been sent, so the natural reaction was to send it once more. The screen states the request number, the address the answer will go to and what happens next. The form is also processed before the page is drawn, so refreshing no longer re-sends the request.
* FIX: A support request could be dropped without a trace. The spam trap on the Support form was a hidden field named `website`, and browsers and password managers autofill exactly that name — a filled trap made the server discard the request while the screen still said "we received it". The field no longer carries a name autofill recognises, and the server now logs every rejection so a false positive can be spotted instead of vanishing.
* FIX: If sending failed, the form was redrawn with "send technical details" ticked again even when you had unticked it — a second attempt would have sent the details you chose to withhold. The checkbox now keeps your choice.
* FIX: The confirmation after a successful request was always shown in Turkish regardless of the site language; it is translated now. Error text still comes from the server, because that is where the diagnosis is.
* FIX: Collecting technical details could raise a PHP warning on hosts with an unusual uploads directory configuration.
* TWEAK: The review prompt is now a small tab in the bottom corner instead of a bar pinned to the middle of the screen edge, where it sat at eye level and stayed there while you scrolled.
* FIX: The technical-details list you are asked to approve before sending was printed in Turkish on English, German, Russian and Arabic sites — you were being asked to confirm a list you could not read. Labels and states are shown in your own language now. What is actually transmitted stays in one fixed language on purpose, so support reads every request with the same vocabulary.

= 1.51.0 — 2026-08-08 =
* NEW: A **Support** screen under Settings. Until now a user who hit a problem had nowhere to write from inside WordPress — and because local backup, restore and the malware scanner work with no account at all, most of those users have no Yedekalma login either, so "open a ticket in the panel" was not an option for them. The new screen needs no account: your site address is filled in automatically, you type the problem, and the reply comes to the e-mail address you give.
* NEW: Optional one-click technical details with the request — plugin/WordPress/PHP/MySQL versions, PHP limits, whether ZipArchive and `exec()` are available, free disk space, whether the backup folder is writable and when the last local backup ran. Support answers usually start by asking exactly these. The complete list is shown on screen before sending and the checkbox can be unticked; no site content, database content or passwords are ever included.
* NEW: If the request cannot be sent (hosts that block outgoing connections), the screen says so and gives the support e-mail address instead of failing silently.
* UX: The "please rate us on WordPress.org" prompt no longer sits across the top of every Yedekalma page. Two lines of text and three buttons were eating the top of the first screen on every visit until it was dismissed. It is now a slim tab on the edge of the screen; the message itself opens in a dialog only if you click it. Closing the dialog changes nothing — snoozing or dismissing still happens only when you press those buttons.

= 1.50.12 — 2026-08-07 =
* FIXED: Your excluded paths were still being ignored by the two code paths that actually build the backup. 1.50.5 added the check, but in both places it was handed a variable that was never assigned — PHP treats that as "no patterns", so every rule silently evaluated to "keep this file". A site that excluded several folders was still packing 70,140 files. The panel-driven chunked backup and the full-ZIP endpoint now read your pattern list before they walk the site.

= 1.50.11 — 2026-08-07 =
* UX: The right column is narrower again (420px) and every pixel it gives up goes to the folder browser. The two buttons under the pattern box now sit one above the other at full column width, and `white-space: nowrap` makes it impossible for "Exclude the suggested unnecessary files and folders" to break onto a second line — if the measurement is ever wrong the button will visibly overflow instead of quietly wrapping.

= 1.50.10 — 2026-08-07 =
* UX: The two columns are no longer equal width. The right column is fixed at 440px — just enough for the "Exclude the suggested unnecessary files and folders" button to stay on one line — and every extra pixel goes to the folder browser on the left, where folder name, size, file count and button all share a row and a narrow column truncates the name you are trying to read.

= 1.50.9 — 2026-08-07 =
* UX: Dropped the "Excluded paths" row label from the exclusion screen. Once each column had its own heading, that label was a third heading lined up with nothing — and it was eating 200px that the folder browser now uses instead. The browser is wider, and two columns now fit from 1000px up instead of 1180px. The pattern box heading became a real `<label>` tied to the field, which the old row label never was.

= 1.50.8 — 2026-08-07 =
* UX: On wide screens the exclusion screen is now two columns — the folder browser on the left, the pattern box on the right. They used to sit one above the other, so clicking "Exclude" on a folder added a line you had to scroll up to see. Cause and effect are now on screen at the same time. On narrow screens it stays a single column, with the pattern box first.

= 1.50.7 — 2026-08-07 =
* Fix: The folder browser marked some folders "excluded by default" when they were in fact being backed up. A folder whose name merely *started* with a skipped name — `.github` next to `.git`, `node_modules_old` next to `node_modules` — got the badge and lost its "Exclude" button, so it looked handled while it kept going into every backup. The badge and the backup now read the same rule from one place.
* UX: Files are badged too. Opening an excluded folder used to show every file inside it with an "Exclude" button, suggesting those files were in the backup. They now show the same "already excluded" badge and sink to the bottom of the list, while still showing their size — so you can still see how much space old archives take.

= 1.50.6 — 2026-08-07 =
* UX: The list explaining what the exclusion suggestion covers no longer takes up half the settings screen. It now sits behind a "What does the suggestion cover?" link that opens a dialog, where you can also apply the whole list in one click.

= 1.50.5 — 2026-08-07 =
* UX: Every leftover file now shows the date and clock time it was created, in your site's own timezone, next to "6 hours ago" — so you can tell which backup attempt left it behind.
* UX: The file settings screen is split into two sub-tabs: "Files to back up" (exclusions and the folder browser) and "Leftover files" (the cleaner). Deciding what goes into a backup and deleting stray working files are two different jobs and no longer sit in each other's way. The cleaner scans by itself the first time you open its tab.

= 1.50.4 — 2026-08-07 =
* UX: The leftover-file cleaner now lists **every** file it found, including the recent ones it protects — "38 files will be kept" told you nothing about which files those were. Each entry shows its folder, size and age, and duplicates are no longer listed twice.
* NEW: A "Clean anyway" button removes the recent files too. The six-hour age rule is only an assumption — a file can look recent because the host cut the request off, not because a backup is still running. The real protection now sits where it belongs: if a backup genuinely is running (local job, panel-driven chunked backup, or the single-run lock), the cleanup is refused and tells you why.
* FIX: Files that could not be deleted (permissions) are now reported instead of being counted as cleaned.

= 1.50.3 — 2026-08-07 =
* UX: The one-click exclusion suggestion now covers everything a WordPress site can safely leave out of a backup — 35 patterns grouped and, next to each one, the reason it is safe: operating-system leftovers (`__MACOSX`, `._*`, `.DS_Store`, `Thumbs.db`), logs, half-finished temp files, editor backups, WordPress's own `upgrade` and `upgrade-temp-backup` folders (which otherwise store a second copy of every plugin and theme), regenerable plugin caches (Divi, Elementor, LiteSpeed, Wordfence, WooCommerce logs) and other backup plugins' archives.
* UX: Your actual site content is never on that list. Uploads, themes, plugins, translations and `vendor/` are always backed up, and patterns that could hide real data were deliberately left out.

= 1.50.2 — 2026-08-07 =
* FIX: The leftover-file cleaner now also looks in the places older versions used (wp-content, uploads, the system temp folder). Files left behind by earlier releases — the "yedekalma_db_….sql.gz" dumps you may see in your file manager — are found and removed instead of sitting there forever.
* UX: The cleaner is now offered on the file settings screen too, right under the folder browser where you actually see those files, not only on the Backups page.
* UX: The one-click exclusion suggestion now lists every pattern with the reason it is safe to skip, and adds `__MACOSX` — the leftover folder macOS creates when you zip something. It holds nothing WordPress reads, but often tens of thousands of tiny files, which is what actually slows a backup down.

= 1.50.1 — 2026-08-07 =
* UX: Every part of the folder path is now clickable, so you can jump straight back to any level instead of pressing "up" repeatedly.
* UX: The file tab now tells you the size and file count of your backup as soon as you open it, without pressing anything (the result is cached for ten minutes, so it appears instantly on later visits).
* UX: Layout fixes — the page no longer sits flush against the admin menu, long paths wrap readably, and the summary line is shown as a proper panel.

= 1.50.0 — 2026-08-07 =
* UX: The Pro settings page has been reorganised. Tabs read as tabs, each section sits in its own card with room to breathe, and a save bar now stays at the bottom of the page — it turns amber the moment you change something, so settings no longer get lost by switching tabs without saving.
* UX: In the exclusion browser, folders and files are now one list sorted by size, largest first — the thing making your backup big is the first thing you see. Folders that never enter a backup can still be opened (you may want to look inside), they simply carry an "already excluded" badge instead of a pointless button.

= 1.49.9 — 2026-08-07 =
* FIX: Every backup left a stray empty file behind, and an interrupted backup left its database dump (often 10-20 MB) on disk for good. Worse, these working files were written to a folder that is reachable from the web and were then packed into the next backup. They now live in the plugin's own hardened backup folder, the empty placeholder is no longer created, and the cleaner recognises them.
* NEW: The Backups screen can list and remove leftover working files with one click, showing exactly how many files and how much space they take. Files touched in the last 6 hours are left alone — they may belong to a backup that is still running.

= 1.49.8 — 2026-08-07 =
* FIX (important): The paths you excluded were never actually applied. The setting was saved and reported to the panel, but the code that builds the backup only honoured its own built-in skip list — so a folder you excluded went into the backup anyway and your backup never got smaller. Exclusions now apply to every backup path, and to the file manifest used by incremental backups.
* NEW: "How much space does this save?" measures your exclusions before you save them and tells you exactly how much smaller the backup becomes and how many files are left out. The measurement uses the same matching rules as the backup itself, so the number is real rather than an estimate.

= 1.49.7 — 2026-08-07 =
* UX: The exclusion browser is far more useful. Every folder now shows its total size and file count, the list is sorted largest first, and folders that never enter a backup anyway (cache, other backup plugins, version control, and the plugin's own backup folder) are marked "already excluded" instead of offering a pointless exclude button. You can now see at a glance what is actually making your backup big.
* NEW: A single "Exclude the usual junk" button adds the patterns most sites need (*.tmp, *.log, error_log, debug.log) without hunting for them.

= 1.49.6 — 2026-08-07 =
* UX: The Backups screen now explains that deleting here removes the file on this server, while the record in your yedekalma.com panel is a separate thing. The panel never deletes files at your backup destination — once the file is really gone you can remove the record there. Previously a record left in the panel looked like the deletion had failed.

= 1.49.5 — 2026-08-07 =
* NEW: When you delete a backup from your yedekalma.com panel, the archive stored on this site is now deleted too, instead of being left behind until it expired. The command targets that one archive only: the file is identified by the backup's own download token, the token must already be in the plugin's own download register, the resolved path is confined to the backup folder, and it must be a file — no folders, no patterns, no bulk deletes. Your site files, your other backups and your database are never touched. If the file cannot be deleted the panel keeps its record instead of losing track of it.
* UX: In the exclusion browser, the plugin's own backup folder is now shown as "already excluded" instead of offering an exclude button — it never goes into a backup anyway (an archive is not packed into itself).

= 1.49.4 — 2026-08-07 =
* FIX: The plugin's own backup folder was correctly left out of the backup itself, but it was still counted when measuring the size of your site and when building the file manifest. On a site holding a few large archives this made the reported site size far bigger than the site actually is, and it would have made incremental backups treat those archives as new files every time. The folder is now excluded everywhere.

= 1.49.3 — 2026-08-07 =
* FIX: A scheduled backup could be started again while the previous one was still running, so several full backups ran on the same site at once. Each of them slowed the others down and the same archive could be uploaded twice. The plugin now refuses a second backup while one is in progress and tells yedekalma.com it is busy, so the panel simply waits instead of starting another. On a large site this alone can cut the time a backup appears to take by more than half.

= 1.49.2 — 2026-08-07 =
* CHANGE: The backup schedule now says "Backup hour (from this hour onwards)" instead of implying an exact minute. Backups start at that hour or shortly after — they are spread over a short window so your server is not hit by several jobs at once, and WordPress's own scheduler depends on a visitor arriving. Nothing is skipped; a late backup is retried by itself. The wording now matches what the system has always actually done.

= 1.49.1 — 2026-08-07 =
* FIX: When several sites you back up live on the same physical server, running their backups at the same moment strains that server and one of them can be killed mid-job. The plugin now reports a short, hashed identifier of the machine it runs on (host name only, never sent in the clear), so yedekalma.com can start those backups one after another instead of together. Nothing about neighbouring sites is disclosed, and no setting of yours is changed.

= 1.49.0 — 2026-08-06 =
* FIX: Large sites could never finish a backup started from the yedekalma.com panel. Each slice reopened the archive with PHP's ZipArchive, and closing a ZIP rewrites the whole file — so the cost grew with the archive. On a 70,000 file / 1.7 GB site the final step (adding the database dump to the archive) rewrote all 1.7 GB and was cut off by the host after 60 seconds, every single time, until all eight automatic retries were spent. Panel backups now use the same append-only archive writer the plugin already used for its own backups: every entry is written at the end of the archive, nothing already written is touched again, and finishing the archive only writes the index. The step that used to time out now takes seconds.
* FIX: If a slice was cut off by the host, the panel's next attempt could start a second process writing into the same archive. Slices now take a lock; an overlapping request is turned away instead of corrupting the archive.
* FIX: The database dump was recorded as 0 bytes in the backup's file list.

= 1.48.0 — 2026-08-06 =
* NEW: The plugin can now keep itself up to date. A backup plugin that stays on an old release quietly misses the very fixes that keep backups working, and updating it was something you had to remember to do. Settings → Automatic Update turns WordPress's own updater on for this plugin; from then on new releases install themselves. It is off until you switch it on, it is never enabled behind your back, and it is the same preference WordPress shows on the Plugins screen, so either place can change it.
* NEW: When an update is waiting, the Yedekalma pages and your Dashboard show it with a single button that installs it on the spot. The reminder can be dismissed for that version, and it comes back only when a newer one is released.
* NEW: Sites that update themselves are marked as such in your Yedekalma panel, and the "your plugin is out of date" email now waits for them instead of arriving while WordPress is already installing the update.

= 1.47.0 — 2026-08-06 =
* FIX: After connecting with Google, the plugin briefly showed the "connect your site" screen — the very screen you had just finished with — before switching to the connected one. The connection token comes back in the URL fragment (deliberately, so it never reaches a server log), which means the page is drawn before the site knows it is connected. The page now waits behind a short "connecting…" veil and comes back already connected, with a single confirmation.
* FIX: Removed the 1.2 second pause that was sitting between "connected" and the page reload.
* CHANGE: The plugin listing is now written in Turkish first, with the English description kept underneath. Turkish searches such as "yedek alma" previously returned nothing at all, because every word in the listing was English.

= 1.46.2 — 2026-08-06 =
* FIX: The icon on the "Full Backup" button still sat below its label. The alignment rule added in 1.46.1 was written at the same weight as one of WordPress's own button rules, so on screens where WordPress's stylesheet was written last it simply lost and the icon dropped again. The rule is now specific enough to win outright.

= 1.46.1 — 2026-08-06 =
* FIX: Icons sat slightly too high next to their labels on several screens — in buttons, tabs and section headings. Each screen had been patching this by hand with a different nudge, so the amount of drift varied from page to page. Icon alignment is now defined in one place and every screen uses it.
* FIX: The "delete selected backups" bar put its button and its counter on different baselines when it appeared.

= 1.46.0 — 2026-08-06 =
* NEW: Backups now work on hosts that block outgoing connections. Until now the plugin had to reach the panel itself twice during an upload — once for permission to upload, once to record the finished backup. On a server where outbound HTTPS is restricted, the backup was packed but could never be sent, and the plugin misdiagnosed it as "this storage destination is not supported". The panel now hands both of those over inside the reply to a request the plugin has *already* opened, so your site never has to connect out to us. Interrupted uploads still resume where they left off.
* FIX: The plugin's recorded version was never read when deciding whether it supports a newer protocol, so newer features stayed switched off forever. The version is now confirmed against the running plugin (and refreshed) when it looks out of date — which also happens when you update the plugin from inside WordPress instead of from the panel.

= 1.45.0 — 2026-08-05 =
* FIX: On resource-limited (shared) hosting the backup could be cut short with "503 Service Unavailable — the server is temporarily busy". Each backup step now does less work at a time (8 seconds / 200 files / 32 MB instead of 15 seconds / 400 files / 64 MB), so a single request stays below the host's limit. The backup is split into more, smaller steps and still resumes exactly where it left off. Hosts can tune the limits with the `yedekalma_chunk_budget_seconds`, `yedekalma_chunk_file_cap` and `yedekalma_chunk_byte_cap` filters.

= 1.44.6 — 2026-08-04 =
* FIX: On large sites a backup could restart from scratch on every retry and therefore never finish. A half-finished backup was discarded after 10 minutes, but the panel's third retry arrives later than that. The window is now an hour, so a backup really does resume where it left off.
* FIX: The plugin crashed with a fatal error on hosts where `disk_free_space()` is disabled — both in the diagnostics endpoint and in the free-space pre-check that runs during a backup. The check is now skipped when the host does not provide the function.

= 1.44.5 — 2026-08-01 =
* FIX: The Pro screen showed the "Manage backups" and "Open panel" buttons twice — the page and the asynchronously loaded status block each drew their own copy. Only the page draws them now, so they also appear when the panel cannot be reached.

= 1.44.4 — 2026-08-01 =
* UX: The Pro screen no longer repeats the last few backups. The Backups page already lists them in full — with type, destination, source and restore — so the Pro screen just links there. It also loads a little faster: one fewer request to the panel.

= 1.44.3 — 2026-08-01 =
* FIX: Backups stored in the cloud never showed up in the Backups list. The plugin had always asked the panel for them, but the endpoint did not exist, so the request failed and the empty answer was accepted silently — only archives lying on this server were listed. They are now fetched and shown.
* NEW: A "Destination" column tells you where each backup actually went — Google Drive (with the account), S3 (with the bucket), your own receiver module, or this site's own disk.

= 1.44.2 — 2026-08-01 =
* UX: The status card now shows where the backups are actually sent (Google Drive, S3, your own server, in-domain storage…), right under the backup times. It said "running" and listed the hours, but you had to open the panel to find out the destination. When more than one destination is set, every one of them is listed and marked primary/copy.

= 1.44.1 — 2026-07-31 =
* UX: The Pro screen now names every place a backup can be sent. It listed Google Drive, S3 and FTP only, which left out the simplest destination of all — the server WordPress itself runs on. The intro text, the setup step and the storage box in the diagram now all mention in-domain storage as well.

= 1.44.0 — 2026-07-31 =
* NEW: The Pro screen now explains the optional cloud service before asking you to sign in. When you are not connected it shows what the service does, a diagram of where a backup actually travels (packed and encrypted on your own server, sent straight to your own storage, never through our servers), a three-step setup guide and what connecting adds. Previously there were four bullet points and a sign-in button, so you had to connect first and find out afterwards. All artwork is inline SVG: the screen makes no external requests.
* NEW: The connection screen lists your actual schedule. Files, database and e-mail each show when they are due (for example "Every day 02:00"); you no longer have to open the Yedekalma panel to find out.
* FIX: A component that cannot run is no longer shown with a time next to it. E-mail is archived over IMAP, so with no mail account configured it never runs — yet the schedule still read "Every day 04:00", which looked like mail was being backed up. It now reads that no mail account is defined and is greyed out, matching what the panel reports.

= 1.43.0 — 2026-07-31 =
* UX: The connection screen now tells you two separate things instead of one long sentence. Backup status (is it actually running, when was the last one) and membership status (days left, expiry date, renew) used to be crammed into a single paragraph that was easy to skim past. They are now two side-by-side panels, and the membership panel turns red with a primary "Manage subscription" button in the last seven days, so an expiring subscription is impossible to miss.

= 1.42.2 — 2026-07-31 =
* UX: You can now see which kind of backup is running. "Full Backup" was always drawn as the filled, primary button, so choosing "Database Only" left the screen looking as if a full backup had been started — the right backup was taken, but the screen said otherwise. The button you clicked is now highlighted for the duration of the run and the progress line is prefixed with the backup type at every stage.

= 1.42.1 — 2026-07-31 =
* FIX: Deleting the plugin no longer orphans backups it deliberately keeps. Removing the plugin is meant to leave your archives on disk unless you explicitly opt in to deleting them — but the cleanup was still wiping the records that point at those archives (the download-token map, the backup list and the backup folder name). The files survived while every download link returned 404, so it looked as if all backups had been lost. Those three records are now kept whenever the files are kept; opting in to full deletion still removes everything.

= 1.42.0 — 2026-07-31 =
* PERFORMANCE: Backups are dramatically faster on large sites. The archive is now written by appending each file to the end of it, instead of letting PHP rewrite the whole archive at the end of every step. Rewriting made the cost grow with the square of the site size — on a real 5,502-file site a single step had grown to over two minutes and kept getting slower. That cost is gone: the work is now proportional to the amount of data, once.
* FIX: Backups no longer need roughly twice the backup size in free disk space. The old approach kept a second copy of the whole archive while rewriting it, which is what turned a nearly-full disk into an "archive came out empty" failure. Only the archive itself needs to fit now, and the free-space check was relaxed accordingly.
* FIX: A file is written into the archive the moment it is read, instead of being queued and read later. A file that changed or disappeared between being listed and being packed can no longer end up silently missing from the backup.
* NEW: Archives larger than 4 GB (or with more than 65,535 files) are written with ZIP64 fields, so very large sites produce a valid archive.
* UX: Because finishing a step is now free, steps are short again — the progress console updates continuously and a running backup no longer holds a PHP process long enough to make wp-admin unresponsive.

= 1.41.4 — 2026-07-31 =
* FIX: "Backup archive came out empty" told you nothing. The message now names the most likely cause — no space left in the temporary directory — and reports the free space, the directory and the expected archive size, so you can act on it.
* NEW: Free-space preflight. A backup that cannot possibly fit now stops before packing thousands of files instead of failing at the very last step. Writing the archive keeps a second copy while it is rewritten, so roughly twice the backup size must be free.
* FIX: A failing backup no longer deletes a half-finished archive that another process may still be writing to; this could turn a recoverable hiccup into an "archive is empty" failure.
* FIX: If the temporary archive disappears mid-run (server temp cleanup or a full disk), packing no longer silently starts a fresh archive and produces an incomplete backup — it stops with a clear message.

= 1.41.3 — 2026-07-31 =
* UX: The backup screen now says what it is waiting for. Writing the archive to disk, adding the database dump and computing the SHA-256 signature can each take minutes, and during them the file counter does not move — previously the screen just showed the last file name with a ticking counter, which reads as a frozen system. Each of those steps is now announced before it starts ("Archive is being written to disk…", "Computing integrity signature…"), the headline above the progress bar shows the same thing, and the seconds counter now reads "running…" instead of a bare number.
* UX: Preparation is no longer silent either — the database dump and the file scan are announced as they happen.

= 1.41.2 — 2026-07-31 =
* UX: The star on the "Yedekalma Pro" menu item now sits after the label instead of before it, so the submenu items line up on the left.

= 1.41.1 — 2026-07-31 =
* FIX: On shared hosting a running backup could make the whole WordPress admin unresponsive — pages and plugin uploads would spin forever. Version 1.40.3 let a single backup slice hold a PHP worker for up to 90 seconds plus the archive write, and most shared accounts allow only one or two PHP processes at a time, so admin requests queued behind it. A slice is now capped at 30 seconds, which still removes most of the slow repeated archive writes without blocking your dashboard.

= 1.41.0 — 2026-07-31 =
* REMOVED: The Test Environment (staging) feature has been dropped completely. It cloned your live site into a `/staging` subfolder with a `stg_` table prefix — useful on its own, but unrelated to backup and restore, and it carried a large amount of code and a write-capable surface on your server for no backup benefit. The "Test Ortamı" menu item, its page, the REST endpoint and all clone/teardown code are gone. Existing `/staging` folders and `stg_` tables on your server are left untouched; delete them yourself if you no longer need them.

= 1.40.5 — 2026-07-31 =
* UX: "Settings" has moved to the bottom of the Yedekalma admin menu, so the pages you use daily — Backups, Malware Scanner and Pro — stay at the top.

= 1.40.4 — 2026-07-31 =
* UX: The Backups table is much easier to read — the Domain column is gone (the page only ever shows this site), Start and End have been merged into a single "Created" date, and the full file path no longer stretches the row (it moved into the source badge's tooltip).
* UX: Restore and Download are now icon buttons with a hover label explaining what they do.
* FIX: A backup taken through the panel but stored inside the plugin's own uploads folder was mislabelled as "WP plugin". The source is now decided by the archive's layout rather than by which folder it was found in, and previously mislabelled rows are corrected automatically.

= 1.40.3 — 2026-07-31 =
* PERFORMANCE: Large backups were far slower than they should be. Every slice closed and reopened the archive, and closing a ZIP rewrites it from scratch — so with ~10,000 files the cost grew quadratically and a single slice eventually took over two minutes. Slice size now adapts to the measured cost of the last archive write, cutting the number of full rewrites dramatically.
* FIX: The progress console only printed the last file of each slice, so the counter jumped from 4800 straight to 5200 and the screen looked frozen. Every file added is now logged, and progress is published every two seconds during a slice instead of only at the end.
* FIX: Cancelling a large backup no longer waits for a full archive rewrite; pending entries are discarded immediately.
* FIX: Total byte size is recomputed if it is missing, so a backup started before the upgrade no longer shows "1 MB / 0 B".
* UX: The "Account status" card has been removed from the dashboard — with the quota model retired it only showed an empty column — and the backup card now uses the full width, with a taller log console.

= 1.40.2 — 2026-07-31 =
* NEW: The Backups page now also lists archives found on disk, even when they have no database record — after a plugin re-install, a wiped option or a manual file drop, your existing backups are no longer invisible.
* NEW: Each row now shows where the backup came from — **Panel** (taken through yedekalma.com with the PHP module) or **WP plugin** (taken by this plugin) — and whether it was already registered in the database or was just discovered on disk.
* NEW: A "scanned folders" list on the same page shows exactly which directories were searched, so a missing backup is easy to diagnose.
* FIX: Download, restore and delete now resolve the archive's real path, so backups living outside the plugin's own folder work too. Only paths under a scanned backup root are accepted.

= 1.40.1 — 2026-07-31 =
* FIX: The backup progress console repeated the same file name over and over. Status is polled about once a second while a single slice takes longer, so the unchanged line was re-printed dozens of times — on one large file it filled the whole console. The line is now printed once and refreshed in place with an elapsed-seconds counter, so you can see it is still working rather than stuck.
* NEW: Byte-level progress. The progress line now shows how much has been packed and how much is left (e.g. "2400 / 9699 files · 1.2 GB / 4.5 GB (2.3 GB left)"), plus the size of the file being added. The progress bar itself is now byte-based, so one huge file no longer counts the same as one tiny file.
* UX: "Open Yedekalma panel" buttons now go straight to the login screen instead of the marketing home page.

= 1.24.0 — 2026-07-29 =
* NEW: The plugin now reports a **configuration summary** to the Yedekalma panel, so the panel's **Backup Plan** step enables or locks each component (Files / Database / Mail) based on what you actually set up on your site — exactly like the standalone PHP backup module already did. If you have **not added any email account** on the *Yedekalma Pro → E-posta* tab, the *Mail backup* row is locked in the panel (no more misleading "mail backup" appearing active when there is nothing to back up). Files and the WordPress database are always available. Only counts and masked names are sent — no passwords ever leave your site.

= 1.23.0 — 2026-07-29 =
* IMPROVED: On the **Yedekalma Pro → File System** tab, the folder browser is now open by default (no extra "Browse folders" click) and loads the site root automatically.
* IMPROVED: Excluded paths now show a green "✓ excluded" badge in the browser, both for items you just excluded and for paths already in your exclude list, so you can see at a glance what is left out.
* NOTE: This release also bumps the asset version, so browsers reliably load the latest admin scripts — this ensures the 1.22.x fixes (Pro connect/disconnect returning to the Pro page, and the real backup-status panel) actually take effect. If a previous update looked like it "did nothing", installing 1.23.0 and hard-refreshing (Ctrl+Shift+R) resolves it.

= 1.22.2 — 2026-07-29 =
* NEW: The **Yedekalma Pro** page now shows the real backup status from your cloud panel — *Awaiting payment / not started*, *Expired*, or *Active* — plus the last backup time. Previously the "connected" box alone could give the false impression that scheduled backups were running when payment was still pending.

= 1.22.1 — 2026-07-29 =
* FIX: After connecting or disconnecting your Yedekalma account from the **Yedekalma Pro** page, the browser now returns to the Pro page instead of jumping to the main control panel.

= 1.22.0 — 2026-07-28 =
* REMOVED: Real-time **Instant Backup** (WooCommerce order / post-page change trigger). Each trigger re-packaged the whole component (it was not incremental), which caused heavy CPU, disk and bandwidth load on large sites. Scheduled incremental backups — as often as every few minutes — cover this need efficiently. All related hooks and settings were removed.

= 1.16.0 — 2026-07-28 =
* NEW: One-click Staging (test environment). Clone your live site into a `/staging` subfolder with a separate `stg_` table prefix — all on your own hosting — so you can safely try plugin/theme updates or changes without touching the live site. The clone runs entirely on your server (files copied on disk, database duplicated with `CREATE TABLE ... LIKE` + `INSERT SELECT`), URLs are rewritten serialization-safely, `WP_HOME`/`WP_SITEURL` are set, and the copy is marked noindex. Managed from your Yedekalma panel. Your live site is never modified — only new `stg_`/`staging` are created. WordPress only.

= 1.15.0 — 2026-07-27 =
* NEW: A one-time, respectful review request appears only inside Yedekalma's own admin pages after you have completed at least three successful backups. It never touches the rest of wp-admin, "Remind me later" postpones it for 30 days, and "Already reviewed / Dismiss" hides it for good. It makes no external connection — clicking "Rate" simply opens the WordPress.org review page in a new tab.
* DOCS: Added FAQ answers for restoring a WordPress backup for free, free site migration, malware scanning without a subscription, and recommended backup frequency.

= 1.14.0 — 2026-07-27 =
* NEW: Manual backups now run in the background on your own server — start a backup, then leave the page or switch menus and it keeps going; it automatically resumes tracking when you return, and shows a confirmation dialog and jumps to the Backups page when finished.
* NEW: Backups on disk are auto-recovered — if a backup file exists in your uploads folder but is missing from the list, it is detected and re-added so it stays visible and restorable.
* IMPROVED: Restore now only offers the sections your backup actually contains (a database-only backup offers only "Database", etc.).
* IMPROVED: "Yedekalma Pro" screen clearly reflects that it is the Yedekalma (yedekalma.com) cloud service; its Files/Database/E-mail tabs stay inactive until you connect. Database and e-mail sections now let you auto-discover accounts and test the connection before saving; the exclude-folder browser also lists files.
* IMPROVED: Admin pages no longer hang when your host blocks outbound connections to yedekalma.com (short timeouts + graceful fallback).
* Various UI polish and fixes.

= 1.22.0 =
Real-time Instant Backup has been removed — it re-packaged the whole site on every change and could overload large sites. Use scheduled incremental backups (as frequent as every few minutes) instead.

= 1.15.0 =
Adds a one-time, respectful in-plugin review request (shown only after three successful backups, easy to dismiss, no external connection) and new FAQ entries. Recommended for all users.

= 1.40.0 — 2026-07-30 =
* SECURITY: Hardened the malware-scanner results view against a stored-XSS vector. A maliciously named file (e.g. one containing a quote and an event handler) could break out of an HTML attribute and run script in wp-admin when scan results were rendered. File paths are now fully attribute-escaped (both quotes).
* SECURITY: The restore downloader now pins the validated IP for the actual request (curl CURLOPT_RESOLVE), closing a DNS-rebinding window between the SSRF safety check and the fetch.
* SECURITY: When `AUTH_KEY` is undefined, the at-rest encryption fallback key is now stored outside the database (in a web-inaccessible file) rather than in `wp_options`, so a database dump no longer contains both the ciphertext and its key.

= 1.37.0 — 2026-07-30 =
* NEW: Email (IMAP) restore. A full restore now also re-injects the archived `.eml` messages back into your mailboxes over IMAP (matching each archived account to your configured e-mail account), completing the round-trip started in 1.36.0. Messages are added with `imap_append` and never deleted; a message already present (matched by its Message-ID) is skipped, so restoring twice is safe and never creates duplicates. Missing folders are created automatically. If the PHP `imap` extension is missing or an account can't be reached, e-mail restore is skipped and reported — the file and database restore still complete. (The archived `.eml` files are no longer written into the web root during restore.)

= 1.36.0 — 2026-07-30 =
* NEW: Email (IMAP) backup for panel-triggered backups. When you have configured e-mail accounts in the plugin (Pro → E-mail), a full backup now also archives every folder of every account as `.eml` files (under `eposta/<account>/<folder>/`), just like the files and database. It runs inside the same resilient chunked engine — a few seconds of messages per step — so even large mailboxes finish without timing out, with live progress. Messages are fetched read-only (they are never marked as read and the mailbox is never modified). Each message is scanned for malware; a malicious message is left in the mailbox but kept out of the archive (so your antivirus can't lock the whole backup) and reported. If the PHP `imap` extension is missing or an account cannot be reached, e-mail is skipped and reported — the file and database backup still complete. (One-click e-mail restore from the panel is coming in a follow-up; until then the messages are available as `.eml` files inside the archive.)

= 1.35.0 — 2026-07-30 =
* UX: The "Connection" tab (Pro page) now opens instantly. Previously the page waited 3-4 seconds for two remote calls (backup status + recent backups) before rendering, so the "Connect with Google" screen flashed before the connected view appeared. Those two panels are now loaded asynchronously after the page opens, with a loading spinner in their place, so the connected screen shows immediately and the flash is gone.

= 1.34.0 — 2026-07-30 =
* CHANGE: Local backups are now stored in a per-site, unguessable folder named `YedekAlmaBackup-wp-XXXXXXXX` under `wp-content/uploads/` instead of the fixed, predictable `yedekalma-backups`. This makes a WordPress-panel backup easy to identify and adds a layer of defence (the folder name can no longer be guessed). On update, any existing `yedekalma-backups` folder is renamed to the new name automatically, so your existing backups and download links keep working — nothing is lost. If the rename cannot be performed, the old folder name is kept safely.

= 1.33.0 — 2026-07-30 =
* NEW: Database malware scanning. In addition to scanning files, a backup now scans the high-risk database tables (posts, options, comments and their meta) for injected malicious code — hidden redirect iframes, spam/skimmer scripts and obfuscated PHP/JS — as the database is dumped. Findings are reported to the Yedekalma panel exactly like file findings (the panel's per-domain file/database scan toggles decide what is kept). Scanning is read-only and never alters the dump; it is deduplicated per table and capped so even a very large database adds negligible overhead.

= 1.32.0 — 2026-07-30 =
* NEW: Multiple storage destinations (fan-out). When your Yedekalma panel configures more than one storage target for a domain, a panel-triggered backup is now copied to every target — not just the first. After the primary destination completes, the same archive is uploaded to each additional destination (each gets its own backup record and download/restore entry). A failure on an extra destination never affects the primary backup. This brings panel-driven WordPress backups in line with the standalone PHP module.

= 1.31.0 — 2026-07-30 =
* FIX: Malware scanner no longer flags pristine WordPress core files as threats. Several signatures were too broad and matched the legitimate content of WordPress core (and legitimate plugins), so a clean install downloaded from WordPress.org showed dozens of "threats". Removed or narrowed the offending signatures: (1) the long hex-escape signature that matched crypto/media byte tables (sodium_compat constants, getID3 magic-byte detection like the PNG signature, SimplePie whitespace tables, compat-utf8) is removed — real hex payloads are still caught inside an execution context; (2) the bare `wp_create_user`/`wp_insert_user`/`add_cap`/`wp_roles`/`grant_super_admin` and `add_filter('determine_current_user')` signatures are removed — those are WordPress's own core user/role/auth API used by pluggable.php, user.php, capabilities.php, class-wp-roles.php, user-edit.php and every legitimate membership plugin; genuine rogue-admin injection is still caught by the raw-SQL signatures; (3) the hidden-iframe signature now requires an external `src`, so plupload's upload iframe and WordPress oEmbed no longer match; (4) `strrev(...strrev(...))` reverse-string idioms (getID3 Lyrics3, wp-admin/post.php) no longer match the nested-obfuscation signature; (5) the temp-dropper signature no longer matches core's `require $file; die` bootstrap. Detection of real web shells, compiled binaries in the web root, and `include $x; unlink($x)` droppers is unchanged.

= 1.30.0 — 2026-07-30 =
* UX: Malware scanner results now have a "Show only deletable threats" filter (on by default). Findings that match WordPress core files are protected and cannot be deleted; the filter hides those protected rows so the actionable threats you can actually select and quarantine are shown first, with a small note of how many protected rows are hidden. Toggle it off to see every finding again.

= 1.29.0 — 2026-07-30 =
* FIX: Malware scanner no longer flags the plugin's own files as threats. The scanner's signature table literally contains web-shell family names (c99shell, r57shell, …) and command-parameter patterns, so left-over COPIES of the plugin outside the active folder — WordPress's own wp-content/upgrade/ update staging folder and any trashed/old copies — were being reported as "known web shell / backdoor". The self-exclusion now recognises the plugin's file layout in any location, not just the active plugin directory.
* FIX: Fewer false positives generally. The bare English words "webshell" and "backdoor" were removed from the known-web-shell signature (they appear in legitimate security plugins, comments and documentation; real shells are still caught by their specific family names). The command-parameter signature no longer matches $_POST['pass'] / ['pwd'] / ['code'], which normal login forms and verification/coupon-code fields use — only genuine command params (cmd/exec/payload/execute) remain.

= 1.28.0 — 2026-07-30 =
* DOCS: Refreshed the WordPress.org listing for clarity and search. Corrected the short description (real-time Instant Backup was removed in 1.22.0 and is no longer advertised), gave each supported cloud destination its own line (Google Drive, Dropbox, OneDrive, Amazon S3 / Backblaze B2 / Wasabi / Cloudflare R2 / MinIO, FTP/SFTP), added a dedicated "backup to your own cloud storage" heading, and expanded the FAQ from ~14 to ~30 entries with truthful answers about WooCommerce backups, large (5–10 GB+) sites, hosting compatibility (shared hosting, cPanel, Plesk, DirectAdmin, LiteSpeed, Nginx, Apache), per-section restore (database-only, uploads-only), scheduled and incremental backups, and client-side AES-256 encryption. Tags trimmed to the five most relevant terms (backup, migration, restore, database backup, malware scanner). No functional changes.

= 1.27.0 — 2026-07-29 =
* NEW: "On this server (Domain internal)" storage target support for panel-triggered backups. When you pick this target in the Yedekalma panel, a panel-triggered backup is now stored on the WordPress server itself (in the hardened wp-content/uploads/yedekalma-backups/ folder, using the path chosen by the panel) instead of failing. A permanent, unguessable-token download link (a public REST endpoint guarded by a 32-hex token) is returned so the backup can be downloaded from the panel; the file itself stays behind the folder's Apache deny rules. Cloud and "own server module" targets are unchanged.

= 1.26.0 — 2026-07-29 =
* NEW: Inbound provisioning for egress-blocked sites. Some servers block all outbound connections, so the plugin's handshake (which carries the secure pull key) can never reach the Yedekalma panel — leaving the panel unable to read the database / files / email summary. A new authenticated `provision` REST endpoint lets the panel pull the key **inbound** instead: the panel already holds the site's API token, presents it as a Bearer credential, and receives the pull key + REST pull URL over TLS. No outbound call from the site is required. The token is accepted only in the Authorization header (never a query string), and the endpoint is guarded by the exact API token the panel issued for this site.

= 1.25.0 — 2026-07-29 =
* NEW: Self-healing connection. The 6-hourly heartbeat now sends full site info (including the secure pull_secret + REST pull URL) in the POST body, so a connection that skipped the full handshake (e.g. connected via Google or an older version) is automatically upgraded to a working data-pull channel on the next heartbeat — no manual reconnect needed. The panel can then read the database / files / email component summary directly from WordPress. The secret travels only in the POST body (never a query string) so it never lands in access logs. On plugin upgrade the heal fires immediately on the first admin page load instead of waiting up to 6 hours.

= 1.21.0 — 2026-07-28 =
* NEW: Restore-to-staging. New ep_staging op='restore' + Test Ortamı page "Yedekten Oluştur": builds the /staging copy from a local backup zip (files at root + database_backup.sql[.gz]) instead of cloning live. Extracts files into /staging, imports the dump into the stg_ prefix (original prefix detected from the dump, table names rewritten to stg_), rewrites the backup's embedded URL to the staging URL (serialize-safe), writes staging wp-config + noindex .htaccess. Reuses all ep_staging helpers; on any import error the stg_ tables + /staging are removed (clean rollback). Live site (ABSPATH + live prefix) is never touched. Runs in the background; the page polls status. Phase 1 = local backups; cloud/panel backups to follow.

= 1.20.0 — 2026-07-28 =
* IMPROVED: Instant Backup activation latency. A lightweight 30-minute config-sync cron (yedekalma_config_sync_event, only when connected to the panel) now caches the instant-backup setting, so enabling it in the panel takes effect within ~30 min without waiting for the 6h heartbeat or an admin visit.
* IMPROVED: Content-triggered instant backup (non-WooCommerce sites) now uses component 'all' (files + database, incremental) so newly uploaded media in a post/page is captured too; WooCommerce order-triggered instant backup stays database-only (fast).

= 1.19.0 — 2026-07-28 =
* NEW: Staging (test environment) built into the plugin admin. New "Test Ortamı" submenu → a page to create/open/re-create/delete a `/staging` copy (files + `stg_` DB prefix) of the live site, entirely on the customer's own server, without needing the cloud panel. Uses the same engine (Yedekalma_Rest_Bridge::ep_staging) the panel uses; the long "create" runs in the background (loopback, ignore_user_abort) and the page polls status. WordPress only; live site never modified.

= 1.18.0 — 2026-07-28 =
* NEW: Instant Backup extended to regular WordPress content. On sites without WooCommerce, publishing or updating a post or page triggers an automatic incremental backup within seconds (debounced into a single backup; autosaves, revisions, auto-drafts and trashed items are ignored). Requires the optional Yedekalma cloud service. WordPress only.
* IMPROVED: The one-time in-plugin review request now counts cloud/scheduled/instant backups in addition to local ones, so it shows for connected sites that have real backups rather than only local-mode users.

= 1.17.0 — 2026-07-28 =
* NEW: Real-time Instant Backup for WooCommerce. A new order, an order status change or a completed payment triggers an automatic incremental backup within seconds. Events are debounced/merged so a busy sale period produces a single backup rather than one per order. The backup runs entirely on your own server through the plugin's own engine (in-process, no extra outbound call) and goes to your configured storage; nothing is kept on Yedekalma. Requires the optional Yedekalma cloud service. WooCommerce only.
* The panel shows the option only on WordPress sites (WooCommerce sites see order-based wording; other WordPress sites see content-based wording); non-WordPress connections never see it.

= 1.13.0 — 2026-07-27 =
* NEW: S3-compatible storage target in Yedekalma Pro (Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, MinIO). Client-side AWS SigV4 presigned PUT — scheduled backups upload straight from your server to your bucket. Secret key AES-256 encrypted on your own site; never sent to Yedekalma (zero-data). Path-style toggle for B2/Wasabi/MinIO compatibility.

= 1.12.0 — 2026-07-25 =
* NEW: "Yedekalma Pro" admin menu — a single hub with tabs for Connection, Backup Content (files, database and e-mail/IMAP components; exclude paths with a browsable folder tree; client-side AES-256 BYOK passphrase), Storage Target (your own FTP/SFTP — credentials stored encrypted on your own site, never on Yedekalma), and Scheduling. Scheduled backups run on your own server (WP-Cron) and are sent straight to your own storage; IMAP mailboxes are backed up as .eml files. Zero data is kept on Yedekalma — backup content and storage/e-mail passwords never leave your site.
* NEW: "Connect with Google" — a one-click button links the site to your Yedekalma account through your browser, using Google sign-in on yedekalma.com. Because the whole handshake runs in your browser (not the web server), it works even on hosting that blocks the server's outbound connections. Only your email address (to create/find your account) and the Site URL are used; no Google Drive or other permission is requested. The one-time connection token is returned in the URL fragment (never sent to server logs) and stored encrypted on your own site.
* NEW: Optional, opt-in site registration. A dashboard button lets you register the site with Yedekalma so it appears in your panel; it sends only the Site URL and technical version info (plugin/WordPress/PHP version, locale) and never runs unless you click it. Fully disclosed under readme "External services"; no automatic phone-home (WordPress.org Guideline 6 / KVKK / GDPR compliant).
* SECURITY: Restore-time database search-replace now unserializes option values with `allowed_classes => false`, so a crafted serialized payload inside a restored row can never trigger PHP object injection (POP-gadget) during a migration/restore.
* SECURITY: Upload-limit raising (runtime ini_set and the optional `.user.ini` directive line) now runs only on Yedekalma admin screens and the plugin's own AJAX endpoints instead of on every wp-admin request — least-privilege, and no unnecessary global/site-wide PHP configuration changes. Note that upload_max_filesize/post_max_size are PHP_INI_PERDIR and were never actually changeable via ini_set at runtime; they are handled through .user.ini only.
* HARDENING: Completed strict WordPress.org late-escaping: the admin maximum-upload-limit notice and the PHP-CLI cron command hint now escape their dynamic values (esc_html). Bulk threat-file removal input is now wp_unslash'd and string-cast before path validation.

= 1.11.7 — 2026-07-22 =
* I18N: Completed the English, German, Russian and Arabic interface translations. 69 strings — confirmation dialogs, error messages, progress text and settings labels — previously fell back to the Turkish source text. All five bundled languages are now at 100%.
* I18N: The plugin name and description shown on the Plugins screen are now translatable.

= 1.11.6 — 2026-07-21 =
* DOCS: Rewrote the plugin description, feature list and FAQ.
* ASSETS: Added plugin directory icon and banner images.

= 1.11.5 — 2026-07-21 =
* FIX: Responsive threat table layout. Adjusted column widths and increased action column width to 110px so the protected shield badges fit cleanly without horizontal overflow.

= 1.11.4 — 2026-07-21 =
* FEATURE: Finalized malware scanner enhancements, core protection filters, and uninstall cleanup logic.

= 1.11.3 — 2026-07-20 =
* FEATURE: Custom malware scan protection layout. Integrated granular, detailed reasons for critical files (wp-config.php, active theme assets, root boot scripts, drop-ins, and admin/includes core files) to protect them from deletion, while still allowing the deletion of planted non-core exploits.

= 1.11.2 — 2026-07-20 =
* FIX: Robust option structure mapping. Hardened list rendering and DB option cleanup to support both array and object elements, preventing PHP type-error crashes on page loads and threat file deletions.

= 1.11.1 — 2026-07-20 =
* FIX: WordPress core protection. Added a strict safety check to prevent accidental deletion of critical WordPress files (such as files inside wp-admin, wp-includes, wp-config.php, index.php, etc.) via the malware scanner deletion tool.

= 1.11.0 — 2026-07-20 =
* NEW: Built-in Malware & Virus Scanner. Scan all PHP, JS, and configuration files for code injections, web shells, backdoors, and malicious patterns.
* NEW: Persistent Scan Results. Scanner results are securely saved on your site so they persist across page refreshes.
* NEW: Bulk Actions. Select all or specific detected threat files and delete them collectively with one click.
* NEW: Responsive Threats Table. Improved threats list layout and added responsive container with horizontal scrolling so long paths and patterns fit beautifully on all screens.
* NEW: Security Reminders. Contextual security notices recommend taking a virus scan before taking backups or restoring a backup.
* NEW: Space-saving Tabs UI. Combined vertical backup upload and import sections into a sleek, premium tabbed layout.

= 1.10.4 — 2026-07-20 =
* NEW: Added drag-and-drop local backup file upload zone (.zip, .sql, .sql.gz) with real-time progress bar.
* FIX: Fixed critical bug where restored backups disappeared from the list due to options database caching.
* FIX: Fixed settings loss on restore by correcting options key preservation to 'yedekalma_settings'.

= 1.10.3 — 2026-07-18 =
* WARNING: Added an explicit warning notice to the backup restoration modal to inform users that restoring a backup to a different domain will trigger an automatic site URL/domain configuration update in the database.
* LOCALIZATION: Updated Turkish, English, German, Russian, and Arabic translation files with the new domain warning string and rebuilt the compiled .mo files.

= 1.10.2 — 2026-07-15 =
* NEW: Cleaned settings page to focus on custom language preferences and system info.
* NEW: Made Settings (Ayarlar) page visible in the WordPress left sidebar menu.

= 1.10.1 — 2026-07-15 =
* NEW: Internationalization added with translations for English, German, Russian, Arabic, and Turkish.
* NEW: Added new SVG brand logo and official asset icons.
* FIX: Resolved permission issue with hidden settings page access.

= 1.10.0 — 2026-07-13 =
* SECURITY: The chunked-backup progress state is stored in a transient with a plugin-specific key prefix (yedekalma_chk_) so it can never collide with another plugin's transients.
* SECURITY: The backup encryption passphrase is now encrypted (with the site's AUTH_KEY) before it is written into that transient — it is never persisted in plaintext.
* PERFORMANCE: Bulky per-file backup state arrays (file list, manifest, reference file list) are kept in private system temp files instead of the transient, keeping the option/transient store small.

= 1.9.0 — 2026-07-08 =
* NEW: Multi-channel source size measurement for the cloud "Kontrol Et" (check) flow.

= 1.8.19 — 2026-07-04 =
* COMPLIANCE: PHP `memory_limit`/`set_time_limit` are now raised only inside the specific backup/restore endpoints that need them (via a helper), never as a global default on init.
* COMPLIANCE: Replaced all raw cURL calls with the WordPress HTTP API (`wp_remote_*`); large streaming uploads use the `http_api_curl` hook as recommended.
* COMPLIANCE: Restore-time `wp-config.php` update now uses the WordPress Filesystem API (`WP_Filesystem`) with strict value sanitization; no `.bak` copy is left in the site.
* COMPLIANCE: Renamed the internal notify-card guard constant to use the full `YEDEKALMA_` prefix.

= 1.8.18 — 2026-07-03 =
* FEATURE: Keyset pagination for database dumping to optimize performance on large sites.
* FEATURE: Native .sql.gz compression support for streaming database backups.
* FEATURE: Chunked execution flow for database and file backups.

= 1.8.16 — 2026-07-02 =
* UX: Removed the "Bulut Hesabına Bağlan" (Connect to Cloud Account) link from the admin submenu. The connect page stays accessible from the in-page CTA; only the sidebar menu item is hidden (via remove_submenu_page) to keep the menu clean.

= 1.8.15 — 2026-07-01 =
* COMPLIANCE (Guideline 5): No built-in feature is locked behind an account any more. When no Yedekalma account is connected, the plugin now runs fully in local mode by default — one-click backup (files + database), local/FTP/SFTP targets, download and restore all work with no account. The optional cloud connection only changes where backups are delivered.
* PRIVACY (Guideline 6 / no phone-home): Removed automatic anonymous registration and anonymous heartbeat. The plugin now makes NO external connection unless you deliberately connect the optional Yedekalma cloud service (enter an API token). This matches the "External services" section exactly.
* SECURITY: Hardened the local backup directory (wp-content/uploads/yedekalma-backups) — Apache 2.2 & 2.4 deny rules + index.php/index.html + directory-listing off, and backup archive filenames now include an unguessable random token so the file cannot be reached by direct URL (important on Nginx where .htaccess is ignored). Raw SQL dumps are written only to the private system temp dir and removed after archiving.

= 1.8.14 — 2026-06-30 =
* FIX: Recent/local backup list showed the wrong date & time. Timestamps are stored in the site's local timezone, but the list rendered them through get_date_from_gmt(), which re-applied the UTC offset. Now displayed with mysql2date() (no double conversion) on both the dashboard and the backups list.

= 1.8.13 — 2026-06-30 =
* FIX: Local backup could fail at finalization with "archive could not be opened" when the file list resolved to zero entries (e.g. database-only, or an empty temporary archive). libzip does not write an empty archive to disk, so re-opening it failed. The intermediate and finalize steps now open the archive with the CREATE flag, making the chunked backup resilient.

= 1.8.12 — 2026-06-30 =
* UX: Local backup now runs in time-sliced chunks, so the progress bar advances smoothly file-by-file (it no longer appears stuck at 50% on large sites). Added a "Show details" log panel that shows, in real time, which file is currently being added (n/total).

= 1.8.11 — 2026-06-30 =
* PRIVACY: True client-side BYOK. The backup encryption passphrase is now entered and stored only on your own site (Yedekalma → Connect Cloud → Backup Encryption), encrypted with your AUTH_KEY. It is never sent to or stored on the Yedekalma servers — the key stays entirely with you. Backup/restore/verify read the passphrase locally.

= 1.8.10 — 2026-06-30 =
* FIX: Local backup produced an empty archive ("Yedek arşivi boş üretildi") on sites with many files. ZipArchive keeps a file handle open per added file until close(), so large sites hit the OS open-files limit and close() failed silently. The builder now adds files in batches (close/reopen every 400 files) and verifies close() succeeded. The local backups folder is also excluded from the archive (prevents bloat and self-inclusion).

= 1.8.9 — 2026-06-30 =
* FIX: Local backup could appear stuck at 50%. The archive build now runs without the default time/memory limits (and continues server-side even if the connection drops), a lock prevents duplicate concurrent builds, and the admin progress poller now handles request timeouts/errors (retries, and surfaces the real error instead of freezing).
* HARDENING: Additional output escaping (esc_attr/esc_html) on schedule selects and the notification field; wp_unslash on the restore mode input.

= 1.8.8 — 2026-06-30 =
* COMPLIANCE: Clarified that the plugin is fully functional standalone — local one-click backup, download and restore work with no account and no external service; the Yedekalma cloud service is clearly documented as optional (Guidelines 5 & 6). Updated readme/description and FAQ accordingly.
* FIX: Removed the diagnostic log file written under wp-content/uploads; diagnostic steps now go to PHP error_log() only when WP_DEBUG is on (no predictable, web-accessible log file).
* SECURITY: The temporary wp-config.php safety copy made during a config-restore is now written to the system temp directory (outside the web root) instead of next to wp-config.php, so database credentials are never left in a downloadable file.

= 1.8.7 — 2026-06-30 =
* NEW: Use the plugin without a Yedekalma account. On activation the site is registered anonymously (technical info only — domain & versions, no personal data) so it can back up and restore right away.
* NEW: "Where should backup notifications go?" email field with double opt-in verification and an optional product-updates consent. Entering an email turns the install into a lead; signing up on yedekalma.com later with the same address automatically links this site to your account (no duplicate accounts).
* PRIVACY: Marketing consent is stored separately from transactional notifications; commercial messaging is gated behind explicit opt-in.

= 1.8.6 — 2026-06-30 =
* SECURITY: Real client-side AES-256 backup encryption (BYOK). When a passphrase is set, the archive is encrypted with AES-256 (CBC + HMAC) on your own server before upload and can only be opened with your passphrase. Each encrypted backup is self-verified (decrypt + checksum) before upload, so an unrecoverable archive is never sent. Restore and integrity-check transparently decrypt.

= 1.8.5 — 2026-06-29 =
* INFRA: Panel servers migrated to Turkey (turkticaret infrastructure); data is not transferred abroad (KVKK). Removed unverified certification wording.

= 1.8.4 — 2026-06-29 =
* RELIABILITY: Added a read-only backup integrity verification endpoint (downloads + checks SHA-256, archive and completion marker; never restores), so backups taken via the plugin can be auto-verified.

= 1.8.3 — 2026-06-29 =
* RELIABILITY: Incremental backups now compare real file mtime (not just size), so files whose content changes without a size change are correctly captured.

= 1.8.2 — 2026-06-29 =
* SECURITY: SSRF protection on restore download URLs (https + public-IP only). DATA INTEGRITY: DB dumps now write and verify a completion marker on the plain .sql path too (partial dumps are refused on restore).

= 1.8.1 — 2026-06-29 =
* CLARITY: When the selected storage target is not configured (e.g. "My Own Storage / FTP-SFTP" chosen but no credentials entered), the backup now fails with a clear, actionable message instead of a cryptic "no direct upload" error.

= 1.8.0 — 2026-06-29 =
* CLARITY: Renamed the "Bandwidth" quota to "Backup Quota" (Yedekleme Kotası) with a one-line explanation, so customers understand the monthly quota measures the data our engine packages and sends to your cloud — not the central server's bandwidth.

= 1.7.9 — 2026-06-29 =
* RELIABILITY: Full & files-only backups can now complete on restricted hosts (exec disabled) via chunked, time-sliced processing. Restore transparently handles the gzipped SQL stored inside the chunked archive.

= 1.7.8 — 2026-06-29 =
* RELIABILITY: Chunked database restore now verifies a completion marker and aborts loudly on a truncated/corrupt archive instead of silently applying a partial restore (data-loss protection).

= 1.7.5 — 2026-06-29 =
* COMPLIANCE: Removed all trial-expired premium locking screens and replaced them with non-blocking warning notices, fully complying with WordPress.org Guideline 5 (Trial/Expired Software).

= 1.7.4 — 2026-06-29 =
* SECURITY: Enforced strict Zero-Server-Storage architecture. Restores and backups are now processed strictly client-side or streamed direct-to-cloud; no temporary backup files or SQL dumps are ever cached/stored on the central backup servers.
* COMPLIANCE: Removed the custom updater class to fully comply with official WordPress.org Plugin Guidelines (Section 3: "Plugins may not bypass the update system").
* COMPATIBILITY: Compatibility enhancements and optimization for PHP 8.x and latest WordPress versions.

= 1.5.6 — 2026-06-27 =
* FIX: Restore button is now a progressive-enhanced link — it opens the secure panel login even if admin JavaScript is unavailable, and shows an in-admin confirmation modal when JS is loaded.

= 1.5.5 — 2026-06-27 =
* RENAME: Plugin display name and slug updated to "Yedekalma — Cloud Backup & Restore" (slug: yedekalma), now that domain ownership is verified.
* DOCS: Clarified the Restore Drill description to match the actual weekly integrity verification.

= 1.5.4 — 2026-06-27 =
* UX: "Restore" button now opens an in-admin confirmation modal.

= 1.5.3 — 2026-06-27 =
* NEW: In-admin "Restore" button on dashboard.
* FIX: Escaped translation strings and resolved REST API route permission callbacks.
* RENAME: Renamed plugin display name and slug to avoid WP brand confusion.
* REMOVE: Removed custom updater to comply with WordPress.org guidelines.

= 1.5.2 — 2026-06-25 =
* RESTORE: Added new `/restore-wpconfig` endpoint to update DB details in `wp-config.php` during database restores to a different host.
* RESILIENCE: Bridge URLs migrated to `?rest_route=` format for compatibility with plain permalink sites.

= 1.5.1 — 2026-06-25 =
* INFO: Added notes to Backup Frequency page explaining synchronization with the optional cloud service.

= 1.4.0 — 2026-06-24 =
* SPEED: Added chunked file transfer support via `/zip-batch` (POST) to speed up backups.

= 1.3.0 — 2026-06-24 =
* Support for large sites: added manifest-based file transfer to avoid execution time limits.

= 1.2.1 — 2026-06-24 =
* Folder exclusions and shared hosting permission handling improvements in file bridge.

= 1.2.0 — 2026-06-24 =
* PLUG-AND-PLAY: FTP/SFTP or MySQL credentials are no longer required to take backups.

= 1.1.4 — 2026-06-24 =
* Bandwidth usage indicator widgets added to admin bar and side dashboard panel.

= 1.1.3 — 2026-06-18 =
* New billing model: 1 GB free bandwidth for new accounts.

= 1.0.0 — 2026-06-17 =
* Initial release.
