=== Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma ===
Contributors: kamkactemha
Tags: yedek alma, yedekleme, backup, site taşıma, virüs temizleme
Requires at least: 5.8
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.58.2
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

WordPress yedekleme eklentisi: site ve veritabanı yedek alma, tek tıkla geri yükleme, site taşıma ve virüs temizleme. Tamamen ücretsiz.

== Description ==

Yedekalma, **WordPress yedekleme** işini tek ekranda toplayan **ücretsiz bir yedek alma eklentisidir**. Tek tıkla sitenizin **tam yedeğini** alır — dosyalar *ve* veritabanı — ve aynı ekrandan **geri yükler**. Ayrıca **WordPress site taşıma** (yeni sunucu veya yeni alan adı) yapar ve **virüs / zararlı yazılım taraması** ile bulaşmış dosyaları temizler. Yedekleme, geri yükleme, taşıma ve güvenlik tek eklentide toplandığı için her iş için ayrı bir araca ihtiyacınız olmaz.

Her şey kendi sunucunuzda çalışır. Hesap, kayıt veya API anahtarı gerekmez: kurun, etkinleştirin, **Yedek Al**'a basın. **Yedek dosyalarınız kendi hostingunuzda kalır** ve dilediğiniz zaman ZIP olarak indirebilirsiniz.

= Neler yapar? =

* **Site yedekleme** — tema, eklenti ve yüklemeler dahil tüm dosyalar.
* **Veritabanı yedekleme** — gzip sıkıştırmalı MySQL dökümü (`.sql.gz`), büyük siteler için uygun.
* **Paylaşımlı hostingde çalışır** — `exec()` kapalı ve PHP limitleri dar olsa bile parçalı (zaman dilimli) çalışıp yedeği tamamlar.
* **Artımlı yedekleme** — dosyaların gerçek değişiklik zamanına bakar, değişen dosya asla atlanmaz.
* **Tek tıkla geri yükleme** — veritabanı, eklentiler, temalar ve yüklemeler; ya da yalnızca seçtiğiniz parça.
* **Elinizdeki arşivden geri yükleme** — `.zip`, `.sql` veya `.sql.gz` dosyasını sürükleyip bırakın.
* **Site taşıma / alan adı değiştirme** — geri yükleme sırasında site adresi veritabanında otomatik güncellenir.
* **Virüs tarama** — WordPress çekirdeği, eklentiler ve aktif temada kod enjeksiyonu, web shell ve arka kapı arar; bulunanları toplu silebilirsiniz.
* **Kendi bulutunuza gönderim (isteğe bağlı)** — Google Drive, Dropbox, OneDrive, Amazon S3 / S3 uyumlu, FTP / SFTP.
* **Zamanlanmış otomatik yedekleme (isteğe bağlı)** — günlük, haftalık, saatlik veya birkaç dakikada bir; saklama kuralı ile.
* **AES-256 uçtan uca şifreleme (BYOK)** — parola sitenizden çıkmaz.

Ücretsiz bir **yedekleme eklentisi** arıyorsanız: geri yükleme, taşıma ve virüs taraması dahil hepsi ücretsizdir; hiçbiri "premium" kilidinin arkasında değildir.

= In English =

Yedekalma is a free **WordPress backup plugin** that takes a one-click **backup** of your entire site — files *and* database — and **restores** it again from the same screen. It also **migrates** your WordPress site to a new host or domain and **scans** it for **malware**. One backup plugin covers backup, restore, migration and security, so you do not need a separate tool for each job.

Everything runs on your own server. No account, no sign-up and no API key: install, activate, click **Take Backup**. Your backup archives stay on your hosting, and you can download them as a ZIP at any time.

Looking for a **free backup plugin** that also does migration and malware scanning without a paywall? Yedekalma gives you a full **WordPress backup**, a **database backup**, one-click **restore**, site **migration** and a **malware scanner** in a single plugin — no premium unlock required for any of it.

= Backup =

* **Full backup** — every file (themes, plugins, uploads) plus the complete database.
* **Database backup** — MySQL dump only, gzip compressed (`.sql.gz`) for large sites.
* **Files backup** — site files only, without the database.
* **Works on shared hosting** — chunked, time-sliced backup that finishes even when `exec()` is disabled and PHP limits are strict.
* **Incremental backup** — compares real file modification times, so a changed file is never skipped.
* **Safe storage** — local backups live in a hardened, non-browsable folder with unguessable file names.

