Portamo Backup

Changelog

1.0.16

• Fixed the most serious bug in this plugin’s history: on many sites a background job could only ever run one step. Every backup, restore, upload and migration advances in small chunks, and each chunk queues the next one. The check that stopped two chunks being queued at once also matched the chunk that was asking — so when the job was driven by the background queue rather than by your browser, the next chunk was never queued and the job simply stopped. It stayed invisible while a tab was open, because the page itself kept the work moving; it showed up as a backup „stuck at 45%” the moment you closed it. Jobs now continue on their own, and a 1.7 GB cloud upload has been carried from start to finish with no browser involved.
• Fixed another plugin being able to take over this one’s job queue. Portamo Backup uses Action Scheduler, the standard WordPress background-task library. Some plugins define its functions themselves, and whichever loads first wins. This plugin was asking only „does this function exist?”, which is true either way — so on those sites it handed every backup to a stranger’s queue, with nothing able to cancel or de-duplicate the work, and the Diagnostics page reported that queue’s numbers as its own. It now confirms the library really is Action Scheduler, names the plugin responsible on the Diagnostics screen when it is not, and falls back to WordPress cron, which is slower but ours.
• Fixed a database-only backup being refused for lack of disk space. The space check sized every run against the most recent backup whatever its type, so a 30 MB database backup was turned away because a 1.7 GB full backup had been taken earlier. It now measures against backups of the same type.
• Fixed a password sent to the REST API being ignored, producing an unencrypted archive. A scripted backup that supplied a password was written in plain text, returned success, and gave no warning. Supplying a password now encrypts the archive. Backups started from the dashboard were never affected.
• Failed backups now say why. A job abandoned after six hours without progress already recorded the reason it stopped — and no screen displayed it, so all you saw was the word „Failed”. The history row now shows the reason, including the setting that most often fixes it.
• A stalled backup is no longer reported as healthy. The dashboard shows „Stalled” when a job has stopped making progress, instead of a reassuring summary of the last one that worked.
• A backup that is running is no longer labelled „None” in the sidebar — it reads „Running”, which is what the rest of the screen already said.
• Finished cloud uploads and migrations no longer linger as phantom „active jobs” for half an hour afterwards.
• Encrypted archives are marked with a lock in the backup list, so an encrypted snapshot is no longer indistinguishable from a plain one.
• Test notifications are unmistakable. The subject carries a [Test] prefix, the first line states that no backup was run, and the figures read „n/a” instead of inventing a plausible archive size. If your server cannot send the message the plugin now says so and quotes the server’s own words, rather than reporting that it was sent.
• After restoring another site onto this one, the dashboard tells you which address will receive failure alerts — that setting arrives with the imported database, and until you change it the alerts go to the other site’s owner.
• The free version can now reach the keep-alive ping URL, in Settings → Advanced. It is what lets a backup finish when no browser is open, and that is not a paid feature.
• Housekeeping can be run on demand from the Diagnostics page, and reports what it removed — or says plainly that nothing needed removing.
• Deleting a snapshot updates the counts in the sidebar immediately, instead of leaving them stale until the next page load.
• Every destructive action — delete, remove all, restore, cancel — now asks in the plugin’s own dialog, naming what will happen and what cannot be undone. Dismissing one never counts as agreeing to it.
• Fixed the import screen describing every archive as a full-site backup. Choosing a database-only file to restore was answered with „this archive contains the COMPLETE site … the current site will be replaced entirely” — the one sentence that tells you what is about to be overwritten, and it was wrong for every archive this plugin has made since the file naming changed. The restore itself always did the right thing; only the warning was wrong. It now names the real contents, and the release will not build if the two copies of that check ever disagree again.
• Fixed a restore of an encrypted backup being reported as a failure after it had worked. The password for the running job was kept in the options table — the very table the restore then replaced with the archive’s copy. The job destroyed its own key halfway through, could not read it back, and filed a completed restore as „restore password no longer available”, blaming your site’s security keys for something the plugin had done to itself. Every byte had been restored correctly. The key now also lives beside the job on disk, where a restore cannot reach it, still sealed and never written in plain text.
• Fixed a restore rewriting the record of restores. The restore log travelled inside backups, so restoring rolled the log back to whatever the archive held: the run that had just finished vanished, the success rate reset, and a database-only restore was listed as a full one. The log is this server’s own record and no longer travels inside an archive.
• Fixed the paid version’s Migration screen filling the page with database errors after an upgrade from the free version. The tables that exist only in the paid version were created behind a check on the version number, and upgrading from free 1.0.16 to Pro 1.0.16 does not change the version number — so they were never created. The check now accounts for which edition is installed.
• Fixed „expires Invalid Date” beside a newly issued migration token. The token was valid; only the expiry was unreadable, because that one screen receives the time in a different format from everywhere else. Dates that cannot be read now say so plainly instead of printing a browser error.
• Fixed a notice in the error log on every admin page. The plugin asked for its own screen list in a way that loaded translations earlier than WordPress 6.7 allows. Nothing was broken by it, but it filled debug logs. The release will not build if the two lists that describe those screens ever stop agreeing.
• Fixed the free version sending you to a screen it does not have. Three places — the restore confirmation, the running-job card and the maintenance page shown while a restore is in progress — told you to set up the keep-alive ping „on the Schedule screen”, which is part of the paid version. Those sentences now say what applies to the version you are running, chosen by whether the screen exists rather than by a separate assumption that could drift from it.
• Fixed buttons and spacing across the admin screens. The bundled stylesheet was a hand-trimmed file that had fallen behind the screens using it, so ninety-odd style rules the markup asked for simply did not exist — most visibly the confirmation dialogs, whose buttons sat jammed together with no padding. The stylesheet is now generated from the screens themselves, and the release will not build if it ever falls behind again.
• Fixed a long restore finishing with every plugin on your site switched off. While a restore is running, the plugin deliberately parks your plugin list and theme to one side and runs with almost nothing active, because the files those settings point at are not on disk yet; it puts them back at the end. The parked copy was kept in a file next to the job, and the housekeeping that clears away abandoned jobs could not tell the two apart — it matched on the file extension alone. The parked copy is written once, early, so after half an hour it looked abandoned and was tidied away. On a short restore nothing happened; on anything over thirty minutes the restore completed, reported success, and left the site with only this plugin running. Housekeeping now recognises the difference, the parked copy stays fresh for as long as the restore is moving, and if it ever does go missing the restore now says so in plain words instead of finishing quietly.
• Fixed links and images breaking when a site is copied into a subfolder. Sites built in a page builder are full of links and image paths typed without a domain, like /about-us — correct while the site owns the root of its domain. Copy it into a subfolder, say localhost/retina, and every one of them points one level too high, at an address that does not exist. Because they carry no domain name, the usual rewriting had nothing to search for and never saw them: one page of a real site held sixty-five, spread across its menu, text, headings and images. These are now moved onto the destination’s folder wherever they are kept — page content, builder layouts and menu items alike. Sites copied between two domains are unaffected, and running a copy twice does not shift them twice.
• Fixed fonts and styling coming out wrong after copying a site to a new address. Page builders — Elementor, WPBakery, Divi, Beaver Builder — do not keep everything in the database: they write finished stylesheets to disk with the full web address baked inside. Those files travelled with the backup still naming the old site, so the copy quietly loaded its fonts from the original address. A browser refuses fonts from another address, says nothing an operator would notice, and falls back to a system typeface — the copied site looked complete and was simply wearing the wrong font. Those stylesheets are now corrected along with everything else.
• Fixed a finished backup not being offered to you for download. Starting a backup from the dashboard’s own window — the one where you pick what to include, which is how most backups are started — built the archive, reported success, and then offered you nothing; you had to find the row in the history list and press Download. Only the toolbar shortcut handed the file over. Both now do. A backup that finishes after you reload the page still waits quietly in the history list rather than starting a download you are not expecting. The archive is also now handed straight to your browser to save, instead of being pulled into the page first — on a real site that meant a multi-gigabyte backup quietly went nowhere, because the page was trying to hold the whole thing in memory. Your browser saves it directly, shows its own progress, and can resume it if the connection drops.
• Large downloads can be resumed, and no longer stop part-way on slower connections. Downloading a multi-gigabyte archive was a single uninterruptible transfer with no time allowance, so on a real connection the server could cut it off before the end — leaving a file of the right name and the wrong size — and any interruption meant starting again from the beginning. Downloads now resume where they left off and are no longer cut short by the server’s time limit.

