=== AI-SiteArk ===
Contributors: atozinfoway
Tags: backup, restore, migration, clone, database
Requires at least: 6.0
Tested up to: 7.0
Requires PHP: 7.4
Stable tag: 2.9.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Back up, restore and migrate your entire WordPress site — database and files — to local storage or the cloud. Free core, no account needed.

== Description ==

AI-SiteArk backs up your entire WordPress site — the full database and your files — into a single portable archive, and restores or migrates it to the same site or a different domain.

AI-SiteArk is made by AtoZ INFOWAY. The "AI" in the name is our company's initials (AtoZ INFOWAY) — it is not an artificial-intelligence feature.

* Full-site backup (database + uploads/themes/plugins/mu-plugins) as one `.aisv` archive.
* Memory-safe, resumable background jobs — works on large sites and modest hosting.
* Restore and cross-site migration with automatic, serialization-safe URL/path rewriting.
* Optional AES-256 password encryption.
* Per-plugin data backup for AtoZ plugins (e.g. AI-Inquiro).

**Free** includes unlimited manual full-site backups, restore, migration, local storage, and password encryption.

**Pro** adds:
* Scheduled automatic backups with count + age retention.
* Off-site upload to Google Drive, OneDrive, Dropbox, Amazon S3, and FTP/FTPS, with resumable chunked uploads.
* Primary + secondary off-site destinations with failover or send-to-both redundancy.
* Incremental backups — only store files changed since the last full backup.
* Recovery points — an automatic database (and optional files) snapshot taken before every restore, so you can roll back.
* Email and webhook notifications when a backup finishes or fails.
* Role-based access — let non-administrator roles create or fully manage backups.
* Full audit trail — 300-event log with user and IP address.

== Installation ==

1. In your dashboard go to **Plugins → Add New → Upload Plugin**, choose the AI-SiteArk ZIP, and click **Install Now** (or search "AI-SiteArk" in Plugins → Add New).
2. Click **Activate**.
3. Open **AI-SiteArk → Backup** and click **Start backup**. That's it — no account, key or sign-up is required; the free plugin works the moment it's active.
4. To restore or move a site, open the **Restore** tab (or upload a `.aisv` archive taken on another site to migrate it here — URLs are rewritten for you).

== Frequently Asked Questions ==

= Is it really free? =
Yes. Full-site backup, restore and cross-site migration are free and unlimited, with no
account required. AI-SiteArk Pro (a separate add-on) adds scheduling, off-site cloud
destinations, incremental backups, pre-restore recovery points, notifications, role-based
access and the full audit trail.

= Do I need an account or license key to use it? =
No. The free plugin works the moment you activate it. Connecting a free or Pro account is
entirely optional and only unlocks the Pro add-on's features.

= Where are my backups stored? =
On your own server, under wp-content/uploads. Off-site cloud destinations are a Pro feature.

= Can I open a backup without WordPress? =
Yes -- a dependency-free extractor and a standalone recovery installer are included, so your
backups are never locked to the plugin.

== External services ==

AI-SiteArk works fully offline and contacts no external service on its own. It only reaches
out when YOU choose to use a feature that needs it:

* AI-SiteArk Pro licensing (optional): if you connect a free or Pro account, the plugin
  contacts the AtoZ licensing service at https://api.wp.aiappstore.in to verify your email
  and license. Your email address and site URL are sent for this. Terms:
  https://wp.aiappstore.in/ai-mailbridge/terms/ -- Privacy: https://wp.aiappstore.in/ai-mailbridge/privacy/
* Cloud destination sign-in (optional, Pro): if you connect Google Drive, OneDrive or Dropbox,
  authorization is handled through the AtoZ connection broker at https://connect.wp.aiappstore.in.
  No backup content passes through the broker; your files upload directly to your chosen
  provider.

No data is sent anywhere unless you enable one of these optional features.

== Changelog ==

= 2.9.2 =
* Published the plugin icon and banner to the WordPress.org listing. No functional changes.

= 2.9.1 =
* Added the plugin icon and banner for the WordPress.org listing. No functional changes.