= Restore =

* **One-click restore** of the database, plugins, themes and uploads straight from your dashboard.
* **Restore only what you need** — pick just the database, just uploads, just plugins or the whole site.
* **Restore from an archive you already have** — drag & drop a `.zip`, `.sql` or `.sql.gz` file and restore from it.
* **Integrity checked** — a truncated or corrupt archive is refused instead of half-applied, so a bad file can never damage a working site.
* **SHA-256 verification** of every archive before a restore begins.

= Migration =

* **Move your site to a new host** — download the backup, install Yedekalma on the target server and restore.
* **Change domain safely** — site URL and home URL are rewritten in the database automatically during the restore.
* **New database server** — `wp-config.php` credentials can be updated as part of a restore.
* **Clone your website** to a fresh install for disaster recovery or a redesign.

= Malware scanner =

* **Security scan** of PHP, JS and configuration files across WordPress core, your plugins and the active theme.
* Detects **code injections, web shells and backdoors** using malicious-pattern matching.
* **Persistent results** — the scan report survives page reloads, so you can review it whenever you like.
* **Bulk clean** — select detected files and delete them in one click.
* **Core protection** — WordPress core files are shielded from accidental deletion while planted files can still be removed.

= Optional cloud service — backup to your own cloud storage =

Local backup, restore, migration and the malware scanner are complete on their own and never contact an external server. If you also want **off-site backup** copies, you can connect the optional Yedekalma cloud service (see *External services* below) to:

* **Backup to Google Drive** — stream backups straight to your own Google Drive.
* **Backup to Dropbox and OneDrive** — send archives to your own Dropbox or Microsoft OneDrive account.
* **Backup to Amazon S3** and S3-compatible storage — Backblaze B2, Wasabi, Cloudflare R2 and MinIO.
* **Backup to FTP / SFTP** — upload to any FTP or SFTP server you control.
* Run **scheduled automatic backups** — daily, weekly, hourly or as often as every few minutes for busy sites — with retention rules.
* **Table-level incremental database backup** — only the database tables that actually changed are exported, so even very frequent backups stay small and fast; unchanged runs are skipped automatically.
* Encrypt archives with **client-side AES-256 (BYOK)** before they leave your server — the passphrase never leaves your site.

= Languages =

Yedekalma ships with English, Turkish (Türkçe), German, Russian and Arabic translations.

== External services ==

This plugin can optionally connect to the Yedekalma cloud service (an external SaaS) to perform off-site backup and restore operations, package backups for delivery to your own cloud storage, check subscription state, and monitor backup quota. This connection only happens if you choose to use the cloud service (by entering an API token, by clicking the optional "Connect with Google" button, by clicking the optional "register this site" button, or by sending a support request from the Support screen — all described below); the plugin's local backup, restore, migration and malware-scanner features work with no external connection at all.

* **Service URL:** https://yedekalma.com
* **Terms of Service:** https://yedekalma.com/legal
* **Privacy Policy:** https://yedekalma.com/legal#privacy
* **Connect with Google (opt-in):** The dashboard shows an optional "Connect with Google" button. It does nothing unless you click it. If you click it, your browser is sent to https://yedekalma.com where you sign in with Google; Yedekalma then creates or finds your account from your Google e-mail address and links this site (identified by its Site URL) to it. Only your e-mail address and the Site URL are used for this; no Google Drive or other Google data permission is requested, and no site content is sent. A one-time connection token is returned to your site and stored encrypted locally.
* **Optional site registration (opt-in):** The dashboard also shows an optional "register this site with Yedekalma" button. It does nothing unless you click it. If you click it, the plugin sends only your Site URL and technical version info (plugin, WordPress, PHP version and locale) to https://yedekalma.com so the site can be listed in your Yedekalma panel; no site content or personal data is sent. If you also enter a notification e-mail, that address and your marketing-consent choice are sent as well. You can ignore the button entirely and every built-in feature still works.
* **Support form (opt-in, no account needed):** The plugin has a **Yedekalma → Support** screen. It sends nothing until you fill it in and press "Send". When you do, the message you typed, the reply e-mail address and name you entered, the chosen category and your Site URL are sent to https://yedekalma.com so the support team can answer you by e-mail. A separate checkbox — shown ticked, and you can untick it — additionally sends technical details of this installation: plugin, WordPress, PHP and MySQL versions, web server, site language, multisite flag, active theme name, the *number* of active plugins, PHP limits (`memory_limit`, `max_execution_time`, `upload_max_filesize`), whether ZipArchive and `exec()` are available, free disk space, whether the backup folder is writable, whether the site is connected to the cloud service, and the date and count of your local backups. The full list is shown on screen before you send it. No site content, database content, passwords, plugin list or user data is sent, and no Yedekalma account is required to use this form.
* **Data Transmission:** When connected (or after opt-in registration), the plugin sends requests to the Yedekalma API containing your Site URL, active plugin features, backup metadata (such as file lists, sizes, and checksums), and your API token (or anonymous install id) to perform secure backup and restore tasks.