1.0.15

• Fixed a self-test that could not fail. The Diagnostics self-test claimed to verify that background jobs reach their handler, but it reported success the moment the job was queued and never checked whether anything ran. In fact nothing ever did: the listener was registered on a hook that only fires during REST requests, while background jobs arrive by cron. Every self-test since the feature shipped quietly dead-lettered and filled the Scheduled Actions screen with failures on sites where nothing was wrong. The listener is now always registered, and the check reports honestly — including telling you outright when background jobs are not running on your site, which is the single most useful thing a backup plugin can tell you.
• Fixed backups being reported as failed while they were still working. Action Scheduler declares a job dead after five minutes, and on a large site one chunk — reading, compressing and encrypting a few hundred megabytes — can legitimately take longer. The backup finished correctly, but it was logged as a failure, Diagnostics stayed red, and the job could be handed to a second worker that threw the work away. The window is now widened while a backup or restore is in flight, and returns to the site’s normal setting the moment the queue drains.
• Fixed the paid version’s own files being unprotected during a restore. The plugin refuses to overwrite itself mid-restore — replacing the code that is driving the restore cannot end well — but that guard only recognised the free version’s folder name. On a Pro site it matched nothing. Restoring an older archive onto a Pro site could therefore overwrite the running plugin halfway through. The same gap meant restoring a Pro backup onto a free site left a second, orphaned copy of the plugin on disk that no update channel owns.
• Fixed a storage security check that raised a false alarm. The Diagnostics page reported that the backup folder did not block PHP execution on sites where it plainly did — the check looked for older wording and did not recognise the rule the plugin itself writes. Telling people their backups are exposed when they are not is worse than saying nothing.
• Fixed a restore showing a PHP error instead of a maintenance page. The plugin puts the site into maintenance while a restore runs, but that gate loads with ordinary plugins — and WordPress loads must-use plugins first. On hosts that ship one (Plesk, WP Engine, Kinsta, Cloudways and most managed hosting), a visitor arriving mid-restore could hit a fatal error from a must-use plugin whose files were half-written, before the gate had any chance to run. The restore itself always completed correctly; the site just looked broken while it did. The plugin now also uses WordPress’s own maintenance file, which core checks long before any plugin loads. It lets the restore’s own background requests through, and WordPress discards it automatically after ten minutes, so a crashed restore can never leave a site stuck offline.
• Your licence activation now survives a restore. Restoring a backup rebuilds the options table from scratch, which could take the plugin’s own licence record with it. The record is now set aside before the database is replaced and put back afterwards, so recovering your site no longer costs you your activation.
• The upgrade explainer on the Upgrade screen is now a centred card that matches the pricing cards below it, instead of a left-aligned notice that looked like it belonged to a different page.

