DadsFam Backups

Changelog

1.11.0

• Rewriting the web address is now your choice, not something that just happens to you. Restoring a site always rewrote every mention of the old address in the database to the new one. That is right almost every time — but not always, and there was no way to say no. Restoring a client’s site onto a test install to look at their data, or putting a site back where it came from, both want the database left alone. The Restore window now asks, with the rewrite ticked by default so the common case is still one click.
• Untick it and the database is restored word-for-word as it was dumped, still referring to the site it came from. The log says plainly which of the two happened, so you are never left guessing why links point where they do.
• The site address itself is still always pointed at the install you are restoring onto, whichever way you set that tick. Without it WordPress would redirect every request back to the original site and you would not be able to reach your own copy — that is a lockout, not an option.

1.10.8

• The uploader now adjusts itself to your connection. Piece size used to be worked out from your host’s PHP limits alone, which says nothing about the line the file has to travel down — so on a slow uplink a single 16 MB piece could take minutes, and one blip meant sending all of it again. It now measures the speed it is actually getting and sizes each piece to take about forty seconds: large pieces on a fast line, smaller ones on a poor one, never above what your host accepts or below 1 MB.
• Progress now shows megabytes uploaded, the speed you are getting and roughly how long is left, instead of a bare percentage — and a short panel explains that closing the tab pauses the upload, that nothing is lost if it does stop, and that uploading a backup changes nothing on your site by itself. Closing the tab mid-upload now asks first.
• Fixed: a piece could in principle be written to the wrong place in a resumed upload. The browser sends a piece index alongside the byte offset, and that index was derived from the piece size — so once the size changed mid-upload (on a strict server, or now as it adapts) the index no longer meant what the server would read it as, and a later piece could look like the first one and truncate the file. The server prefers the byte offset, so this could not be reached in normal use, but the index is now simply first-piece or not, which is true whatever the size does.

1.10.7

• Fixed: an encrypted backup could not be uploaded. Importing a .zip.enc file — the encrypted copy the plugin itself puts in your off-site storage — was refused with “That is not a .zip file”. Your own backup was being told it was not a backup. Encrypted backups now upload normally and are unlocked automatically on arrival using this site’s passphrase, the same way a cloud restore already did it. Encryption is detected by reading the file, not by its name, so a renamed backup still works.
• Fixed: housekeeping only ran when a backup finished or when off-site storage was in use. A site with off-site switched off never swept its staging folder, so an interrupted restore or an abandoned upload could sit there indefinitely. It is now hooked to the hourly watchdog that runs on every site regardless of settings.
• The Support tab’s “More from DadsFam” has been rebuilt: every plugin now has its own card, the ones available on WordPress.org are marked, and the guide sites and hosting are listed properly instead of being left out.

1.10.6

• Fixed: the screen did not catch up when a job finished. A backup finishing is not the end of the work — it hands over to an off-site upload that finishes later still, and nothing was watching for that. So the panel could sit on “your backup is on its way off-site” long after it had safely arrived, until you reloaded the page yourself. It now refreshes on its own the moment nothing is running any more, whether that is a backup, an upload, or a download from the cloud.
• The refresh happens exactly once per job and never on an idle screen, so a dashboard you have left open does not reload itself for no reason.

1.10.5

• Fixed: a site whose backups had all gone off-site was told it had none. If your local copies are deleted once they are safely uploaded — the recommended setup — the dashboard could announce “your site is not backed up yet” and ask you to make your first backup, on a site with dozens of them. The cause: the list of what is in your cloud storage is deliberately cleared the moment an upload succeeds, and an empty list was being read as an empty cloud. It now falls back to the upload log, which is always right, and says “checking” while it re-reads.
• Fixed: the guided setup would not go away. Because of the same fault, the first two steps never ticked off, so the “Finish your safety net” panel kept nagging sites that were already fully set up. It now ticks correctly and disappears as it was meant to.
• Fixed: pressing Back Up Now did not visibly change anything. The backup started and the console filled up, but the status panel still said what it said before, so the only way to see it change was to reload the page yourself. It now switches to “Backing up your site now” the instant you press it, and puts itself back if the backup fails.
• The off-site upload progress bar is back. Uploads showed only in the console; there is now a proper bar with the destination and the byte count again, sitting in the off-site panel.
• Fixed: the tiles were counting only what is on this server, so the same screen could say “32 backups you can restore” at the top and “1 ready to restore” just below it. Fixed: the “Off-site copies” tile could read “On this server”, which is the opposite of what it is for.