== Installation ==

1. In your WordPress admin, go to **Plugins → Add New**.
2. Search for **Yedekalma**.
3. Click **Install Now**, then **Activate**.
4. Open **Yedekalma** in the admin sidebar.
5. Click **Start without an account** and take your first backup.

Manual installation: upload the `yedekalma` folder to `/wp-content/plugins/` and activate it from the Plugins screen.

== Frequently Asked Questions ==

= WordPress sitemin yedeğini nasıl alırım? =

**Yedekalma → Kontrol Paneli**'ni açın ve **Yedek Al**'a basın. **Tam Yedek** (dosya + veritabanı), **Sadece Dosya** veya **Sadece Veritabanı** seçebilirsiniz. Yedekleme kendi sunucunuzda parça parça çalışır; bittiğinde arşivi ZIP olarak indirebilirsiniz.

= Veritabanı yedeği nasıl alınır? =

**Yedek Al → Sadece Veritabanı** deyin. Sıkıştırılmış bir MySQL dökümü (`.sql.gz`) elde edersiniz; indirebilir veya daha sonra geri yükleyebilirsiniz.

= Yedek alma eklentisi ücretsiz mi? =

Evet. Yedekleme, geri yükleme, taşıma ve virüs taraması hesap açmadan ve ücret ödemeden tam olarak çalışır. İsteğe bağlı Yedekalma bulut hizmeti site dışı (off-site) depolama ekler ve ücretsiz bir başlangıç paketi vardır.

= WordPress site taşıma nasıl yapılır? =

Evet. Yedeği indirin, yeni sunucuda Yedekalma'yı kurun ve arşivden geri yükleyin. Site adresi ve ana sayfa adresi veritabanında otomatik olarak yeni alan adına göre güncellenir.

= Yedekler nerede saklanıyor? =

Varsayılan olarak kendi hostingunuzda, dışarıdan listelenemeyen korumalı bir klasörde ve tahmin edilemez dosya adlarıyla. İsterseniz isteğe bağlı bulut hizmetiyle kendi Google Drive, Dropbox, OneDrive, S3 veya FTP alanınıza gönderebilirsiniz — yedeğin içeriği Yedekalma sunucularında tutulmaz.

= Paylaşımlı hostingde çalışır mı? =

Evet. Yedekleme zaman dilimli parçalar halinde ilerler; `exec()` kapalı olsa ve PHP zaman/bellek limitleri dar olsa bile tamamlanır. Sunucu yoğunluk nedeniyle isteği reddederse eklenti bekleyip kaldığı yerden devam eder.

= WordPress virüs temizleme yapar mı? =

Evet. **Yedekalma → Zararlı Yazılım Taraması** ekranından tarama başlatın: WordPress çekirdeği, eklentiler ve aktif tema PHP/JS ve yapılandırma dosyaları için kod enjeksiyonu, web shell ve arka kapı kalıplarına karşı taranır. Bulunan dosyaları tek tıkla toplu silebilirsiniz; WordPress çekirdek dosyaları yanlışlıkla silinmeye karşı korunur. Virüs temizleme ücretsizdir, hesap açmanız gerekmez.

= Otomatik (zamanlanmış) yedekleme var mı? =