1.0.14

• Buying Pro no longer leaves you guessing. Paying does not turn the free plugin into the paid one — the Pro version is a separate download you install over the free one — and until now nothing in the plugin said so. The Upgrade screen now explains the three steps before you buy, and if a licence is active while the site is still running the free version, every Portamo Backup screen shows a panel with a direct download button and a link straight to the upload screen. It disappears on its own once Pro is installed.
• Fixed: notices from the plugin’s own licensing system were being hidden on Portamo Backup screens. The plugin clears other plugins’ notices off its pages to keep the layout clean, and that sweep was too broad — it also removed the message that appears after a purchase telling you where to download the paid version. On the pages a new customer is most likely to open, the one thing they needed to read was missing. Third-party notices are still kept off these screens.
• No changes to backup, restore or migration behaviour in this release.

1.0.13

• Fixed a bug that left files out of every backup this plugin has ever made. Folders were skipped by name, anywhere on the site — so any folder called cache was dropped even when it held program code rather than a cache. WPML is the clearest example: it ships required PHP classes inside a folder named cache, and a site restored without them stops with a fatal error. The same rule removed UpdraftPlus, BackWPup and WP STAGING outright, because those plugins’ own folders are named after their backup directories. Cache and backup folders are still skipped everywhere else, but never inside plugins, themes, mu-plugins or vendor. Backups taken before this release are permanently missing those files — please take a fresh one.
• Why this was not caught sooner: restoring onto the same site hides it completely, because the missing files are still sitting on disk. It only appears when you move a site to a new install, which is the case this plugin exists for. Migration testing now covers it.
• Fixed: a restore that ran longer than 30 minutes had its own maintenance lock released while it was still working, putting a half-restored site back online mid-copy. The lock now tracks whether the restore is still making progress rather than how long it has been running, so it lasts as long as the job does — and still clears itself when a restore genuinely dies.
• Added an unlock button to the „restore in progress” page, for when a restore has died and the site is stuck behind the maintenance screen. It appears only after the restore has stopped advancing for five minutes. It puts the site back online at once but does not cancel the restore — anything still running carries on in the background — and the page says so. Previously the only way out was to wait for the timer or delete a file over FTP.
• Added a wpsb_exclude_dirs filter for folders you want left out of backups. It is ignored inside plugins, themes, mu-plugins and vendor — the same protection as above, so a filter cannot produce a backup that will not restore.
• Fixed (Pro): a cloud destination whose authorisation had expired still showed a green „connected” badge while every upload failed. It now reads „reconnect required” and explains the most common cause — a Google Cloud OAuth app left in „Testing” mode, which revokes its access after 7 days. Genuine network problems and provider outages do not trigger it.

