Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3555613,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3555613,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["3.2.526","3.2.548","3.2.592","3.2.594","3.2.600","3.2.604","3.2.605","3.2.617","3.2.627","3.2.637","3.2.639","3.2.653","3.2.654","3.2.698","3.2.700","3.2.704","3.2.817"],"block_files":[],"assets_screenshots":{"screenshot-1.jpg":{"filename":"screenshot-1.jpg","revision":3555507,"resolution":"1","location":"assets","locale":"","width":1280,"height":980},"screenshot-2.jpg":{"filename":"screenshot-2.jpg","revision":3555507,"resolution":"2","location":"assets","locale":"","width":1280,"height":790}},"screenshots":{"1":"Schedule and settings panel showing configurable backup interval in days, run-at hour, retention count, folder sizes, and system information including detected backup and restore methods.","2":"Manual backup panel with individual component checkboxes and live progress bar, plus the full backup history table showing stored backups with type badges, age, and Download \/ Restore DB \/ Delete actions."}},"plugin_section":[262246],"plugin_tags":[151,153,1281,152,265189],"plugin_category":[59],"plugin_contributors":[258042],"plugin_business_model":[],"class_list":["post-293223","plugin","type-plugin","status-publish","hentry","plugin_section-dashboard-widgets","plugin_tags-backup","plugin_tags-database","plugin_tags-maintenance-mode","plugin_tags-restore","plugin_tags-scheduled-backup","plugin_category-utilities-and-tools","plugin_contributors-andrewjbaker","plugin_committers-andrewjbaker"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/icon-128x128.png?rev=3555613","icon_2x":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/icon-256x256.png?rev=3555613","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/screenshot-1.jpg?rev=3555507","caption":"Schedule and settings panel showing configurable backup interval in days, run-at hour, retention count, folder sizes, and system information including detected backup and restore methods."},{"src":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/screenshot-2.jpg?rev=3555507","caption":"Manual backup panel with individual component checkboxes and live progress bar, plus the full backup history table showing stored backups with type badges, age, and Download \/ Restore DB \/ Delete actions."}],"raw_content":"\n
Most backup plugins fail exactly when you need them most: on your biggest site, or the site that's grown since you installed them.<\/strong> All-in-One WP Migration's free version caps imports at 512MB (its Unlimited extension costs $69\/year to remove the cap). Duplicator's free version starts failing and timing out around 500MB, with no chunking until you upgrade to Pro. UpdraftPlus has no hard site-size limit, but its free version is restricted to a single cloud storage destination, so you're stuck with whatever free-tier space that one provider gives you.<\/p>\n\n CloudScale Backup & Restore has no site-size limit, no destination limit, and no plan wall.<\/strong> It reads your database in 500-row chunks and never loads the whole thing into memory, so a 50MB site and a 50GB site back up the same way, reliably, without hitting your host's memory limit or execution timeout. It backs up to five destinations at once, for free: Amazon S3, Google Drive, Dropbox, Microsoft OneDrive, and CloudScale's own Managed Cloud Backup, and every destination you enable gets a copy of every backup.<\/p>\n\n Choose any combination, packaged into one Automatic backups are off by default.<\/strong> Run your first backup manually to confirm everything works on your server, then configure a schedule if you need one.<\/p>\n\n Clicking Restore DB opens a confirmation modal that:<\/p>\n\n During restore, WordPress's native Restore any backup into a separate WordPress install on the same server<\/strong>, with its own directory and database, instead of over the live site.<\/p>\n\n This plugin optionally connects to third-party services when those features are configured by the site administrator. No data is sent to any external service unless the administrator has explicitly enabled the relevant integration.<\/p>\n\n When Telegram is configured, the plugin sends backup, restore, and plugin\nrollback notifications, plus error alerts, to the administrator-configured\nTelegram chat via the Telegram Bot API. The message contains the site name,\nevent status, and (for error alerts) a summary of the PHP error, file name,\nand line number. No personal visitor data, post content, or backup data is\ntransmitted. No data is sent unless a Telegram bot token and chat ID have\nbeen entered in the plugin's Notifications settings.\nAPI endpoint contacted: https:\/\/api.telegram.org\/bot{token}\/sendMessage\nTerms of Service: https:\/\/telegram.org\/tos\nPrivacy Policy: https:\/\/telegram.org\/privacy\nTelegram Bot API documentation: https:\/\/core.telegram.org\/bots\/api<\/p>\n\n When S3 settings are configured, the plugin uploads backup zip files directly\nto the administrator's own S3 bucket via the AWS S3 REST API (no external\ntools required). Only the backup zip file is transmitted. Credentials (bucket\nname, access key ID, secret access key, region) are stored in the WordPress\noptions table and are never sent anywhere except to the AWS S3 endpoint.\nAPI endpoint contacted: https:\/\/s3.{region}.amazonaws.com\/\nTerms of Service: https:\/\/aws.amazon.com\/service-terms\/\nPrivacy Policy: https:\/\/aws.amazon.com\/privacy\/<\/p>\n\n When Google Drive settings are configured, the plugin transfers backup zip files\nto the administrator's own Google Drive account using the Google Drive v3 REST\nAPI and OAuth 2.0. No data is sent unless the administrator has completed the\nOAuth authorisation flow (entered a Client ID and Client Secret from Google\nCloud Console and clicked \"Connect to Google Drive\"). Only the backup zip file\nis uploaded. OAuth tokens (access token and refresh token) are stored in the\nWordPress options table.\nAPI endpoint contacted: https:\/\/www.googleapis.com\/ and https:\/\/oauth2.googleapis.com\/\nTerms of Service: https:\/\/policies.google.com\/terms\nPrivacy Policy: https:\/\/policies.google.com\/privacy<\/p>\n\n When Dropbox settings are configured, the plugin transfers backup zip files to\nthe administrator's own Dropbox account using the Dropbox v2 REST API and\nOAuth 2.0. No data is sent unless the administrator has completed the OAuth\nauthorisation flow (entered an App Key and App Secret from the Dropbox App\nConsole and clicked \"Connect to Dropbox\"). Only the backup zip file is\nuploaded. OAuth tokens are stored in the WordPress options table.\nAPI endpoint contacted: https:\/\/api.dropboxapi.com\/ and https:\/\/content.dropboxapi.com\/\nTerms of Service: https:\/\/www.dropbox.com\/terms\nPrivacy Policy: https:\/\/www.dropbox.com\/privacy<\/p>\n\n When OneDrive settings are configured, the plugin transfers backup zip files to\nthe administrator's own Microsoft OneDrive account using the Microsoft Graph\nREST API and OAuth 2.0. No data is sent unless the administrator has completed\nthe OAuth authorisation flow (entered an Azure App Client ID and Client Secret\nand clicked \"Connect to OneDrive\"). Only the backup zip file is uploaded.\nOAuth tokens are stored in the WordPress options table.\nAPI endpoint contacted: https:\/\/graph.microsoft.com\/ and https:\/\/login.microsoftonline.com\/\nTerms of Service: https:\/\/www.microsoft.com\/en-us\/servicesagreement\/\nPrivacy Policy: https:\/\/privacy.microsoft.com\/en-us\/privacystatement<\/p>\n\n When the administrator subscribes to the optional CloudScale Managed Cloud Backup\nservice, the plugin contacts the CloudScale broker to request a short-lived,\nprefix-scoped Amazon S3 access token, then uploads backup zip files directly to\nCloudScale's managed S3 storage (hosted in the EU, eu-west-1). Only the site's\ndomain name, the subscription licence key, and the backup zip file are involved;\nthe backup bytes are uploaded straight to S3 and do not pass through the broker.\nNo data is sent unless the administrator has subscribed and entered a licence key.\nAPI endpoint contacted: https:\/\/api.cloudscale.consulting\/ (broker) and\nhttps:\/\/cloudscale-backup-restore-global.s3.eu-west-1.amazonaws.com\/ (storage)\nTerms of Service: https:\/\/cloudscale.consulting\/terms\nPrivacy Policy: https:\/\/cloudscale.consulting\/privacy<\/p>\n\n Subscription payments for the optional CloudScale Managed Cloud Backup service are\nprocessed by PayPal. Payment details are entered on PayPal's own hosted checkout\npage and are never collected, stored, or transmitted by this plugin. When the\nadministrator starts a subscription, the subscriber's email address and a PayPal\norder amount ($5.00 USD) are sent directly from the WordPress server to the PayPal\nREST API (api-m.paypal.com) to create a checkout session; no payment-card data is\nhandled by the plugin or the WordPress site. No data is sent unless the administrator\nchooses to subscribe to the paid service.\nAPI endpoint contacted: https:\/\/api-m.paypal.com\/ (live) or\nhttps:\/\/api-m.sandbox.paypal.com\/ (sandbox testing)\nBrowser-loaded script: https:\/\/www.paypal.com\/sdk\/js - PayPal's JavaScript SDK, loaded\ninto the plugin's admin screen only after an administrator opens the subscription\ncheckout. PayPal requires the SDK be served from its own origin so a compromised build\ncan be revoked, so it cannot be bundled with the plugin.\nTerms of Service: https:\/\/www.paypal.com\/us\/legalhub\/useragreement-full\nPrivacy Policy: https:\/\/www.paypal.com\/us\/legalhub\/privacy-full<\/p>\n\n When the AMI snapshot feature is used, the plugin reads instance metadata\n(instance ID and region) from the local EC2 Instance Metadata Service at\nhttp:\/\/169.254.169.254. This address is only reachable from within an EC2\ninstance and no data leaves the server at this step. AMI creation, status poll,\nderegister, and snapshot delete requests are then issued directly to the AWS\nEC2 REST API (no external tools required). The same AWS credentials\n(access key ID and secret key) used for S3 are used; if none are configured\nthe plugin attempts to use the EC2 instance role via IMDS.\nAPI endpoint contacted: https:\/\/ec2.{region}.amazonaws.com\/\nTerms of Service: https:\/\/aws.amazon.com\/service-terms\/\nPrivacy Policy: https:\/\/aws.amazon.com\/privacy\/<\/p>\n\n When Automatic Crash Recovery is enabled, the plugin periodically sends an HTTP\nrequest to the administrator-configured health check URL to verify the site is\nresponding. The URL defaults to the site's own home URL. No personal data is\ntransmitted. The request is a plain GET with no authentication payload. The\nsame probe is made when the administrator clicks \"Test Health Check\" in the\nplugin settings. If a system-cron watchdog script is installed on the server,\nthat script also probes this URL independently via curl. The health check URL\nis set by the administrator and is never shared with any third party.\nNo Terms of Service or Privacy Policy apply (the request goes to a URL you own).<\/p>\n\n CloudScale Backup & Restore does not collect, transmit, or store any personal data. All backups are stored locally in the Option 1: WordPress admin (recommended)<\/strong><\/p>\n\n Option 2: Manual via FTP\/SFTP<\/strong><\/p>\n\n In a dedicated No. The plugin sets PHP 8.1 or higher. The plugin uses typed parameters, Yes. The The plugin registers a custom WordPress cron interval based on the number of days you configure. For reliable scheduling, your server should have a real system cron job pointing at Yes. The restore function extracts Yes. The restore imports the SQL as-is. If the database contains hardcoded URLs from the old domain, run a search-replace using WP-CLI after restoring:<\/p>\n\n Install WordPress and this plugin on the second server, then open the Standby & DR tab there (never on the live site). Choose a hot standby or a refreshed copy, label its alerts, type MAKE THIS A COPY and press Apply. Then on the Automated Restore tab connect the cloud storage the live site backs up to, choose the folder or site to copy from, and switch on the schedule. The checklist on the Standby & DR tab shows anything still missing. A hot standby also needs something outside WordPress to move your DNS and to tell the standby when it is serving; the help site and the plugin's GitHub repository describe a Cloudflare script that does the DNS half.<\/p><\/dd>\n Create the target first: an empty directory the web server can write to, containing a The plugin removes maintenance mode even when a restore fails, so your site will be accessible. Check the plugin page to confirm the maintenance badge is gone. Errors are logged to your server's PHP error log. If the database is in a partial state, restore from a server snapshot or use phpMyAdmin or Adminer to assess the database directly.<\/p><\/dd>\n Yes. Use WP-CLI to trigger a backup from the command line:<\/p>\n\n Adjust the four boolean arguments ( Each zip may contain:<\/p>\n\n Yes. Run a full backup on the old site, install WordPress on the new host, install and activate this plugin, then use Restore from Upload to import the database. Copy the The Automatic Crash Recovery feature writes a single file outside the plugin\nfolder when it is enabled: The file is written using the WordPress Filesystem API (WP_Filesystem). It is\nonly written when the feature is enabled, only overwritten if it was written by\nthis plugin (identified by an internal marker), and is deleted when the feature\nis disabled or the plugin is uninstalled. No personal data is stored in this file.<\/p>\n\n The plugin also writes the following, all of which are removed on uninstall:<\/p>\n\n No personal data is stored in any of these files beyond what the site itself already\nholds.<\/p><\/dd>\n\n<\/dl>\n\n\nAny Size, No Limits<\/h4>\n\n
\n
$wpdb<\/code>; never loads the full database into memory, regardless of size<\/li>\nset_time_limit(0)<\/code> and ignore_user_abort(true)<\/code> on every backup and restore, so PHP's execution-time limit never cuts a large operation off mid-run<\/li>\nINSERT<\/code> statements, on files of any size<\/li>\nBack Up to Five Destinations at Once<\/h4>\n\n
\n
What It Backs Up<\/h4>\n\n
.zip<\/code> with a descriptive filename (for example backup_db-media-plugins_2026-02-21_09-10-00.zip<\/code>) that reflects exactly what it contains:<\/p>\n\n\n
\/wp-content\/uploads\/<\/code>)<\/li>\n\/wp-content\/plugins\/<\/code>)<\/li>\n\/wp-content\/themes\/<\/code>)<\/li>\nphp.ini<\/code>, robots.txt<\/code>, favicon, .well-known\/<\/code>, and search-engine verification files<\/li>\nbackup-meta.json<\/code>: plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were included, so you can verify a backup without restoring it<\/li>\n<\/ul>\n\nRestore Safely<\/h4>\n\n
\n
.maintenance<\/code> file is created so visitors see the standard maintenance page. It is always removed when restore finishes, whether the restore succeeded or failed. The plugin header shows a live badge indicating whether the site is online or in maintenance mode.<\/p>\n\nDisaster Recovery<\/h4>\n\n
\n
tools\/cloudflare-failover.sh<\/code> in the plugin's GitHub repository polls the primary, repoints one DNS record at the standby after three consecutive failures, and points it back after ten consecutive clean probes. Every failback prints a reconcile reminder, because work done on the standby while it served exists nowhere else and the standby's next refresh erases it. Not included in this zip, which carries no shell scripts<\/li>\nClone to a Staging Site<\/h4>\n\n
\n
wp-config.php<\/code>, then press Clone Now. URLs are rewritten everywhere, including serialized data and JSON<\/li>\ncsbr_clone_post_restore<\/code> action instead<\/li>\nSecurity<\/h4>\n\n
\n
.htaccess<\/code> syntaxes), nginx, IIS (web.config<\/code>), and a silent index.php<\/code>, plus 0700<\/code> permissions, not just an .htaccess<\/code> that nginx and IIS ignore<\/li>\nDeveloper & Automation<\/h4>\n\n
\n
.zip<\/code> or .sql<\/code> file, on the same host or a new one<\/li>\n<\/ul>\n\nExternal services<\/h3>\n\n
Telegram Bot API (optional notifications)<\/h4>\n\n
Amazon S3 (optional cloud backup)<\/h4>\n\n
Google Drive (optional cloud backup)<\/h4>\n\n
Dropbox (optional cloud backup)<\/h4>\n\n
Microsoft OneDrive (optional cloud backup)<\/h4>\n\n
CloudScale Managed Cloud Backup (optional, paid service)<\/h4>\n\n
PayPal (optional, payment for Managed Cloud Backup)<\/h4>\n\n
AWS EC2 \/ AMI snapshots (optional, AMI snapshot feature only)<\/h4>\n\n
Automatic Crash Recovery: health check probe (optional)<\/h4>\n\n
Privacy Policy<\/h3>\n\n
cloudscale-backups\/<\/code> folder inside your WordPress uploads directory. No telemetry or analytics are sent by this plugin. Optional cloud backup features (S3, Google Drive, Dropbox, OneDrive, AMI snapshots) transmit data only when explicitly configured by the site administrator. See the External services section above.<\/p>\n\n\n\n
cloudscale-backup.zip<\/code><\/li>\n\n
cloudscale-backup.zip<\/code><\/li>\ncloudscale-backup<\/code> folder to \/wp-content\/plugins\/<\/code><\/li>\n\n
Where are backups stored?<\/h3><\/dt>\n
cloudscale-backups\/<\/code> folder inside your WordPress uploads directory. This folder is created automatically on activation and protected with an .htaccess<\/code> deny-all rule. Download backups using the Download button in the admin panel, which uses a nonce-secured handler.<\/p><\/dd>\nWill it time out on large sites?<\/h3><\/dt>\n
set_time_limit(0)<\/code> and ignore_user_abort(true)<\/code> for all backup and restore operations. The PHP streaming implementation reads data in small chunks so memory usage stays flat regardless of database size. Check the System Info card for details about your server's configuration.<\/p><\/dd>\nWhat PHP version is required?<\/h3><\/dt>\n
match<\/code> expressions, str_contains()<\/code>, and first-class callable syntax introduced in PHP 8.0\/8.1.<\/p><\/dd>\nIs ZipArchive required?<\/h3><\/dt>\n
ZipArchive<\/code> extension is needed to create and read backup zip files. It is bundled with PHP on the vast majority of shared hosting environments. If it is missing, contact your host and ask them to enable the zip<\/code> PHP extension.<\/p><\/dd>\nHow does the scheduling work?<\/h3><\/dt>\n
wp-cron.php<\/code> rather than relying on WordPress's visitor-triggered pseudo-cron. Most managed WordPress hosts configure this automatically. Your server's current time and timezone are shown on the settings page so you can pick the right hour.<\/p><\/dd>\nCan I restore just the database and keep my current media?<\/h3><\/dt>\n
database.sql<\/code> from the backup zip and imports it. Media, plugin, and theme files inside the zip are not automatically restored. You can unzip the backup manually and extract only the folders you need. This prevents accidentally overwriting files you have added since the backup.<\/p><\/dd>\nCan I restore on a different server or after a domain change?<\/h3><\/dt>\n
wp search-replace 'olddomain.com' 'newdomain.com' --path=\/path\/to\/wordpress\n<\/code><\/pre><\/dd>\nHow do I set up a standby or disaster-recovery copy of my site?<\/h3><\/dt>\n
How do I clone my site to a staging copy on the same server?<\/h3><\/dt>\n
wp-config.php<\/code> that names an empty database (or one your database user can create). Take a backup that includes WordPress core files. Then open the Clone Targets tab, add a target with that directory, the URL it will be served from and the path to that wp-config.php<\/code>, press Verify, and press Clone Now. The target's files and database are replaced by the backup and every URL is rewritten. The plugin refuses if the target is this site's own directory or database, or a directory that contains this site. Point your web server or hosting panel at the new directory to view it. The wp-config.php<\/code> must contain literal database values: one that reads them from environment variables cannot be used, and the plugin says so. Cloning needs the PHP mysqli<\/code> extension, and the database user named in that wp-config.php<\/code> must be able to create the database, or the database must already exist. Clone Now names the directory and database it will overwrite and asks first, because everything in the target is replaced and that cannot be undone. You can also refresh a target automatically after each scheduled backup, on the days you choose, and hook the csbr_clone_post_restore<\/code> PHP action to run your own steps afterwards: the clone itself runs no shell scripts. A clone is a complete copy, including your mail settings and scheduled tasks, and nothing in it blocks outgoing email, so block email on it before you browse it.<\/p><\/dd>\nThe restore failed. Is the site broken?<\/h3><\/dt>\n
Can I trigger a backup from WP-CLI or a system cron job?<\/h3><\/dt>\n
wp eval 'csbr_create_backup(true, true, true, true); csbr_enforce_retention();' --path=\/path\/to\/wordpress\n<\/code><\/pre>\n\n$include_db<\/code>, $include_media<\/code>, $include_plugins<\/code>, $include_themes<\/code>) as needed.<\/p><\/dd>\nWhat is inside the backup zip?<\/h3><\/dt>\n
\n
database.sql<\/code>: complete SQL dump of all WordPress tables<\/li>\nuploads\/<\/code>: full media uploads directory tree<\/li>\nplugins\/<\/code>: full plugins directory tree<\/li>\nthemes\/<\/code>: full themes directory tree<\/li>\nbackup-meta.json<\/code>: metadata including plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were backed up<\/li>\n<\/ul><\/dd>\nCan I use this to migrate my site to a new host?<\/h3><\/dt>\n
uploads\/<\/code>, plugins\/<\/code>, and themes\/<\/code> folders manually from the zip if needed, or use the backup of those folders.<\/p><\/dd>\nWhat files does the plugin write outside its own folder?<\/h3><\/dt>\n
wp-content\/fatal-error-handler.php<\/code>. This is a\nWordPress-recognised drop-in file (documented in the WordPress Developer\nHandbook under get_dropins()<\/code>). WordPress core checks for this file on every\nrequest; if present, it replaces the default fatal-error screen with a custom\nhandler. The plugin uses this mechanism to show a branded recovery page to\nvisitors while a crash is being fixed, instead of a blank white screen.<\/p>\n\n\n
wp-content\/uploads\/cloudscale-backup-<random>\/<\/code> - the backup archives themselves,\nplus an .htaccess<\/code>, a web.config<\/code> and an index.php<\/code> that block public access to\nthem. The directory name carries a per-site random token because a fixed, guessable\nname meant sequentially-named archives could be downloaded by anyone who guessed a\nfilename.<\/li>\nwp-content\/csbr-secrets.php<\/code> - cloud storage credentials, the licence key and the\nbackup encryption password, held outside the database so they are not carried inside\nthe database dumps this plugin creates. It begins with a PHP exit guard so it cannot\nbe read over HTTP, is written 0600<\/code>, and is excluded from every backup. A lock file\nand a short-lived temporary file sit alongside it during a write.<\/li>\nwp-content\/cloudscale-backup-par.json<\/code> - the Automatic Crash Recovery state file,\nrecording which plugins are being monitored.<\/li>\nwp-content\/csbr-state\/csbr-auto-restore.json<\/code> - on a standby site only, the automatic\nrestore schedule and the source it pulls from. The directory carries the same deny-all\nrules as the backup directory, so the file is not readable over HTTP. Installs upgrading\nfrom an earlier version have their existing wp-content\/csbr-auto-restore.json<\/code> moved\nhere automatically.<\/li>\n<WordPress root>\/.maintenance<\/code> - WordPress's own maintenance-mode file, written only\nwhile a restore is running and removed when it finishes or fails. This is the\nmechanism WordPress itself uses during core updates.<\/li>\nwp-content\/csbr-state\/plugin-auto-recovery\/<\/code> - Automatic Crash Recovery only: a copy of\na plugin taken just before WordPress updates it, so a bad update can be rolled back. It is\nremoved when the monitoring window closes and otherwise after 72 hours, and on uninstall.\nIt sits outside the uploads folder because it holds PHP, and it carries deny rules.<\/li>\nwp-config.php<\/code> the administrator named) is written into the directory the\nadministrator chose for that target, which is normally outside wp-content<\/code>, and the\ntables in that target's own database are dropped and recreated. It never writes to this\nsite's own directory, and no script is generated or run. The target list is stored in\nthe csbr_clone_targets<\/code> option.<\/li>\n<\/ul>\n\n3.2.817<\/h4>\n\n
\n
3.2.816<\/h4>\n\n
\n
3.2.815<\/h4>\n\n
\n
wp plugin update --all<\/code> left every plugin in the batch without a copy to roll back to, and the log said \"No pre-update backup found\". Both now get a copy and the same post-update monitoring as a single update.<\/li>\n<\/ul>\n\n3.2.814<\/h4>\n\n
\n
&<\/code> instead of &<\/code>, so when PayPal sent the buyer back the plugin could not find the order and quietly did nothing. The link is now built correctly and a return with a missing or expired security token is logged, with \"Recover licence\" as the way out.<\/li>\n<\/ul>\n\n3.2.813<\/h4>\n\n
\n
wp-content\/csbr-state\/<\/code>, outside uploads, with deny rules. Rolling back works exactly as before, and copies taken by earlier versions are still used and are cleared by the same 72-hour sweep.<\/li>\n<\/ul>\n\n3.2.812<\/h4>\n\n
\n
csbr_clone_post_restore<\/code> PHP action for steps to run after a clone. The clone runs no shell scripts.<\/li>\n<\/ul>\n\n3.2.809<\/h4>\n\n
\n
3.2.806<\/h4>\n\n
\n
3.2.805<\/h4>\n\n
\n
3.2.804<\/h4>\n\n
\n
3.2.803<\/h4>\n\n
\n
3.2.802<\/h4>\n\n
\n
3.2.801<\/h4>\n\n
\n
3.2.800<\/h4>\n\n
\n