Evet, isteğe bağlı bulut hizmetiyle. Günlük, haftalık, saatlik ya da yoğun siteler için birkaç dakikada bir otomatik yedekleme kurabilir, her biri için saklama kuralı tanımlayabilirsiniz. Tek tıkla manuel yedek her zaman ücretsizdir ve zamanlama gerektirmez.

= Büyük siteleri (5 GB, 10 GB) yedekleyebilir mi? =

Evet. Yedekleme küçük zaman dilimlerine bölünerek ilerler ve veritabanı doğrudan gzip sıkıştırmalı döküme akıtılır; böylece PHP süre ve bellek limitlerine takılmadan tamamlanır. Çok büyük siteler için isteğe bağlı bulut hizmetiyle arşivi hostinginizi doldurmadan doğrudan kendi Google Drive, S3 veya FTP alanınıza gönderebilirsiniz.

= WooCommerce mağazamı yedekler mi? =

Evet. Tam yedek tüm WordPress veritabanını içerir — WooCommerce siparişleri, ürünler, müşteriler ve ayarlar dosyalarla birlikte kaydedilir. Yoğun mağazalarda isteğe bağlı bulut hizmetiyle sık artımlı yedekleme kurup iki yedek arasındaki yeni siparişleri de koruyabilirsiniz.

= Nasıl destek alabilirim? Üye olmam gerekiyor mu? =

Hayır, üyelik gerekmez. WordPress yönetim panelinizde **Yedekalma → Destek** ekranını açın, sorununuzu yazın ve gönderin. Site adresiniz otomatik olarak eklenir; isterseniz PHP/WordPress sürümü ve sunucu limitleri gibi teknik bilgileri de tek tıkla iletebilirsiniz (ne gönderileceğini göndermeden önce ekranda görürsünüz). Yanıt, yazdığınız e-posta adresine gelir — yedekalma.com hesabınız olmasa bile.

= Yedeklerimi Google Drive'a gönderebilir miyim? =

Evet, isteğe bağlı Yedekalma bulut hizmetiyle. Arşiv sunucunuzdan doğrudan **kendi** Google Drive, Dropbox, OneDrive, Amazon S3 / S3 uyumlu veya FTP / SFTP alanınıza aktarılır; Yedekalma bir kopyasını saklamaz.

= Is this backup plugin free? =

Yes. Backup, restore, migration and the malware scanner are fully functional with no account and no payment. The optional Yedekalma cloud service adds off-site storage and has a free tier.

= Is this a good free backup plugin for WordPress? =

Yedekalma is a free WordPress backup plugin that bundles full-site backup, database backup, one-click restore, site migration and a malware scanner — features that many plugins split between free and premium tiers. Everything runs on your own server and needs no account.

= How do I back up my WordPress site? =

Open **Yedekalma → Dashboard** and click **Take Backup**. Choose **Full** (files + database), **Files Only** or **Database Only**. The backup runs in time-sliced chunks on your own server and you can download the archive as a ZIP when it finishes.

= How do I back up my WordPress database? =

Open **Yedekalma → Dashboard**, click **Take Backup** and choose **Database Only**. You get a compressed MySQL dump (`.sql.gz`) that you can download or restore later.

= Can I back up a WooCommerce store? =

Yes. A full backup includes your entire WordPress database — WooCommerce orders, products, customers and settings — together with your files, so your whole store is captured. For very busy stores you can schedule frequent incremental backups through the optional cloud service so new orders are protected between runs.

= Can it back up large sites (5 GB, 10 GB or more)? =

Yes. Backups run in small time-sliced chunks and the database is streamed to a gzip-compressed dump, so large sites finish without hitting PHP time or memory limits. For very large sites, connecting the optional cloud service lets archives stream straight to your own Google Drive, S3 or FTP storage instead of filling your hosting disk.

= Does it work on shared hosting, cPanel, Plesk or DirectAdmin? =

Yes. Yedekalma is a pure-PHP plugin with no server dependencies, so it works on any standard WordPress host — shared hosting, cPanel, Plesk, DirectAdmin or a managed platform. It does not need `exec()`, shell access or SSH.

= Does it work on LiteSpeed, Nginx and Apache? =

Yes. The plugin runs inside WordPress itself and does not depend on the web server, so it works the same on LiteSpeed, Nginx, Apache or any other server that runs PHP.