1.10.4

• Added screenshots to this plugin’s WordPress.org page so you can see what you are installing before you install it.
• Same plugin as 1.10.3 otherwise — no code changed.

1.10.3

• The whole plugin has been redesigned around one question: if your site broke right now, would you be all right? The Dashboard answers it first, in a sentence, in plain English, before a single number — then the detail sits underneath for anyone who wants it.
• The screen no longer reads as white boxes on a white page: a proper masthead with the navigation built into it, cards that sit off the page instead of being outlined onto it, larger type, and colour that always means the same thing — green is safe, amber is worth a look, red needs you.
• The live activity console is now part of the free plugin. The window under the progress bar that shows what the server is actually doing, line by line, while a backup runs — it used to sit in the Pro add-on, which meant anybody on the free plugin watching a long backup had only a bar moving and no idea whether it was working or stuck. That was never right. It is core to how this plugin works and it belongs here.
• It now reports more than it used to: the backup being built, a restore being applied, an off-site upload with its real byte count and percentage, a backup being pulled back down from the cloud, and anything still waiting in the upload queue. A small light in its title bar pulses only while something is genuinely running, so one glance tells you whether the machine is busy or you are just looking at history.
• Fixed along the way: the off-site upload line had silently stopped appearing after off-site storage moved into the free plugin in 1.9.0, because it was still reading an option that nothing writes any more. It works again.
• New: a guided setup that tells you what “finished” looks like. Three steps — make a backup, keep a copy off the server, put it on autopilot — with a progress bar and one button pointing at whichever you have not done. It ticks itself off as you go and disappears entirely once you are properly covered, so it never nags a site that is already safe.
• New: the Dashboard is now six large tiles you press, each showing its own live state with a green or grey dot, instead of six words in a menu bar. Big targets, plain names — “Put my site back” rather than “Restore”.
• New: “If the worst happens” — a plain-English recovery plan built into the plugin. Four things that actually go wrong, each one telling you exactly what to do about it: a broken update, a hack, hosting that has vanished, something deleted by mistake. Written to be read by somebody in a panic.
• Choosing what to back up is now six large tiles that light up when ticked, readable at arm’s length, instead of six small checkboxes.
• Your backups list now shows each backup as its own row card rather than a line in a grid.
• Everything respects your system’s reduced-motion setting.
• Fixed: the Dashboard tab ignored your off-site backups completely. If you had connected Google Drive or OneDrive and let the local copies go, the headline figures still read “0 backups stored” with dashes for the last backup and its size, and there was no sign anywhere on that screen of the copies sitting safely in your cloud storage. The off-site engine itself was working the whole time — it was only the Dashboard that never learned to ask. Those three figures now count every backup you have, wherever it is kept.
• Added: a protection line under the figures that tells you in one sentence whether your most recent backup has actually made it off-site, is still queued to go, or is only on this server.
• Added: an “Off-site backups” panel on the Dashboard listing your five most recent backups and where each one is being kept, so you can see at a glance that the copies are really there without opening the Off-site tab.
• Added: a Support tab. Every way to reach a human, the version and environment details worth quoting when you do, and the handful of checks that answer most questions before they get asked.
• Note for Pro users: the off-site figures on the Dashboard used to be drawn by the Pro add-on, which meant they disappeared for everyone else when off-site storage became free in 1.9.0. They are part of this plugin now. Update DadsFam Backups Pro to 1.6.2 alongside this release.

1.10.1

• Housekeeping for the WordPress.org plugin review. Google Drive and OneDrive came across from the Pro add-on in 1.9.0, and that code had never been through the review checks — it was written for a self-hosted plugin. Every one of its direct network and file calls now carries a plain explanation of why it is there: ranged, resumable transfers and chunked reads of very large archives are the whole reason this plugin finishes where others time out, and neither can be done with the helpers the review normally expects.
• Fixed: the terms and privacy links in the readme pointed at pages that do not exist. They now point at the real privacy policy, which covers both.
• No change to how the plugin behaves. This release is about the paperwork.

1.10.0