1.0.12

• Fixed a serious bug in the paid version: restoring a backup deactivated every plugin on the site, including this one. While a restore runs, the plugin briefly narrows the active-plugin list to just itself, so that the code driving the restore keeps loading while files are being replaced. That list named the free package’s folder, which does not exist in a Pro install — so WordPress found nothing valid, switched everything off, and the restore stopped with no way to finish or undo itself. The list is now taken from the plugin’s own location, so it is correct in either package. If a restore left your plugins disabled, re-enable this one and use Rollback in the restore history to bring the rest back in one step. The free version was never affected.
• Hardened the same code so a wrong value can never do that again: the plugin now checks that the file it is about to name really exists before touching the active-plugin list, and leaves the list alone if it does not. Doing nothing is always recoverable; switching off every plugin on a live site is not.

1.0.11

• Fixed: a rollback could erase its own paper trail. The safety snapshot taken before a restore included the plugin’s restore-history table, so rolling back rewound that table too — deleting the record of the restore that had just failed, which is the first thing anyone looks at when working out why. The site itself was always restored correctly; only the history was affected. The snapshot now leaves the history table alone. Ordinary backups still include it, so a site moved to new hosting arrives with its history intact.
• Fixed (Pro): a large upload to Google Drive could be abandoned when Drive expired the upload session. Drive discards resumable sessions after a while, and once expired the plugin kept asking a dead session where to resume — which can only ever fail. It now opens a fresh session and re-sends the archive, up to twice, instead of giving up. A restart does mean uploading the file again from the beginning: Drive will not accept bytes sent under a session it has forgotten.
• The „keep this tab open” warning has moved into the progress panel, where it stays visible for as long as the job runs. It used to be a notification that disappeared after eight seconds — easy to miss on a restore that takes an hour, which is exactly when it matters.
• Housekeeping: removed the last heredoc blocks from the codebase, a syntax the WordPress.org Plugin Check tool flags. No behaviour changes — the generated output is byte-for-byte identical.

1.0.10

• The temporary must-use plugin a restore used to install is gone. While a restore was running, the plugin wrote a small PHP file into wp-content/mu-plugins and deleted it again at the end; that file served the „restore in progress” page and kept the restore moving. It now does both from inside the plugin itself, so nothing is ever written outside the plugin’s own uploads folder.
• The „restore in progress” page loads its stylesheet and script as ordinary files instead of writing them into the page, and the licence dialog opener on the Plugins screen is enqueued the way WordPress expects.
• Fixed: the progress bar during a restore could jump backwards — reaching 90%, dropping to around 70%, then climbing again. It reported whichever figure the server sent last, and a tick that arrived without a precise figure fell back to a rough estimate for the current stage. Progress describes work already finished, so it now never decreases.
• Removed a duplicate notification when a restore starts. The confirmation dialog already warns you not to close the tab, and the progress panel is on screen — a third copy of the same message on top of the panel you are trying to read is noise.

1.0.9

• The WooCommerce backup scope is now part of the free version. On a store you can choose „WooCommerce Data” as a fourth scope and get a snapshot narrowed to the tables WooCommerce writes to plus the uploads folder — a much smaller archive when the shop is all you need to move. The order journal, which records orders placed between snapshots and replays them after a restore, remains part of the paid version and is not included in this package.
• The helper scripts that used to sit in the plugin’s bin folder have been removed. Nothing in this package is a web-reachable PHP file any more; every file refuses to run unless WordPress loaded it. The work those scripts did has not gone away — the restore driver now runs inside the temporary must-use plugin a restore installs, and the post-restore URL audit is a proper screen under Settings → Diagnostics.
• Added: Settings → Diagnostics now has a post-restore URL audit. After moving a site between domains it scans every table in the database for addresses still pointing at the old site — including tables belonging to page builders, sliders and SEO plugins, which a restore does not rewrite — and can correct them. It reports first and only writes when you confirm.
• Fixed: the URL rewrite tool could be triggered by a link on another website while an administrator was logged in. It is now a form submission protected against that.
• Housekeeping now removes leftover upload staging files automatically. Restoring from an uploaded archive could leave a copy of it on disk; on a site that had imported a few times this was several gigabytes doing nothing.

