Changelog

Backups no longer run inside the browser's request

Most hosts cut an HTTP request off after 60 to 90 seconds. Every export step ran inside one such request, so on a site large enough for the ZIP or the Drive upload to take longer, the host closed the connection, the browser received an error page instead of a reply, and the screen reported a generic failure. Starting an export now hands the work to a background process on the server. The browser only asks how it is going, so no host timeout can interrupt a backup, however long it takes.

Google Drive uploads resume instead of restarting

The upload is sent in slices that carry their position. If anything interrupts it, the next attempt continues from the exact byte Google last confirmed rather than starting a multi-gigabyte transfer again. No part of the file is ever sent twice.

Progress you can trust, and honest errors

Long stages report in as they work, so the bar keeps moving through a big ZIP or a long upload, and if the process genuinely dies the screen says so instead of spinning forever. A server timeout, a dropped connection and a real failure now read differently, and the result panel no longer announces Success! above a failure, which was its own bug.

Nothing to configure. Existing schedules, destinations and settings are untouched, and scheduled backups were never affected by this bug.

Incremental scheduled backups

Schedule now offers a backup mode: full every time, which is what every install did before and remains the default, or incremental, where each scheduled run archives only the files whose size or modification time changed since the previous backup. On a site with a large media library that turns a nightly backup from hours and gigabytes into minutes and megabytes. The database is always dumped in full, so a restore never replays database changes.

Chains that restore as one

Restoring any incremental backup rebuilds the whole site: the plugin walks back to the last full backup and replays the chain in order, so you pick a date, not a puzzle. A new full backup starts automatically every few runs, when the increments outgrow half the full backup, or whenever the baseline cannot be read, so the fallback is always a larger backup rather than a broken one.

Change detection you can tune

Fast compares size and modification date and suits almost every site. Thorough verifies contents with a checksum, for hosts or deploy processes that rewrite file timestamps and would otherwise make every file look changed.

The update source is no longer a user setting

1.3.0 exposed the repository, release channel, and an access token as fields on the Settings page. Wrong call. Which repository a build updates from is a property of the build, not a preference, and those fields only invited someone to point a production install somewhere arbitrary. What remains is a status block and a check-now button. Forks override it in code instead.

Two descriptions that were false

The Schedule page claimed retention applied only to scheduled backups. It applies to every archive in the folder, manual ones included, so the wording now matches the behaviour. The email field now describes what the report contains.

Help page rewritten

The manual still documented a five-feature plugin. It now covers nine topics, including Drive restores, what retention really deletes, and the Nginx caveat.

Automatic updates from GitHub releases

Installed manually, the plugin had no update source, so a new version could sit unnoticed indefinitely. It now answers for itself: releases are polled, the update appears on the Plugins screen with a working details modal, and a dismissible dashboard banner covers owners who rarely open that screen. The hook is scoped to our own host rather than filtering every plugin's update check.

Branded HTML notification emails

Backup reports were four lines of plain text. They are now a table-based HTML email with a logo, accent colour, status badge, per-destination cards, and action buttons, with a plain-text alternative generated from the same data so the two cannot drift.

Reports that say something

Which schedule fired, what the archive contains, whether the local copy was kept, Drive upload status with a folder link, an explicit failure notice with the reason, the retention policy, and the next scheduled run.

Security

• CR/LF stripped from the sender name, closing mail header injection.
• An invalid accent colour falls back instead of being interpolated into every inline style.
• A private-repo token is attached only to requests targeting the configured repository.
• Release notes are escaped before limited Markdown is reintroduced.

Fixes to the server cron panel introduced in 1.2.0: the trigger URL was not shell quoted, the setup box mixed the schedule and the command together, and the schedule fields rendered full height.

Monthly backups, and more than one frequency at a time

Frequency became a set of checkboxes with independent timers, so a daily and a monthly schedule can run together without resetting each other.

Server cron trigger

A private trigger URL with ready-made crontab, curl, and WP-CLI lines, so scheduling works on sites where DISABLE_WP_CRON is set. It replies "not due yet" when called more often than the chosen frequency.

Custom notification system

Plus fixes: the progress modal printed the current step twice, and the progress bar sat at 100% for the whole Google Drive upload.

The post-restore flow was wrong in two ways: "Finish and log out" never actually logged you out, and the flow landed on the Dashboard rather than on Settings and Permalinks, where a cross-domain restore needs you to go.

Google Drive downloads could stall forever and then time out. Added a stall guard with a clearer timeout error, and truncated downloads are now rejected at download time rather than failing later during the restore.

The release that made restores trustworthy. Seven critical data-integrity bugs were found and fixed:

• Serialized data corrupted on restore, and again in the nested case.
• The SQL tokenizer split statements incorrectly.
• Backups contained duplicated and missing rows.
• Rows were lost from tables with generated columns.
• A Google Drive download could destroy a local backup.
• ZIP write failures were ignored, producing an archive that looked fine.

Security: finalize_restore leaked the admin finalize token. Also in this release: icons bundled locally so there is no CDN dependency, a PHP 8.4 deprecation fixed in the Drive client, the plugin no longer includes its own backups in a backup, and regression test suites were added.

Fixed "Plugin generated N characters of unexpected output during activation", and hardcoded URLs inside plugin and theme source files. Added a file-content URL rewriter that runs during restore, which is what makes a migration survive themes that write the domain into their own files.

Migration coverage hardening. Cross-scheme migration was the root cause behind "WebP broken after restore", and both are fixed here, along with a regression that had been silently reverting earlier fixes.

An architectural change to how restores are staged, plus supporting changes.

A run of fixes and refinements across the export and import paths in the days after the first public release.

The first substantial release: Google Drive integration, scheduling, and the backup manager, together with critical and high-severity security fixes and documented upgrade notes.

Early development. Export, import, and the basic admin screens.