• Added: thirteen more things an AI assistant can do for you through an MCP plugin such as WPVibe — thirty in total now. It can delete a backup you point at, hand you a private download link, scan the server for backups it does not know about yet, tell you how much room your backups take and how much disk is left, read and rebuild your schedule when its cron event goes missing, clear the activity log, send a test notification email, test an off-site destination that has started failing, list what is actually sitting in your cloud storage, show the upload queue, and stop an upload or a cloud download that is running.
• Restoring is still deliberately not something an assistant can trigger. Neither is starting a restore by any other indirect route. That stays a decision you make yourself, on purpose.
• Deleting a backup and clearing the log are both marked as destructive and ask for confirmation first, so an assistant cannot quietly throw away the thing you were relying on.
• Download links handed out this way are private and time-limited, exactly like the ones from the Backups screen.

1.9.0

• Off-site backups are now part of the free plugin. Connect Google Drive or OneDrive on the new Off-site tab and every backup gets a second home automatically. One click to connect — no API keys, no developer setup, no license.
• Restore straight from the cloud, free. Lost the server, or let the local copy go to save space? Pick one of your off-site backups and DadsFam pulls it back onto the site for you, then a Restore button appears. Nothing to download to your computer, nothing to re-upload, no filenames to type.
• The restore screen lists your cloud backups as a proper picker rather than a dropdown: the date and time first and large, then where each one is stored, how big it is, whether it is encrypted, and whether it is already on this site. Pick a row and only the questions that actually apply to that backup appear.
• Uploads and downloads run in slices and continue in the background, so a large backup finishes on a slow shared host instead of hitting the PHP time limit — and picks up from the exact byte if the connection drops or you close the tab.
• Fixed: the dashboard widget called a site “not protected” whenever there was no backup on the server — even with recent copies sitting safely off-site, which is exactly the situation deleting the local copy creates. It now counts off-site copies, says plainly when a backup is held off-site rather than here, and reports how many are stored where.
• Added: choose how many backups to keep at each destination, and optionally delete the local copy once a backup is safely off-site.
• Added: six AI abilities covering the new features, so an assistant connected through an MCP plugin such as WPVibe can list your destinations, send a backup off-site, list every restore point, and pull one back down. Restoring is still never exposed to an assistant — that stays a deliberate step you take yourself.
• If you use DadsFam Backups Pro: Google Drive and OneDrive have moved here from Pro, and your existing connections are carried across untouched — nothing to reconnect. Pro keeps Amazon S3, FTP, SFTP, encrypted off-site copies and advanced schedules, and needs updating to 1.6.0 to work with this release. Until you update it, this plugin leaves off-site storage to Pro so nothing is ever uploaded twice.

1.8.3

• Housekeeping release. An older build (1.7.0) was published to WordPress.org by mistake, which would have rolled sites back to code from several releases earlier. This release republishes the current, correct code so everyone lands back on the right version. If you updated and noticed missing features, updating to 1.8.3 restores them.
• No functional changes from 1.8.2 — the code is identical.

1.8.2

• Added: a plain-English “A word about PRO” note in the readme — what stays free, why the optional add-on exists, and what it does. No features were moved behind a paywall.
• Housekeeping: the readme now lists the current WordPress and PHP versions it is tested against, and the “learn more about Pro” link points at the live plugins site instead of a page that had moved. No code changes.

1.8.1

• Hardening: admin actions now fall back to WordPress’ own admin-ajax address if the plugin’s own settings object ever fails to load, so buttons keep working instead of silently doing nothing. No change to what the plugin does day to day.

1.8.0

• Housekeeping release, prompted by the WordPress.org plugin review. Everything the plugin registers inside WordPress — its settings, its scheduled events, its hooks and its classes — now carries a full-length dadsfam_backups name instead of the old short dfb one, so it cannot collide with another plugin or theme on your site.
• Your settings, backup index, history, log and schedule are moved across to the new names automatically the first time the updated plugin loads. Nothing is lost, and your actual backup archives are never touched. A backup that happens to be running mid-update carries on.
• Two things change if you drive the plugin from outside the dashboard. The REST routes move from /dfb/v1/... to /dadsfam-backups/v1/..., and the WP-CLI command changes from wp dfb ... to wp dadsfam-backups .... Update any scripts or monitoring you have pointed at the old ones.
• Add-on hooks were renamed to match (for example dfb_capability is now dadsfam_backups_capability), so DadsFam Backups Pro must be updated to 1.5.0 at the same time. If one is updated without the other, Pro simply stops loading and tells you — nothing breaks.
• Every folder the plugin reads or writes is now resolved in one place through the WordPress functions for the job, which makes the plugin behave correctly on installs with a moved wp-content folder, a custom uploads path, or Windows-style paths.
• Fixed: the Plugin URI in the plugin header pointed at a page that no longer existed.