= Can I use it to migrate my site to a new host or domain? =

Yes. Take a full backup, download the ZIP, install Yedekalma on the target site and restore the archive there. The site URL and home URL in the database are updated for the new domain automatically.

= Can I clone my website for disaster recovery? =

Yes. Take a full backup and restore it onto a completely separate install; the site URL is rewritten for the new domain automatically. Your original site is never modified.

= Where are my backups stored? =

In `wp-content/uploads/yedekalma-backups/` on your own server. The folder is protected from directory browsing and the archive names include a random token, so nobody can guess the URL. If you connect optional cloud storage, backups go to your own Google Drive, Dropbox, OneDrive, S3 or FTP account instead.

= Can I back up to Google Drive? =

Yes, through the optional Yedekalma cloud service. Backups stream directly from your server to **your own** Google Drive; Yedekalma never keeps a copy.

= Can I back up to Dropbox or OneDrive? =

Yes. With the optional cloud service you can send scheduled backups to your own Dropbox or Microsoft OneDrive account.

= Does it support Amazon S3, Backblaze B2 or Wasabi? =

Yes. The optional cloud service supports Amazon S3 and any S3-compatible storage — Backblaze B2, Wasabi, Cloudflare R2 and MinIO. Uploads use a client-side signed (SigV4) request and your secret key is AES-256 encrypted on your own site, never sent to Yedekalma.

= Can I back up to FTP or SFTP? =

Yes. The optional cloud service can upload backups to any FTP or SFTP server you control. The credentials are encrypted on your own site.

= Does it support scheduled automatic backups? =

Yes, through the optional cloud service. You can schedule automatic backups daily, weekly, hourly or as often as every few minutes for busy sites, each with its own retention rules. One-click manual backups are always available for free without any schedule.

= What is incremental backup and does it support it? =

An incremental backup only saves what changed since the last run, so it stays small and fast. Yedekalma compares real file modification times for files and, with the cloud service, exports only the database tables that actually changed — unchanged runs are skipped automatically.

= Can I encrypt my backups? =

Yes. With the optional cloud service you can turn on client-side AES-256 (BYOK) encryption. Archives are encrypted on your own server before they leave it, and the passphrase never reaches Yedekalma.

= How does the malware scanner work? =

It scans PHP, JS and configuration files in WordPress core, your plugins and the active theme for malicious patterns, code injections, web shells and backdoors. Results are saved so you can review them later, and you can delete detected files in bulk. Core WordPress files are protected from deletion.

= How do I restore a WordPress backup for free? =

Open **Yedekalma → Backups**, find the backup you want and click **Restore**. You can restore the database, plugins, themes and uploads separately or all at once. You can also drag & drop a `.zip`, `.sql` or `.sql.gz` archive you already have and restore from it — no account and no payment required.

= Can I restore only the database? =

Yes. When restoring, pick the **Database** section on its own and the rest of the site is left untouched. This is handy for rolling back a bad content change without reverting files.

= Can I restore only the uploads, media or a single component? =

Yes. Restore offers each section your backup contains — database, plugins, themes and uploads — so you can restore just your media/uploads, just plugins or any single part instead of the whole site.

= Is there a free WordPress migration plugin here? =

Yes. Yedekalma migrates your WordPress site to a new host or domain for free: take a full backup, download the ZIP, install Yedekalma on the target site and restore. The site URL and home URL are rewritten in the database automatically, and `wp-config.php` credentials can be updated during the restore.

= How can I scan WordPress for malware without a subscription? =

The built-in malware scanner is completely free and needs no account. Open **Yedekalma → Malware Scanner** and start a scan; it checks WordPress core, your plugins and the active theme for injected code, web shells and backdoors, then lets you delete detected files in bulk while protecting core files.

= How often should I back up my WordPress site? =

For most sites a weekly full backup plus a daily database backup is a good baseline; busy or e-commerce sites should back up daily or more often. You can run a one-click backup any time for free, and the optional Yedekalma cloud service adds scheduled automatic backups with retention rules.

= What happens to my backups if I delete the plugin? =

Nothing. Local archives under `wp-content/uploads/yedekalma-backups/` stay where they are unless you remove them yourself, and anything in your own cloud storage stays there too.

= Türkçe destekliyor mu? =

