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

WordPress backup, restore, and migration. FTP, SFTP, AWS S3, and Wasabi storage. Encrypted, schedulable, and shared-hosting friendly.

== Description ==

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 PHP ssh2 extension when available.
* **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.

= 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? =

No. BackReload restores your database, uploads (media), and other non-code `wp-content` files, but it never deploys plugin, theme, or mu-plugin code into your live site. Full backups still contain those files for off-site safekeeping, but after a restore you reinstall plugins and themes through the normal WordPress installer. This keeps the plugin from ever writing executable code into your site.

= 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), and other non-code 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.0.9 =
* Fixed site-to-site auto-migration failing at the final step on a destination that had itself been migrated before. The destination's Local Storage still held the previous source server's absolute path, so landing the incoming backup failed ("Local Storage path is unusable"). The storage location is now resolved at runtime with the same self-healing fallback used for import.
* Fixed "Storage path is not writable" on import/restore after a migration or host move. The Local Storage destination stored an absolute path, and the migrated database carried the OLD server's path (e.g. a Cloudways /home/<account>/... path) to the new host where it doesn't exist. The plugin now resolves the storage directory at runtime and falls back to this site's real uploads folder (via wp_get_upload_dir), healing the stored path automatically.
* The BackReload admin menu now includes the System page (it was reachable inside the app but missing from the WordPress sidebar submenu).
* Restore and Import now bring back plugins, themes, and mu-plugins too (previously data-only). Uploading or importing a full backup restores the complete site. A data-only build that never deploys code remains available via the BACKRELOAD_DATA_ONLY constant.
* Import now skips plugin/theme parts gracefully instead of failing. Selecting every downloaded part (including plugins-N.zip / themes-N.zip) no longer errors the whole import — the code parts are flagged "not imported" and only the data parts (database, uploads, other content) are brought in. Reinstall plugins/themes through WordPress, or use a site-to-site migration to move them.
* After migrating an Elementor site, stale compiled CSS (built with the old domain) is now cleared so styling — including the header — rebuilds correctly on the destination. This runs only AFTER the dynamic-tag repair from 1.0.6, so the CSS rebuild can't re-trigger the Elementor crash.

