Documentation

Requirements

Without ZipArchive the plugin cannot write an archive at all, and there is no setting that works around it. Ask your host to enable it.

Installing

SitesSaver is not listed on the wordpress.org plugin directory, so it installs as an uploaded plugin.

1. Download the ZIP from the releases page.
2. In wp-admin, open Plugins › Add New › Upload Plugin.
3. Choose the ZIP, install, then activate.

Alternatively, copy the folder into wp-content/plugins/sitessaver/ and activate from the Plugins screen. There is no build step.

After activation a SitesSaver menu appears in the sidebar with Export, Import, Backups, Schedule, Settings, and Help.

Making a backup

Open Export, choose what to include, and click Create Backup. The plugin packages the database and your files into one ZIP. Large sites are processed in chunks rather than held in memory, so there is no file size at which it stops working.

When it finishes, the archive appears on the Backups page where you can label it, download it, or delete it. Give real labels to the ones that matter, for example before theme switch, because a list of timestamps tells you nothing six weeks later.

Restoring

Open Import. Drag the backup ZIP into the drop area, or click to pick the file, then run the restore. You can also restore an archive already on the server from the Backups page.

Restoring from Google Drive

On the Backups page, scroll to the Google Drive Backups section and choose Restore on the file you want. It downloads and restores in one step, and the downloaded copy stays on your server afterwards.

Moving to a new domain

Export on the old site, install WordPress and SitesSaver on the new one, and import the archive there. URLs are rewritten during the restore in the places they hide:

• options, post content, post meta, and widget data
• inside serialized arrays and objects, with string lengths recalculated, so the data does not corrupt the way a plain search-and-replace corrupts it
• nested serialized structures, which are a common source of broken sliders and page-builder layouts after a migration
• hardcoded URLs inside plugin and theme source files
• cross-scheme moves, so http to https does not leave broken image references

Scheduling

Open Schedule and enable automatic backups. Frequency is a set of checkboxes rather than a dropdown, and each ticked frequency runs on its own independent timer. Daily plus Monthly is a normal configuration: recent restore points alongside a long-term archive.

You also decide where each run is stored: on the server, on Google Drive, or both.

Use Run backup now to perform a real scheduled backup immediately with your saved settings. It is the fastest way to find out whether the destination and the notification email actually work, instead of discovering it at 3am on a Sunday.

Server cron, when WP-Cron is not enough

WP-Cron is not a real scheduler. It fires when someone loads a page, so a quiet site runs hours or days late, and a site with DISABLE_WP_CRON in wp-config.php never runs a scheduled backup at all.

The Schedule page has a Server Cron panel with a private trigger URL and ready-made crontab, curl, and WP-CLI lines. A typical crontab entry looks like this:

*/15 * * * * curl -fsS "https://example.com/?sitessaver_cron=YOUR_PRIVATE_KEY" >/dev/null

No shell access? Point a free uptime monitor at the same URL. It is safe to call more often than your chosen frequency, because SitesSaver answers "not due yet" until a backup is genuinely owed.

Retention

Retention controls how many backups stay on your server. After each scheduled run, anything beyond that count is deleted oldest first, so the disk does not fill up.

Google Drive

1. Open Settings and click Connect Google Drive.
2. Authorise with your Google account.
3. SitesSaver creates its own folder in your Drive and uses only that folder.
4. In Schedule, choose to store backups locally, on Drive, or both.

A backup that exists only on the server it is protecting will not help you when that server is the thing that fails. If you configure nothing else, configure this.

Email reports

Enter an address in the Email Notification field on the Schedule page to get a report after every scheduled run. The report states which schedule fired, which file was created and how big it is, what the archive contains, whether the copy was kept locally or uploaded to Drive, the retention policy, and when the next run is due.

A failed backup and a successful backup whose Drive upload failed are reported differently, and neither is reported as plain success. That distinction is the whole point of the email.

Branding the reports

Settings › Email Branding sets your logo, an accent colour, the sender name and address, an optional support link, and a footer note. Send test email saves your changes and delivers a real sample through the same renderer a live report uses. Untick branded HTML if you prefer plain text; a text version is always included either way.

Use a sender address on your own domain, such as [email protected]. An address from another domain is far more likely to be filtered as spam.

Where backups live

In wp-content/sitessaver-backups/, deliberately outside the plugin folder so that updating or reinstalling SitesSaver can never delete them. The folder is protected from direct download by a generated .htaccess rule.

location ^~ /wp-content/sitessaver-backups/ {
    deny all;
    return 403;
}

Updates

Although the plugin is installed manually, it still updates itself. It checks for new releases automatically, and when one exists the update appears on your Plugins screen like any other plugin. Click Update and you are done.

Your backups, schedule, Drive connection, and email branding all survive an update. Settings › Plugin Updates shows the version you are running and a button to check immediately rather than waiting for the next automatic check.

Forks and private mirrors

The release repository is fixed in the build, not a user setting. If you fork the plugin, point it at your own repository in code:

add_filter('sitessaver_update_config', function (array $config): array {
    $config['repo']  = 'your-org/your-fork';
    $config['token'] = 'github_pat_...';   // private repositories only
    return $config;
});

The sitessaver_update_source option works too, for setups that prefer WP-CLI or a mu-plugin. Automatic updates function against a private repository, because the token is sent on both the release lookup and the asset download.

Troubleshooting

Scheduled backups never run

Almost always WP-Cron. See Server cron, and confirm with Run backup now that the schedule itself is sound.

The backup fails partway through

Usually disk space or a PHP time limit on a shared host. Check the free space on the account first, since the archive needs roughly the size of your site. Excluding large directories you can rebuild, such as caches, also helps.

Images are broken after a restore

Visit Settings › Permalinks once to flush rewrite rules. If the site moved from http to https, that case is handled during restore, so a remaining problem is more likely a CDN or a page-builder cache still holding old URLs. Clear those caches.

A Google Drive upload fails

Reconnect the account in Settings; a revoked or expired authorisation is the common cause. The notification email states the reason the upload failed rather than reporting success.

Something else

Open an issue on the issue tracker, or email [email protected]. Include your PHP version, WordPress version, and whether the host runs Apache or Nginx.

Uninstalling

Deactivating the plugin stops the schedule. Deleting it removes the plugin and its settings. Your archives in wp-content/sitessaver-backups/ are not part of the plugin folder, so check that directory yourself if you want the disk space back.