Evet. Yedekalma tamamen Türkçe arayüze sahiptir: site yedekleme, veritabanı yedekleme, yedekten geri yükleme, site taşıma ve virüs/zararlı yazılım taraması işlemlerinin tümünü Türkçe olarak yapabilirsiniz.

= Is Multisite supported? =

Not in version 1 — a separate plugin instance per site is required. Full Multisite support is on the roadmap.

= Is it GDPR / KVKK compliant? =

Yes. The plugin makes no external connection at all unless you deliberately connect the optional cloud service, and explicit consent is collected for that data transfer.

== Screenshots ==

1. Dashboard — one-click full, files-only or database backup; runs on your own server, no account needed.
2. All backups — one-click restore or download, each with size and SHA-256 checksum.
3. Built-in malware scanner — scan WordPress core, plugins and the active theme for injected code, web shells and backdoors.
4. Settings — interface language and safe uninstall data handling.
5. Optional Yedekalma Pro — connect to schedule off-site backups straight to your own cloud (Google Drive, S3, FTP) with client-side AES-256.

== Changelog ==

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

= 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.

== Upgrade Notice ==

= 1.57.8 =
Hardening: a corrupt or malicious encrypted backup can no longer exhaust memory and kill a restore. Encrypted archives are read frame by frame, and the integrity (HMAC) pass had no upper bound on the declared frame length, so a tampered file could request up to a 4 GB read and crash PHP. The decrypt pass already had that bound, but it runs second, so it was never reached. Both passes are bounded now.

= 1.57.7 =
Restore now lets you deliberately bring back wp-config.php, .htaccess and .user.ini with an explicit checkbox. They stay protected by default - that default is what saves a site whose database credentials or server changed after the backup was taken - but you finally have a supported way to restore them on purpose. The restore result screen also tells you what actually happened: whether those files were protected, and whether the archive could only be verified structurally because the backup carried no SHA-256 record. Fixed: a site whose storage target is a self-hosted "Receiver Module" could never finish a backup, because the plugin did not implement that upload method at all - the archive was built and then the upload step failed. It is implemented now, with resumable chunked upload for large archives.

= 1.57.6 =
Important for recovery: restoring a CLOUD backup from wp-admin always failed with a 403 - the required header was added to only one of the two call sites. Fixed, and both paths now go through a single gate. Also critical: on hosts where the document root is a symlink (common on shared hosting), a restore wrote NO files at all yet still reported "completed successfully" - the site was never repaired and you would only find out on the day you needed it. The root is now resolved, and "the archive had files but none were written" is now an error instead of a success. Restore also verifies transfer length and archive consistency before overwriting your site, exclusion patterns behave identically on every host, and failures on extra storage destinations are finally reported instead of being swallowed.

= 1.57.5 =
Important: on shared hosts that disable PHP functions such as set_time_limit, backups could die with a fatal error in their first second. All remaining unguarded calls are now routed through a single safe gate. This release also stops restore from overwriting wp-config.php and .htaccess - if your database credentials or server changed after the backup was taken, restoring no longer takes your site down. Plus a security fix: the upload-limit tweak that writes .user.ini required no capability check and could be triggered by any logged-in user.

= 1.54.5 =
Critical: your exclusion list was never applied to the backup. The patterns you set under Files worked only on screen - the badge counted them, the "how much will this save?" measurement used them, and the list reported to the panel was correct - but the code that PRODUCES the backup read them from a different record that nothing ever wrote to. The list was therefore always treated as empty and everything you excluded went into the archive anyway. The same fault inflated the reported site size. Measured in the field: the estimate said 9,214 files would be backed up while the backup was processing 16,669 - the ~8.1 GB difference was exactly the data that should have been excluded.

= 1.54.4 =
Critical: two backups could run at once on the same site. The plugin has two backup paths and each used its own run lock, so a scheduled trigger could start a second full backup while the panel was still driving a chunked one - double disk, double CPU, and neither finishing on a constrained server. Both paths now share one lock; whichever starts first wins and the other backs off without disturbing its progress.

