Back to blog
MagicWP Updates: Portable Backups, and a Platform That Runs Itself
Snapshots move any backup onto any site, dashboard Redirects and cache controls steer traffic, and real server-side cron keeps every site's jobs running on time.
Snapshots move any backup onto any site, dashboard Redirects and cache controls steer traffic, and real server-side cron keeps every site's jobs running on time.
This release is about two things: making your backups portable, and making the platform quietly handle the work you shouldn't have to think about. Snapshots let you take a full backup from one site and drop it onto another, even across regions. Real server-side cron now runs every site's scheduled jobs on a fixed clock instead of waiting for a visitor to show up. In between, there's dashboard-managed Redirects, control over how long pages stay cached, a one-click site Clone, a new Analytics page, temporary phpMyAdmin access, more accurate usage counts, and a redesigned dashboard.
Below is what shipped, why each piece matters, and how to use it.
TL;DR
- Snapshots let you restore any backup onto a different site in a couple of clicks — across regions now too — with an automatic safety backup of the target first.
- One-click Clone copies a whole site (files, database, themes, plugins) into a new one with URLs rewritten for you.
- Real server-side cron runs every site's due jobs every 5 minutes, so scheduled posts publish on time and updates install themselves even on zero-traffic sites.
- Redirects run at the web-server level from the dashboard — pick 301/302/307/308, use regex capture groups, bulk-import by CSV, no plugin needed.
- Page cache expiration control lets you set cache lifetime from 1 hour to 1 year; changing it safely flushes the old cache.
- Plus a new Analytics page, temporary phpMyAdmin, accurate site/storage counts, and a redesigned dashboard.
For a long time, a backup was tied to the site it came from. You could restore it, but only back onto the same site. That's fine for recovery and useless for everything else — cloning a setup you've tuned, rolling a tested configuration out to a second site, or lifting content from one place and dropping it somewhere new. This release breaks that tie.
The new Snapshots page lists every backup across all your sites in one place. From there you can restore any of them onto a different site, not just the one it came from. That's the whole point: a backup becomes a portable object you can move around your account.
A few things make this safe to actually use in practice rather than just in theory:
Cross-location restores are supported too. Earlier, both sites had to sit in the same region for a Snapshot to move between them. Now the two sites can be in different locations, so you can clone, roll out a tested setup, or recover content anywhere in your account regardless of where each site lives.
Typical uses:
If you don't need the flexibility of picking an arbitrary backup, Clone is the direct path. It makes a complete copy of any site — files, database, themes, and plugins — into a brand-new site in one step. You choose the copy's name, domain, region, PHP version, and storage, and the platform rewrites URLs for you so the copy works immediately instead of half-loading with the old domain baked into the database.
That URL rewrite is the part that usually goes wrong in a manual clone. Copying files and a database is straightforward; it's the serialized data in the database — widget settings, page-builder content, options — where a naive find-and-replace corrupts things. Having it handled is the difference between a clone that just works and an afternoon of debugging.
Clone is the natural fit for staging copies and safe testing: make a full copy, break things on it freely, throw it away when you're done. The original never sees any of it.
Snapshots vs. Clone: Use Clone when you want a fresh copy of a site as it is right now. Use Snapshots when you want to move a specific past backup onto another site, or when the source and target already exist and you're restoring into one of them.
The other half of this release is about the platform doing work on its own — reliably, without setup on your side. Most of it centers on a long-standing WordPress weak spot: scheduled tasks.
WordPress ships with its own task scheduler, WP-Cron, and it has a quirk worth understanding. Per the WordPress Plugin Handbook, WP-Cron checks its list of scheduled tasks on every page load and runs whatever is due during that request. It doesn't run on a fixed clock the way a real system cron does — it's only triggered when someone visits the site.
That design exists for a good reason: WordPress has to run on shared hosting where users can't touch the server's scheduler, so tying jobs to page loads is the one mechanism that always works. But it has an obvious failure mode. The Handbook spells it out directly: schedule a task for 2:00 PM, have no page loads until 5:00 PM, and the task doesn't run until 5:00 PM.
For a busy site you rarely notice. For a quiet site — or a heavily cached one, where most requests are served as static pages and never reach PHP — it means scheduled posts publish late, plugin auto-updates sit uninstalled, and cleanup routines pile up. The jobs you most want to run automatically are exactly the ones that quietly don't.
Every site now gets real server-side cron. Due tasks run automatically every 5 minutes, whether the site had a single visitor in that window or none at all. There's no setup on your side — it's on by default for every site.
The practical results:
If you've ever disabled WP-Cron and wired up a system cron by hand — the standard advice for serious sites — this is that, done for you and applied to every site automatically.
Caching is what makes a site fast, but "how long should a cached page stay fresh?" has no single right answer — it depends on how often the content changes. You can now set page cache expiration from 1 hour to 1 year right from the caching page.
The trade-off is simple:
When you change the expiration, the platform safely flushes the existing cache so the new setting applies immediately rather than waiting for old entries to age out. Like every server-level change on the platform, the change is validated before it goes live.
Redirects have always been a slightly awkward thing on WordPress. The usual route is a plugin, which means PHP runs on every request just to decide where to send someone — overhead on a task that a web server can handle far more efficiently. This release moves redirects out of WordPress entirely.
You can now point old paths to new destinations for any site straight from the dashboard. What's on offer:
/old-blog/(.*) → /blog/$1 moves an entire path prefix without writing a rule per URL.Two things worth calling out. First, the rules run at the web-server level — no plugin, no PHP overhead — so redirects are fast and don't add load. Second, every change is validated before it goes live, so a malformed rule can't take your site down. A broken redirect rule loaded blindly is a genuine way to knock a site offline; validating first removes that risk.
A new Analytics page charts your site's resource usage — web, PHP, and database — over time, with one-click ranges from the last hour up to the last 30 days. It's built for answering the questions that used to require guesswork: what happened during that traffic spike, what's actually drawing resources, and how the site behaves under load at a glance. When something feels slow, this is where you look first.
You can now open phpMyAdmin for any site straight from the database page. A private instance spins up on your site's own domain in seconds, stays online for 2 hours, and removes itself automatically. You sign in with your database credentials — the link alone grants nothing, so a stale link left in a browser tab isn't a security hole.
The temporary-by-default design is deliberate. A permanently-exposed database admin tool is a standing risk; one that exists only when you need it and disappears on its own gives you full database access for the occasional manual query, schema check, or targeted fix without leaving an attack surface open the rest of the time.
Your dashboard now shows the correct number of sites used and storage consumed against your plan. Part of this was a real bug: some sites' disk usage was counting internal platform files that didn't belong to them, over-reporting usage by up to roughly 200 MB per site. Storage accounting now counts only your site's actual files, so the number you see is the number that counts against your plan.
A round of smaller fixes and improvements shipped alongside the headline features:
/wp-admin) now reliably redirects to the secure https version every time, including on custom domains. Previously some of these could land without redirecting.Use Clone to make a fresh copy of a site exactly as it is right now — files, database, themes, and plugins — into a new site, with URLs rewritten automatically. Use Snapshots when you want to move a specific past backup onto another site, or when both the source and target sites already exist and you're restoring into one of them. Clone starts from the live site; Snapshots start from a chosen backup.
Restoring a Snapshot onto a target site does overwrite that site's content, but the target is automatically safety-backed-up first. If the result isn't what you wanted, you can roll the target back to exactly how it was before the restore. You also get an email the moment the restore finishes.
No. Real server-side cron is on by default for every site, with no configuration on your side. The platform runs each site's due tasks every 5 minutes automatically, so scheduled posts, plugin updates, and maintenance jobs run on time regardless of traffic. There's nothing to install or wire up.
For most cases, yes. Dashboard Redirects run at the web-server level, so they don't load PHP or WordPress on every request the way a plugin does — they're faster and add no overhead. They also support regex capture groups, status-code selection (301/302/307/308), on/off toggles, and CSV bulk import, and every rule is validated before it goes live so a bad rule can't break the site.
It depends on how often your content changes. Set a longer expiration (up to 1 year) for stable sites that rarely change, so more requests are served from cache. Set a shorter expiration (down to 1 hour) for frequently-updated content like news or an active store, so visitors see fresh pages sooner. Changing the setting safely flushes the existing cache so it applies right away.
The instance is private, runs on your own site's domain, stays online for only 2 hours, and removes itself automatically. The link by itself grants no access — you sign in with your database credentials — so there's no standing, always-open database tool to worry about. It exists when you need it and disappears when you don't.
Some sites' disk usage was including internal platform files that didn't actually belong to the site, over-reporting usage by up to roughly 200 MB. That's fixed — storage accounting now counts only your site's real files, so the figure shown against your plan is accurate.
The theme running through this release is removing work you shouldn't have to do. Portable backups mean a good setup or a clean backup isn't stuck on one site anymore — with Snapshots and one-click Clone, you move it wherever you need it, safely, with a rollback waiting if you need it. Real server-side cron means scheduled posts, updates, and maintenance just happen, on time, without you thinking about traffic. Dashboard Redirects and cache controls give you server-level tools without a plugin, and Analytics, phpMyAdmin, and accurate counts give you a clearer view of what each site is doing.
All of it is on the platform now, nothing to install. If you're already running sites on MagicWP, the Snapshots and Analytics pages are the two new spots worth opening first. If you're weighing a move, this is the kind of managed-hosting groundwork that saves you from bolting the same features on with plugins later.
Monthly engineering notes, product updates, and WordPress performance tips. No spam, unsubscribe anytime.
