Yedekalma — Backup, Restore, Migration & Malware Scanner

དག་བཅོས་ཉིན་ཐོ།

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

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.