=== BackReload – Backup, Restore & Migration ===
Contributors: shiponkarmakar
Tags: backup, restore, migration, ftp, s3
Requires at least: 6.0
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.1.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Backup, restore & site migration. FTP, SFTP, Google Drive, OneDrive, S3 & Wasabi. Encrypted, scheduled, shared-hosting friendly.

== Description ==

https://www.youtube.com/watch?v=3I6Q4O8fT-Q

BackReload is a backup, restore, and migration plugin for WordPress. It backs up your database, uploads, plugins, themes, and the rest of `wp-content` into split zip archives, encrypts them at rest, and uploads them to one or more remote destinations of your choice. When something goes wrong, you can restore your full site — database, media uploads, plugins, themes, and other content — back onto the same site, or onto a different site with automatic URL and path rewriting.

Direct site-to-site **migration** is full-fidelity: it moves the complete site — database, uploads, other content, and plugins, themes, and mu-plugins — so the destination works immediately after the move. Restore and import are full-fidelity too — they bring back plugins, themes, and mu-plugins along with the database and uploads. A fully-compliant, data-only build (no code ever deployed) is available by defining the BACKRELOAD_DATA_ONLY constant.

= Storage destinations =

* **Local Storage**: files written to `wp-content/uploads/backreload/` inside the site itself.
* **FTP**: any standard FTP server.
* **SFTP**: over SSH, using the bundled phpseclib library (pure PHP — no ssh2 extension needed).
* **Google Drive**: your own Drive, connected with your own Google OAuth app.
* **Microsoft OneDrive**: your own OneDrive, connected with your own Microsoft app.
* **AWS S3**: buckets in any AWS region, with full SigV4 signing.
* **Wasabi**: Wasabi-compatible signing built in.
* **S3-compatible**: works with any provider that speaks the S3 API (Backblaze B2, DigitalOcean Spaces, MinIO, and so on).

You can attach multiple destinations to a single backup. Each archive part is uploaded to every destination in turn, with automatic retries on transient failures.

= Restore and migration =

The Restore wizard lets you pick which content to bring back — database, uploads (media), plugins, themes, mu-plugins, and other `wp-content` files. If the backup came from a different site, BackReload rewrites URLs and absolute paths inside the database as part of the restore, including inside serialized values, so the site comes up correctly on the new domain without any manual search-and-replace. 

Maintenance mode can be automatically engaged for the duration of a restore, then turned back off when the work finishes.

= Site-to-site migration via key =

For moving a site to a new host or domain, BackReload ships a direct site-to-site push. The destination site generates a one-time key URL under **Migrate → Receive**. You paste that URL on the source site under **Migrate → Send**, click **Start migration**, and the source builds a backup and streams it to the destination in encrypted chunks over HTTPS. With auto-restore enabled (default), the destination unpacks and applies the backup automatically. One-click migration.

There's no FTP step, no manual download, no shared cloud storage required. Chunked transport with WAF / mod_security tolerance, cross-tick retry caps, table-prefix fixup, and a live progress UI with phase stepper, throughput, and log feed on the source side.

= Multisite =

On a multisite network, BackReload backs up and restores the whole network from Network Admin. Each site also gets its own BackReload, for that site's backups and restores only. You can move a single site out of the network to a standalone WordPress site, or bring a standalone site into the network. Only network admins can use BackReload.

= Encryption =

Archives can be encrypted at rest with AES-256-GCM using a passphrase you set in Settings. The passphrase is required to restore. The encryption layer is fail-closed: a corrupted or tampered archive refuses to extract rather than producing partial output.

= Scheduling =

Multiple independent schedules are supported. Common patterns: a daily database-only backup, a weekly full backup, and a monthly archive backup, each retaining a different number of historical copies.

= Notifications =

Send backup-completion and failure alerts to email, Slack, Discord, Telegram, Microsoft Teams, Google Chat, Pushover, or any custom webhook. Each channel is opted into success and failure events independently.

= Privacy =

The plugin does NOT send analytics, telemetry, or usage data to any external server. The only outbound network traffic is to the storage destinations you configure and the notification channels you opt into. OAuth flows for Google Drive and OneDrive run only when you explicitly start them.

== External services ==