= 1.54.3 =
Critical fix for the plugin's own scheduled backup on large sites. Panel-triggered backups moved to the streaming archive writer in 1.49, but backups started by the plugin's own schedule still used PHP's ZipArchive, which rewrites the whole archive on every close - and it was closing every 400 files. On a multi-gigabyte site each round copied the entire archive into a temporary ".part" file next to it; shared hosting cut the request off at 60 seconds, so the copy never finished and the next round started from zero. Both paths now use the streaming writer: entries are appended, never rewritten.

= 1.54.2 =
Large sites could never finish a backup. Two steps read or wrote the whole archive inside a single request: the finished archive was COPIED from the temporary folder to the backup folder, and its SHA-256 was recomputed on every round of the upload handshake. On a 7-9 GB site neither fits in the 60-second window shared hosting allows, so each round restarted from zero - leaving a file that grew and reset forever while the disk filled up. The archive is now moved (same disk, instant, atomic) and the checksum is computed once. Leftovers from interrupted runs are also cleaned up now, even when the session record is gone.

= 1.54.1 =
Archive integrity follow-up to 1.54.0. When a disk or hosting quota fills up, the OS can complete a write only partially; the archive writer treated that as success and the tracked offset drifted from the real file size, which silently corrupts every later entry. Partial writes are now completed, and packaging stops if the data really cannot be written. Encryption also now reports "not enough disk space" instead of blaming OpenSSL.

= 1.54.0 =
Critical backup and restore fixes. Backups: the plugin never verified the archive it produced, so a write error during packaging (full disk, hosting quota, transient I/O) did not stop the run and the damaged file was uploaded looking like a valid zip — you would only find out on the day you restored. Archives are now checked before upload and packaging aborts on the first write error. Restores: the component selection you make in the panel was ignored, so unchecking "Database" still overwrote your live database; the "do not touch this file" list was not applied to the deletion step, so protected paths could be deleted from your site; and a truncated database dump was applied first and rejected afterwards, with no rollback. All are fixed.

= 1.53.3 =
Important restore fixes. Files you chose to KEEP were being overwritten anyway (wp-config.php, .htaccess and uploads were the usual victims), with no warning. Archives made by the standalone module also unpacked into a "dosya/" subfolder instead of your site root, and the database dump was written to the web root where it could be downloaded. Both are fixed.

= 1.53.2 =
Backup integrity fix. If a file could not be read while the archive was being written, it was silently padded with zero bytes: the backup looked successful but that file was empty on restore. Read failures now fail the file loudly instead of corrupting it quietly.

= 1.51.1 =
Fixes a Support form spam trap that browser autofill could trip, which silently discarded the request while the screen said it was sent. Also keeps your "send technical details" choice after a failed attempt, and shows that list in your own language.

= 1.51.0 =
New Support screen under Settings: write to us straight from wp-admin, with your site address filled in and no Yedekalma account required.

= 1.50.12 =
Important: your excluded paths were still being backed up. Update — the exclusion list is now actually read by the backup.

= 1.50.11 =
Narrower right column, wider folder browser, and the suggestion button can no longer wrap onto two lines.

= 1.50.10 =
The folder browser now takes every pixel the pattern box does not need, so folder names stop getting truncated.

= 1.50.9 =
The folder browser is wider — the redundant row label next to it is gone and the space went to the browser.

= 1.50.8 =
The exclusion screen is now two columns on wide screens: browse folders on the left, see the excluded patterns fill up on the right.

= 1.50.7 =
The folder browser no longer claims a folder is "excluded by default" when it is actually being backed up — `.github` was wrongly badged because of `.git`.

= 1.50.6 =
The long "what does the suggestion cover?" list is now a dialog you open when you want it, instead of half a screen of text.

= 1.50.5 =
Leftover files now show the date and time they were created, and the file settings screen is split into two sub-tabs: what gets backed up, and leftover files.

= 1.50.4 =
The leftover-file cleaner now shows every file it found — including the recent ones it protects — and a "Clean anyway" button removes those too, unless a backup really is running.

= 1.50.3 =
One click now excludes everything a WordPress site can safely leave out of a backup — 35 patterns, each with the reason next to it, including WordPress's own upgrade-temp-backup folder that quietly stores a second copy of every plugin and theme.

= 1.48.0 =
Yedekalma can now keep itself up to date: turn on Settings → Automatic Update and new releases install themselves, so your backup plugin never quietly falls behind on fixes.