= 2.9.0 =
* **Internal renaming for a cleaner, conflict-proof namespace.** Every internal identifier now uses the distinctive `aisiteark_` prefix (options, scheduled tasks, admin actions) and the `AtoZ\SiteArk` PHP namespace, replacing the older short prefix. Your existing settings, schedules, backup history and connections are migrated automatically on update — nothing to do, and your backup files are untouched and fully restorable as before. The WP-CLI command is now `wp aisiteark …` (previously `wp aisv …`). Also corrected the plugin's homepage and author links in the plugin header.

= 2.8.7 =
* **Tamper-proof encrypted backups.** Password-protected backups are now authenticated with a password-keyed signature, not just an ordinary checksum. If even a single byte of an encrypted backup is altered after it was created, the restore refuses it before touching your site — protection an ordinary checksum can't give, because anyone could recompute a plain checksum but not this key-bound one. Existing password-protected backups are unaffected and still restore normally.

= 2.8.6 =
* **Reliable FTP/FTPS off-site uploads.** Backing up to an FTP destination now uploads in resumable, time-limited pieces instead of one long transfer — so a large backup no longer risks timing out, and if a transfer is interrupted it continues from exactly where it stopped instead of starting over. An interrupted upload can never leave a corrupt or truncated file, and the final size is verified before the copy is considered complete.

= 2.8.5 =
* **Dropbox parity + one more safety guard.** Dropbox destinations now support off-site cleanup (old backups are pruned instead of piling up), restoring a backup straight from Dropbox, and the backups-folder README index — matching Google Drive, OneDrive and S3. Also tightened the "restore from a URL" safety check further so it pins the connection to the address it verified, closing a rare DNS-swap trick.

= 2.8.4 =
* **Reliability hardening.** Migrations now rewrite URLs correctly in tables with a combined (multi-column) primary key and in tables with no primary key at all (previously the latter were skipped, leaving old links). Off-site cleanup no longer risks deleting your newest backup when a destination reports no timestamp for it, backups never follow directory symlinks (so nothing outside your site is pulled in), and the database backup reads rows in a stable order so a busy live site can't cause a row to be missed or duplicated. On Google Drive, the backup index file is only ever written inside your own backups folder and never duplicated.

= 2.8.3 =
* **Security hardening.** Closed a potential code-execution path when restoring or migrating a backup that came from an untrusted source (serialized data is now decoded without ever instantiating objects), and tightened the "restore from a URL" safety check so it can't be tricked — via a redirect or an IPv6 address — into reaching an internal/cloud-metadata address. Normal backups, restores and migrations are unaffected.