1.0.8

• Fixed: the in-page navigation bar listed screens that the free version does not include, so following one of those links reached a permission error instead of a page. The bar now lists only the screens that exist.
• Renamed to Portamo Backup. The previous name overlapped an existing website-preservation service, which could have confused users about who provides what.
• The free version no longer contains any licence check. Features that are not part of this package are simply absent from it rather than present-but-disabled: the paid screens, their menu entries and their form endpoints are all removed from the free build, and nothing in it consults a licence.
• Uploaded archives are now handed to WordPress’ own upload handler instead of being moved by hand, so the platform’s checks and any host-level upload filters apply.
• Restores refuse to write through a symbolic link that would place a file outside the WordPress install, even when the path inside the archive looks legitimate.
• Schedule identifiers arriving from the browser are now validated before being stored or passed to the scheduler.
• Installs that keep their uploads folder somewhere other than the default are now handled correctly everywhere the plugin resolves that path.
• The helper scripts no longer assume a fixed directory depth or a fixed plugin folder name when locating WordPress, so a renamed plugin directory or relocated wp-content no longer breaks a restore.

1.0.7

• Fixed: on a site with an active licence, the free build reported itself as the paid one. It kept the paid menu label and took every paid code path, then stopped with „missing view partial” on screens whose files the free build does not include. Paid behaviour now requires the paid files to actually be present, so this combination simply behaves as the free version.

1.0.6

• Fixed: an upload that kept failing on the same byte range retried forever instead of giving up after five attempts. The resume query reset the attempt counter every time it succeeded, so the counter never climbed past one — a stuck transfer spun as fast as the network allowed, logged the same line dozens of times per second, and grew the debug log into the hundreds of kilobytes.
• Fixed: the delay between retries was calculated and then ignored. A single request kept re-entering the upload immediately, so the intended 5s / 10s / 20s backoff never happened.
• Fixed: the Cloud Debug Log panel had no scrollbar and a long log rendered down over the rest of the page. It relied on a CSS class that is not present in the stylesheet the plugin ships.

1.0.5

• Fixed: external cron services reported the ping as „Failed (timeout)” whenever a backup or upload was running. The ping was in fact succeeding — it answered in 0.6 seconds when idle but took over 40 while pushing a job forward, which is past the 30-second limit services like cron-job.org enforce. Because those services disable a job that keeps failing, a site could quietly lose its scheduled backups. The ping now answers immediately and continues the work after the response is sent.
• Changed: scheduled backups reach cloud storage considerably sooner. Work was capped at 20 seconds per ping because a client was assumed to be waiting; now that the response goes out first, each ping does far more, so a large archive no longer advances in short slices spread across many pings.

1.0.4

• Fixed: a backup could finish perfectly and then never be sent to cloud storage, with nothing written to any log. If the request was interrupted in the moments after the archive was sealed and verified — which on a multi-gigabyte site is exactly when it is closest to the host’s time limit — the completion event never fired, and the housekeeping pass that should have noticed simply discarded the job. That pass now finishes the interrupted job instead, so the upload still goes out.

1.0.3

• Fixed: large cloud uploads to Google Drive were abandoned after a transient error. The query that asks Drive where to resume was sent without a Content-Length header, so Drive answered „411 Length Required” and the upload gave up — with every byte already transferred thrown away. Small uploads never hit the error that triggers this path, which is why it only appeared on multi-gigabyte archives.
• Fixed: upload jobs had no concurrency lock, so two background ticks could process the same transfer at once. One tick could report an upload as failed while the other was still uploading it successfully, and their retry counters overwrote each other. Uploads now take the same lock the backup, restore and migration pipelines already used.
• Changed: a failed resume query no longer counts against the transfer’s retry budget, and no longer ends the upload. It is retried a few times on its own, then the transfer continues from the last known position.

1.0.2

• Fixed: weekly schedules always ran at midnight. PHP’s „this Monday” resets the time to 00:00, so the hour and minute the operator chose were discarded.
• Changed: the Schedule screen’s third option was labelled …