BackReload does not phone home and has no servers of its own. It only contacts an external service when **you** configure that service as a backup destination or notification channel, or when you start a site-to-site migration. Nothing below is contacted out of the box. For each service, the data sent is your backup/restore content and the API requests needed to store or retrieve it, sent only while the relevant backup, restore, import, or migration is running.

**Google Drive (Google Drive API)** — Used only if you add a Google Drive destination. You provide your own Google OAuth application (Client ID/Secret). BackReload exchanges the OAuth authorization code for access tokens and then uploads, lists, and downloads your backup files in your Drive. Endpoints: accounts.google.com, oauth2.googleapis.com, www.googleapis.com. Terms: https://policies.google.com/terms · Privacy: https://policies.google.com/privacy

**Microsoft OneDrive (Microsoft Graph API)** — Used only if you add a OneDrive destination. You provide your own Microsoft (Azure AD) application. BackReload exchanges the OAuth code for tokens and uploads/lists/downloads your backup files. Endpoints: login.microsoftonline.com, graph.microsoft.com. Terms: https://www.microsoft.com/servicesagreement/ · Privacy: https://privacy.microsoft.com/privacystatement

**Amazon S3 (AWS)** — Used only if you add an Amazon S3 destination, with credentials you provide. BackReload uploads/downloads/lists backup archives in your bucket via the S3 REST API at `s3.<region>.amazonaws.com`. Terms: https://aws.amazon.com/service-terms/ · Privacy: https://aws.amazon.com/privacy/

**Wasabi** — Used only if you add a Wasabi destination, with credentials you provide. BackReload uploads/downloads backup archives to your bucket via the Wasabi S3 REST API at the regional endpoints `s3.wasabisys.com`, `s3.us-east-2.wasabisys.com`, `s3.us-central-1.wasabisys.com`, `s3.us-west-1.wasabisys.com`, `s3.eu-central-1.wasabisys.com`, `s3.eu-west-1.wasabisys.com`, and `s3.ap-northeast-1.wasabisys.com`. Terms: https://wasabi.com/legal/terms-of-use · Privacy: https://wasabi.com/legal/privacy-policy

**Other S3-compatible storage** — If you add an "S3-compatible" destination (e.g. Backblaze B2, DigitalOcean Spaces, MinIO, or another provider), BackReload connects only to the endpoint and bucket you enter, using credentials you provide, to upload/download your backup archives. The applicable terms and privacy policy are those of the provider you choose.

**FTP / SFTP servers** — If you add an FTP or SFTP destination, BackReload connects only to the host you specify, with credentials you provide, to upload/download your backup archives. The applicable terms are those of that server's operator.

**Site-to-site migration** — Used only when you start a migration. BackReload connects to the other WordPress site you target (the one whose one-time key URL you paste) and streams the backup directly between the two sites over HTTPS. No third-party or BackReload server is involved.