= 2.8.2 =
* **Reliability fixes for backups and recovery.** A database backup that hit a read error mid-table used to finish as "complete" while silently missing rows — it now stops pretending and clearly marks the backup incomplete so you never trust a partial one. With two off-site destinations set to "send to both", backups now reliably reach BOTH clouds (previously one copy could be missed). Restoring a backup directly from the cloud now works. And restores are protected against a rare timing overlap that could skip files. A handful of per-plugin backup safeguards were also added (never touch WordPress's own core tables or site settings).

= 2.8.0 =
* **New (Pro): a README index inside your backups folder.** AI-SiteArk now keeps a `README.md` file alongside your backups — on this server and in your cloud folder (Google Drive / OneDrive) — that lists every backup with its date, size and what it is, and explains the difference between a full-site `.aisv`, a single-plugin `.aisvp`, and a `.sha256` checksum. It's rebuilt automatically after each backup, so anyone opening the folder can tell at a glance what each file is.

= 2.7.1 =
* **Cleaner Plugin Backups screen.** The page is now organised into three tabs — Back up now, Automatic, and Restore — so you see one task at a time, and the plugin list no longer appears twice on the same screen. Each plugin row shows whether it's active and exactly what a backup will capture, and the whole page now matches the rest of AI-SiteArk.

= 2.7.0 =
* **New (Pro): automatic plugin backups.** The per-plugin backups can now run on their own schedule, just like scheduled full-site backups. Pick the plugins, choose Daily, Weekly, Every-two-weeks or Monthly, optionally include each plugin's own files and upload each backup to your cloud destination, and keep only the newest few per plugin (older automatic ones are cleaned up for you).

= 2.6.1 =
* **Seamless upgrade for sites still on the old "AI-SiteVault" name.** When the plugin was renamed to AI-SiteArk, WordPress treated the new name as a different plugin, so existing installs stopped seeing updates. This release restores the in-place upgrade path: sites running AI-SiteVault now get the update in their dashboard and move to AI-SiteArk without reinstalling — every backup, setting, schedule, cloud connection and license is kept exactly as it was. No functional change to the plugin itself versus 2.6.0.

= 2.6.0 =
* **New (Pro): Plugin Backups — back up any single plugin's settings and data on its own.** Pick any installed plugin and save its configuration (its options and its own database tables) to a portable file, so after a rebuild you can restore that plugin exactly as it was instead of setting everything up again by hand. Back up several at once, optionally send each file straight to your cloud destination, and restore from a saved file or an upload. Each backup is named for the site and plugin (e.g. `example-com-my-plugin-20260812-120000.aisvp`).
* **New (Pro): optionally include a plugin's own files (code) in its backup.** Tick one box and the backup also bundles the plugin's whole folder, so a restore rebuilds the plugin completely — code, settings and data — even on a bare site where the plugin was removed. Off by default (it makes the backup larger); large plugins are guarded by a size limit so a backup never exhausts memory.

= 2.5.0 =
* **Renamed to AI-SiteArk.** Same plugin, clearer name — the "AI" is our company's initials (AtoZ INFOWAY), not an AI-feature claim. Your existing backups, schedules and cloud connections carry over unchanged.
* Backup filenames now include the site's address, so backups from several sites are easy to tell apart.
* Cloud backups are filed into a per-site folder ("AI-SiteArk - <your-site>") on Google Drive and OneDrive, keeping each site's backups separate when an account is shared.

= 2.4.15 =
* **AI-SiteArk can no longer take your site down — whatever goes wrong.** 2.4.14 stopped a *half-installed* copy from crashing a site. This closes the rest of it: if AI-SiteArk ever hits a fatal error while your site is loading — for any reason at all, not just missing files — it now records what happened and switches itself into **safe mode**. From the very next request the plugin loads but runs nothing, so your site stays up, and an admin notice tells you exactly what the error was and how to fix it (reinstall, then deactivate and reactivate to clear safe mode). Anything AI-SiteArk throws while starting is also caught and contained. The worst case AI-SiteArk can now cause is "backups are paused until you reinstall it" — never a site that is down. Safe mode is deliberately limited to errors while the site is loading: a problem inside a backup or restore job fails that job only, and will never silently switch your backups off. A fatal from a *different* plugin never trips it either.

= 2.4.14 =
* **Critical fix — an interrupted update could take the whole site down with a fatal error.** If an update was cut short after WordPress deleted the old plugin folder but before it finished writing the new one (common on shared hosting when the request hits the host's time limit), AI-SiteArk was left half-installed. WordPress only checks that the plugin's *main* file exists, so it loaded the plugin anyway — and the first reference to a missing file threw `Uncaught Error: Class "AtoZ\SiteVault\Helpers\Plan" not found`, which white-screened the **entire site**, front end and admin. AI-SiteArk now checks its own files are present before it does anything: a half-installed copy quietly switches itself off and shows an admin notice telling you to reinstall, instead of crashing your site. Your backups are never affected.
* **Critical fix — updating AI-SiteArk no longer risks half-installing itself.** With "back up before an update" enabled (Pro), updating *AI-SiteArk itself* ran a full site backup first, inside the very same request WordPress then uses to delete and re-extract AI-SiteArk's own folder — so on a host with a hard request limit the update could be killed mid-write, leaving exactly the broken install described above. AI-SiteArk now skips the pre-update backup when the plugin being updated is itself (it holds no site data, and reinstalling restores it). Backups still run before every other plugin, theme and core update, exactly as before.

= 2.4.13 =
* **New (Pro): OneDrive remote retention and restore-from-cloud.** OneDrive backups can now be pruned to your "keep newest N" limit like local and Amazon S3 ones, so off-site storage no longer fills up — and the recurring "OneDrive does not support listing backups yet" note in the activity log is gone. The Restore screen can also list and one-click restore a backup straight from OneDrive. (Uploading to OneDrive already worked; this adds listing, downloading and safe pruning via Microsoft Graph. Only ever prunes the surplus beyond your keep count, and only files AI-SiteArk itself put in its OneDrive backups folder.)

= 2.4.12 =
* **Critical fix — a migration could stall at "Rewriting site URLs…" and leave AI-SiteArk deactivated.** When the site you backed up had AI-SiteArk under a different folder name (e.g. `ai-siteark-1`), importing its list of active plugins dropped AI-SiteArk's real folder — so on the very next request WordPress no longer loaded the plugin, the background worker that finishes a restore couldn't run, and the restore froze near the end. Because it never reached the final step, permalinks weren't set and the plugin stayed switched off with "Plugin file does not exist." AI-SiteArk now keeps itself active under its real folder after **every** step of a restore (not just at the end), so the restore always runs to completion, permalinks are set to "Post name", and the plugin stays active. (The earlier 2.4.10/2.4.11 fixes only took effect at the final step, which this migration never reached.)

= 2.4.11 =
* **Fix — a restore that actually finished could still show "server error 400" and stop short of 100%.** A restore keeps running on the server even if the browser tab's own request is interrupted — a timeout, a server restart, or a brief moment where the page is signed out. When that happened the page showed a scary error and froze near the end, even though the restore had completed. The Restore screen now checks with the server before giving up: if the restore actually finished it shows 100% and success, if it's still working it waits and says so, and only if it truly failed does it show an error — with the real reason.
* **Change — permalinks are always set to "Post name" after a restore.** Migrated sites (especially ones that ran a security or permalink-obfuscation plugin) often carry a custom, hashed permalink structure that breaks pretty URLs — sometimes with a real tag hidden inside the hash, so it slipped past the previous "fix only if broken" check. A restore now always sets the clean, universally understood `/%postname%/` structure, so posts and inner pages just work. (You can still change it afterwards under Settings → Permalinks.)
* **Improved — the restore confirmation is now an in-page dialog, not a browser system popup.** The "REPLACE this site with the backup" confirmation (and the "restore anyway" prompt) now use AI-SiteArk's own styled dialog instead of the browser's plain "<site> says" popup.

= 2.4.10 =
* **Fix — after migrating a site, AI-SiteArk could show as deactivated with "Plugin file does not exist."** If the site you backed up had AI-SiteArk installed in a differently-named folder (for example `ai-siteark-1`, which WordPress creates when a plugin is uploaded twice), that folder name was carried over in the restored list of active plugins. AI-SiteArk deliberately never overwrites or duplicates its own folder during a restore, so that entry pointed at a folder that isn't there — and WordPress switched the plugin off with a "Plugin file does not exist" error. It was always only *this* plugin, because it's the only one a restore skips re-writing. A restore now reconciles that list so AI-SiteArk stays active under the folder it's actually installed in, and any stray duplicate entry is removed. Every other plugin is left exactly as restored.

= 2.4.9 =
* **Critical fix — a cross-site migration could sign you out and stop at "Rewriting site URLs…" with a 400 error.** When restoring a backup taken on a different domain, importing the archive's database briefly set this site's address (`siteurl`/`home`) to the *source* site's URL. WordPress derives the name of your login cookie from that address, so on the very next request the browser's cookie no longer matched, the restore's own request arrived logged-out, and it failed with "The operation could not complete (server error 400)" — typically right at the search-replace step — leaving the site flagged as restoring. AI-SiteArk now keeps this site's address pinned to its real URL for the whole restore, so you stay signed in from start to finish. The migration still rewrites the old URL everywhere else exactly as before. (Same-site restores were unaffected.)

= 2.4.8 =
* **New: "Replace all files" — restore an exact copy instead of a merge.** By default a restore adds and overwrites the files in your backup but leaves anything that isn't in the backup in place (a merge), so a plugin or theme that only exists on the destination survives the restore. The Restore screen now has an opt-in **Replace all files (exact copy)** checkbox: tick it and AI-SiteArk first empties the folders being restored — media uploads, themes, plugins and must-use plugins — so the site ends up an exact copy of the backup, with anything not in the backup removed. It's off by default and clearly marked as irreversible. WordPress core, your stored backups and AI-SiteArk itself are always protected and never deleted, and it respects the "What to restore" selection (ticking only Uploads wipes only uploads). Also available on the command line: `wp aisiteark restore <file> --replace-all`.
* **New: back up the current site before restoring.** The Restore screen has a new opt-in **"Back up the current site before restoring (recommended)"** checkbox. Tick it and AI-SiteArk takes a full backup of the site as it is now, then only starts the restore once that backup has finished — so if the restore goes wrong you can roll straight back. If the safety backup fails, the restore is cancelled and your current site is left untouched. The safety copy appears in your backups list like any other.
* **Fix — a restore no longer leaves broken permalinks that 404.** After restoring a backup whose permalink structure was a custom, "tagless" value (for example a hashed structure like `/{e59df6…}/` left by a security/obfuscation plugin), every post resolved to the same URL and the site returned 404s. AI-SiteArk now detects a restored permalink structure that contains no recognised permalink tag and safely falls back to "Post name" (`/sample-post/`) as the last step of the restore — no need to open Settings → Permalinks by hand. A normal structure (anything with a real tag such as `%postname%`) and a deliberately "Plain" structure are both left exactly as they were.

= 2.4.7 =
* **Fix — "Upload a backup to restore" stuck at 0% on many hosts.** The uploader sent the file in fixed 5 MB chunks, but a great many hosts cap uploads at `upload_max_filesize = 2M`, so the server silently rejected every chunk and the upload never started. AI-SiteArk now sizes each chunk to what the host actually allows (from `upload_max_filesize` / `post_max_size`), so uploading a backup works on tight shared hosting. If a chunk is still refused, the message now names the real reason (the host's upload limit) instead of failing quietly.

= 2.4.6 =
* **Fix — a restore could leave a duplicate copy of AI-SiteArk.** While restoring, the plugin skips its own folder so it can't overwrite itself mid-run — but that skip only matched the exact `ai-siteark` folder. If a backup contained the plugin under a different folder name (for example `ai-siteark-1`, which WordPress creates when a plugin is uploaded twice), the restore extracted it as a *second* copy, so the Plugins screen showed AI-SiteArk twice and deleting one could deactivate the other. The restore now skips every copy of AI-SiteArk — the one actually installed, plus any `ai-siteark-…` variant — so no duplicate is ever created, while all your other plugins still restore normally. (If you already have a duplicate: keep the newer copy, then delete the older `ai-siteark-1` folder — your backups and settings are shared, so nothing is lost.)

= 2.4.5 =
* **Rebuild a dead site with no WordPress — a one-click recovery installer.** Under Help & guide, download the recovery installer, upload it with your `.aisv` backup to a bare server (even one with no WordPress at all), open it in a browser, and enter an empty database and the new address. It imports the database, extracts your files, downloads the matching WordPress core, rewrites every URL for the new location (serialization-safe), and writes a fresh wp-config.php. This is true disaster recovery — the archive is no longer only restorable through a working WordPress. Encrypted and split backups are supported. (Ships as a `.txt` so it can never run by accident inside the plugin; save the download as `aisv-installer.php` on the recovery server, and delete it and the backup when you're done.)

= 2.4.4 =
* **Open a backup without WordPress.** A new `tools/aisv-extract.txt` — a single, dependency-free PHP script — lists and extracts any `.aisv` archive (including encrypted and multi-volume ones) into a plain `database.sql` and a `files/` folder, with no WordPress and no plugin required. Your backups are no longer locked to this plugin. See `docs/DISASTER-RECOVERY.md`.
* **New (Pro): back up right before an update.** Optionally take a full snapshot immediately before a WordPress core, plugin or theme update — the copy you actually want if the update breaks the site. The update waits briefly for the backup, then continues while it finishes in the background.
* **New (Pro): restore straight from the cloud.** The Restore screen now lists the backups on your connected destination, and one click downloads and restores a backup — no manual download-and-re-upload. (Available now for FTP/SFTP and Amazon S3.)
* **New (Pro): remote retention.** Old backups on a cloud destination are pruned to the same "keep newest N" limit as local ones, so off-site storage can't fill up silently.
* **New: slim down the database.** Optionally skip post revisions, transients and spam comments, or exclude whole tables (e.g. analytics/logging) — smaller, faster backups with nothing of value lost.
* **New: disk-space check.** A backup or restore now refuses up front, with a clear message, when there isn't enough free space — instead of failing halfway through.
* **Restores no longer depend on the browser tab.** A restore now continues on the server (via a background worker and WP-Cron) even if you close the tab or lose your connection, and the Restore page gains a "Resume now" button for hosts where background requests are blocked.
* Fix: a single crashed backup job could silently disable automatic (scheduled / after-update) backups; they now self-heal.

= 2.4.3 =
* **Fix — permalinks after a migration.** After restoring a backup taken on another site, WordPress kept the rewrite rules of the *destination* site while using the *restored* site's permalink structure, so posts and inner pages returned 404 until you opened Settings → Permalinks and pressed Save (the step other migration plugins ask you to do). AI-SiteArk now re-reads the restored permalink structure and rebuilds the rewrite rules — and the WordPress block in `.htaccess` — as the final step of every restore. Nothing to do by hand.

= 2.4.2 =
* **Critical fix — a restore stopped near the end with "Backup file not found."** The backups folder is named from the `aisv_backup_secret` option, so the moment a restore imported the archive's options table the folder silently renamed itself to the *source* site's name. The running restore lost both its own progress record and the archive it was reading, so the next step was treated as a brand-new restore and failed. AI-SiteArk now keeps this install's backups folder fixed for the whole restore — the folder belongs to this server, not to the restored content. Most visible when restoring or migrating a backup taken on another site.
* Sites already affected by this (backups and recovery points stranded in an old folder, and seemingly missing from the Restore screen) now repair themselves automatically on the next page load, provided there is exactly one such folder to adopt.
* A restore that loses its progress record now says so plainly, instead of the misleading "Backup file not found."

= 2.4.1 =
* **Critical fix — restore failed with a 503 and left the site in maintenance mode.** Starting a restore wrote WordPress's own `.maintenance` file. Core checks that file before plugins load and exempts nothing — not wp-admin, not `admin-ajax.php` — so every follow-up restore step received a "Briefly unavailable for scheduled maintenance" 503 page instead of JSON. The restore could never get past its first request, and the whole site (including the dashboard) was locked out for 10 minutes. The front end is now closed to visitors by the plugin itself, after WordPress loads, so the dashboard and the restore's own requests are never blocked. Any stale `.maintenance` left by an earlier version is removed when a restore ends or is cleared.
* **Critical fix — a restore could sign you out halfway through and strand itself.** Restoring the database replaces the users tables, which can invalidate the login cookie that authorised the restore (when the backup predates your current session, or holds a different password). The remaining steps then arrived logged-out and the restore stopped one step short of finishing. AI-SiteArk now re-establishes your session against the restored database mid-restore and hands the browser a fresh security token, so the restore runs to completion.

= 2.4.0 =
* New: redesigned off-site Destinations settings — choose a primary and an optional secondary destination, with **Failover** (primary, then secondary) or **Send to both** (upload to both for redundancy) modes.
* New: clear Basic (Free) vs Pro feature tiering with in-app Pro badges and upgrade prompts.
* Free vs Pro gating aligned to the license: incremental backups, recovery points, notifications, role-based access, and the full audit trail are now Pro; manual full-site backup, restore, migration, local storage and encryption stay free.
* Activity log: free plan shows the recent log; Pro shows the full 300-event audit trail with user IP addresses.
* New: a built-in **What’s New** screen — a per-version release history inside the dashboard, with a one-time banner after each update so you never miss a new feature.
* Help & guide refreshed with a plain-English “What’s free, and what’s Pro” overview and the redesigned destinations workflow.
* Restore reliability: an interrupted restore (closed tab, server restart or timeout) now shows a clear message and a one-click “Clear interrupted restore” on the Restore page instead of a stuck, unexplained state; a restore that reads a backup but finds nothing to restore now reports a specific reason instead of silently “completing”; and network/server errors during a restore give an actionable message with recovery steps.
* Modern, consistent admin look across every page — flat cards, status pills, and the AtoZ teal accent.

= 1.0.0 =
First release — full-site backup, restore, migration, scheduling, retention, encryption, and off-site destinations.