= 1.0.6 =
* Site-to-site migration now moves the complete site — plugins, themes, and mu-plugins included — so the destination works immediately after the move (previously the database came across but the plugin/theme files did not). Restoring a backup and importing an archive remain data-only.
* Auto-restore on the destination now runs reliably in the background on sites where WP-Cron is disabled, instead of blocking (and sometimes timing out) the migration's finalize request.
* Added a live restore-progress panel on the destination's Migrate → Receive page, so you can watch an incoming migration restore (download → files → database → URL rewrite) as it happens.
* Fixed a false "migration failed" error where the source's stale-record watchdog marked a long, still-progressing migration as failed.
* Hardened the admin app against optimization/cache plugins that append an HTML comment (e.g. a cache signature) to REST API responses. That trailing text broke JSON parsing and could leave the BackReload screens blank; responses are now salvaged so the UI loads regardless.
* Fixed a critical error ("There has been a critical error on this website") that could appear on the destination after a migration. WordPress drop-ins (object-cache.php, advanced-cache.php, db.php and similar) are tied to the origin server's environment and are no longer carried across — they were loading before the rest of WordPress on a host that couldn't support them and taking down the whole site. Backups skip them and restore ignores any a previous version included; each drop-in's plugin recreates it on activation.
* Migrated sites now always come up on the destination's own domain. Previously the site address could keep the source domain if it was stored in a slightly different form (www vs non-www, a trailing slash, or the opposite scheme) than the search-replace expected; the destination's real siteurl/home are now pinned authoritatively after the URL rewrite.
* Migration is now resilient to caching/optimization plugins on the OTHER site that append an HTML comment to REST responses — the source-to-destination probe, handshake, and finalize calls no longer fail with a confusing "HTTP 200" error. When a destination's REST API is genuinely intercepted (by a "coming soon", security, or cache plugin), the error now explains exactly what to deactivate.
* After a migration restore, the destination's Migrate page no longer shows a phantom "still pushing…" panel or the source site's migration keys. The migration bookkeeping replayed from the source database is now reset so the page reflects the destination itself.
* Added a pre-flight check on the Send page that detects active caching, security/firewall, redirect, and page-builder plugins and advises how to handle them before migrating (including an Elementor "Regenerate CSS" tip).
* URLs stored in encoded form are now migrated too. Page builders keep links inside encoded blobs (Elementor's dynamic-tag settings are URL-encoded JSON, and raw JSON escapes slashes), so a plain search-replace skipped them and those links kept pointing at the old site. The rewrite now also matches the JSON-escaped, URL-encoded, and URL-encoded-JSON shapes of every URL and path.
* Fixed the "There has been a critical error on this website" white screen that could appear on the destination after migrating an Elementor site. Elementor stores dynamic tags whose settings sometimes cannot be parsed; when it rebuilds its CSS (which a move prompts, and add-ons like ElementsKit force on every page load) it passes that unreadable value into code that requires an array and crashes the whole front end. Such tags are already non-functional, so BackReload now normalises them during a migration and the site loads normally. Working tags are left untouched.
* Fixed a critical error on the destination after migrating an Elementor site. BackReload no longer deletes Elementor's compiled CSS after a move — doing so forced Elementor to regenerate CSS on the next visit, which could hit an Elementor-internal crash and white-screen the front end. The compiled CSS is now left in place (as other migration tools do), so the site loads normally after migrating.
* The destination's live restore panel now shows a full activity log and a clear notice that you'll be signed out when the database is restored (sign back in with the source site's login). The migration progress panel also flags when a task stops responding.

= 1.0.3 =
* Fixed site-to-site migrations stalling after the build on sites where WP-Cron is disabled (common with managed hosts and cache plugins). The push now self-continues in the background via a loopback driver — completing even if you close the tab — with the Send page's live status as a fallback.
* The migration Send page now re-attaches to an in-progress migration after a browser reload, so you no longer lose the live progress view while a push is running.
* Fixed Abort not stopping a migration mid-push — the push now honours an abort immediately instead of overwriting it and resuming.
* Fixed database restore failing on migrations between sites with different table prefixes when a plugin table (e.g. All-In-One WP Security's `aiowps_logged_in_users`) confused prefix detection. The source prefix is now detected reliably, so cross-prefix restores complete.

= 1.0.2 =
* Restore is now data-only: BackReload no longer extracts plugins, themes, or mu-plugins into live WordPress paths. Restore, import, and site-to-site migration bring back the database, uploads (media), and other non-code content only. Full backups still capture everything for off-site safekeeping; reinstall plugins and themes through the WordPress installer after restoring.
* Import no longer accepts uploaded plugin, theme, or mu-plugin archive parts.
* Unified all internal identifiers under a single `backreload` prefix (PHP namespace, constants, functions, hooks, options, transients, custom database tables, REST namespace, and the WP-CLI command `wp backreload`).

= 1.0.1 =
* Update the bundled phpseclib library to 3.0.55 (latest stable).

= 1.0.0 =
* Initial release.
* Full-site backup engine with multi-zip splitting and per-category resumption.
* Restore wizard with component picker, source-destination override, and live progress.
* Storage destinations: Local, FTP, SFTP, AWS S3, Wasabi, S3-compatible, Google Drive (OAuth), OneDrive (OAuth).
* Notification channels: email, Slack, Discord, Telegram, Microsoft Teams, Google Chat, Pushover, custom webhook.
* Encryption at rest (AES-256-GCM, PBKDF2 key derivation).
* Site-to-site migration via one-time key: destination generates a key URL, source pastes it and clicks Start. Backup builds, streams direct between the two servers in chunks, and the destination optionally auto-restores. No FTP, no shared cloud storage, no manual download. Works through host upload caps and most WAF / mod_security setups.
* Cross-site migration with URL/path rewrite including inside serialized values. Cross-prefix data fixup ensures admin capabilities survive migrations between sites that use different `$table_prefix` values.
* Cross-server import via shared storage destination (no upload required).
* Sync button to discover backups created by sibling sites on the same destination.
* Maintenance mode with branded "be right back" page that engages automatically during restore.
* Multi-schedule support: combine independent daily/weekly/monthly schedules, each with its own destinations list and retention count.
* Honours the `DISALLOW_FILE_MODS` constant: when file modifications are locked (as on many managed hosts), restoring/importing executable code components (plugins, themes, mu-plugins) is skipped, mirroring WordPress core's own lockout. Database, uploads, and other content still restore.
* WP-CLI command suite: `wp backreload ...`.

== Upgrade Notice ==

= 1.0.9 =
Fixes broken Elementor styling (e.g. an oversized header) after a migration by rebuilding stale CSS for the new domain.

= 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.