**Notification channels** — If you enable a notification channel, BackReload sends a short backup-status message (success/failure, site name, basic stats) to the endpoint you configure, only when a backup completes or fails. Channels and their providers: Slack (https://slack.com/terms-of-service · https://slack.com/trust/privacy/privacy-policy), Discord (https://discord.com/terms · https://discord.com/privacy), Telegram (https://telegram.org/tos · https://telegram.org/privacy), Microsoft Teams (https://www.microsoft.com/servicesagreement/ · https://privacy.microsoft.com/privacystatement), Google Chat (https://policies.google.com/terms · https://policies.google.com/privacy), Pushover (https://pushover.net/terms · https://pushover.net/privacy), and any custom webhook URL you provide (terms/privacy of that endpoint's operator). Email notifications are sent through your own WordPress site's mail, not a third party.

== Source code and build process ==

The admin interface is a React + TypeScript application compiled with Vite, and the minified production bundle ships in `assets/dist/`. To keep the plugin fully reviewable, the complete, human-readable source is included in the published package and can also be rebuilt from scratch:

* The unminified front-end source lives in the `src/` directory (included in this plugin).
* Build/tooling config: `package.json`, `vite.config.ts`, `tsconfig.json`, `tailwind.config.js`, `postcss.config.js`.
* PHP library dependencies are declared in `composer.json`.

To rebuild the compiled JavaScript/CSS in `assets/dist/` from source:

1. `npm install`
2. `npm run build`

To install the bundled PHP libraries (phpseclib, used for SFTP):

1. `composer install`

== Installation ==

1. Upload the plugin folder to `/wp-content/plugins/backreload/` or install from the WordPress Plugins screen.
2. Activate **BackReload** in **Plugins → Installed Plugins**.
3. Open the plugin from the WordPress admin sidebar.
4. Visit **Destinations** to attach at least one storage location (Local Storage is created by default).
5. Optional: open **Settings** to enable encryption, configure exclusions, and set the compression level.
6. Optional: open **Schedule** to set up daily, weekly, or monthly automated backups.
7. From the **Dashboard** or **Backups** page, click **Backup now** to create your first backup.

== Frequently Asked Questions ==

= Does this work on shared hosting? =

Yes. The backup engine is tick-based: it does a small amount of work on each cron tick rather than holding a long-running request. This keeps memory and time per request well within shared hosting limits.

= How large can my site be? =

The engine streams files into zip parts and uploads each part as it finishes, so disk and memory use stay bounded regardless of total site size. The largest single zip part is auto-tuned to roughly 80% of your PHP `memory_limit` (capped between 200 MB and 1 GB).

= Can I restore a backup to a different domain? =

Yes. The Restore wizard detects that the source domain doesn't match the destination domain and runs an automatic URL/path rewrite during restore. Serialized values are walked safely.

= My backups are encrypted. What happens if I lose the passphrase? =

You will not be able to restore them. There is no recovery mechanism. That's the entire point of encryption. Store your passphrase in a password manager.

= Can I import a backup from another WordPress site? =

Yes, three ways:
1. Upload the backup parts via **Backups → Import**.
2. Drop the part files into `wp-content/uploads/backreload/backreload-import/` on the server and use **Server folder** import.
3. Configure the same storage destination on both sites and use **Import → From destination** to bring it across (no upload required).

= Does the plugin send data to a third party? =

No. The plugin only contacts storage destinations and notification channels that you explicitly configure. There is no telemetry.

= Does restore bring back my plugins and themes? =

Yes. A restore, import, or site-to-site migration brings back plugins, themes, and mu-plugins along with the database, uploads (media), and other `wp-content` files, so the site works immediately afterwards. The Restore wizard lets you untick any of these if you only want part of a backup. BackReload's own backup storage is never wiped, and the copy of BackReload running on the site is never replaced by the one inside the backup. If you prefer a data-only setup where code is never restored, define `BACKRELOAD_DATA_ONLY` as `true` in `wp-config.php`.

= Does BackReload support WordPress multisite? =

Yes. In Network Admin, BackReload backs up and restores the whole network, and every site keeps its own address. Each site also has its own BackReload, which works on that site only: its own backups, restores, and schedules. Only network admins can use either one. You can move a single site out of a network into a standalone WordPress site (Network Admin → BackReload → Sites → Move out). You can also bring a WordPress site into any site of the network with Receive, or by restoring its backup there. Users are matched by email, and only plugins and themes the network doesn't have are added. Moving a whole network to a different domain is not supported yet.


= What happens when I uninstall the plugin? =

Uninstalling deletes all plugin settings, custom database tables, scheduled cron events, and transients. The backup archive files inside `wp-content/uploads/backreload/` are NOT deleted. Those are your data and survive the uninstall in case you want to reinstall later. Delete that folder manually if you want a fully clean removal.

== Screenshots ==

1. Dashboard — backup health, storage used, success rate, next scheduled run, and a live backup-progress panel.
2. Backups list — every backup with its type, size, duration, destination, and status, plus filter, sync, and import controls.
3. Import a backup — bring in a backup by uploading its parts, scanning a server folder, or pulling it from a connected destination.
4. Restore wizard, step 1 — choose which backup to restore.
5. Restore wizard, step 2 — pick the content to bring back: database, uploads (media), plugins, themes, and other files.
6. Restore wizard, confirm — review the restore and choose Replace (roll back exactly) or Merge (keep newer files).
7. Site-to-site migration — the destination site generates a one-time key URL to receive a push.
8. Site-to-site migration — the source site pastes the key and streams the backup directly to the destination.
9. Schedule — combine independent hourly/daily/weekly/monthly schedules, each with its own backup type, retention, and destinations.
10. Storage destinations — Local, FTP, SFTP, Google Drive, OneDrive, AWS S3, Wasabi, and S3-compatible providers.
11. Activity log — searchable, downloadable per-backup log of every step.
12. Notifications — email, Slack, Discord, Telegram, Microsoft Teams, Google Chat, Pushover, or a custom webhook.
13. System health check — PHP, WordPress, and the extensions the plugin needs (ZipArchive, OpenSSL, cURL).
14. Maintenance mode — a branded "be right back" page that can auto-enable during a restore.

== Changelog ==

= 1.1.0 =
* New: multisite support. In Network Admin, BackReload backs up and restores the whole network. Each site in the network also has its own BackReload, which works on that site only: its own backups (database and media), restores, and schedules. Only network admins can use either one.
* New: Network Admin → BackReload → Sites lists every site in the network, with shortcuts to each site's backups, Receive, and Move out.
* New: move a single site out of a network. Use Move out (or pick a site under Migrate → Send in Network Admin) to send it to a standalone WordPress site. Only that site's tables, its members, and its media go across, and media links are rewritten to the new address.
* New: bring a WordPress site into a network. Use Receive in a site's own BackReload (the main site included), or restore or import a single-site backup there. That site is replaced, and the rest of the network is left alone. Users are matched by email: existing accounts are kept unchanged, and new ones are added with their passwords. Plugins and themes the network doesn't have are added; existing ones are kept.
* A whole-network backup restores only in Network Admin, and every site keeps its own address. A site's backup can't overwrite the network or another site.
* Backups, schedules, and the backups list each belong to either the network or one site, and each screen shows only its own.
* WP-CLI: `wp backreload create` on a network backs up the whole network. Add `--site-only` to back up only the main site.
* Deactivating BackReload across the whole network now clears scheduled events on every site.
* Deleting a site from the network also removes its BackReload tables.
* Permalinks after a restore are now your choice. A restore checks whether the server's .htaccess has WordPress's permalink rules (without them, pages other than the homepage show "Not Found") and, when they are missing, shows "Fix permalinks" — one click does exactly what Settings → Permalinks → Save Changes does, and nothing else in the file is touched. BackReload no longer edits .htaccess by itself; 1.0.23 did this automatically.

= 1.0.23 =
* Fixed: on sites using "Plain" permalinks, the Restore and Backups pages could fail with "No route was found matching the URL and request method", and log, import-source, download and migration-status requests could fail the same way. On those sites WordPress's API address already contains a "?", and the plugin was adding a second one. Requests are now built correctly for every permalink setting.
* Fixed: a restore or import that included plugins could stop at "Restoring plugins from plugins-1.zip" and fail. The plugins archive contains the source site's own copy of BackReload, and the restore was extracting it over the BackReload that was running the restore, replacing its files mid-run (often with a different version). The running copy of BackReload is now always kept and the backed-up one is skipped; every other plugin is restored as before.
* The Restore page now reopens the progress screen of a restore that is still running, after you reload the page or come back to it later. Before, it went back to "Choose backup" while the restore and maintenance mode carried on unseen.
* Restore completion is now also confirmed from the restore's own server-side progress record, not only from the log.
* The firewall panel ("allow past this site's firewall") is now on the Restore and Backups pages as well as Migrate (on Restore and Backups only while the exemption is not allowed), with the no-firewall alternatives (Server folder and From destination import) listed.
* Fixed: enabling the firewall exemption while the site was in maintenance mode was wrongly reported as rejected by the server (maintenance mode answers HTTP 503). The check now compares against how the site answered before the change. When an existing exemption is kept, the message no longer says it was removed.
* Fixed: clicking "Start restore" while a restore was still running (for example during a long plugin or uploads extraction) started the whole restore over, wiping and re-extracting folders it had already restored. A running restore is now detected and the page shows its progress instead. A restore with no progress for 30 minutes is treated as stopped, so a failed one never blocks a retry.
* Fixed: a duplicate background step could clear a running restore's saved progress, so its next step started from scratch. It now leaves the running restore alone.
* The restore log now shows "Restoring uploads…" and the folder-wipe result as soon as each step starts, so a long extraction no longer looks frozen at the previous step.
* Fixed: after restoring a site that uses pretty permalinks onto one without WordPress's rewrite rules in .htaccess (for example a site that had Plain permalinks), inner pages returned "Not Found" until Settings → Permalinks was saved. The restore now does that step itself, using WordPress's own function: it writes only the standard "# BEGIN WordPress" block and leaves the rest of .htaccess alone.
* Fixed: "Remove exemption" left an empty "Backreload Import Compat" block in .htaccess, and the firewall panel then still showed "Allowed". The block is now removed completely, and the panel shows "active" only when the rules are really in place.
* Fixed: on sites with a persistent object cache (Redis or Memcached, common on LiteSpeed hosts), a restore to the same site could leave WordPress using cached pre-restore users and roles, so wp-admin showed "Sorry, you are not allowed to access this page". The object cache is now cleared after every database restore.
* Fixed: the database backup included every table in the database, including other WordPress installs sharing it. On restore, the wrong install could be chosen and its tables renamed onto the site's own, mixing two sites' data and leaving wp-admin at "Sorry, you are not allowed to access this page". Backups now contain only the site's own tables. When restoring an older backup that holds several installs, BackReload restores only this site's (or the one that made the backup) and skips the others' tables.
* After every database restore, BackReload now checks that WordPress can find its user roles. If they were saved under another table prefix, it renames them automatically, so admins keep access without editing the database.
* Fixed: site-to-site migration to a site using Plain permalinks failed, because the sending site always used the /wp-json/ address. New keys carry the destination's real API address, and older keys fall back automatically.
* New: if a restore stops because the host ended the request, the Restore page shows "The last restore stopped" with Resume (continues from the last checkpoint) and Turn off maintenance mode.
* Backup uploads from the browser are now sent as compressed binary instead of base64 text, which server firewalls often block with "406 Not Acceptable".
* Fixed: a migration arriving while a restore was running could take over the restore's progress; it is now refused and reported. A restore that fails in its first step now also turns off maintenance mode.
* Restoring a backup made by an older BackReload now upgrades BackReload's own tables immediately. Oversized upload and migration chunks are rejected before being decompressed.
* Multisite: BackReload is now available only to network admins on the main site. On every other site of the network, network admins get the same BackReload menu, toolbar entry and Settings link as shortcuts that open the main site's BackReload. Before, every sub-site admin could use it, and restoring a backup with plugins would have changed code for the whole network. Site-to-site migration is refused on multisite with a clear explanation, because moving a network to another domain is not supported yet.
* One backup at a time: "Backup now" while a backup is already running (another tab, or a scheduled backup) now shows that backup's progress instead of starting a second one, and a scheduled backup waits 15 minutes for a running one instead of overlapping it.
* If restoring the database signs you out (it replaces the site's users), the Restore page now says so and offers a reload, instead of waiting at 99%.

= 1.0.22 =
* Fixed: a large restore that continued in the background could stay at 99% ("Restore in progress", with the maintenance notice still showing) even though it had actually finished and the site was already back online. Restoring the database replaces the plugin's own log history with the one from the backup, which confused the progress screen's check for the "Restore complete" line. The progress screen now recognises completion reliably, including when the last step finishes within a couple of seconds.

= 1.0.21 =
* The plugin package now includes the full, human-readable source of the admin interface again (the `src/` folder and build configuration), as described in "Source code and build process". It had been left out of the 1.0.20 package by mistake.
* Readme corrections: the FAQ now correctly says restore brings back plugins and themes (and how to opt out), Google Drive and OneDrive are listed under storage destinations, SFTP is described as using the bundled phpseclib library, and a demo video was added.
* No changes to backup, restore, or migration behaviour.

= 1.0.20 =
* Site-to-site migration is more likely to get past a destination's server firewall. The transfer chunks were sent as file uploads, which a server firewall (LiteSpeed / mod_security) inspects much more strictly than ordinary requests - so on some hosts it blocked them with a 403 error while letting the rest of the migration through. Chunks are now sent the same way as the migration handshake that those firewalls already allow (a plain JSON request, not a file upload), which should clear that block. Migrating to a site running an older version still works; the destination accepts both formats.

= 1.0.19 =
* Tested and confirmed compatible with WordPress 7.1. No functional changes - BackReload's admin is a self-contained interface that does not rely on the parts of WordPress 7.1 that changed (the block editor, jQuery UI, or the editor component library), so nothing needed updating for the new version.

= 1.0.18 =
* Fixed fonts (and other assets) still loading from the OLD site after an Elementor migration, which broke the design and could stop tabs and other widgets from working. Elementor keeps its self-hosted Google Fonts stylesheet in a separate folder (uploads/elementor/google-fonts/css) that the migration's URL rewrite wasn't touching, so those font files were still requested from the source domain and blocked by the browser's cross-origin (CORS) rules. The rewrite now covers Elementor's font stylesheets and ElementsKit's cached CSS too, so all builder asset URLs point at the migrated site.

= 1.0.17 =
* Added a one-click way to let incoming site-to-site migrations past the destination site's own firewall. When a source site can't push to a destination because the destination's security (LiteSpeed / mod_security, or a security plugin such as All-In-One WP Security) blocks the transfer with a 406 error, the destination's Migrate > Receive page now shows a notice with an "Allow migrations past this site's firewall" button. It writes a narrow exemption for only the migration and import URLs, immediately checks that the site still loads, and undoes itself automatically if the server rejects it - so it can never leave the site broken. Previously the exemption covered only manual imports, never migration.

= 1.0.16 =
* Fixed site-to-site live migration failing with a firewall "406" error that started in 1.0.15. That release lowered the transfer chunk size, which unintentionally multiplied the number of upload requests (for example 47 instead of 6). Security layers on the destination site (such as All-In-One WP Security) treat that burst of requests as suspicious and start blocking them, so migrations that worked in 1.0.14 stopped working. The chunk size is back to the 1.0.14 value, so live migration works again. The clearer error message added in 1.0.15 (explaining a destination firewall block and how to work around it) is kept.

= Older versions =
The complete history of every earlier version is in changelog.txt, included with the plugin.

== Upgrade Notice ==

= 1.1.0 =
Adds multisite support: whole-network backups in Network Admin, per-site backups and restores, and moving single sites into or out of a network.

= 1.0.23 =
Important fixes: restores no longer stop at "Restoring plugins" or restart on a second click, admins keep access after restore, Plain permalinks work, and a stopped restore can be resumed. Recommended for all users.

= 1.0.22 =
Fixes the restore progress screen getting stuck at 99% after a large restore had already completed.

= 1.0.21 =
Packaging and readme fixes: restores the bundled admin source code and corrects the documentation. No functional changes.

= 1.0.20 =
Improves site-to-site migration through strict destination firewalls (LiteSpeed / mod_security) that were blocking transfer chunks with a 403. Install on BOTH sites.

= 1.0.19 =
Confirmed compatible with WordPress 7.1. No functional changes.

= 1.0.18 =
Fixes Elementor fonts and assets still loading from the old domain after a migration (a cross-origin/CORS failure that broke the design and widgets). Recommended for anyone migrating Elementor sites.

= 1.0.17 =
Adds an opt-in, one-click option on the destination to allow incoming migrations past its own firewall, for site-to-site migrations that fail with a 406 error. Nothing is changed on your server unless you click to enable it.

= 1.0.16 =
Fixes live site-to-site migration breaking with a 406 firewall error introduced in 1.0.15. Recommended for anyone using live migration.

= 1.0.15 =
Large-site restores now resume across host request limits. Fixes a site-wide 500 error on Apache/LiteSpeed + mod_security hosts caused by an auto-written .htaccess block, which is removed on update. Failed migration key checks are now logged with their reason.

= 1.0.14 =
Adds a Dashboard health score and a clear "from -> to" migration summary, and fixes several large-site issues: files silently dropped from a backup, a restored site keeping the original domain when restoring from shared storage, and hardening against tampered import archives.

= 1.0.13 =
Fixes large-site backups sticking at 5-10% and failing before upload: slow dump or archive steps were wrongly treated as crashes. Also adds diagnostics so a genuine failure reports which step died.

= 1.0.12 =
Scheduled backups now run on your site's timezone instead of UTC, and all admin dates display in site time. Existing schedules are corrected automatically. Also fixes percent signs being corrupted in backups - take a fresh backup after updating, as earlier backups already contain that damage.

= 1.0.6 =
Fixes a post-migration "critical error" caused by carrying WordPress cache/database drop-ins across hosts. Also: full site-to-site migration (plugins and themes included), and reliable background auto-restore on WP-Cron-disabled hosts.

= 1.0.3 =
The migration Send page re-attaches to a running migration after a page reload.

= 1.0.2 =
Restore is now data-only (database, uploads, and other content — not plugins, themes, or mu-plugins). All internal names unified under the backreload prefix.

= 1.0.1 =
Updates the bundled phpseclib library to 3.0.55.

= 1.0.0 =
Initial release.