1.7.1

• New: the dashboard headline stats (Backups stored / Last backup / Last size) can now be enriched by add-ons via a new dadsfam_backups_dashboard_stats filter, so DadsFam Backups Pro can show what is stored off-site alongside what is on this server. On its own the free plugin looks and behaves exactly as before.

1.7.0

• Added: AI assistant support. If you connect an AI assistant to your site through an MCP plugin such as WPVibe, it can now check whether a backup is running, run the health checks, list and verify your backups, read the history and log, start or cancel a backup, and read or change your schedule and settings — all through the WordPress Abilities API (WordPress 6.9 and newer).
• Security: every AI action requires the same permission the plugin’s own screens use, and restoring a backup is deliberately not exposed to assistants — a restore overwrites your live site, so it stays a deliberate action behind the admin screens.
• Note: the AI interface reuses the plugin’s existing REST layer, so the same cooldowns, busy-checks and audit logging apply to an assistant exactly as they do to the API.
• On WordPress versions without the Abilities API, nothing changes and the plugin works exactly as before.

1.6.9

• Fixed: DadsFam Backups PRO was being left out of a restore. Only this plugin needs holding back during a restore, because it is the code doing the work; PRO is a separate plugin and is now copied across like any other, so a restored or cloned site arrives with it in place.

1.6.8

• Fixed: “Restore stalled — the server may be hitting a memory or time limit” while copying files. The time allowed for each step was only being checked between folders, not between files, so a single folder holding thousands of files (any uploads month, or a large plugin) was worked through in one go. That runs past the server’s time limit, the step is killed before its progress can be written down, and the next attempt begins that same folder all over again — so the restore could never get past it. The clock is now checked for every file, and a step that runs out of time stops exactly where it is and carries on from that same file next time.
• Added: if one individual file really is too large to copy within the time a step is allowed, the restore now stops and says what to change, rather than trying it over and over.

1.6.7

• Fixed: the checks that keep a restored site loading were running before the cache was cleared, so they were reading the site’s settings from before the restore. They could therefore leave a genuinely missing plugin switched on, or switch off one that was perfectly fine. The cache is now cleared first.
• Fixed: updating the plugin while a restore was already running could stop that restore with an error. A restore started on an older version now continues safely.
• Fixed: the free disk space a restore asks for was set too high and could turn away a restore that would have completed without trouble. It now asks for what is genuinely needed.
• Fixed: if a file could not be moved into place, the copy no longer removes the existing file first — the file already on your site is left exactly as it was and the problem is reported instead.
• Fixed: the check that spots a file too large to unpack now records each attempt as it happens, so it still works when a request is cut off by the server rather than by PHP.

1.6.6

• Added: before a restore unpacks anything, it now checks there is enough free disk space for the job. Running out of room partway through is one of the ways a file ends up half-written, and a half-written PHP file takes a site down. If there isn’t room the restore refuses to start and says how much is needed, so nothing has been touched.
• Fixed: if a single file in the backup is too large to unpack within the server’s time limit, the restore now stops and explains what to change, instead of quietly trying the same file over and over.

1.6.5

• Fixed: THE cause of restores that finished and then left the site showing a critical error. Unpacking the backup counted a file as done before it had finished writing it, so if that step ran out of time halfway through a file, the next step carried on from the following one – leaving a half-written file behind permanently. A half-written PHP file is a parse error, which takes the whole site down. Files are now only counted once they are completely written and checked, so an interrupted step simply picks the same file up again.
• Fixed: files are now written to one side and moved into place in a single step, both when unpacking and when copying into the site. An interrupted restore can no longer leave a half-written file where a working one used to be.
• Fixed: every unpacked file is now checked against the size recorded in the backup. If anything is short – which nearly always means the server ran out of disk space, or the backup is damaged – the restore stops immediately with a plain explanation, before your site has been touched.
• Fixed: a file that could not be read from the backup, or could not be written, was previously skipped in silence and simply went missing from the restored site. This now stops the restore and says which file and why.
• Added: any file that could not be written during the copy is now listed in the activity log as an error rather than passing unnoticed.

1.6.4

• Fixed: if a backup did not record which database table prefix it was made with, the restored tables were left under the old prefix – WordPress then could not find its own data and showed the installer, which looks exactly like the site needing to be set up again. The prefix is now read from the backup itself when it isn’t recorded, so the data always lands where this site expects it.
• Changed: the notes about files a restore deliberately leaves alone are now summarised in the activity log rather than listed one per file, so the log stays readable on sites with many of them.
• Changed: if a restored site’s theme is missing and the standard WordPress theme isn’t installed either, the site now falls back to whichever theme is available instead of being left without one.

1.6.3

• Fixed: a restore could finish and then leave the site showing nothing but a critical error. The cause was files that WordPress runs on every single request being copied in from the backup – a caching drop-in belonging to a plugin or service that is not on this site will bring the site down before it can even load the dashboard, leaving no way in to undo it. Those files are now left alone.
• Fixed: .htaccess and other server configuration files are no longer copied in from a backup. They belong to the server rather than the site, and one from a different host is a common cause of a blank error page. WordPress rebuilds .htaccess from your permalink settings.
• Fixed: the backup plugin no longer replaces its own files while it is in the middle of restoring, which could interrupt a restore part-way through.
• Added: after a restore, anything the restored database expects but that is not actually on the site is now handled instead of being allowed to crash it. Plugins whose files are missing are left switched off, and if the theme is missing the site falls back to a default one. Every one of these is written to the activity log so you can see exactly what happened and put it right.

1.6.2

• Changed: uploading a backup is now much faster. The plugin reads what your server actually allows and sends the largest pieces it safely can, instead of always sending small ones. On a server set up to allow it this cuts the number of requests dramatically – and since every request has to load the whole of WordPress before it writes anything, that overhead was most of the wait.
• Changed: each piece is now written straight to disk as it arrives rather than being held in memory first, so larger pieces do not increase memory use.
• Added: if a server refuses a piece for being too large (some setups cap this below the PHP settings), the plugin halves the piece size and carries on instead of failing.
• Note: to benefit, your hosting needs upload_max_filesize and post_max_size raised. The plugin adapts automatically either way – it will never send a piece your server cannot accept.

1.6.1

• Fixed: uploading a backup no longer starts again from zero when the connection drops. The upload is now given a name based on the file itself, so choosing the same file again picks up exactly where it stopped instead of throwing away what was already sent.
• Fixed: a brief connection glitch no longer cancels the whole upload and delete what had been received. The plugin now waits and retries the piece, up to six times, with a growing pause between attempts, and asks the server how much it already holds before carrying on.
• Added: pieces are now placed by position rather than counted in order, so a piece that arrives twice after a dropped connection cannot be written twice or land in the wrong place. The file is checked as a whole before it is imported.
• Added: if an upload is left unfinished, what was already sent is kept for three days so it can be resumed, then tidied away automatically.

1.6.0

• NEW: Pick exactly what to restore. The restore window now shows a checkbox for each part a backup contains — Database, Plugins, Themes, Uploads (media library), Other wp-content, and WordPress core — so you can bring back just what you need (say, only your uploads, or only plugins) instead of all-or-nothing. Leave everything ticked for a full restore or clone (behaviour unchanged); untick parts for a surgical restore. Only the parts a given backup actually contains are shown.

1.5.0

• NEW: One-click site cloning. Restoring a backup taken on another site already rewrote every URL to this install automatically — now the flow makes it obvious and effortless. Import a backup from another site and a big “Clone onto this site now” button appears the moment the upload finishes; the restore screen shows exactly which site the backup is a copy of and which address it will be rewritten to, and in the backups list a foreign backup’s action is labelled “Clone here”. No wp-config edits, no search-and-replace plugins — copying a live site onto a staging/test subdomain is genuinely a couple of clicks.
• NEW: A short, plain-English “Copying your live site onto this one?” guide right on the Import panel.
• NEW: “Scan for backups on the server.” Dropped a backup .zip onto the server another way — cPanel File Manager, FTP, or copied from off-site storage? One click finds it, adds it to your Backups list, and it’s ready to restore or clone. The Import panel now also shows the exact folder to drop files into. No more hand-placing …